Commit fa3d1940bf added separate grab handling for GtkSearchEntry, but
didn't consider whether the bar was revealed or concealed. The expected
behavior for the latter is that the entry is cleared rather than focused,
fix the condition accordingly.
With the last commit, pressing the same button with multiple fingers
doesn't cause extra emissions, so we can remove exclusive and allow
pressing multiple buttons at once on touch.
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.
Since GtkATContexts are now lazily realized, we need to go through the
GtkAccessible's implementation to access the :accessible-role property,
in case there are fallbacks.
There's no need to do a lot of work on construction, if we're delaying
all remote work after the GtkATContext is realized.
The GtkAtSpiContext should also keep a reference on the root, and drop
it at unrealize time.
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.
Making the list row child css depend on the position
is very expensive, and does not acutally work correctly
(since we don't have widgets for all children, so the
position of the child widget does not reflect the actual
model item position).
To make this more palatable, use the bottom border
instead of the top border, since most lists have a natural
border at the top (with headers), and may end up with
empty space at the bottom.
The overarching goal here is to not queue a resize
unless something has actually changed. In columnview
scenarios, we often deal with hundreds of labels.
Labels are cattle, not pets.
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.
The hypothetical widget that needs to clone ATContext instances
because it needs to control the accessible role post-construction is
really GtkModelButton.
Fixes: #3342
Some widgets might want to override GtkAccessible and create their own
context in order to control the accessible role post-construction time.
To avoid explicitly copying the existing state over from the original
ATContext to the new one, we need a way to clone the context's state
from inside the ATContext itself.
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
Use a single environment variable for everything:
- select the ATContext implementation
- select the test ATContext
- disable ATContext entirely
We use the same pattern as GSK_RENDERER, GTK_DEBUG, etc.
The documentation needs to be updated to include the environment
variable.
The GtkPlacesOpenFlags enum is only used in private
API, so move it to private headers. Since we still need
a GType for it, add gtkplacessidebarprivate.h to the
headers we use for generating private enum types. In turn,
this registers the other private enums in that header, so
take the opportunity to fix their naming, and use the
generated types for the corresponding sidebarrow properties.
Fixes: #3337
Check the text handle role, instead of looking for the other handle
visibility. The other handle may be invisible during selection mode
(e.g. pointing to offscreen contents). This fixes both this code
switching to cursor mode out of the blue, and possible crashes later
on as this handle might be hidden in the process, while its own event
controller is handling events on the parent surface.
The gtk_text_view_set_handle_position() function called some lines above
takes care of handle visibility already, also accounting for other
conditions (e.g. whether the handle points to contents onscreen).
Forcibly showing handles here misbehaves if the handle should stay hidden,
and somewhat expensively as it involves creating and throwing a native
surface every time.
With the scrolledwindow drag gesture not claiming the sequence immediately,
we end up placing the cursor (and undoing the previous selection) each time
we scroll.
There is already handling too short drags in ::drag-end, so let this code
handle touchscreens as well.
If the gesture becomes captured (e.g. from a parent scrolledwindow), we
leave some things in the air. Clean these up properly. This is recurrent
with touch scroll.
In destruction paths of a focused entry, the IM context might first
end up detached from its widget, then destroyed. This currently prevents
the IM context from detaching itself from the GtkIMContextWaylandGlobal.
Make it do so when unsetting the client widget, so the IM context gets
properly unfocused before destruction.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3176
In wayland, popup positioning and event handling are doubly async.
This makes it unreliable to figure out parent surface coordinates
out of the popup position and the events received. This results in
jumpy text handles there.
The best way to deal with parent surface coordinates is to handle
the events there. Make the handles transparent to input, and make
the drag gesture be set up on the parent widget's native.
The gesture is set up in the capture phase, setting it on the native
(as opposed to the parent widget) achieves a feeling similar to it
being a distinct surface, as it should take precedence over other
gestures in the emission chain (e.g. scrolledwindows).
As everything is in parent widget's native's coordinates, the drag
handles become smooth again.
The intended use case of the "presentation" role is
| […] when an element is used to change the look of the page but does not
| have all the functional, interactive, or structural relevance implied
| by the element type, or may be used to provide for an accessible
| fallback in older browsers that do not support WAI-ARIA.
One of the examples is, literally:
| An element whose content is completely presentational (like a spacer
| image, decorative graphic, or clearing element);
Which fits perfectly for the GtkTreeExpander's "indent" builtin icon
widget.
Mark gtk_drag_icon_create_widget_for_value with
GDK_AVAILABLE_IN_ALL, since it is meant to be public.
Also, clarify the documentation a bit.
Fixes: #3325
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.
The magnifier in entries is magnifying the GtkText
widget, which does not draw any background itself.
Therefore, we give the magnifier a background, to
make things look as expected.
Fixes: #3318
Install a log writer function that is a bit simpler than
the default GLib log writer, and does not put PIDs and
timestamps in the output, so we can compare easily in
our testsuite.
It doesn't make much sense to set this in per-directory
meson files, since that makes use use different logging
facilities in different parts of the project. Set it
globally.
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.
We were not checking the passed-in type in the right
way. An interface type can still pass the
g_type_is_a (..., G_TYPE_OBJECT) check, if G_TYPE_OBJECT
is one of its prerequisites. What we need to check is
whether the fundamental type is G_TYPE_OBJECT.
When using GtkBuilder to create constraints and guides,
the layout manager is already rooted when the guides get
created, and we were forgetting to create the guides
constraints in this case. Fix it by adding a call to
gtk_constraint_guide_update().
This was showing up in the new builder-based constraints
demo as the guide not having the expected effect.
This isn't strictly required for correctness, but
it makes the GtkBuilder codepath do the same that
the vfl codepath does: call gtk_layout_manager_layout_changed
only once, after all the constraints have been added.
Make the default factory add a checkmark to the
currently selected item (not the hovered item)
in the popup. This will unfortunately have to be
done in non-default factories too.
Related: #3291
Add a way to add children at certain places in
the generated menu for both GtkPopoverMenu and
GtkPopoverMenuBar.
New apis:
gtk_popover_menu_add_child
gtk_popover_menu_remove_child
gtk_popover_menu_bar_add_child
gtk_popover_menu_bar_remove_child
Fixes: #3260
This makes it so that you have to explicitly specify
"true" and "false" for the checked state, but it
matches how this enumeration is meant to be used.
This ensures that keybindings for small-step changes
work despite draw-value being FALSE now. This was
fallout from 8ca612c966 that showed up
as arrow keys not working anymore for the color scales
in the color chooser.
Instead of monitoring the list of toplevels, rely
on GtkWindow updating the HIDDEN state before windows
get removed. This is better, since we still have the
object available when it happens, so we can pass it
to the ATs.
We want to use the HIDDEN state to control when
things get added and removed from the accessible
tree, so ensure that we a) set HIDDEN to true
initially for windows, and b) we update HIDDEN
when a window is shown or hidden.
The second part is handled by gtk_widget_hide
for other widgets, but hiding a window does not
always go through that code path.
When a toplevel window gets hidden (and not destroyed),
the frontend code set the HIDDEN state, and we need to
emit child notification when that happens.
We need to use gtk_accessible_should_present() whenever we
calculate accessible tree positions, to avoid inconsistencies.
While we are at it, make these helpers usable for finding
the position of accesibles that are now ignored, by not
looking at should_present for the object itself. This will
be relevant when we calculate the position of objects whose
HIDDEN state changes.
We need to translate the list model position into
an accessible tree position, since hidden toplevels
will be skipped.
While we are at it, add an api for this notification
that will be used in the next commit.
Hidden elements are not presented in the accessible
tree, so when then HIDDEN state changes, we should
emit child-added or -removed signals.
This commit does not yet handle all cases (HIDDEN
toplevels or hidden stack pages are not handled),
but it should cover the common case.
The ARIA spec is clear on this: when an element has the
HIDDEN state, it should not be presented in the accessible
tree.
This change is incomplete, we also need to emit child-added/
removed signals when the state changes, but that needs to
wait for the child added infrastructure to land.
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).
Unparenting the stack finalizes the entry and label,
but at least the label is available via the
gtk_editable_get_delegate API, and the a11y
implementation uses that at dispose time. So, clear
the pointers to prevent them from being dangling.
This was showing up as a segfault of the doc-shooter.
When the compositor unmaximized the window, we get a
state-changed signal, and we update the maximized field.
But then we go and recompute our layout based on the
maximize_initially field, and that is still TRUE, when
we were maximized initially. So we need to update both
fields.
This fixes a problem where using the window menu to
unmaximize an initially maximized window would not
work.
Fixes: #3226
We are not using a box layout here since we want
to ignore the icons for measuring. But we still
want the layout to respect border spacing that
comes from the theme.
If the operation mode is OPERATION_MODE_RECENT and we end up in the
'goto file_entry' case, we don't set info.result. Then later after
calling check_save_entry, is_empty is TRUE which causes a goto out and
here we then try to use info.result, which is uninitialized.
Initialize info.result before doing all this.
Found by scan-build
Unparent the child widget before tearing down its
stack page. This is necessary so a11y can still access
the stack page accessible to emit change notification
when it learns that the child is removed.
Since we mention abstract roles in the documentation
for GtkAccessibleRole, we should say what roles are
abstract. Doing this shows that we actually use two
abstract roles heavily, ourselves: WIDGET and WINDOW.
GtkModelButton is no longer derived from GtkButton,
but can still treat it like a button for the purposes
of having a click action. This lets ATs activate
menu items again.
When the button role changes, we want to update the
accessible role to match. Since accessible roles are
unchangeable post-creation of the AT context, we have
to cheat a bit and recreate the whole context.
Set the accessible role to GTK_ACCESSIBLE_ROLE_MENU_ITEM.
This is incomplete, we need to recreate the context when
the buttons role changes, and there are other things that
need to be set.
According to section 7.1 of WAI-ARIA, the progressbar role
has the "Children presentational" characteristic, which
indicates that children should not be represented in
the a11y tree.
According to section 7.1 of WAI-ARIA, the meter role
has the "Children presentational" characteristic, which
indicates that children should not be represented in
the a11y tree.
According to section 7.1 of WAI-ARIA, the switch role
has the "Children presentational" characteristic, which
indicates that children should not be represented in
the a11y tree.
According to section 7.1 of WAI-ARIA, the slider role
has the "Children presentational" characteristic, which
indicates that children should not be represented in
the a11y tree, which makes sense, since these are all
just internal gizmos.
Recompute the layout when the css style change
affects text attributes. This matches what we do
in GtkLabel, and without this, changing the
font-features-setting css property in the Inspector
does not have immediate effect.
The last event, matching lifting the finger/releasing the mouse button,
is important when there's a large delay between it and the previous events,
as in when performing a movement, stopping, then releasing fingers as
opposed to doing a swipe.
If this event is skipped, doing this will result in kinetic deceleration
matching the previous finger movement, while the expected behavior would
be no deceleration.
See also 5dc6194b98 for a similar fix in
GtkEventControllerScroll.
GtkAtSpiRoot is not a context, which means it needs to emit
ChildrenChanged events by itself whenever a toplevel is added to, or
removed from, the list of toplevels.
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.
The nameless, faceless gizmos inside a range do not
contribute to the accessible experience at all, lets
not add them to the tree. All the accessible functionality
is on the main widget (either a scale or a scrollbar).
Show the object path of the object on the a11y bus,
this is can be useful information. While we are here,
make sure that the Inspector does not throw criticals
when used with GTK_NO_A11Y=1.
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
The stack page objects were not properly integrated
in the accessible tree - they were appearing as parent
of the pages when navigating up, but not as children
of the stack when navigating down.
Instead of falling back to the role nick for both,
fall back to the class name for the name, and to
the empty string for the description. This makes
labels show up in Accerciser the same way they
did in GTK 3, and seems more useful to me than
the alternative.
The ARIA spec determines the name and description of accessible elements
in a more complex way that simply mapping to a single property; instead,
it will chain up multiple definitions (if it finds them). For instance,
let's assume we have a button that saves a file selected from a file
selection widget; the widgets have the following attributes:
- the file selection widget has a "label" attribute set to the
selected file, e.g. "Final paper.pdf"
- the "download" button has a "label" attribute set to the
"Download" string
- the "download" button has a "labelled-by" attribute set to
reference the file selection widget
The ARIA spec says that the accessible name of the "Download" button
should be computed as "Download Final paper.pdf".
The algorithm defined in section 4.3 of the WAI-ARIA specification
applies to both accessible names (using the "label" and "labelled-by"
attributes), and to accessible descriptions (using the "description" and
"described-by" attributes).
Our Text implementation requires that we have
a GtkEditable with a delegate that is a GtkText
widget.
This change make the Text implementation work for
the custom widget in the tagged entry demo.
Implement the non-questionable parts of the Component interface
for accessibles which are widgets.
This does not include:
- global coordinates
- setters
- scrolling
- alpha, layers, zorder, and the like
