There is no good reason to do so, besides a nice way to check whether
a particular button is enabled. However there are legitimate reasons
for overdrawing like box-shadows or outlines, so remove the clip.
With support for the old metacity theme format gone, there's no
reason to keep storing theme information in terms of the old theme
properties. Just store the padding/border information for each
element directly.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
MetaFrameStyle now only holds a MetaFrameLayout, so we can cut out
the middle man and use the layout directly. And as we are already
using a single style/layout per frame set and handle frame state
and focus by setting appropriate style flags, MetaFrameStyleSet
is pointless too - just store one MetaFrameLayout per frame type
directly in the theme.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Rest in peace you magnificent format, love-child of arcane X11 drawing
API and markup craze, you will not be missed.
We do remember however the bravery of a many men and women, who fearlessly
descended into the guts of your intrinsics and turned ugliness into beauty;
their work will still be spoken of when you will long have been forgotten.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
All geometry/drawing information is now picked up from the GTK+ theme,
so replace the remaining bits (hide_buttons + title_scale) with
hardcoded values from the default Adwaita theme and stop loading
the metacity theme altogether.
If there is a need to theme those constants again in the future,
we should make them available from GTK+ where they are available
for client-side decorations as well. They certainly don't justify
maintaining support for a complex theme format.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Few themes ever had support for those in the first place, and even
less supported them properly; in particular support in the default
theme has been broken for a while now.
With this in mind (and considering that not even the tweak tool exposes
any UI to configure them), let's (try to) remove support altogether - the
corresponding rects are still kept around, so it's easy to add back in
case we reconsider (and get the necessary artwork).
https://bugzilla.gnome.org/show_bug.cgi?id=741917
GTK+ doesn't deal with different frame types for its client-side
decorations - it just treats dialogs the same as normal windows
and ignores the odder frame types like UTILITY and MENU. That's
fine as those have largely gone out of fashion anyway, but it's a
different case for the WM - we still have to support them somehow.
For now, just apply the existing title_scale factor to the geometry
information picked up from the theme in addition to the title font.
If it turns out that there's demand for something more sophisticated,
we can still consider adding wm-only style information to the GTK+
theme.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
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
Since GTK+ commit 3a337156d11a86c7, save()/restore() may only be
used for subelements; in this particular case, the change broke
the backdrop state in decorations. Luckily we don't actually need
the save()/restore() pair anyway, as we only touch the context's
state and always set it explicitly.
From a quick code search and grep of gnome-themes-standard, none of
the themes that I inspected used this feature. Since it's the last
thing that uses a lot of old legacy GdkPixbuf code, I'd rather just
consider the feature unsupported at this point and clean up everything
I need to.
https://bugzilla.gnome.org/show_bug.cgi?id=662962
While the comment claims that we may want to keep this around
for optimization purposes, the operations are raw bitmap operations
that would be cleaner done in cairo.
https://bugzilla.gnome.org/show_bug.cgi?id=662962
We want to synchronize the button layouts of our server side
decorations and GTK+'s client side ones. However each currently
may contain buttons not supported by the other, which makes this
unnecessarily tricky.
So add support for a new "appmenu" button in the layout, to display
the fallback app menu in the decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
We already do it in the theme code, but not the actual WM code. Since
we include the left/right borders, it only seems fair to include the
bottom border.
This effectively makes it so that shading a window means that the
client window "slot" has 0 height.
Switching meta/util.h to gi18n.h was wrong, mutter is a library
and needs gi18n-lib.h, but that cannot be included from a public
header (since it depends on config.h or command line options),
so split util.h into a public and a private part.
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Conflicts:
src/compositor/compositor.c
src/meta/util.h
g-ir-scanner will emit more warnings regarding broken GTK-Doc
syntax in the near future, which due to --warn-error being used
would break the build:
'''
ui/theme.c:1883: Warning: Meta: missing ":" at column 20:
* @tokens_p: (out) The resulting tokens
^
g-ir-scanner: compile: gcc -Wall -Wno-deprecated-declarations ...
g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC gcc ...
libtool: link: gcc -o /home/dieterv/gnome.org/checkout/mutter/...
<unknown>:: Fatal: Meta: warnings configured as fatal
<unknown>:: Fatal: Meta: warnings configured as fatal
make[4]: *** [Meta-3.0.gir] Error 1
'''
https://bugzilla.gnome.org/show_bug.cgi?id=699636
GtkWindow added the BACKGROUND style class to all windows, which the
CSS file selects on to set a background color for all windows. Without
this, the background color becomes undefined, and thus window frames
look like they have "glitchy" graphics.
https://bugzilla.gnome.org/show_bug.cgi?id=690317
