Add an API to start or stop continually updating the frame clock.
This is a slight convenience for applcations and avoids the problem
of getting one more frame run after an animation stops, but the
primary motivation for this is because it looks like we might have
to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably
accurate timing, and for that we'll need to know if there is an
animation running.
https://bugzilla.gnome.org/show_bug.cgi?id=693934
We clear GtkTickCallbackInfo on creation to ensure all fields start
as 0. Before we sometimes ended up with destroyed being 1
so the tick was never called.
We need to disconnect the frame clock when we unrealize (at which
point the old clock is still alive) not in destroy(). Since there
is no common unrealize for containers, trigger this from GtkWidget.
Add a very simple GtkWidget function for an "tick" callback, which
is connected to the ::update signal of GdkFrameClock.
Remove:
- GtkTimeline. The consensus is that it is too complex.
- GdkPaintClockTarget. In the rare cases where tick callbacks
aren't sufficient, it's possible to track the
paint clock with ::realize/::unrealize/::hierarchy-changed.
GtkTimeline is kept using ::update directly to allow using a GtkTimeline
with a paint clock but no widget.
Switch GtkStyleContext to using GdkFrameClock. To do this, add a new
UPDATE phase to GdkFrameClock.
Add a GdkFrameClockTarget interface with a single set_clock() method,
and use this to deal with the fact that GtkWidget only has a frame
clock when realized.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Instead of having gdk_frame_clock_request_frame() have
gdk_frame_clock_request_phase() where we can say what phase we need.
This allows us to know if we get a frame-request during layout whether
it's just a request for drawing from the layout, or whether another
layout phase is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
This adds a way to get the gtk_widget_set_opacity liike behaviour
of retargeting GdkWindows and exposing every child in ::draw, without
actually having an alpha. This is needed if you're doing more complex things
such as cross fading of widgets.
We do this as a hack by using opacity values that round to 255 yet not
really 1.0 in order to avoid having some magical API call for this
mainly internal call.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This adds gtk_widget_get/set_opacity, as well as a GtkWidget.opacity
property. Additionally it deprectates gtk_window_get/set_opacity and
removes the GtkWindow.opacity property (in preference for the new
identical inherited property from GtkWidget, which should be ABI/API
compat).
The implementation is using the new gdk_window_set_opacity child
window support for windowed widgets, and cairo_push/pop_group()
bracketing in gtk_widget_draw() for non-window widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This is a quickfix to keep things working.
It turns out GtkWindow assumes it can do sizing operations while not
being visible, or while in the process of show()ing/hide()ing itself.
And commit b495ce54 broke these operations.
Figuring this properly requires some more thinking and restructuring on
my part, so for now we relax the requirement of visiblility enough for
these things to start working again.
GtkWidget::visible is required for the widget to:
- have a preferred size other than 0/0
- have a size allocated
- return other values than { -1, -1, 1, 1 } from get_allocation()
This is an experimental patch aiming to make concepts and behaviors
inside GTK more concreate. GtkWidget::visible is now essentially what
CSS does for "display: none".
Note that if you want the effect of CSS's "visibility: hidden", you'll
have to use a GtkNotebook with an empty page as the concept of reserving
space but not drawing anything isn't supported natively in GTK.
Previously, with STATE_FLAGS_REPLACE we would unset _all_ the state
flags on children, not just the ones that do propagate. This caused the
RTL/LTR flags to get lost.
Now that Pango tracks changes to the context automatically there is
no need to do it manually in e.g. style-updated or direction-changed,
in fact the only case we have to care about is when we re-create
the PangoContext due to a screen change, so we only have to clear
the layouts in GtkLabel in screen-changed.
This means we're not clearing all the layouts whenever the state changes,
which happens to every widget when the window is unfocused, which helps
performance a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=340066
queue_resize basically tells the parent widget that it may need
to pick a different size/layout. However, for a hidden child widget
that should never be needed. It may be that the widget is in a
sizegroup that has ignore_hidden == FALSE though, so it may
affect the size group calculations.
However, if a widget is not visible and not in a size group then
its safe to avoid the resize, as the widget will be resized on
becoming visible anyway.
This avoids a lot of size allocation for hidden things like menus
and tooltips.
Resizes are queued via
gtk_widget_propagate_state()
=> gtk_style_context_set_state()
=> gtk_style_context_queue_invalidate()
=> gtk_style_context_validate()
=> _gtk_widget_style_context_invalidated()
so there's no need to queue an extra one.
This way we don't need a marker on GtkWidgetParivate that needs to be
unset later, so we have all our data in the same place and can avoid
problems with reentrancy and shenanigans like that.
But the main reason I wrote that is cleaner code.
With this function now available, we can do size computation in 2
ways:
(1) Compute size with size groups
(2) Compute size without size groups
And have (1) use (2) instead of setting flags on widgets. This patch
does exactly that.
It seems we missed updating this since GTK+3, widgets cannot be
allocated less than the size they requested in thier request
phase, and explicit sizes are used only to grow the size request.
Otherwise the evil widgets that don't chain up their map and unmap
vfuncs will not get updated style contexts. This is in particular true
for GtkWindow and the CSS Theming / animated backgrounds demo in
gtk-demo.
This change is necessary because the old code did not accound for corner
cases (like translucent child windows), which could stop
gtk_widget_queue_resize() to not trigger redraws.
