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
Make right-aligned content work in resized columns.
There is currently no way to make a title right-aligned,
but we can still make it work correctly. This is a follow
up to 7eb0ae39c5.
Fixes: #3276
When resizing columns, we clip a shrunk column
on the right, so the separator disappears in that
case unless we put it on the left side of the other
column.
Ensure that the column resize cursor stays in place
for the duration of the resize drag. This is a bit
annoying, since the implicit grab can end up on the
header of a different column from the one we are
resizing, so just set the cursor on all column headers.
Make it so that for overlapping resize rectangles (with
very narrow columns), we prefer the narrow column, so you
can regrow a column after shrinking it all the way.
Related: #3274
Ensure that we place the resize rectangle at the visible
right edge of the column, not where the allocation ends
(we clip the header drawing, after all).
Related: #3274
We only want to show relevant, local actions for
widgets, but _gtk_widget_get_action_muxer() will
return the muxer of a parent widget (all the way
up to the toplevel), if the widget does not have
any actions of its own. To detect this situation,
compare what _gtk_widget_get_action_muxer() returns
for the parent widget, and act accordingly.
