Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
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
The previous fix broke the case where we're Shift-Tabbing
from a listboxrow child to the row itself. This was causing
the widget-factory2.tab-backward test to fail. Fix it, by
grabbing the focus to the row explicitly.
If a row has content that is focus-on-click, and is set
to focus-on-click itself, then the row steals the focus
fromt he content, since it uses focus-on-click on button
release, as opposed to button press. Avoid that by
refusing to take focus if it is already on some
descendent of the row.
This was showing up in the widget-factory listbox on
page 2, where clicking on the spinbutton would briefly
put the focus on the spinbutton, only to lose it to
the row.
Add back a property that determines whether an individual
widget will accept focus or not. :can-focus prevents the
focus from ever entering the entire widget hierarchy
below a widget, and :focusable just determines if grabbing
the focus to the widget itself will succeed.
See #2686
This was only living in gtkcontainer.c for historic
reasons. Move it closer to where it belongs, and
rename it from 'idle' to 'layout', since it is
really about the layout phase of the frame clock,
nowadays.
This commit handles complicated cases where we selections.
We handle this by adding extend and modify parameters to
the ::move-cursor signals, and adjust the bindings
accordingly.
After the :can-focus change in the previous commit, widgets
need to set suitable focus and grab_focus implementations
to implement the desired focus behavior.
This commit does that for all widgets.
Make widgets can-focus by default, and change the semantics
of can-focus to be recursive . If it is set to FALSE, focus
can not enter the widget or its descendents at all anymore.
This commit temporarily breaks focus behavior of widgets
that did not expect to receive focus.
Reviewing the existing settings, the only backend with
some differences in the modifier intent settings is OS X,
and we would rather have that implemented by interpreting
the existing modifiers in the appropriate way.
X11 Wayland Win32 OS X
primary ctrl ctrl ctrl mod2
mnemonic alt alt alt alt
context menu - - - ctrl
extend sel shift shift shift shift
modify sel ctrl ctrl ctrl mod2
no text alt|ctrl alt|ctrl alt|ctrl mod2|ctrl
shift group varies - - alt
GTK now uses the following modifiers:
primary ctrl
mnemonic alt
extend sel shift
modify sel ctrl
no text alt|ctrl
The context menu and shift group intents were not used
in GTK at all.
Update tests to no longer expect <Primary> to roundtrip
through the accelerator parsing and formatting code.
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
It’s possible for code which uses a `GtkListBox` to reuse a single
header row, and move it around between rows. For example, this might
happen if the code has interactive widgets (like buttons) in the row,
and doesn’t want to continually recreate them and reattach signals to
them whenever the row headers change.
Unfortunately, this was broken, as the old header widget was
unconditionally unparented, even if it had just been set as the header
for a different row in the same `GtkListBox`. This left it assigned as
a child widget in the `GtkListBox` (so it was iterated over by
`forall`), but without its parent widget set.
Fix that by only unparenting the header if it hasn’t already been
assigned as the parent of a different row.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
