Before the resulting window size would differ if the default size was set
before adding a headerbar vs after. Now the saved state is again the actual
requested size and it is adjusted at the time we request a window size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
GtkHeaderBar will not show the maximize button if the window in not of
type normal or not resizeable.
Use the same restriction for double-click actions as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757530
An application may use gtk_window_get_size() to retrieve the current
window size and later reuse that size with
gtk_window_set_default_size().
gtk_window_set_default_size() and gtk_window_get_default_size() should
also take client side decorations offset into account.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
Getting the shadow width must not call gtk_style_context_set_state()
because that will invalidate the node and cause a style-updated emission
which can cause gtk_widget_queue_resize() calls.
And calling queue_resize() from get_preferred_size() essentially means
the size is permanently invalid because you invalidate it while
querying it.
This causes flickering of windows when going from/to backdrop state. To
avoid this we either need to fix the theme to not have different shadow
sizes in those cases or we need to ensure the window doesn't flicker in
the first place.
At the time gtk_window_move() or gtk_window_resize() get called, there
is no way to predict if a popup window will actually draw its shadow, so
applying an offset in this case may end up with a wrong size or
positioning for such windows.
Changing the logic in gtk_window_should_use_csd() as previously done to
address that issue will cause some other breakage as popup windows may
not draw a shadow but still need CSD.
So best is to actually apply client side decorations offset for regular,
top level windows only. This is actually a lot simpler and safer and
less likely to cause additional breakage.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
git commit a5b1cdd0 introduced a regression where CSD windows are not
resizable with metacity.
Reason being that metacity does not support "_GTK_FRAME_EXTENTS" and
therefore gtk_window_supports_client_shadow() would always return FALSE.
This explains why it works with window managers which support
"_GTK_FRAME_EXTENTS" such as mutter/gnome-shell or xfwm4.
Partially revert commit a5b1cdd0 to reinstate the logic in
get_shadow_width().
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757805
The list of popovers will specify the stacking order, a
_gtk_window_raise_popover() private call has been added so popover
widgets can request being on top.
Also, the stacking on popovers is ensured on gtk_window_size_allocate(),
after the size/stacking changes on the child widget have finished, this
will ensure popovers are kept on top of window contents.
https://bugzilla.gnome.org/show_bug.cgi?id=756670
Previous commit 305b34a "GtkWindow: fix move/get position with CSD"
introduced a regression because some windows presumably use shadows but
actually don't, resulting in a negative offset being wrongly applied.
Problem is that get_shadow_width() would return non-zero shadows even
for windows that have no shadow, thus causing the negative offset.
Fix the logic in get_shadow_width() and gtk_window_should_use_csd() so
that get_shadow_width() returns accurate values.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
This commit toggles the big switch. We now don't run size_allocate()
from the toplevel up anymore in cases where we don't need to.
Things might be broken in subtle ways as a result of this commit. We'll
have to find them and fix them.
Widgets that already have a resize queued don't need to walk the whole
parent chain and queue another resize. It's enough to do it once per
resize.
This also means that sizegroups cannot use the shortcut of just
invalidating the first widget in the group anymore. That widget might
already have a resize queued while others don't.
Ignore the geometry widget passed to gtk_window_set_geometry_hints().
Usind the widget itself was a hack that complicates the size request
machinery.
It is also incorrect in that it doesn't respect height-for-width.
Last but not least, it was only used by gnome-terminal and that
application can easily work without it.
Take into account and compensate for the size of the client side
decorations widgets in gtk_window_move() and gtk_window_get_pos()
including gravity.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
When client side decoration is used, the size passed to
gtk_window_resize() or retrieved from gtk_window_get_size() for top-
level windows also accounts for the client side decorations widgets
such as the title bar or the shadow borders.
Add up the size of these additional controls to the given size to get
the size expected.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
If a window is decorated, we need to draw the frame and shadow, even if
it is app-paintable - it's just nonsense to have a frame that we handle
events on, but expect the app to paint it. (We paint the titlebar in
any case.) If a client wants to handle all painting, it should use an
undecorated window.
https://bugzilla.gnome.org/show_bug.cgi?id=756886
Make it what it is - the enum - so that that it is sure that the hint
will fit in the field. Without this, any hint that doesn't fit in 3
bits will be truncated to the 3 least significant bits, causing
unexpected behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Once a window is maximized/fullscreen, resize increments should be
ignored otherwise the window may appear smaller than the screen size.
That also applies to configure requests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
Check whether the given popover even changed size in
_gtk_window_set_popover_position. If not, just move its GdkWindow
without calling gtk_widget_queue_resize. Using popover_get_rect here is
still relatively costly, but popover_size_allocate would be doing that
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
To GtkGesture machinery, if an event triggers a controller/gesture signal,
and gesture reset/cancellation as a result, the event has been managed
after all.
Commit e3bd895667 effectively changed the return value of the
wrapping gtk_event_controller_handle_event() function, which broke some
paths (eg. gtk_popover_button_press() wouldn't while the GTK+ grab was
active for this reason because the button press event was consumed early
on gtk_window_check_handle_wm_event()).
That patch is not too off-track given potential child widgets' behavior,
we want nonetheless to distinguish the denied vs cancelled paths here
(because GtkWindow itself relies on the GtkGesture behavior described in
the first paragraph on the begin_move/resize paths), so just reset
gestures after the event has already gone through the GtkEventController
so the return value is unaffected.
Traditionally a sequence is set to GTK_EVENT_SEQUENCE_DENIED state when
it is to be ignored, which means it is dormant, but still managed by the
gesture (accounting, "denied" sequences still make "slots" in multitouch
gesture busy, etc...).
This gesture will run for all button presses and releases in the window
though when presses happen on the "window content" region, and we can't
account for every children to be as educated as setting the proper mask
on every window, or ensuring events will be propagated as they should.
In order to cater for this, just reset the gestures, we can live without
such accounting in these specific GtkGestureSingle gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
This reverts commit 3eacfa88f2.
Apart from the patch not being correct, we don't want to expose private
structures in header files if we can avoid it.
And this type-checking overhead is not an optimization that is even
measurable.
https://bugzilla.gnome.org/show_bug.cgi?id=754932
Instead of queueing a new idle handler every time we call
gtk_window_update_debugging(), only queue one if none is queued that.
Saves a lot of work, in particular when templates create context menus
for every row in a large listbox as in the gtk-demo listbox example.
This ensures that windows appear in the inspectors tree when
they are created, and it prevents GTK_DEBUG=interactive from
coming up with an empty object tree.
https://bugzilla.gnome.org/show_bug.cgi?id=752664
The previous fix was falling into the crack between
realized and mapped - we would apply the state when a window
is just realized, then unset the _initially flag, and then
when the window gets mapped, we'd undo the state. To fix
this, go back to the way things were when these flags were
first introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=752765
Go back to use these variables only for pre-mapped state changes.
Their use got muddied over the years, and it was hard to keep track
of what is acutal state, and what just a queued request.
