These ended up square in the various refactors. Make them again L-shaped
by extending these along the edge being checked. This means we have to
check for corner positions in all edges, though.
In order to do this, leverage smooth scroll handling into the capture
phase scroll controller, controlled by ::scroll-begin in the propagation
phase controller.
There's 2 cases here:
- A child widget handles scroll. The scrolled window does not get
::scroll-begin, the child widget handles the full scroll sequence.
- No child handles scroll, the scrolled window gets ::scroll-begin,
and transfers control of scrolling to the capture phase controller.
As scrolling is performed, the pointer may fall into scrollable children,
but the scrolled window will be capturing the scroll events, so these
won't be seen by the child widgets.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/593
We let smooth scroll events that don't trigger a ::scroll signal through.
This is unintended, these are handled, even if just accumulated.
This fixes cases like GtkSpinButton inside GtkScrolledWindow, where both
would handle events, until the GtkSpinButton eventually shifts away from
underneath the pointer.
Brought up at https://gitlab.gnome.org/GNOME/gtk/-/issues/593
This code was here in gtk3 to cater for the completion window being
positioned. That was only to meant once as long as the completion window
was shown.
This doesn't work as well for gtk4, ::size-allocate gets propagated from
the toplevel, so happens much more often for the completion window, this
ends up with the completion position being reset to the first row
frequently.
Do this simply once when popping up the completion, instead.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3083
The coordinates are already widget-local here, not transformed by the
adjustment positions. Using the adjustment value here ends up pushing
the entry far from the left border.
The correct minimum value here is 0, which matches the treeview left
border.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3009
Let model buttons handle unpaired releases, these may happen indirectly
e.g. due to other child menus being opened at the time. Clicking would
dismiss the menu, but the menu item beneath the pointer would not get
activated.
We can handle that button release though via ::unpaired-release, so
there's no second click required.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3463
Tracking it through the GtkGestureClick becomes a bit cumbersome for
handling of simultaneously pressed buttons. We can track ::stopped,
but that also emits for a number of situations where we want drag to
continue.
However, the GtkGestureDrag is grouped with the click gesture, and
knows better when to finish the drag gesture (not just because of a
button release), so hook drag and zoom mode finalization there.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3426
Having a property with the same name of a method makes some languages
which put properties and method names in the same flat namespace not
really happy about our choices. To avoid collisions, let's put the the
"fullscreen" property into the past, alongside the "maximized" property.
Drop the "don't write code that crashes" folksy bit; don't start
sentences with conjunctions; remove copy-pasted references to
"iconified" states; point to the corresponding property notification in
a consistent manner.
Currently, the implicit grab is broken on the first button release,
in the case of pressing multiple buttons simultaneously. This means
that we emit crossing events early, and the next button releases
are sent to the pointer focus widget instead.
Consider the implicit grab effective until all buttons are released,
and only unset the pointer implicit grab (and emit crossing events)
after there are no further buttons pressed. We do this by checking
event modifiers, given button release events do contain the modifiers
in effect at the time the event was generated, we have to look for
exactly one active button modifier.
Fixes weird pointer states after pressing multiple buttons on a
widget.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3426
It was used by all surfaces to track 'is-mapped', but still part of the
GdkToplevelState, and is now replaced with a separate boolean in the
GdkSurface structure.
It also caused issues when a widget was unmapped, and due to that
unmapped a popover which hid its corresponding surface. When this
surface was hidden, it emitted a state change event, which would then go
back into GTK and queue a resize on popover widget, which would travel
back down to the widget that was originally unmapped, causing confusino
when doing future allocations.
To summarize, one should not hide widgets during allocation, and to
avoid this, make this new is-mapped boolean asynchronous when hiding a
surface, meaning the notification event for the changed mapped state
will be emitted in an idle callback. This avoids the above described
reentry issue.
This makes it possible to set 'maximized' to true in .ui files, and the
window will show up maximized.
gtk_window_is_maximized() will return the intended maximized state until
actually mapped, it will then show the actual maximized state. The same
applies to reading the property.
This commit changes the behavior of window size computation and the
default size properties to:
* The default-width and default-height properties are updated to the
current window size unless the size is fixed by e.g. being maxmized,
tiled etc.
* The compute-size semantics are to just pick the default size, or if
not adequate, use the measured size, and consequently update the
default size, unless unresizable.
* gtk_window_get_size() is removed, what's more likely relevant is the
gtk_window_get_default_size() which will now contain more sensible
values.
Various places that used gtk_window_get_size() were updated to use
gtk_window_get_default_size() to remember and restore previous sizes.
This also changes the default value of 'default-width' and
'default-height' from -1 to 0. The gtk builder simplify tool is taught
how to omit when the default size is set to both -1 and 0.
This fixes an issue where the focus of the window continuously received
fake motion events even when a popover was open, making input events end
up behind the popover.
It also adds a comment describing why motion events are requested. Note
that popovers won't work with this, and it's possible both in the past
and now that sporadic missplaced motion events will appear, e.g. when a
window changes allocation but a popover is open.
While the workaround hides majority of the issue there are still two big downsides:
- shadow does eat from the widget dimensions so alignment is broken
- situations like popover going upwards on screen edge break completely
The appropriate action is to revert these theme duct tape solutions to make room
for a proper fix.
This reverts commit b3dba1dca6.
Issue https://gitlab.gnome.org/GNOME/gtk/-/issues/1987
This removes the gdk_surface_set_shadow_width() function and related
vfuncs. The point here is that the shadow width and surface size can now
be communicated to GDK atomically, meaning it's possible to avoid
intermediate stages where the surface size includes the shadow, but
without the shadow width set, or the other way around.
This changes allocation of the widget trees to happen as a side effect
to the GdkSurface::layout signal, which first passes the GtkNative
instance where it is then forwarded to the implementations of the
GtkNative interface.
The implementations of GtkNative are the ones doing the actual
gtk_widget_allocate(), and they do so in their GtkNativeClass::layout
function.
The size should correspond what gtk_widget_measure() does, and it
measures what's within the window excluding the shadow; so make this
helper function correspond to this.
