Since realize does a lot of the heavy lifting of setting up
csd, we have to re-realize the window if we go from no-custom
titlebar to a custom titlebar or vice versa.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
When gtk_window_set_titlebar is called, we need to set up
client-side decorations properly, and the easiest way to do
so is to realize the window again. Really, you should call
set_titlebar before the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
GtkWindow has 4 (!) APIs for setting window icons, and we
have to try them all in the right order to find the right
icon. This commit makes it so, and keeps the icon list
manipulation inside gtkwindow.c by adding a private API
for getting a single icon at the right size.
https://bugzilla.gnome.org/show_bug.cgi?id=722515
When all popovers are removed on destroy(), if a popover is nested into
(eg. with relative_to within) another popover, the removal of one can
lead to the other being removed while the hashtable is being iterated,
which would lead to undefined behavior in further iterations.
Then, use a GList to store popovers, iterating can be made more resilient
on these situations, and unless on pathological cases there's not going
to be as many of those popovers as to cause performance decreases at the
times those are iterated.
The popovers may return keyboard grabs to previous widgets, so if
called after unsetting the focus, the window may be left with a
dangling GtkWidget that would cause crash at later dispose() calls.
Popovers are strange in the sense that they aren't attached to a
parent directly, they rely on the relative_to widget so the toplevel
is shared, and when they have a parent, it is the toplevel itself,
not relative_to. This also means that there are conditions where the
popover loses it's parent, so they must survive unparenting.
The previous code would be floating the last reference as soon as the
parent is gone, but it was non-obvious who'd own that reference. So
fix this situation by granting the ownership of popovers to their
relative_to widget, an extra reference may be held by the toplevel
when the popover has a parent, but the popover object will be
guaranteed to be alive as long as the parent lives.
This way, memory management of popovers is as hidden from the user
as regular widgets within containers are, users are free to call
gtk_widget_destroy() on a popover, but it'd eventually become
destructed when relative_to is.
This makes it possible to move/resize client-side decorated windows that are
otherwise obscured by a GTK+ grab somewhere else, either a popover within the
window itself or a modal dialog above the window.
Popovers are transient floating widgets that are confined to the
window space. These have their own GdkWindow that is set on top
of the regular window contents, so they can be used for popup menu
alike UIs with custom popup/popdown/grabs behavior.
With proper notifications, plus an accessor method for that state. This
allows client to just listen to notify::is-maximized instead of tracking
window-state-event.
https://bugzilla.gnome.org/show_bug.cgi?id=698786
This leads to disastruous results, since each menu is itself
in a GtkWindow, so holding down the menu key leads to a neverending
cascade of menus on top of menus.
https://bugzilla.gnome.org/show_bug.cgi?id=722106
The window-dragging code had a number of issues: The code was
starting a drag on every button press, never bothering to cancel
them. This leads to the odd hand cursor occurring between the two
clicks to maximize. We relied on GDK's multi-click detection, which
gives us triple-clicks when we really want sequences of double-clicks.
Lastly, we didn't propery restrict double-click handling to the primary
button, so e.g. if you had a window on an empty workspace, double-right
click on the titlebar would maximize it, which is not intended.
This commit solves all three problem by a doing our own double-click
detection, and only starting a drag when the pointer goes out of
'double-click range'. We change the way dragging is implemented for
menubars and toolbars to just letting events bubble up, so they
get the same behaviour as the titlebar. To make this work, we
have to select for pointer motion events in a few more places.
gtkapplication.c has turned into a bit of an #ifdef mess over time, and
many of the current checks are incorrect. As an example, if you build
Gtk for wayland, and exclude the X11 backend, much of the functionality
required by wayland (such as exporting menu models) will be disabled.
Solve that by introducing a backend mechanism to GtkApplication (named
GtkApplicationImpl) similar to the one in GApplication. Add backends
for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
'DBus' superclass.
GtkApplicationImpl
|
/--------------+-------------------\
| |
GtkApplicationImplDBus GtkApplicationImplQuartz
|
/-----------+-----------------\
| |
GtkApplicationImplX11 GtkApplicationImplWayland
GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
hooks for various things that the platform-specific backends may be
interested in doing (startup, shutdown, managing windows, inhibit, etc.)
With this change, all platform specific code has been removed from
gtkapplication.c and gtkapplicationwindow.c (both of which are now free
of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
gtkapplicationwindow.c).
Additionally, because of the movement of the property-setting code out
of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
friends) will be set on non-GtkApplicationWindows, such as dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=720550
We don't want the maximum size to be smaller than the minimum size. Not
just because it's wrong but also because when this happens the rest of
GTK gets mighty confused and infloops resizing to min-size and
max-size in turns causing a flickering window. Well, at least if you
run X without a window manager. Or your window manager hasn't finished
starting up.
Private RHEL bug finding this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1035409
Both GtkApplicationWindow and GtkHeaderBar listen for changes
of the gtk-shell-shows-app-menu setting, so they need to somehow
coordinate who is going to take action and show a fallback.
We prefer the menu button in the title over the menubar, so
let GtkApplicationWindow opt out if it finds that the header bar
has been configured to show window controls.
And deprecate the X11-specific version of it.
We call this new API _set_shadow_width() and not _set_frame_extents()
because we already have a gdk_window_get_frame_extents() with a
different meaning and different type of value.
https://bugzilla.gnome.org/show_bug.cgi?id=720374
When setting a custom titlebar that happens to be a GtkHeaderBar,
we connect to notify::title to pick up title changes on the headerbar,
but we forgot to sync the title initially. Fix that.
Win32 does not have alpha channel currently ; fix the check
for this, so trying to enable CSDs on this platform will
not "succeed" and crash the app anymore.
Partially fixes gtk3-widget-factory.
Instead, use the monitor's work area.
This might have unforseen side effects that warrant a later revert, such
as:
- Apparently some WMs assume maximizing when a window is maximum screen
size.
- WMs might not shrink the window by the decorations' size when it tries
to be fullscreen.
- Applications might have buggy size request code that causes weirdly
sized windows.
Do the menubutton for app menu fallback ourselves in GtkWindow
for the csd, non-custom titlebar case. This fits better with
the way we handle other title buttons. Themes have control
over the placement of this button by placing menu in the
decoration-button-layout style property.
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Previously, GtkWindow would add the "app" action group to its own
toplevel muxer.
Change the setup so that GtkApplication creates the toplevel muxer and
adds itself to it as "app". Use this muxer as the parent muxer of any
GtkWindow associated with the application.
This saves a small amount of memory and will allow for accels to be
propagated from the application through to all of the windows.
Resize modes don't work anymore, both because nobody ever uses them and
because the frame clock changed the way things work quite a bit. So we
don't want to advertise them as a good idea.
https://bugzilla.gnome.org/show_bug.cgi?id=708787
Previously, we were showing and hiding the custom titlebar
widget in response to state changes such as maximization.
Instead, use gtk_widget_set_child_visible() and leave
show/hide to applications. This makes it possible to set
a custom titlebar and hide it, for a titlebar-less appearance.
https://bugzilla.gnome.org/show_bug.cgi?id=707132
The size of the shadow and invisible borders can (and usually
will) change between backdrop and focused windows, while the
overall window size remains unchanged. This causes the visible
window to visually 'jump'. We can avoid this by always reserving
the maximum of the focused and unfocused border sizes. The code
for positioning the input-only windows making up the invisible
border is adjusted to deal with this. We now always place the
invisible border right outside the visible content, even if the
shadow extends out much farther.
https://bugzilla.gnome.org/show_bug.cgi?id=707524
We need to subtract border_width from the size we're passing to the
children hfw functions as those are added by ourselves.
Fixes the window-border-width.ui reftest.
At least for header bars, there's often application controls
in this area, which should be included in the focus chain.
We make it so that the initial focus avoids the titlebar,
but tabbing around will eventually get there.
https://bugzilla.gnome.org/show_bug.cgi?id=708067
There were some code added to this file that is meant for the X11 backend,
but they are being unconditionally built. Add build-time checks for the
X11 backend for these to fix the build on non-X11 platforms.
We'll use a style class to be able to give this a different appearance,
but for the time being we don't really need to give this such different
margin.
https://bugzilla.gnome.org/show_bug.cgi?id=706592
"title_box" is used for both a custom header bar and for a titlebar.
Since we want to help differentiate these cases in the code, rename
everything titlebar-internal to use "titlebar_".
https://bugzilla.gnome.org/show_bug.cgi?id=706529
Attached widgets inherit from the style of the widget they are
attached to. This can sometimes have unintended consequences,
like a context menu in the main view of gedit inheriting the font
that is configured for documents, or the context menu of the preview
in the font chooser coming up with humongous font size.
To fix this problem, we introduce a context menu style class
and use it for all menus that are used like that. The theme
can then set a font for this style class.
https://bugzilla.gnome.org/show_bug.cgi?id=697127
Make sure we always deal with the same screen when
connecting / disconnecting the theme-variant changed handler.
Pointed out by Morten Welinder in
https://bugzilla.gnome.org/show_bug.cgi?id=705640
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
Other code assumes that the widget has a window if it is realized.
Since we might trigger such code indirectly from gtk_window_realize,
don't mark the window as realized before we've registered its window.
Group the buttons on each side in a box, and give them different
style classes, so themes can differentiate (this is partially a
workaround for limitations in our css selectors). The boxes also
let us add a margin below the buttons, without affecting the
allocation of the buttons themselves.
gtk_widget_get_allocated_height returns the adjusted
allocation, so we can't use it as measure for how much
room to leave when drawing the window background.
Bring back need_default_size. We need it to preserve this
documented behavior:
The default size of a window only affects the first time a window is
shown; if a window is hidden and re-shown, it will remember the size
it had prior to hiding, rather than using the default size.
With this patch, all of the window sizing tests in
gtk/tests/window pass again.
This avoids an evil trap when doing MAX (..., ... - 2 * border_width)
and the expression on the right gets promoted to unsigned, instead
of going negative as you would expect.
https://bugzilla.gnome.org/show_bug.cgi?id=699633
Instead of having three different boxes and style classes, we can just
get away with the regular background box, plus a window-frame, which
contains the external frame, together with the window drop shadows.
GtkWindow now has special code to ensure the backing actual window is
allocated big enough to accomodate the shadows (using the shadow size
calculations introduced in the previous commit). We also use the margin
value to determine the size of the invisible borders (which can then be
different than the shadow).
We still need to respect this border value even when we're not running
under CSD, since we support setting a custom titlebar in all cases.
The border/style magic in gtk_window_draw() really needs to be separated
out into logical pieces soon, but for now let's keep a consistent
behavior with the previous code.
Instead of reparenting the content, use input-only windows to
set cursors and capture clicks on the window frame. This avoids
some of the problems that were introduced by content_window, such
as black flashes and non-working opacity.
Don't just look at previously remembered sizes, also look at the current
size.
This is useful for cases where the window was resized by the user or WM
and not by the application itself.
https://bugzilla.gnome.org/show_bug.cgi?id=696882
We don't want to remember sizes in the not resizable case. Also a
function named "guess_default_size" should not look at previous sizes,
it should guess.
Old code assumed the size was stored in widget.allocation. This is no
longer true as the allocation is cleared upon hide. However, we store
the last configure request, and that one tracks the last size, so we can
just use that number.
Sometimes things are so easy - once you figure them out...
https://bugzilla.gnome.org/show_bug.cgi?id=696882
When the window has no mnemonics modifier set, as in the case of a
GtkMenu, never schedule a display of mnemonics on focus-in.
Previously, for those windows, the GdkModifierType mask fetched from the
device would typically have been zero, leading to the
mnemonic_modifier == (mask & gtk_accelerator_get_default_mod_mask ())
check to succeed, so we would always trigger a display for popup menus.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
