gtk_snapshot_pop() => removed
gtk_snapshot_pop_and_append() => gtk_snapshot_pop()
So now there is no way to get a rendernode out of the snapshotting API
until you gtk_snapshot_finish().
... and use it.
The function is a bit awkward because it requires 2 calls to
gtk_snapshot_pop(), but once you accept that, it's very convenient to
use, as can be seen by the 2 implementations.
This uses the new push()/pop() mechanism to its fullest extent when
implementing transitions. It's fun to inspect the results in the
inspector.
Crossfades don't work yet, they continue using a Cairo fallback.
A side effect of the stack conversion is that widget-factory now uses
snapshots for a lot more things.
Unlike other container widgets, GtkStack would allocate its children
prior to moving its windows, which might prevent further valid size
allocation signals to be emitted.
Re-order the size allocation of child widgets to be performed after
moving the GtkStack windows.
Thanks to Owen for spotting the real issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=767713
In that case, we can't just rely on the stack allocation being big
enough. Especially, the child can actually be bigger than the current
stack allocation, so take that into account when positioning it.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
gtk_widget_set_parent() will map the widget if the parent is mapped
and the widget is both visible and child-visible. As we currently
only set the child visibility after adding the child, we immediately
map all children that are added to a mapped stack, even when they
are not actually shown. Avoid this by setting the child visibility
before adding the child, so widgets are only mapped when shown.
https://bugzilla.gnome.org/show_bug.cgi?id=766737
Sometimes on wayland we're seeing a frame draw before the first tick
callback, where the window position has not yet been updated.
With this change, the window is properly positioned as soon as
gtk_stack_start_transition returns.
https://bugzilla.gnome.org/show_bug.cgi?id=766405
Not the ideal solution for this problem, but in practice leads to
much better performance on lower end hardware.
Stack does a double draw on the first frame of its animation, of
both the old contents (into a cairo surface) and the new contents.
Homogeneous stacks only need to reallocate contents on the first
frame.
On lower powered hardware where our frames will be a good deal
slower than the refresh rate anyway, we can assure a smother
experience by waiting a frame to start tweening where frame duration
will be more consistent.
When animating, we might be changing the size allocation of the previous
stack child. However, we were not querying the size in the process
meaning you would often see warnings about allocating the size without
knowing what it should be.
This simply adds an innocuous size request, since responding to last_child
sizing requests is not all that critical in the transition.
https://bugzilla.gnome.org/show_bug.cgi?id=763900
Always have Since: annotations at the very bottom, use the correct
ClassName::signal-name/ClassName:property-name syntax, fix a few typos
in type names, wrong function names, non-existing type names, etc.
Doing things the other way around seems to cause problems in
some cases where children want to do different things depending
on the window position.
https://bugzilla.gnome.org/show_bug.cgi?id=758563
Currently GtkStack has some G_PARAM_CONSTRUCT properties. That means,
the properties are set with its default value after the initializacion
of the object.
When using GtkBuilder to build objects, GtkBuilder creates them and
after that sets the properties found on the xml definition.
However, this is not true for templates because the template is initialized
in the init() function of the actual object, and after that, the construct
properties will be set.
This is a problem when someone wants to use templates with GtkStack and
set those properties, since they will be set on the tempalt initialization
and set again to its default values afterwards.
To fix this, make those properties not G_PARAM_CONSTRUCT.
https://bugzilla.gnome.org/show_bug.cgi?id=758086
We only allocate a size to the currently visible child, so we obviously
need to rerun allocation when the visible child changes.
In the case where the stack is not homogenous, we also need to queue a
resize because our size request just changed.
