Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
always initialize clips to the (content) allocation, don't walk up the
widget hierarchy in gtk_widget_set_clip, implement
gtk_widget_size_allocate in GtkSeparator. This way we don't end up using
uninitialized clip values.
The entire clip handling is up for major rework since we can't and don't
want to force every single widget to call _set_clip in size-allocate
implementations.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
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.
