That stupid space in the bottom right when n_items isn't a multiple of
n_columns needs its own tile, or we'll get errors about not finding a
tile.
So make one.
Otherwise, when removing the columns, each column will trigger a
sorter::changed signal emission.
And because sorters are often still connected to a sortlistmodel, we
can't skip that emission and need to do it.
But we only need to do it once.
The previous check does not longer work.
When a model gets all items deleted, there will still be existing tiles
until the next time garbage collection is run.
So do that before checking if the list is empty.
Instead of making it 2 vfuncs for getting horizontal and vertical area,
make it one vfunc to get the area.
Also rewrite the implementations to use the tile's area instead of
trying to deduce things with fancy math.
Instead of randomly changing tiles, the listitemmanager gains a split
vfunc that listview and gridview implement so they can keep their tile
areas intact. The listitemmanager will now conform to these rules:
1. Never delete a tile.
This ensures that all areas stay intact.
2. Never change the n_items of a tile other than setting them to 0.
This causes "empty" areas to appear, but listview/gridview can
easily check for them by checking for tile->n_items == 0.
gtk_list_tile_gc() will get rid of them.
3. Adding items always creates new tiles that are added with empty area.
That way they don't interrupt any existing machinery until the next
allocation.
4. Adding/removing widgets has no effect on areas
This is useful in particular when scrolling where new widgets are
moving between tiles. When the manager moves the widgets, it may
split some areas, but will not remove any existing tiles, so the
whole area stays intact and the list can deal with further scroll
events before an allocation.
This improve the situation for #3334
Instead of the custom size property, use the new tile size.
Also introduce the ability to split tiles, so that gridview can split a
layout that would look like (question mark denoting cells without a
widget, which in this case would be a single tile)
█ █ █ ? ?
? ? ? ? ?
? ? ? ? ?
? ? ?
into 3 rectangular tiles like so:
█ █ █ A A
B B B B B
B B B B B
C C C
This of course also means we need to be able to merge those tiles again
when cells got added/deleted or the gridview was resized. For that job,
gtk_list_tile_gc() exists now, which removes tiles without items and
merges adjacent tiles without widgets.
... and use it to handle ListView allocations.
Nothing spectacular, just proof of concept.
The code introduces the idea that every tile stores its area (others
would call it "allocation", but I avoided that because tiles aren't
widgets). This should allow moving lots of code into gtklistbase.c and
not require special handling inside ListView and GridView.
And that in turn hopefully makes it easier to add more features (like
sections and so on.)
* Instead of using a gpointer to refer to it, use the GtkListTile type.
* Use gtk_list_tile_get_foo() instead of
gtk_list_item_manager_get_tile_foo() naming.
GLib 2.75 started checking if a GFileInfo was created with the attribute
we're querying, instead of failing silently and leaving us in an
inconsistent state.
Turns out that GtkFileChooserWidget, GtkFileSystemModel, and GtkPathBar
trip the newly introduced check.
The GL renderer was creating sripes for nodes that were scaled in
particular ways, probably due to rounding errors.
This testsuite focuses on one of those stripes to make sure they are
gone.
This test fails if we naively create fullscale
intermediate offscreens. This was fixed in the
previous commits.
This tests the fixes in 22ba6b1f33 (for
cairo) and 3a0152b65f (for GL).
Use the same approach and only create an offscreen
that is big enough for the clipped part of the scaled
texture.
If the clipped part is still too large for a single
texture, we give up and just render the texture without
filters (using the regular texture rendering code path
which supports slicing).
The following commit will add the texture-scale-magnify-10000x
test which fails without this fix.
Scale nodes can use large scale factors and we don't want to create
insanely huge Cairo surfaces.
A subsequent commit will add the texture-scale-magnify-10000x
test which fails without this fix.
Cairo surfaces are created transparent.
And even if they weren't, overdrawing with transparency wouldn't erase
what's in the surface because it's a no-op.
It would require CAIRO_OPERATOR_CLEAR or CAIRO_OPERATOR_SOURCE.
GtkAccessible implementations in C can get away returning objects just
by shuffling pointers around, but higher level languages prefer using
full ownership transfer in virtual functions.
Fixes: #5615
