The code previously forgot to include the left child of the model's
node. Which of course only happened if that child wasn't NULL, which is
a common case.
Found and test provided by Matthias Clasen.
Differentiate between wrapping around and
stopping at the end of the focus chain.
Update the existing tests, and add two
new ones where the difference matters.
Add a test that enumerates the focus chain by
emitting move-focus repeatedly, and compares
the result to expected output.
The test expects a ui file and a reference
file as input. The reference file can be created
using the --generate option.
We want to use a gdk_surface_new_popup for popups,
and align the constructor names with the surface
types, so rename
gdk_surface_new_popup -> gdk_surface_new_temp
gdk_surface_new_popup_full -> gdk_surface_new_popup
The temp surface type will disappear eventually.
The calls used old bugzilla URLs and nobody cared about that.
So apparently they are very unused.
There's also a potential conflict between gitlab and bugzilla URLs and
what base bug to use there.
The old usages have been converted to comments.
The need of a specialised fixed layout container that can be placed into
a GtkScrolledWindow ceased to exist once GtkScrolledWindow gained the
ability to automatically interpose a GtkViewport when adding a child
that does not implement GtkScrollable.
All the other justifications that led to the existence of GtkLayout as a
separate widget from GtkFixed have been largely made irrelevant in the
20 years since its inception.
GtkLayoutChild instances are created on demand once we have a widget, a
GtkLayoutManager, and a child widget. This makes testing their creation
fairly tricky.
Let's skip them, for the time being.
Check that we get the expected sequences of focus
change events for the nonlinear, inferior and ancestor
cases.
It would be nice to do the same checks for crossing
events, but we have no gtk_window_set_hover().
Make the API expect a tranform of the proper category instead of
doing the check ourselves and returning TRUE/FALSE.
The benefit is that the mai use case is switch (transform->category)
statements and in those we know the category and don't need to check
TRUE/FALSE.
Using the wrong matrix will now cause a g_warning().
In particular, check that to_matrix() and to_2d(), to_affine() and
to_translate() return the same values.
This also requires a recent Graphene version or the tests will fail.
