This is a really old behavior introduced in commit
585e362526 which is inconsistent since
it only applies to SSD windows.
If we really want this, we should focus the window elsewhere so that
it applies consistently to all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=756789
The default theme started to use them in GTK+ commit 371f50, so
we need to update the style contexts to keep matching the style
of client-side decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=757101
We have been ignoring those buttons since 3.16 after they had been
broken in the default theme for a couple of versions. As nobody
appears to miss them, it's time to remove them for good.
We use a single style context to draw titlebar buttons, updating
its state according to each button's prelight state as necessary.
This assumes that the original state is neither ACTIVE nor PRELIGHT,
which means we need to reset the state after drawing to avoid
propagating the state of the last-drawn button.
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.
