We can get this operation in some cases, for example when
we're trying to resize window that cannot be resized.
This can occur with maximized windows that have a border
(without border we couldn't resize them by mouse in maximized state).
In this case we reached abort() beacuse we did not handle this op.
https://bugzilla.gnome.org/show_bug.cgi?id=751884
In commit cc5def1, buttons were changed from GdkRectangles to
MetaButtonSpace units, but the corresponding memset hack was not.
This means that the clickable portion of the unshade rectangle
was always set to uninitalized memory. The effects of this were
random, but in cases where the moon is aligned just right, the
rectangle would graze over the borders, and so it would take priority
over other borders and show a pointer cursor instead of a resize
cursor.
As we opt out of GTK+/Clutter's HiDPI handling, we need to apply the
window scaling factor manually to decorations, both the geometry and
when drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=744354
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.
We're locked to frame sync anyway, so it doesn't make sense to try to
redraw early. In casual testing, this seems to actually make things
faster, as well.
Break down the beautiful core/ui abstraction barrier by inserting
a pointer to MetaWindow into a MetaUIFrame. I'm a scoundrel, I know.
We'll use this very soon to destroy meta_core_get.
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
