Shift-clicking to extend selections now also works, imitating the
behavior of normal clicking and Windows Explorer (but not treeview):
1. We track the last selected item (normally, not via extend-clicking).
2. When shift-selecting, we modify the range from the last selected item
to this item the same way we modify the regular item when not using
shift:
2a. If Ctrl is not pressed, we select the range and unselect everything
else.
2b. If Ctrl is pressed, we make the range have the same selection state
as the last selected item:
- If the last selected item is selected, select the range.
- If the last selected item is not selected, unselect the range.
Make sure the APIs follow a predictable path:
setup
bind
rebind/update (0-N times)
unbind
teardown
This is the first step towards providing multiple different factories.
... and replace the anchor tracking with a tracker.
Trackers track an item through the list across changes and ensure that
this item (and potentially siblings before/after it) are always backed
by a GtkListItem and that if the item gets removed a replacement gets
chosen.
This is now used for tracking the anchor but can also be used to add
trackers for the cursor later.
Remove a bunch of API from the headers that isn't used anymore and then
refactor code to not call it anymore.
In particular, get rid of GtkListItemManagerChange and replace it with a
GHashTable.
This is implemented by using actions, which are a neat trick to get to
allow the ListItem to call functions on the ListView without actually
needing to be aware of it.
This way, newly displayed rows don't play an unselect animation (text
fading in) when they are unselected, but the row was previously used for
a selected item.
Instead of just destroying all items and then recreating them (or even
hide()ing and then show()ing them again (or even even repositioning
them in the widget tree)), just try to reust them in the order they are.
This works surprisingly well when scrolling and most/all widgets
just moved.
We reorder widgets start to end, so when reusing a list item, we
correctly know the previous sibling for that list item, but not the
next sibling yet. We just know the widget it should ultimately be in
front of.
So we can do a more correct guess of the list item's place in the widget
tree if we think about where to place an item like this.
Actually using this change will come in the next commit.
This is the big one.
The listview only allocates 200 rows around the visible row now.
Everything else is kept in ListRow instances with row->widget == NULL.
For rows without a widget, we assign the median height of the child
widgets as the row's height and then do all calculations as if there
were widgets that had requested that height (like setting adjustment
values or reacting to adjustment value changes).
When the view is scrolled, we bind the 200 rows to the new visible area,
so that the part of the listview that can be seen is always allocated.
The anchor is now a tuple of { listitem, align }.
Using the actual list item allows keeping the anchor across changes
in position (ie when lists get resorted) while still being able to fall
back to positions (list items store their position) when an item gets
removed.
The align value is in the range [0..1] and defines where in the visible
area to do the alignment.
0.0 means to align the top of the row with the top of the visible area,
1.0 aligns the bottom of the widget with the visible area and 0.5 keeps
the center of the widget at the center of the visible area.
It works conceptually the same as percentages in CSS background-position
(where the background area and the background image's size are matched
the same way) or CSS transform-origin.
We now don't let the functions create widgets for the item from the
listmodel, instead we hand out a GtkListItem for them to add a widget
to.
GtkListItems are created in advance and can only be filled in by the
binding code by gtk_container_add()ing a widget.
However, they are GObjects, so they can provide properties that the
binding code can make use of - either via notify signals or GBinding.
Also refactor the whole list item management yet again.
Now, list item APIs doesn't have bind/unbind functions anymore, but only
property setters.
The item factory is the only one doing the binding.
As before, the item manager manages when items need to be bound.
Require that items created with the manager get destroyed via the
manager.
To that purpose, renamed create_list_item() to acquire_list_item() and
add a matching release_list_item() function.
This way, the manager can in the future keep track of all items and
cache information about them.
It's all stubs for now, but here's the basic ideas about what
this object is supposed to do:
(1) It's supposed to be handling all the child GtkWidgets that are
used by the listview, so that the listview can concern
itself with how many items it needs and where to put them.
(2) It's meant to do the caching of widgets that are not (currently)
used.
(3) It's meant to track items that remain in the model across
items-changed emissions and just change position.
(2) It's code that can be shared between listview and potential
other widgets like a GridView.
It's also free to assume that the number of items it's supposed to
manage doesn't grow too much, so it's free to use O(N) algorithms.
The thing we're actually doing is create and maintain a widget for every
row. That's it.
Also add a testcase using this. The testcase quickly allocates too many
rows though and then becomes unresponsive though. You have been warned.
Thisis the abstraction I intend to use for creating widgets and binding
them to the item out of the listview.
For now this is a very dumb wrapper around the functions that exist in
the API.
But it leaves the freedom to turn this into public API, make an
interface out of it and most of all write different implementations, in
particular one that uses GtkBuilder.
<lookup>foo</lookup>
is now short for
<lookup>
<constant>foo</constant>
</lookup>
ie it looks up the object with the given name so it can then do a
property lookup with it.
This is the most common operation, so it's a nice shortcut.
A constant without a type is assumed to be an object. This is the most
common case and allows
<constant>foo</constant>
without requiring updates to the type whenever the foo object changes.
The sort of the sortlistmodel is now stable with respect to the original
list model.
That means that if the sorter compares items as equal, the model
will make sure those items keep the order they were in in the original
model.
Or in other words: The model guarantees a total order based on the
item's position in the original model.
We need to keep this data around for changes in future commits where we
make the sorting stable.
An important part of the new data handling is that the unsorted list
needs to always be dealt with before the sorted list - upon creation we
rely on the unsorted iter and upon destruction, the sorted sequence
frees the entry leaving the unsorted sequence pointer invalid.
This change does not do any behavioral changes.
This is an enum that we're gonna use soon and it's worth introducing as a
separate commit.
The intention is to have meaningful names for return values in
comparison functions.
Use a weak ref to invalidate bindings. Make sure that this happens
before creating any watches, so that notifies from the
watched expression about changes will not trigger set_property() calls
during dispose()/finalize().
Invalidating also ensures that the watches aren't removed, which can
trigger warnings if the watches are watching the object itself, and the
weak refs cannot be removed anymore.
Users provide a search filter and an expression that evaluates the items
to a string and then the filter goes and matches those strings to the
search term.
GtkExpressions allow looking up values from objects.
There are a few simple expressions, but the main one is the closure
expression that just calls a user-provided closure.
We want to deliver crossing events to controllers
with scope same-native as long as at least one of
the targets is on the same native. As a new approach,
treat out-of-scope targets like NULL, and deliver
crossing events as long as one of the targets is
not NULL.
Iterate the shortcuts we found in order, not in
reverse. Otherwise, we always end up activating
the last_selected one, since it is last in the
list.
This broke in fb9b54d4b2 when a list was
turned into an array.
We don't want wrapping labels to cause tooltips to
have excessive height, so we need to set a reasonable
value for width-chars, without forcing short tooltips
into a full line length. Also be careful to respect
preexisting line breaks (we have such examples in
widget factory).
Drop apis and code related to appmenus from
both GtkApplication and GtkApplicationWindow.
We still keep the menubar support, since it
is needed for system integration on OS X.
Fixes: #2731
We are using floating point for coordinates
everywhere now, so be consistent here.
This commit also changes the implementation of
gtk_fixed_get_child_position to work with
non-translation child transforms.
We are passing the event to the tooltip handle_event
function at the very end. Unfortunately, the target_widget
may have already died at that point. We prevent that
by taking a ref during propagage_event, but the tooltip
code was outside of that. Keep a ref until the very
end ot prevent crashes.
Trash monitor queries info from gvfsd-trash after each file monitor
change which can be problematic when too many changes happen in
a short time. Let's rate limit the number of queries...
Fixes: #1010
The expected behavior is that we trigger a keyboard-driven
interactive move or resize operation. But that doesn't work
with common compositors like mutter or weston, so lets not
expose non-working menuitems.
It is possible that the target widget is already
unparented at the time that we call the tooltips
handle_event function. Quietly return in that case,
no need to emit a critical.
When displaying accelerators, differentiate keypad
symbols with a 'KP' prefix. Fixing a 17 year old bug.
Update expected output in accelerator tests.
Fixes: #227
Get the native transform only once, for all overlays. Unfortunately we
have to undo this for the updates overlay since that one gets values
in surface coordinates.
Provide the minimal info necessary. Improves apparent responsiveness
(since we don't visibly clear and repopulate the list) and saves doing
file stat/reads on every file in the result set.
The filechooser tries to figure out whether it got results by poking
the model, but all files might go through the async GFileInfo querying
state.
Make all search engines (and the composite one) just notify about this
fact, so the file chooser can behave appropriately without waiting for
the async operations to finish.
There are a few more places where we were forgetting
to apply the surface->native transform. With these
changes, tooltips are positioned correctly when
the toplevel has padding applied.
Fixes: #1619
If you run weston with the headless backend, you get a Wayland
display with no seat, which is just fine by the protocol.
gdk_display_get_default_seat() returns NULL in this case. Various
widgets assume that we always have a seat with a keyboard and a
pointer, since that is what X guarantees. Make things survive
without that, so we can run the testsuite under a headless
Wayland compositor.
Once upon a time, there was a function called gdk_event_get_scroll_deltas().
It returned %TRUE when an event had scroll deltas and that was used as the
condition to decide whether to push scroll deltas to the scroll history,
even when the both deltas are 0 for the stop event at the end of scrolling.
When GtkScrolledWindow kinetic scrolling code was adapted for
GtkEventControllerScroll, it was replaced with a (dx != 0 && dy != 0)
check. This prevented the stop event from getting into the history, and
instead allowed non-smooth scrolling to affect the history as they have
synthetic deltas with one of the values being -1 or 1 and the other on 0.
Instead, check the direction as we already have it as a local variable.
The api contract for size_allocate() vfuncs is
that they must allocate all the children that are
going to be snapshotted in snapshot(). The flowbox
size_allocate() was just bailing out when the children
request a size of 0x0, leading to an assertion in
snapshot() vfunc later. Just allocate all children
a size of 0x0 in this case.
The previous fix broke the case where we're Shift-Tabbing
from a listboxrow child to the row itself. This was causing
the widget-factory2.tab-backward test to fail. Fix it, by
grabbing the focus to the row explicitly.
If a row has content that is focus-on-click, and is set
to focus-on-click itself, then the row steals the focus
fromt he content, since it uses focus-on-click on button
release, as opposed to button press. Avoid that by
refusing to take focus if it is already on some
descendent of the row.
This was showing up in the widget-factory listbox on
page 2, where clicking on the spinbutton would briefly
put the focus on the spinbutton, only to lose it to
the row.
This was not working in the case that the existing child
is not a scrollable. It showed up as crashes of the
scrolling benchmark in gtk4-demo when switching examples.
The previous code was unreffing the window twice, which caused problems
during dialog destruction. Move to g_list_store_find instead of
iterating manually.
ref() the window before and unref() after. g_list_store_remove will
actually unref() the window, since the toplevel_list owns its own
reference.
Fixes#2741Fixes#2742
I thought I could get away with just unrealizing the
window, but it turns out that gtk_window_hide() is the
place where we remove grabs when a modal dialog goes
away, so we ended up with stuck grabs.
Nested main loops are bad, as they introduce layers of complexity caused
by the potential re-entrancy in the case of multiple event sources, like
IPC, threads, etc. Additionally, the programming model they provide—stop
the world while spinning a new loop—does not conform to the event-driven
model employed by GTK.
Replace it with an explicit nested main loop, as we need to block the
signal handler currently being emitted depending on the response of the
overwrite confirmation dialog.
This is a bit of a hack, and the only reason we need it is that the
print dialog will load the last used path as the output file name, when
printing to a file; this means that, in theory, it would be possible to
press Print without selecting a file, and accidentally overwriting an
existing file.
It would be much simpler if we did not store the last used path, and
always explicitly asked the user to select a file; this would avoid
destructive actions, and would allow us to rely on the overwrite
confirmation dialog right inside the file chooser.
Nested main loops are bad, as they introduce layers of complexity caused
by the potential re-entrancy in the case of multiple event sources, like
IPC, threads, etc. Additionally, the programming model they provide—stop
the world while spinning a new loop—does not conform to the event-driven
model employed by GTK.
Let keyboard/pointer paths handle their own events, and find the
current focus. The event will be propagated through instead of
being just emitted on the toplevel.
This makes it handled throughout all the gestures that want to
know about it.
It is unreliable to use the widget dom api to locate
action widgets. For example in a headerbar, they might
be deeper in the hierarchy, with boxes in between.
Therefore, make GtkDialog keep a list of action widgets,
and use that when operating on action widgets.
When GtkBox stops being a container, GtkShortcutsSection
will also no longer be a container. So, stop overriding
container vfuncs, and instead add a buildable implementation
that does the right thing.
When GtkBox stops being a container, GtkShortcutsGroup
will also no longer be a container. So, stop overriding
container vfuncs, and instead add a buildable implementation
that does the right thing.
