This is a selection model that stores the selection
state in a boolean property of the items, and thus
persists across reordering and similar changes.
Fixes: #2826
The selection model will only emit one of items-changed
or selection-changed, so when we handle an items-changed,
we must assume that selection state may have changed for
any of the newly added items.
This fixes lingering selection state in the visible range
if you change the sorting of the colors demo.
Fixes: #2827
Move the selection changes to button release, to
avoid conflict with the drag gesture for rubberbanding.
This avoids peeking at the parent, and is generally
nicer.
Among other things, you can now shift-click to select
a range in the colors demo in gtk4-demo.
When I changed things to only collect the set
in the stop() function, I overlooked that this
has the side-effect of only handling items which
are backed by a widget at the time stop() is called.
If we make a big rubberband and autoscroll down too
far, we loose the items that go out the visible range
at the top. Fix that by maintaining the set as we go.
It's finally unused.
Accessible types should either watch properties they are interested in
directly, or should have (private) API to allow widgets to update the
accessible state directly.
Now that we don't have any additional subclasses of GtkEntryAccessible
in GTK, we can drop all the conditional fluff in the base class.
We still need to subscribe to the global notify signal, because of the
sheer amount of properties watched by GtkEntryAccessible.
GtkPasswordEntryAccessible is not a GtkEntryAccessible any more, so it
will need a proper implementation of various interfaces and
functionality in order to work like any other entry.
We're already listening to the adjustment property on the spin button,
there's no need to reset the adjustment on widget set/unset, since the
accessible instance is always tied to the same widget.
Drop the GtkWidgetAccessibleClass.notify_gtk and the
AtkObjectClass.initialize overrides: they don't do anything relevant.
Instead, have GtkProgressBar update the accessible state when the
fraction changes.
Do not use a generic "notify" signal handler.
Additionally, clean up the GtkIconViewAccessible implementation to bring
it up with modern idiomatic GObject.
It feels slightly wrong to have GtkOrientable operate on widgets, but at
least what happens when an orientable widget changes orientation should
be part of GtkWidget.
This will allow to add more state changes without accessing widget state
from the outside of gtkwidget.c.
We expect widgets to use their own derived GtkWidgetAccessible type,
these days, and given that we hard code the default accessible type of a
GtkWidget to GtkWidgetAccessible, and that we enforce the dependency of
the type passed to gtk_widget_class_set_accessible_type(), the registry
code path is clearly unused.
The tooltip handling in GtkWidget is "special":
- the string is stored inside the qdata instead of the private
instance data
- the accessors call g_object_set() and g_object_get(), and the
logic is all inside the property implementation, instead of
being the other way around
- the getters return a copy of the string
- the setters don't really notify all the involved properties
The GtkWidgetAccessible uses the (escaped) tooltip text as a source for
the accessible object description, which means it has to store the
tooltip inside the object qdata, and update its copy at construction and
property notification time.
We can simplify this whole circus by making the tooltip properties (text
and markup) more idiomatic:
- notify all side-effect properties
- return a constant string from the getter
- if tooltip-text is set:
- store the text as is
- escape the markup and store it separately for the markup getter
- if tooltip-markup is set:
- store the markup as is
- parse the markup and store it separately for the text getter
The part of the testtooltips interactive test that checks that the
getters are doing the right thing is now part of the gtk testsuite, so
we ensure we don't regress in behaviour.
When exclusive is TRUE, we would not always emit a
::selection-changed signal that covers all the items
that were unselected.
This commit includes a test.
Tell reordered columns to reorder their cells to
the new position. This is necessary to get things
like separators right. The visible symptom of this
problem was the lack of the right border when the
last column is reorder to another position, since
the title widget was still the last in its container,
so :last-child applied.
