We're printing out the file we're testing once we succeed, but it's hard
to know which file caused a failure. Let's add a g_test_message()
directive so we can look in our logs.
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.
When displaying accelerators, differentiate keypad
symbols with a 'KP' prefix. Fixing a 17 year old bug.
Update expected output in accelerator tests.
Fixes: #227
If we don't destroy the surface, it leaks.
GDK backends keep an extra reference on the
surface for the external resources associated
with it, and only drop it in destroy().
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.
When moving from gtk_container_forall to the widget dom
api, we are now iterating over all children of the listbox,
including headers, separators, etc. So, skip everything
that is not a listboxrow, to make the tests work again.
This test was relying on gtk_container_forall returning
the visual (ie sorted) order of children, while iterating
with the widget dom api gives the insertion order.
Instead of using gtk_container_forall, use
gtk_list_box_row_get_index to reconstruct the visual
order.
One of the treeview tests was calling gtk_widget_destroy
on a child instead of the toplevel, which leaks the toplevel
unnecessarily. Plus, we're moving towards allowing destroy
only on toplevels.
Add template tests that show the complex dialogs before
destroying them. This reveals that we are leaking in
several of them. These leaks don't show up if the
dialogs are destroyed right away, as the existing
tests do.
Disable the two failing tests for now:
/template/GtkFileChooserDialog/show
/template/GtkPrintUnixDialog/show
It turns out that we have a ref leak at the very
core of our dom model :( gtk_widget_insert_before/after
leak a reference if the widget was already under
the same parent. This is something that GtkBox
frequently does. It shows up e.g. when packing
widgets at the end in a headerbar.
