We want to remove GtkBin and GtkContainer as they don't
provide much useful functionality anymore. This requires
us to move get_request_mode and compute_expand down.
See #2681
As pointed out in https://gitlab.gnome.org/GNOME/gtk/issues/1481
and seen from critical warnings with swinging revealers in widget-factory
there are some size allocation issues in GtkRevealer.
What happens is that we request a size of the revealer itself
based on the child natural size and the current stage of the transition
by applying a scale to the natural size. We then round up to nearest
int size. However, we want the widget to render as if it did get the
natural size so we can transform it, rather than the scaled down size.
For example, a label should not start ellipsizing in the animation.
So we inverse the scale when allocating the child.
Unfortunately, for very small scales the inversion of the scale can
result in very large sizes, and for such scales we rounded up the
requested size to 1, so we will be allocating huuuuge children.
In order to avoid such issue we pick an arbitrary maximum upscale
scale factor of 100. This means that in the case where the allocated
size is 1 we never allocate the child at > 100 px. This means
that in large downscaling cases we may run into the clipping issue
described above. However, at these downscaling levels (100 times!)
we're unlikely to notice much detail anyway.
Make the transform (transfer full).
1. This makes sure we actually reference the transform. Previously we
did not.
2. Most callers create a new transform to pass to us. Now they don't
have to uref it anymore.
Refactor the child allocation machinery, so that the complex allocation
paths are only run when the animation is running.
And in particular, ensure that when no animation is running, the
identity transform is allocated.
The target position is irrelevant for determining if the child should be
visible. When the current position is 0, it needs to be hidden, period.
Fixes#1355
If the revealer is told do animate and then unrealize itself, we do
(correctly) stop the animation, but used to do a shortcut where we
just set the target state as current.
Other things are dependent on the animation properly finishing though,
like the contained widget child visibility. This may lead to inconsistent
state where gtk_revealer_get_child_revealed() returns TRUE but the child
widget is unmapped, or vice-versa.
Fully finish the animation here, so the child state is coherent the next
time the revealer is mapped. We can also skip notifying on the property
since it will be handled by gtk_revealer_set_position().
Up until now when allocating the child it only used the natural size
while the measuring also used the minimum size, resulting in a clipped
child when animating if the child had different minimum size and
natural size. This was an obvious case when using labels that had
ellipsization.
This commit gives full allocation to the child by inverting the size
the revealer reduces from its animation progress.
Code done by Benjamin Otte.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/635
Currently, GtkRevealer clips the child if the transition type is
sliding, regardless of whether the animation had already ended. An
example where that is a problem would be in Nautilus: the file
operations popover button is animated on reveal to draw attention, but,
given that the button is in turn stashed inside a revealer with a
sliding animation, things suddenly fall apart.
This is an automated change doing these command:
git sed -f g gtk_widget_set_has_window gtk_widget_set_has_surface
git sed -f g gtk_widget_get_has_window gtk_widget_get_has_surface
git sed -f g gtk_widget_set_parent_window gtk_widget_set_parent_surface
git sed -f g gtk_widget_get_parent_window gtk_widget_get_parent_surface
git sed -f g gtk_widget_set_window gtk_widget_set_surface
git sed -f g gtk_widget_get_window gtk_widget_get_surface
git sed -f g gtk_widget_register_window gtk_widget_register_surface
git sed -f g gtk_widget_unregister_window gtk_widget_unregister_surface
git checkout NEWS*
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Since gtk+ draws more than the widget and allocates more size to it than
it knows about, this flag doesn't work anymore. Removing it (or setting
it to TRUE for widgets that used to set it to FALSE) fixes drawing
invalidation when these widgets get allocated a new size.
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.
Previously, we would request a size of 0×0 when the transition type was
NONE and the child un-revealed, making the revealer in this case a
gtk_widget_set_visible replacement. Instead, to the exact same thing we
do in the CROSSFADE case and request the child size instead. This also
keeps the revealer from under allocating the child when the transition
type is set to NONE.
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().
Also, "ie" wasn't very clear, but fixing that to "i.e." would cause
truncation of the summary when processed by bindings using doxygen. So,
I replaced it with "in other words", which is no _less_ clear, at least.
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.
Depending of float rounding during target calculation, the size of the
GtkRevealer can be set to zero will the animation is not finished.
If the GtkRevealer is in a GtkPaned, it will be hidden and so the animation
will be stopped before it is finished.
In this case, force the emission of the child-revealed signal to let
client code know the animation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=765973
If animations are disabled, the only difference we need to make is that
we don't have to start the transition. Size requests should remain the
same.
https://bugzilla.gnome.org/show_bug.cgi?id=762996
... if the child is concealed and the transition type is set to NONE.
In this case, both preferred width and preferred height should be 0, but
we still can't use that to allocate a size for the child, so care about
the minimum size of the child in gtk_revealer_get_child_allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=761760
