In some cases we explicitly want to unset an accessible attribute; for
instance, an accessible property is gated on a widget property, and if
the widget property gets unset, the accessible property should be reset.
We're currently overloading NULL to mean both "this value is undefined,
and should be reset to its default" and "the value collection failed".
Let's do error reporting right, by using GError to mean "the collection
failed, for this specific reason"; then, we can use a NULL return value
to signal that the accessible attribute should be reset to its default
value.
This is only relevant for pointer-sized attribute values: strings,
references, and reference lists; numeric, boolean, tristate, and token
values either cannot be undefined, or have a specific "undefined" value.
Some widgets have different roles after they are constructed, so we need
to allow changing the role defined by the class. We should still avoid
setting a role after the GtkATContext has been created.
Only GtkWidget should use GTK_ACCESSIBLE_ROLE_WIDGET as its default
accessible role; the default for GtkAccessible and GtkATContext should
be GTK_ACCESSIBLE_ROLE_NONE, meaning "an element whose implicit native
role semantics will not be mapped to the accessibility API", according
to the WAI-ARIA specification.
It's pointless, we can use an explicit value of `-1` everywhere.
Additionally, it complicates all code that uses the state enumeration as
an array index, since now we need to guard against a negative offset.
Some widgets have different accessible roles depending on some
parameter, so we cannot set the role at class init time. For those
widgets, we add an "accessible-role" property to GtkAccessible, and we
allow setting it (only) at construction time.
An Accessible implementation must create an ATContext object. UI
elements are supposed to interact with the GtkAccessible API, but we
expose GtkATContext to allow patterns like delegation.
GtkAccessible is an interface for accessible UI elements.
Currently, it doesn't do much except exist as a type; in the future, it
will be the entry point for all accessible state in GTK.
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
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
Unsetting the widget causes events to get emitted and we want to
(a) really emit that event to our signal handlers
(b) still be recognized as a real GObject while doing that
https://bugzilla.gnome.org/show_bug.cgi?id=669794
I expect them to be used a lot, so this approach seems better than
requiring signals that connect to "notify::widget". Also, we can't use
regular functions (like dispose or constructed), becaiuse those assume
that (un)setting of the widget only happens once and with the current
design (a puble set_widget() function) we can't really guarantee that.
Also, I split them into two separate functions as one function is part
of construction and the other part of destruction of the object. And it
doesn't sound like a good idea to have that both be part of one
function.
I wanted to use weak refs to ensure this instead, but it's a performance
problem when used in the treeview and each and every cell adds a weak
ref to the treeview.
