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
This reverts commit 40d4441fd8.
The accessible parent of the child widget in a GtkStackPage is cleared
when the GtkATContext gets disposed, so we don't need to unset it
ourselves. This also avoids a temporary vivification of the GtkATContext
during dispose.
If the early return path in `emit_property_changed()` is taken, and
`value` is floating, it will be leaked. Fix that by sinking `value` on
entry to the function.
Spotted by asan:
```
Direct leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af)
#1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130
#2 0x7f44764f6d8a in g_slice_alloc ../../source/glib/glib/gslice.c:252
#3 0x7f447654655d in g_variant_alloc ../../source/glib/glib/gvariant-core.c:565
#4 0x7f447654664c in g_variant_new_from_bytes ../../source/glib/glib/gvariant-core.c:608
#5 0x7f4476536ed5 in g_variant_new_take_string ../../source/glib/glib/gvariant.c:1307
#6 0x7f4475c75ada in gtk_at_spi_context_state_change ../../source/gtk4/gtk/a11y/gtkatspicontext.c:1112
#7 0x7f44758ee194 in gtk_at_context_update ../../source/gtk4/gtk/gtkatcontext.c:694
#8 0x7f44758dbfcf in gtk_accessible_update_property ../../source/gtk4/gtk/gtkaccessible.c:326
#9 0x7f4475b5abe3 in gtk_widget_set_tooltip_text ../../source/gtk4/gtk/gtkwidget.c:9740
#10 0x58439d in gs_updates_page_update_ui_state ../../source/gnome-software/src/gs-updates-page.c:302
#11 0x5857dc in gs_updates_page_set_state ../../source/gnome-software/src/gs-updates-page.c:403
#12 0x5879f1 in gs_updates_page_load ../../source/gnome-software/src/gs-updates-page.c:636
#13 0x58822d in gs_updates_page_reload ../../source/gnome-software/src/gs-updates-page.c:678
#14 0x50ff48 in gs_page_reload ../../source/gnome-software/src/gs-page.c:731
#15 0x5491ce in gs_shell_reload_cb ../../source/gnome-software/src/gs-shell.c:830
#16 0x7f4477363f54 in g_cclosure_marshal_VOID__VOID ../../source/glib/gobject/gmarshal.c:117
#17 0x7f447735e0ad in g_closure_invoke ../../source/glib/gobject/gclosure.c:832
#18 0x7f4477391f3f in signal_emit_unlocked_R ../../source/glib/gobject/gsignal.c:3802
#19 0x7f4477390c13 in g_signal_emit_valist ../../source/glib/gobject/gsignal.c:3555
#20 0x7f4477391324 in g_signal_emit ../../source/glib/gobject/gsignal.c:3612
#21 0x7f447705b3c3 in gs_plugin_loader_reload_delay_cb ../../source/gnome-software/lib/gs-plugin-loader.c:1538
#22 0x7f44764bd140 in g_timeout_dispatch ../../source/glib/glib/gmain.c:5054
#23 0x7f44764b9eb1 in g_main_dispatch ../../source/glib/glib/gmain.c:3460
#24 0x7f44764bb72c in g_main_context_dispatch ../../source/glib/glib/gmain.c:4200
#25 0x7f44764bba15 in g_main_context_iterate ../../source/glib/glib/gmain.c:4276
#26 0x7f44764bbbfa in g_main_context_iteration ../../source/glib/glib/gmain.c:4343
#27 0x7f44769ef655 in g_application_run ../../source/glib/gio/gapplication.c:2589
#28 0x4f2da5 in main ../../source/gnome-software/src/gs-main.c:49
#29 0x7f4474e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This particular relation was not exposed to at-spi2.
Exposing it required adding a missing at-spi2 relation variant, but it was introduced
in at-spi2-core 2.26, so that's likely safe as well.
It was, for some reason, mapped to ATSPI_ROLE_SECTION, and GTK_ACCESSIBLE_ROLE_SECTION was mapped to
ATSPI_ROLE_FILLER, so the mapping is reversed. So, reverse it and make it correct.
