Don't call gtk_root_get_focus when we already have
the GtkWindowPrivate struct at hand. And use
gtk_window_set_focus to update the focus, like the
old code did.
When a widget is hidden, check harder for the keyboard focus being
contained in that widget, in order to reset it. Portions of the
focus child hierarchy may be outdated at the time, so it is more
reliable to check GtkRoot::focus (i.e. the property we intend to
update here).
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3214
We were not updating the remembered size at all when
the window is interactively resized, causing it to
snap back to its default size the next time we call
gdk_toplevel_present().
This is a bandaid fix to prevent very broken resizing
behavior, until we have properly redone toplevel sizing.
Fixes: #3076
This way the child widgets can rely on the renderer (for example what
type it is) to decide details about how they render (such as if they
should use OpenGL shaders).
Most of the surface api we have in the Wayland backend
only makes sense for toplevels, so reshuffle things to
take a GdkToplevel instead of a GdkSurface.
Update all callers and the docs.
Commit 658719a205 moved the call to
gtk_window_compute_default_size() outside the
if (priv->needs_default_size)
but unfortunately, that function cleared that field,
so we never entered the branch.
Keep the setting of priv->needs_default_size in the
branch, where it belongs.
GTK will not up front know how to correctly calculate a size, since it
will not be able to reliably predict the constraints that may exist
where it will be mapped.
Thus, to handle this, calculate the size of the toplevel by having GDK
emitting a signal called 'compute-size' that will contain information
needed for computing a toplevel window size.
This signal may be emitted at any time, e.g. during
gdk_toplevel_present(), or spontaneously if constraints change.
This also drops the max size from the toplevel layout, while moving the
min size from the toplevel layout struct to the struct passed via the
signal,
This needs changes to a test case where we make sure we process
GDK_CONFIGURE etc, which means we also needs to show the window and
process all pending events in the test-focus-chain test case.
Emit crossing events when the active window changes.
We don't want to emit GTK_CROSSING_FOCUS events, since
every window has its own focus location (focus does not
jump from window to window), so we use the new
GTK_CROSSING_ACTIVE type of crossing event for this.
It's not a portable API, so remove it. The corresponding backend
specific functions are still available, if they were implemented, e.g.
gdk_macos_monitor_get_workarea() and gdk_x11_monitor_get_workarea().
To build a better world sometimes means having to tear the old one down.
-- Alexander Pierce, "Captain America: The Winter Soldier"
ATK served us well for nearly 20 years, but the world has changed, and
GTK has changed with it. Now ATK is mostly a hindrance towards improving
the accessibility stack:
- it maps to a very specific implementation, AT-SPI, which is Linux and
Unix specific
- it requires implementing the same functionality in three different
layers of the stack: AT-SPI, ATK, and GTK
- only GTK uses it; every other Linux and Unix toolkit and application
talks to AT-SPI directly, including assistive technologies
Sadly, we cannot incrementally port GTK to a new accessibility stack;
since ATK insulates us entirely from the underlying implementation, we
cannot replace it piecemeal. Instead, we're going to remove everything
and then incrementally build on a clean slate:
- add an "accessible" interface, implemented by GTK objects directly,
which describe the accessible role and state changes for every UI
element
- add an "assistive technology context" to proxy a native accessibility
API, and assign it to every widget
- implement the AT context depending on the platform
For more information, see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2833
We only want to send grab-notify to widgets that might have been
interacting with devices via events. Instead of going through all
widgets in all toplevels, we have the window/pointer focus information,
so we can just traverse the widget stacks for every involved foci.
This got stuck in ancient times when widgets were windowed, so the devices
in a window to know the devices in that widget would pan out. We do only
want here the devices that are inside the widget, not spread over the
surface, so rewrite this helper function to poke the toplevel foci, and
look they are contained inside the widget.
