Simplify all view model APIs and always return G_TYPE_OBJECT as the
item-type for every model.
It turns out nobody uses item-type anyway.
So instead of adding lots of APIs, forcing people to think about it and
trying to figure out how to handle filter or map models that modify item
types, just having an easy life is a better approach.
All the models need to be able to deal with any type of object going
through anyway.
When the position is 0, we can't check for unchanged
elements below with gtk_bitset_size_in_range. And
we don't need to, either.
And be careful when translating [start,length]
intervals to [first,last] ones. Off-by-one errors
lurk everywhere.
GtkTextLayout is private now and therefore we can drop all of
the indirection through the class vtable. Instead, just call the
implementations directly and remove the unused vtable entries
for default signal handlers.
Rename the DataList object to TreeData, in preparation
for adding a ListData object for list models. While
we are touching it, modernize it a bit (drop the Private
struct, use a layout manager, etc).
This makes the inspector lock up when used with any production
size list model, and blocks access to properties of the model
itself. Instead, we'll make the model available as an object
and add a data tab for list model contents, like we already
do for tree models.
In particular, it will NULL-ified the current global context if this is
the finalized one, avoiding dangling invalid pointers.
Would have been a cherry-pick from branch gtk-3-24 of commit
b592ded80a, but files moved.
Even if `gtk_expression_watch()` will do the same, we're calling public
API, so we should perform a check at the point of use, to ensure that
warnings are easily debuggable.
Use GTK_DEBUG=builder-objects to make GtkBuilder warn
if a named object from a ui files doesn't get claimed
by gtk_builder_get_object(). This is useful for finding
dead wood in .ui files.
Always keep the order:
- [value]
- [marks.top]
- [marks.bottom]
- trough
Which makes sense given the rendering order. Slider should be drawn
after the marks.
Makes it possible to simply remove the custom snapshot implementations
in scale and range. And Adwaita does not depend on the node order
anyway.
Take ordering of cursor_position and selection_bound
into account when copying text to the clipboard, and
ensure that both orders work the same.
Fixes: #2898
We don't want to select on focus-in when the focus
comes from a child. The case where this does harm
is when you activate copy or paste actions from the
context menu. We close the menu before triggering the
action, and if that causes the text in the entry to
be selected, unexpected things happen, since the action
applies to the current selection.
Fixes: #2869
This reverts commit 67c2665028.
The splicing we do here has the important side-effect
of shifting the preedit attributes to the right position.
Without it, we end up always underlining the first chars
in the entry, regardless where the preedit happens.
This makes sure that we do actual key input right
in the middle between all the capture and bubble
event controllers, and are not dependent on the
ordering of those controllers.
The bug that triggered this change was that the
shortcut for activation (Enter) was getting triggered
before the key input, causing Ctrl-Shift-u hex
to stop working, since it never received the enter
to commit the sequence.
The gesture should claim the sequence after triggering uncancellable
actions, like pasting, showing a menu or selecting words/lines. A
single first button press initiating a drag does not trigger
anything yet, so it should avoid claiming the sequence.
The gesture should be accepted whenever it triggers uncancellable
actions in the widget. This means it should be accepted if the
click does result in toggling the switch.
This leaves the pan gesture room to handle dragging the handle.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2895
... and do the right things:
nothing: selection = rubberband
ctrl: selection = selection OR rubberband
shift: selection = selection AND (NOT rubberband)
ctrl+shift: selection = selection XOR rubberband
(not sure this one makes sense, but toggling is fun)
Instead of storing the active items as we go, compute the affected items
whenever the rubberband changes and in particular when the rubberband
ends.
That way, the rubberband is guaranteed to select a rectangle even
after scrolling very far.
This is achieved by having a get_items_in_rect() vfunc that selects all
the items in the rubberbanded rectangle and returns them as a bitset.
The rubberband is now handled on the list coordinate system.
When starting the rubberband, we track the item under the pointer and
follow it when it is moving.
This may lead to the rubberband start position changing position and
while this may be confusing, it alerts users to the fact that something
crazy is going on.
In particular, track which items remain in ::items-changed
signal emissions.
But the main use case is sorting, which causes items-changed(0, n, n)
to be emitted.
