gtk_css_node_ensure_style() recurses over previous siblings to ensure
these have a style before its following sibling. As seen in
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2027 this can
cause us to stack overflow and crash if we have a lot of children.
And even if we don't have *that* many children its still somewhat
bad to have stack depths of the same magnitude as the number of
children, both for performance reasons and debuggability.
Rename the show-separators property to show-row-separators,
and add a matching show-column-separators property. It is
implemented by setting the .column-separators style class
on the column view.
This is an expected feature with rubberband selection:
as you get close to the edge while doing rubberband
selection, the list scrolls to extend your selection.
Implement the typical rubberband selection, including
autoscroll. This is only useful with multiselection,
and not very compatible with single-click-activate.
Therefore, it is not enabled by default, and needs
to be turned on explicitly.
Autoscroll when the pointer gets close to the
edge during column resizing or reordering. This
is similar to what the treeview does, but it is
implemented using a tick callback, and has
variable speed.
Allow rearranging columns by dragging, in the same
way the treeview does.
We add the "dnd" style class to the header while
it is dragged, and we move the header of the dragged
column to the end of its parents children, so that
it gets drawn on top.
Add helper functions that let us temporarily give
a different allocation to headers. These will be
used to implement interactive column reordering
in GtkColumnView.
The listview inside always thinks it gets its full size,
and updates its horizontal adjustment accordingly.
So keep our own adjustment, and update it when allocating.
Tweak the behavior slightly. We don't show
a scrollbar as long as we have at least
min-size available, but we still give the
entire size to the child, up to nat-size.
This matches how viewports handle scroll-minimum.
stat/fstat aren't compatible with GStatBuf on Windows in all cases.
Since we don't really need the file descriptor anyway here replace it with
a g_stat call.
This fixes a compiler warning with 64bit mingw.
And lets us remove this scary ifdeffery.
Since it's a type with sub-classes, we need to use GTypeInstance (at the
very least), otherwise we won't be able to address each sub-class as
such.
This is similar to how GskRenderNode and GdkEvent are handled, with the
added difficulty that GtkExpression is meant to be used in properties,
in order to be deserialised by GtkBuilder. This requires adding a
GParamSpec sub-class that we can match on from within GtkBuilder,
alongside some convenience API for storing a GtkExpression inside a
GValue.
The print backends do some complicated dispose handling
where the implementations call gtk_print_backend_destroy().
Our tests (in particular, the templates test) trigger
situations where we use print backends after dispose,
and they can't handle the printers listmodel being
NULL at that time. So just remove the printers in
dispose, keep the empty liststore until finalize.
There is no agreement that a coverflow widget is
appropriate for GTK 4.
It would be ok as a demo if it could live in gtk-demo,
but that requires us to make GtkListBase public first.
The demo is also somewhat rough and needs more work
to look plausible.
Drop GtkCoverFlow and the related demo for now.
We require a C compiler supporting C99 now. The main purpose of
these fallbacks was for MSVC. From what I can see this is now all supported
by MSVC 2015+ anyway.
The only other change this includes is to replace isnanf() with the
(type infering) C99 isnan() macro, because MSVC doesn't provide isnanf().
This is a somewhat large commit that:
- Adds GtkColumnViewSorter
This is a special-purpose, private sorter implementation which sorts
according to multiple sorters, allowing each individual sorter to be
inverted. This will be used with clickable column view headers.
- Adds a read-only GtkColumnView::sorter property
The GtkColumnView creates a GtkColumnViewSorter at startup that it uses
for this property.
- Adds a writable GtkColumnViewColumn::sorter property
This allows defining per-column sorters. Whenever an application sets a
sorter for a column, the header becomes clickable and whenever
a header is clicked, that column's sorter is prepended to the list of
sorters, unless it is already the first sorter, in which case we invert
its order. No column can be in the list more than once.
Add a mode to GtkListItemWidget that activates on
single click and selects on hover. Make
GtkListItemManager set this on its items
when its own 'property' of the same name is set.
The port is kind of evil, in that it stores either a PangoFontFamily or a
PangoFontFace in the list, depending on if the fontchooser is configured
to select fonts or faces.
It also does not cache the font description anymore, so more calls to
pango_font_describe() may happen.
If both of these issues turn out problematic, the fontchooser would need
to resurrect GtkDelayedFontDescription again and put objects of that
type through the model.
These changes depend on Pango 1.46's introduction of listmodels and
various new getters, so the dependency has been upgraded.
This uses a custom GtkColumnViewTitle widget. So far that widget is
pretty boring, but that will change once we added
resizing, reordering, dnd, sorting, hiding/showing of columns or
whatever UIs we want.
The ColumnView now allocates column widths first and then the individual
rows use the new layout manager which looks at the column allocations to
allocate their children.
It's a GtkListItemWidget subclass that tracks the column it belongs to
and allows the column to track it.
We also use this subclass to implement sizing support so columns share
the same size and get resized in sync.
It's private, no APIs, we don't talk about it. But we will start using
it very soon, so we can do size request caching in columns and avoid
sizegroups...
We only create them in root/unroot (they should be created in
appear/disappear, but that vfunc doesn't exist yet), that way we can
avoid expensive work while the widget isn't used for anything.
This way, we can ensure it's always there when we need it (before the
item gets created) and gone when we don't (if some GC language holds on
to the item after we've destroyed the widget).
Instead of 6 vfuncs, we now have 3 and rely on the factory keeping track
of what it needs to do.
We're doing lots of dancing from one object to another here, but this
will hopefully get simpler with further commits.
This splits GtkListItem into 2 parts:
1. GtkListItem
This is purely a GObject with public API for developers who want to
populate lists. There is no chance to cause conflict with GtkWidget
properties that the list implementation assumed control over and
defines a clear boundary.
2. GtkListItemWidget
The widget part of the listitem. This is not only fully in control of
the list machinery, the machinery can also use different widget
implementations for different list widgets like I inted to for
GtkColumnView.
The widget mostly works out of the box, but some tweaking may be
necessary (in particular in the theme) and the gtk-demo changes might
require removing before this is production-ready.
This reverts commit 6a164ab306dad9096bde736c907494c71086d3c4.
The function was awkward and we now have only one caller again, so we
can fold it back into it.
Nothing really changes, because both ListView and GridView still keep
self->item_manager around, but it's set up to point at the base's item
manager.
This way we can slowly move things to GtkListBase that need the item
manager (like trackers).
- Handle anchor as align + top/bottom
This fixes behavior for cells that are higher than the view
- Add gtk_list_view_adjustment_is_flipped()
This should fix RTL handling of horizontal lists
- Fix scrolling
This should make scrolling more reliable, particularly on short lists
that are only a few pages long.
I couldn't come up with a better way to automatically inherit the scope
in the builder list item factory that didn't involve a magic
incantation in the XML file. And I do not want developers to know magic
incantations to do a thing that should pretty much always be done.
This implements all the keybindings from GtkTreeView that can be
supported.
It does not implement expand-all, because supporting that means
causing the TreeListModel to emit lots of create_model vfuncs which in
turn would cause many items-changed signal which in turn would cause
many signal handlers to run which in turn would make "expand-all" very
reentrant, and I'm uneasy about supporting that.
For the mouse, just add a click gesture to the expander icon that toggles
expanded state.
Focus in the listitem now works like this:
1. If any child can take focus, do not ever attempt
to take focus.
2. Otherwise, if this item is selectable or activatable,
allow focusing this widget.
This makes sure every item in a list is focusable for
activation and selection handling, but no useless widgets
get focused and moving focus is as fast as possible.
It's quite a bit faster now, but the code is also a bit more awkward.
Pain points:
- GtkTreeListModel cannot be created in UI files because it needs
a CreateModelFunc.
Using a signal for this doesn't work because autoexpand wants to
expand the model before the signal handler is connected.
- The list item factory usage is still awkward. It's bearable here
because the list items are very simple, but still.
This is a container widget that takes over all the duties of tree
expanding and collapsing.
It has to be a container so it can capture keybindings while focus is
inside the listitem.
So far, this widget does not allow interacting with it, but it shows the
expander arrow in its correct state.
Also, testlistview uses this widget now instead of implementing
expanding itself.
Implement measuring and allocating items - which makes the items appear
when drawing and allows interacting with the items.
However, the gridview still does not allow any user interaction
(including scrolling).
Due to the many different ways to set factories, it makes sense to
expose them as custom objects.
This makes the actual APIs for the list widgets simpler, because they
can just have a regular "factory" property.
As a convenience function, gtk_list_view_new_with_factory() was added
to make this whole approach easy to use from C.
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.
