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.
1. This confuses the code as it's using the old type hint with the new
type hint on GDK window creation
2. It only existed as a workaround for old code that directly accessed
window->type_hint which hasn't been possible since 3.0.
This behavior has been made optional on add_popover() time, text handles
will keep being able to overflow the window, in order to allow text
selection on views too close to the window edge.
Regular GtkPopovers are reinstaurated to the previous size positioning
logic though, that is, limited by the visible area of the window.
Under Wayland, fullscreen/maximized windows may not cover the entire
area when a size increment is specified.
Ignore size increments for fullscreen/maximized windows just like most
window managers do under X11 so that windows with size increments can
still be fullscreen or fully maximized under Wayland as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
Since 740bcf5, we use these properties to properly compute shadow widths
for unmapped windows. If a client calls gtk_window_maximize and a window
manager unmaximizes a window, we should draw borders, so we need to
reset these when we get the property notification.
