GitLab

Hugo Lefeuvre authored Sep 26, 2018 and Daniel Boles committed Oct 07, 2018

The gtk_stack_snapshot_slide() function dereferences the
last_visible_child pointer without proper != NULL ckeck. This might
result in NULL pointer dereference and crash if last_visible_child is
invalid.

Add a != NULL check before dereferencing the pointer.

cherry-picked from !361

Return with error if gtk_stack_set_visible_child_name is called
with NULL parameter

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

Show only the currently visible child to a11y.

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.

Christian Hergert authored Mar 18, 2016 and Matthias Clasen committed Mar 21, 2016

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

g_logv adds one for us already.

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.

Having priv->view_window be the same as widget->window does not make
sense.

And because we need to clip the content area, we need the view window.

We use cairo_paint() when doing that and we don't want to overdraw the
content area.

Matt Watson authored Dec 10, 2015 and Jasper St. Pierre committed Dec 10, 2015

In gtk_stack_set_transition_position we should only need to
queue_resize if we are non-homogeneous, which is already done
earlier in the function.

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

Carlos Soriano Sánchez authored Nov 11, 2015 and Matthias Clasen committed Nov 19, 2015

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

make check checks this for writable properties, and fails now that
we've made this property writable.

This is just a cleanup commit, no actual bug.

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.

And it is...stack.

It looks like the param spec for interpolate-size was
copied from the line above it, which is a read only property.

There is a setter for interpolate-size, and it is implemented in
set_property().

These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).

So, by not setting the mask we avoid emitting these events and then
later ignoring them.

We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.

And use it to determine whether we should actually interpolate between
stack sizes or not.

We already have an in-destruction flag, so use it.

Paolo Borelli authored Feb 16, 2014 and Matthias Clasen committed Jun 21, 2015

When the stack is destroyed we do not want to waste time running
animations and notifying listeners about which is our current
visible child.

This is not only an optimization, but it is important for the stack
switcher widgets: since they are in another branch of the hieratchy
we do not want to get notifications while the stack is being destroyed.

Based on a patch by Paolo Borelli
https://bugzilla.gnome.org/show_bug.cgi?id=724506

We will call gtk_widget_queue_resize anyway later when finishing the
(maybe non-running) transition, which will also cause the stack to be
repainted.