We now have everything in place to pick up geometry and drawing
information from GTK+ rather than the metacity theme, so do just
that; the metacity theme is now only used for some constants
(title_scale, hide_buttons, ...), which we will replace soon.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
We want to eventually pick up all theme information from GTK+ instead
of our own theme format; to prepare for this, add another helper method
to fill in geometry information from the GTK+ theme.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
GTK+ expresses the window state as style classes and widget state for
client-side decorations. Add a helper method to translate our own frame
state to the corresponding changes to the style context hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Sounds obvious, doesn't it?
After this change when titlebar-uses-system-font is set, the "system
font" used will not be a generic one, but match what GTK+ uses in
client-side decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
In order to pick up all theme information from GTK+, a single style
context is not enough; a style hierarchy that closely matches the widget
hierarchy by GTK+'s client-side decorations will allow this soon.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Our current use of style contexts is fairly limited - we don't
use them for much more than picking up some color information.
We will soon start to make more elaborate use of GTK style
information, but a single context will no longer be enough
to draw a frame then.
To prepare for this, add a simple ref-counted type to wrap
style information.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Rather than defining the space to the left and right of buttons, add a
simple spacing property that defines the space between buttons, which is
what GTK+ does for client-side decorations (e.g. GtkButtons in a GtkBox).
Unfortunately the value is hardcoded in GTK+; if it is exposed in the
theme in the future, we should pick it up from there, but for now we
just use the same value as GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Basically it's odd to have "button_rect" be a function with all the
foo_rect GdkRectangles around - renaming to get_button_rect() will
free the name for the generically named "rect" once buttons are the
only movable pieces in the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
This reverts commit 47e339b46e80f01c2a4d020dbef7341e5a02b7eb. The
approach that was used to reduce the amount of work we do on RR events
to the necessary minimum is flawed. It assumes that, when the first
event we see where the retrieved XRRScreenResources.timestamp is
bigger than the previous, we already have all the data we need to
rebuild our view of the world.
That isn't true however, because the X server sends
RRScreenChangeNotify events for every step of the configuration
change, i.e. it lacks an atomic reconfiguration API. In particular, if
the X screen size is one of the changes, when we rebuild our state and
emit monitors-changed, the X screen size might still be the previous
one and since we stop updating ourselves until another reconfiguration
happens (noticed by looking at XRRScreenResources.timestamp) we end up
with the wrong idea of the X screen size.
https://bugzilla.gnome.org/show_bug.cgi?id=738630
This reverts commit fcc67e99bccc981774d59625b73118dadc75f6ea.
It seems this causes some recursion overflow in GNOME Shell's usage of
constraints, and needs more investigation.
Bind the preferred size of an actor using a BindConstraint to the
preferred size of the source of the constraint, depending on the
coordinate of the constraint.
Constraints can only update an existing allocation, which means they
live only halfway through the layout management system used by Clutter;
this limitation makes it impossible, for instance, to query the
preferred size of an actor, if the actor is only using constraints to
manage its own size.
And move the only private ClutterConstraint method to it.
This commit also sneaks in a change that makes sense for the debugging
of the update_allocation() method, which checks if the allocation was
effectively changed.
The syntax for some introspection annotations has changed between 1.38
and 1.39, so we need to bump up the dependency in order to get the new
scanner. Introspection should be updated in lock-step with GLib, so we
should also bump up the required GLib version.
