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.
