Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
The _gtk_widget_grab_notify() function just (maybe) did a) reset
controllers and b) hide toplevels. The second part was a testing
remnant introduced in commit 024d832d94, not part of the original
fix.
Do the former more concisely, called from the place where we figure
out whether a widget's ability to receive events changed due to
GTK grabs. It's across those changes that we are interested in
resetting the controllers.
With the gestures being reset both ways, GtkWindowHandle (and
probably other) gestures are now able to reset after a GTK grab
takes input away (e.g. GtkMenuButton). This could be seen as
a sudden jump the next time they'd be dragged with the mouse,
as the gesture would "resume" the previous interaction.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3942
With most context realization happening inside
GtkAtspiContext in response to D-Bus calls, the
code in gtk_widget_realize_at_context that sets
the role is not executed for most accessibles,
causing them to be stuck with the 'filler' role
that makes orca ignore them.
To fix this, split gtk_widget_realize_at_context
into the actual context realization (getting on
the bus) and the setting of widget-specific
properties, and do the latter part when the
widget is rooted.
This makes accerciser report proper roles for
entries and buttons. Orca still has an issue
with getting the hierarchy populated.
Orca ignores events unless the object is inside an object
with role window and states ACTIVE and SHOWING. To arrange
for this, introduce a new ACTIVE platform state, and set it
for windows when they are active.
This gets orca to be a lot more talkative.
Ever since we added surface-to-widget transforms,
the autofading of the fps overlay did not work anymore,
since it was given the transient transform node, most
of the time.
Fix this by passing both the root of the node tree and
the node for the toplevel widget to prepare_render, and
hande the widget node to the overlays. Update the
affected overlays that need to have their positioning
adjusted.
This was needed to work around widgets claiming event sequences on press,
by ignoring them and starting the drag anyway unless they have certain
event controllers on them.
The most visible offender was GtkButton, but since the last commit it
doesn't claim the sequence anymore and we can remove the hack.
Before turning off pangos rounding of glyph positions,
we must check if the cairo we are using is new enough
to have working subpixel positioning (the relevant
cairo commit is 52a7c79fd4ff96bb5fac175f0199819b0f8c18fc).
Setting can-focus to FALSE on a widget is supposed
to prevent focus from entering the entire subtree.
So when we grab focus directly to a widget, we need
to check the can-focus flag not just of the widget
itself, but all its ancestors.
Fixes: #3610
Implement most of transform-origin. We only
handle the xy components currently, which lets
us reuse the position value implementation that
is used for background-position.
We only realize the ATContext on the top level, which will create an
GtkAtSpiRoot object and the corresponding GtkAtSpiCache object. Whenever
an AT connects to the accessibility bus, and asks for the various
objects, all the ATContext will be realized on demand.
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.
Don't have GtkRoot listen directly to the layout signal on the frame
clock, but let it pass through GdkSurface. This will allow GdkSurface to
be more involved in the layout phase.
We need to tell people what signal will be emitted when calling
gtk_widget_activate(), and that the shortcuts API might be more
appropriate to what they are looking for.
Setting a field on a class structure is not always an easy task from
languages other than C. While bindings can provide access to the class
pointer, twiddling the fields in the class structure can be awkward.
Additionally, signal ids are not always readily available.
We can paper over the direct access to the class structure, as well as
the "signal name to id" mapping with a simple couple of setter
functions.
We may have the situation of multiple touchpoints in the same
widget, or combinations with other devices. Stack those ::active
states are preserved on widgets on all but the last pointer/touch
going away.
Now that GtkATContext is explicitly realized and unrealized, we should
always create an instance at widget initialization time, and drop it
during the widget finalization. This should make it easier to set up the
initial accessible state of a widget during the instance initialization,
as well as reduce the chances of accidental creation of GtkATContext
instances during the destruction sequence.
By unrealizing the context we avoid additional work during the dispose
phase, in case widget code updates the accessible state. We use
GtkAccessible's API, to ensure we unrealize the right ATContext, instead
of the one we store inside GtkWidgetPrivate.
We drop the ATContext instance inside GtkWidget during finalization, to
mop up eventual vivifications there.
This is leftover code from when widgets were hidden
by default, and was setting them back to their initial
state.
This is getting in the way now, as hiding the widget
updates the HIDDEN accessible state, which ends up
re-creating the at context that we've already disposed
of, leading to memory leaks.
Using GList is a bit lame, and makes the API more complicated to use
than necessary in the common case.
The only real use case for a GList is gtk_widget_add_mnemonic_label(),
and for that we can use the GValue-based API instead.
Fixes: #3343
The accessible-role property in GtkWidget has three possible targets:
- the :accessible-role of a GtkATContext, if realized
- the accessible_role field of GtkWidgetPrivate
- the accessible_role field of GtkWidgetClassPrivate
When we set the accessible role of a widget using the GObject property
mechanism, we want to either set the GtkWidgetPrivate.accessible_role
field, if there's no ATContext *or* if the ATContext is not realized.
Conversely, when we get the accessible-role property we want to have a
series of fallbacks in place:
- if GtkAccessible.get_at_context() returns an ATContext, and that
ATContext is realized, return the :accessible-role of the context
- if GtkWidgetPrivate.accessible_role is not WIDGET, return the
stored accessible role
- return GtkWidgetClassPrivate.accessible_role
This should help catch the case of getting the accessible role of
widgets that override GtkAccessible.get_at_context(), like
GtkModelButton.
See: #3342
We are doing too much work during the construction phase of the
AT-SPI backend for GtkATContext. Instead of having the AtSpiContext
register itself at construction time, let's add explicit realize
and unrealize operations, and connect the ATContext realization to the
rooting operation of a GtkWidget.
We are setting the value to TRUE initially, but
the property had a declared default of FALSE.
This is messing up the simplification of .ui files
with gtk4-builder-tool, since it thinks it can
omit can-target properties when it really can't.
gtk_widget_reposition_after is called both to add new children,
and to reposition existing children. We only want to emit
accessible changes in the former case (since AT-SPI doesn't
have events for reordering).
A bit hacky: we skip parsing values that have a reference or
reference-list type, but we do not error out. Instead, we return a NULL
value, which we catch in the GtkBuildable interface implementation to
get the actual object, and construct a reference list value.
There's still some ickyness around the value type that can only be
solved by having an attribute and role taxonomy.
Accessible attributes are not GObject properties. This means that we
need a custom parser for setting attributes in our UI description files.
The new section is defined as a sub-tree with the `<accessibility>`
element at its root, and elements for each type of accessible
attributes, i.e. properties, relations, and states:
```xml
<object class="..." id="...">
<accessibility>
<property name="label">The accessible label</property>
<state name="pressed">false</state>
<relation name="labelled-by">label1</relation>
</accessibility>
</object>
```
The name of the attribute is the enumeration value; the value is defined
by the WAI-ARIA specification.
There were several places where we were confusing
GList and GSList and list->data and list->next, causing
a crash in the accessible name computation for buttons
with mnemonic labels.
Anybody who keeps their own CSS nodes around or wants to order CSS nodes
different from widgets will from now on have to do it manually all the
time.
This is outdated behavior, nobody should be doing either of those two
things.
Also, the correct case is much more common, and not doing it
automatically was causing bugs.
Fixes#3280
And honor it in gtk_popover_popdown(). By default, a GtkPopover
pops down automatically if a child popover was closed, if this
property is FALSE, the popover will remain opened.
As a companion to go with the platform_change api,
add a gtk_accessible_get_platform_state() function
that can be used by backends to get the platform
state.
This is in preparation for making entries inherit
their focus states from the text widget within.
Since we need to check at run time what kind of AT context to use, we
need a hook into the whole GDK backend machinery. The display connection
seems to be the best choice, in this case, as it allows us to determine
whether we're running on an X11 or Wayland system, and thus whether we
should create a GtkAtSpiContext.
This requires some surgery to fix the GtkATContext creation function, in
order to include a GdkDisplay instance.
GtkBuildable's get_name()/set_name() methods may shadow
GtkWidget's methods. Avoid that by renaming the API to
get_buildable_id()/set_buildable_id(), which also reflects
the name of the XML attribute the API refers to.
https://gitlab.gnome.org/GNOME/gtk/-/issues/3191
Using gtk_widget_insert_before on a complex container
is a *bad* idea; it will mess up the containers bookkeeping
of its children and can easily lead to failure and crashes.
