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.
The buttons here are not really buttons (the action
is not tied to the "clicked" signal), so triggering
the buttons via a11y does not have the expected effect.
And we expose the Value interface that ATs can use
to set the value.
The Selection interface is defined in terms of child
positions, so we need to always translate from that
to model positions if we want to use the selection
model apis.
Add a paragraph to the migration guide that explains
how to properly render symbolic GtkIconPaintables.
Also mention this in the GtkIconPaintable docs.
There's a reason you can't spell 'paintable' without
'pain'...
This implementation works for both GtkListView and
GtkGridView, and by extension, also for GtkColumnView
and GtkDropDown, since those just use a list view
internally.
Use the TREE_GRID, ROW, COLUMN_HEADER and GRID_CELL roles
for the various widgets involved in a GtkColumnView. To
enable this, we subclass GtkListView for the internal
list in the column view.
This is a bit different from the way things were done
in GTK 3 - we follow what was done for GtkStackSwitcher,
and make the tab bar carry the GTK_ACCESSIBLE_TAB_LIST
role, and implement Selection there.
Set up the necessary roles, relations and properties
for the tab patterns. This parallels what we have done
for GtkStackSwitcher, and implements the Tabs pattern
as described in the ARIA authoring guidelines.
Set the tablist role on the stackswitcher itself, and
the tab role on the buttons. This is another step towards
implementing the tabs pattern for GtkStack.
platform change is called from gtk_widget_set_focusable
which is likely to be called early on in init(). We don't
want to create an AT context that early if we can help
it, e.g. since it makes it impossible to override the
accessible-role with a construct property.
This requires some cleanup to remove assumptions
about accessibles being widgets in the backend,
and some code to navigate the tree with these
extra objects in between widgets.
The accessibles for stack pages have the role
GTK_ACCESSIBLE_ROLE_TAB_PANEL. This is the first
step towards implementing the tabs patterns
as described in the aria authoring guidelines
for GtkStack.
