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.
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.
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
When interpolating the stack size, we compute the current size by using
the prefered/minimum current size and the last size. We can't use the
last_visible_surface_allocation because that is not available until the
first _draw call and it doesn't include the child's margins.
Add notebook-like focus handling: Keep track of the last focused
descendent of each page, and focus it again when switching back
to the page. If there is no last focused child, we move the focus
into the page as if the user had hit Tab.
If a child has set_has_window == FALSE, it purely relies on the events set on
the parent window, for which the bin window used to just ensure the exposure
mask, eating all input events.
https://bugzilla.gnome.org/show_bug.cgi?id=734357
