The easing state is part of the AnimationInfo structure, which is stored
inside the GObject's datalist. Each instance frees the data stored there
during finalization, so there is no point for us to restore an easing
state (which may or may not be the last one) just to have everything
cleared out once we chain up to GObject's own finalize() implementation.
Whenever we added a frame to the GHashTable, we added the frame itself
as the value, and a pointer to its storage of the frame window XID,
as the key.
When we iterated over the hash table, we actually looked up the
MetaUIFrame in the key, which might seem extraordinarily wrong, but
eagle-eyed viewers might notice that the XID is the first field in
MetaUIFrame, so the key and value are actually the same pointer.
Changing the layout of MetaUIFrame at all causes this to go haywire,
so let's not do this and simply put the MetaUIFrame in the value,
as expected.
When the frame type updates, we were doing something funky that
caused us to reset the title used for the text layout here. I can't
really think of any place that it would trigger, and in testing I
haven't hit this either, so let's just remove the fancy logic and
assert this.
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
The frame shape is relevant in three places:
- the window decoration we draw
- the frame mask (used for the shape region)
- the frame bounds (used for clipping)
All three should match, so make sure to use the same GTK+ method for
the first two, and bring the (non-antialiased) third closer to the
other two by removing an obscure modifier from the corner radius.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
