Show a tab for accessibility information.
This shows the role and the accessible attributes
(states, properties, relations).
For now, changing the values is not possible, and
we only show the explicitly set values. In the future,
we want to show the attributes that are relevant for
the role, regardless of whether they are set or not,
and allow changing some of the attributes (the ones
that are not fully managed by GTK itself).
We're stopping activity mode when finalizing, which will change
accessible state; this will create a GtkATContext, and since GtkWidget
drops its GtkATContext on dispose(), we're going to end up leaking it on
the floor:
```
2,007 (64 direct, 1,943 indirect) bytes in 1 blocks are definitely lost in loss record 36,242 of 36,944
at 0x483977F: malloc (vg_replace_malloc.c:307)
by 0x5222105: g_malloc (gmem.c:106)
by 0x523E222: g_slice_alloc (gslice.c:1025)
by 0x523E261: g_slice_alloc0 (gslice.c:1051)
by 0x534B398: g_type_create_instance (gtype.c:1849)
by 0x53302EE: g_object_new_internal (gobject.c:1937)
by 0x53312AF: g_object_new_valist (gobject.c:2262)
by 0x532FEE8: g_object_new (gobject.c:1780)
by 0x4B3F942: gtk_test_at_context_new (gtktestatcontext.c:107)
by 0x491CC50: gtk_at_context_create (gtkatcontext.c:380)
by 0x4BFEDA0: gtk_widget_accessible_get_at_context (gtkwidget.c:8127)
by 0x4906079: gtk_accessible_get_at_context (gtkaccessible.c:83)
by 0x490618F: gtk_accessible_update_state (gtkaccessible.c:137)
by 0x4ACBA6D: gtk_progress_bar_act_mode_leave (gtkprogressbar.c:690)
by 0x4ACB4F8: gtk_progress_bar_finalize (gtkprogressbar.c:564)
```
We're also unparenting widgets and changing styles, which is another
potential source of leaks and side effects.
We must initialize the properties in init, since they
are expected to be there ab initio, and we can't call
gtk_accessible_update_property from finalize - it causes
us to recreate an at context and badness follows.
Accessible values storing references and reference lists can be unset by
using NULL to mean "undefined"; since we cannot return the NULL value,
we need to intercept it when collecting a value, and replace it with an
undefined GtkAccessibleValue, which is also the value used as the
default for GtkAccessibleRelation values that store a reference or a
reference list.
Fixes: #2955
Make both gtk_grid_view_new and gtk_grid_view_new_with_factory
take a model as first argument, and make all arguments
allow-none and transfer full.
Update all callers.
Make both gtk_list_view_new and gtk_list_view_new_with_factory
take a model as first argument, and make all arguments
allow-none and transfer full.
Update all callers.
A dropdown without a model is useless, so accept a model
and expression in the constructor. Allow them to be NULL,
but consume them if given. This makes chained constructors
convenient without breaking language bindings.
Drop gtk_drop_down_set_from_strings() and instead add
gtk_drop_down_new_from_strings().
Update all users.
We don't pay attention to item-type anymore, so
drop the item-type property and the _for_item_type()
constructor, and allow passing NULL to the regular
constructor.
We don't make this constructor transfer-full, since
the selection filter model is not a wrapping model
like the others. It is more like fork than a wrap.
This is for consistency with other wrapping list constructors.
We want them all to be transfer full, allow-none.
Also make the constructor return GtkMultiSelection *.
Update all callers.
Make gtk_tree_list_model_new() take the root model
as first argument, and make it transfer full, for
consistency with other wrapping list constructors.
Update all callers.
Still missing here: Make the model property writable,
and allow passing NULL in the constructor.
We don't need as many functions to print out the property, relation, and
state of an accessible. Additionally, we should allow comparing the
accessible attributes with an expected value, and print out the real
accessible value if they do not match.
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.
This is a bit unfortunate, since the aria modelling
doesn't quite agree with ours, so we have to listen
for the togglebutton property change, and we inherit
the pressed state from the togglebutton accessible.
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.
We want to test the accessibility API, as well as the implementation
inside each widget. For that, we should expose an API that lets us
verify that a GtkAccessible has a given role, as well as a given
property.
The API follows the pattern of other GTest API:
- a macro to assert that a condition is respected
- a function that prints out the error message in case of failure
While we have split the various attributes for convenience, there's no
reason why we should have specialised data types for the attributes
container object.
Reduce the amount of subclassing, by handling collection of fundamental
types directly from the generic code paths. We now handle boolean,
tristate, integer, number, string, and relation values in the generic
code path; if an attribute supports the "undefined" value, we return the
undefined value singleton.
Drop roles and properties that were deprecated in WAI-ARIA 1.1, and add
new roles and properties defined in WAI-ARIA 1.2 and later.
We also split the relationship properties into their own enumeration, so
we can keep the GtkAccessibleProperty type more compact.
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.
Each widget type has an accessible role associated to its class, as
roles cannot change during the life time of a widget instance.
Each widget is also responsible for creating an ATContext, to proxy
state changes to the underlying accessibility infrastructure.
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.
The ATContext type is meant to be used as the base class for
implementations of the assistive technology API—the actual mechanism
needed to communicate to components like the screen reader, or any other
AT.
Every time the widget state changes, the ATContext is meant to broadcast
the state change; and every time the AT queries the state of a UI
element, the ATContext is meant to provide that information.
We also have a "test" ATContext implementation, which is meant to be
used to write tests to verify that changes are propagated without
requiring a whole desktop session.
All accessible properties and states may have one of the following
types:
- true/false
- true/false/undefined
- true/false/mixed/undefined
- reference (to another UI element)
- reference list
- integer
- number (real numerical value)
- string
- token (one of a limited set of allowed values)
- token list
See: https://www.w3.org/WAI/PF/aria/states_and_properties#propcharacteristic_value
The GtkAccessibleValue is a simple reference counted type that can be
"subclassed" to implement each value type.
This initial commit adds GtkAccessibleValue and the basic subclasses for
plain boolean, tristate (true/false/undefined), and token types,
including statically allocated values that can be shared instead of
allocated.
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.
The list of roles is taken from the WAI-ARIA 1.2 specification:
https://w3c.github.io/aria/
Some of these roles do not make entirely sense from a GTK application
perspective, but we can remove them before finalizing the API.
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
We are using floats for rgb, and we don't need more precision
for hsl colors either. We use hsl for computing color expressions
like shade(), lighter() and darker(), which are not precisely
specified anyway.
This commit updates the one test where the output changes a
tiny bit due to this.
Setting a width request is not quite enough, since
gtk_widget_set_size_request() only queues a resize
when the widget is visible. Explicitly force one
here. Without this, the popup sometimes shows up
too small.
This is truly a russian doll of documentation formats:
a string containing <> inside an xml fragment in an |[ ]|
gtk-doc example in markdown in a doc comment.
Sadly, something gets escaping wrong, so the <> end up
literally in the docbook and mess up the last step of
our document formatting, even after turning them into
entities.
Work around this with an extra level of entities that
really shouldn't be necessary.
Commit 0145809a94 replace the response-requested
signal with an action, but didn't actually remove the emission
of that no-longer-existing signal.
Fixes: #2942
SSave the missing keys as a bitset and iterate over that bitset in the
step function.
Solves the problem with a large UI block at the beginning of a sort
operation when all the keys were generated, in particular when key
generation was slow.
Benchmarks for maximum time taken by a single main loop callback:
initial sort with complex GFileInfo keys
old new
32,000 items 137ms 3ms
128,000 items 520ms 31ms
initial sort with string keys
old new
32,000 items 187ms 1ms
128,000 items 804ms 3ms
When updating a (partially) sorted model, take the known runs for the
existing sort and apply them to the new sort. That way, we don't have to
check the whole model again.
Benchmarks:
appending half the items to a model of strings
old new
512,000 items 437ms 389ms
1,024,000 items 1006ms 914ms
appending 10% of the items to a model of strings
old new
512,000 items 206ms 132ms
1,024,000 items 438ms 301ms
appending 1 item to a model of strings
old new
64,000 items 1.8ms 0.00ms
512,000 items --- 0.01ms
Previously, the sort was not stable when items were added/removed while
sorting or the sort algorithm was changed.
Now the sort looks at the item position (via the key's location in the
keys array) to make sure each comparison stays stable with respect to
this position.
This massively speeds up sorting with expensive sort functions that it's
the most worthwhile optimization of this whole branch.
It's slower for simple sort functions though.
It's also quite a lot slower when the model doesn't support sort keys
(like GtkCustomSorter), but all the other sorters do support keys.
Of course, this depends on the number of items in the model - the number
of comparisons scales O(N * log N) while the overhead for key handling
scales O(N).
So as the log N part grows, generating keys gets more and more
beneficial.
Benchmarks:
initial sort of a GFileInfo model with display-name keys
items keys
8,000 items 715ms 50ms
64,000 items --- 554ms
initial sort of a GFileInfo model with complex keys
items keys
64,000 items 340ms 295ms
128,000 items 641ms 605ms
removing half a GFileInfo model with display-name keys
(no comparisons, just key freeing overhead of a complex sorter)
items keys
512,000 items 14ms 21ms
2,048,000 items 40ms 62ms
removing half a GFileInfo model with complex keys
(no comparisons, just key freeing overhead of a complex sorter)
items keys
512,000 items 90ms 237ms
2,048,000 items 247ms 601ms
GtkSortKeys is an immutable struct that can be used to manage "sort
keys" for items.
Sort keys are memory that is created specifically for sorting. Because
sorting involves lots of comparisons, it's a good idea to prepare the
data relevant for sorting in advance and sort on that data.
In measurements with a PropertyExpression on a string sorter, it's about
??? faster
Instead of one item keeping the item + its position and sorting that
list, keep the items in 1 array and put the positions into a 2nd array.
This is generally slower while sorting, but allows multiple improvements:
1. We can replace items with keys
This allows avoiding multiple slow lookups when using complex
comparisons
2. We can keep multiple position arrays
This allows doing a sorting in the background without actually
emitting items-changed() until the array is completely sorted.
3. The main list tracks the items in the original model
So only a single memmove() is necessary there, while the old version
had to upgrade the position in every item.
Benchmarks:
sorting a model of simple strings
old new
256,000 items 256ms 268ms
512,000 items 569ms 638ms
sorting a model of file trees, directories first, by size
old new
64,000 items 350ms 364ms
128,000 items 667ms 691ms
removing half the model
old new
512,000 items 24ms 15ms
1,024,000 items 49ms 25ms
1. Run step() for a while to avoid very short steps
This way, we batch items-changed() emissions.
2. Track the change region accurately
This way, we can avoid invalidating the whole list if our step just
touched a small part of a huge list.
As this is a merge sort, this is a common occurence when we're buys
merging chunks: The rest of the model outside those chunks isn't
changed.
Note that the tracking is accurate: It determines the minimum change
region in the model.
This will be important, because the testsuite is going to test this.
... and use it in the SortListModel
Setting runs allows declaring already sorted regions so the sort does
not attempt to sort them again.
This massively speeds up partial inserts where we can reuse the sorted
model as a run and only resort the newly inserted parts.
Benchmarks:
appending half the model
qsort timsort
128,000 items 94ms 69ms
256,000 items 202ms 143ms
512,000 items 488ms 328ms
appending 1 item
qsort timsort
8,000 items 1.5ms 0.0ms
16,000 items 3.1ms 0.0ms
...
512,000 items --- 1.8ms
Simply replace the old qsort() call with a timsort() call.
This is ultimately relevant because timsort is a LOT faster in merging
to already sorted lists (think items-chaged adding some items) or
reversing an existing list (think columnview sort order changes).
Benchmarks:
initially sorting the model
qsort timsort
128,000 items 124ms 111ms
256,000 items 264ms 250ms
The model now tracks the original positions on top of just the items so that
it can remove items in an items-changed emission.
It now takes twice as much memory but removes items much faster.
Benchmarks:
Removing 50% of a model:
before after
250,000 items 135ms 10ms
500,000 items 300ms 25ms
Removing 1 item:
4,000 items 2.2ms 0ms
8,000 items 4.6ms 0ms
500,000 items --- 0.01ms
This is the dumbest possible sortmodel using an array:
Just grab all the items, put them in the array, qsort() the array.
Some benchmarks (setting a new model):
125,000 items - old: 549ms
new: 115ms
250,000 items - new: 250ms
This performance can not be kept for simple additions and removals
though.
This was preventing any sort of building on macOS, even though the quartz
backend is currently non-functional. Fixing this is a pre-requisite to
getting a new macOS backend compiling.
Changing the selection in the object tree is
not a useful action if we are already in the
object details. Most likely, a user who picks
an object wants to inspect its details, so
just always show them.
Fixes: #1876
Bring back the actions tab; we don't receive
changes anymore, since GtkActionMuxer lost
the GActionGroup signals for this, and the
action observer machinery has no way to listen
for all changes.
Instead of implementing the GActionGroup interface
and using its signals for propagating changes up
and down the muxer hierarchy, use the GtkActionObserver
mechanism. This cuts down on the signal emission
overhead.
