Enabling code that is supposed to be used in compositing conditions is harmful if compositing is not actually available. Just checking the preference is not enough to make sure that compositing is available - the X server might be missing crucial extensions for compositing to work, which in turn correctly disables the internal compositor. The end result is graphical issues like black borders around windows in such situations. Make sure that compositing is both requested AND available to fix this bug.
- this will be needed for proper window decoration color updates on theme change when theme variants fixes are applied - realize/unrealize functions are dropped instead of map/unmap ones, because we didn't change these during GTK+3 porting - MetaFrames now has GtkWindow as parent instead of GtkInvisible, otherwise the hack doesn't work (revert part of 96c7256d638b8c76c8abf786ba307e82a595dd67) adapted from: https://github.com/GNOME/metacity/commit/ba8500663457ad9f18ebfdf405162c2cb5caf88f
... to differentiate PangoLayout from MetaFrameLayout. https://bugzilla.gnome.org/show_bug.cgi?id=741917 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/8e5781bc
With compositing manager: 1. Apply only client shape. Without compositing manager: 1. Apply client shape. 2. Apply shape around visible frame. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3913dcf1
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/cd383e72
https://bugzilla.gnome.org/show_bug.cgi?id=628195 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3994d7a0
An ARGB window with a frame is likely something like a transparent terminal. It looks awful (and breaks transparency) to draw a big opaque black shadow under the window, so clip out the region under the terminal from the shadow we draw. Add meta_window_get_frame_bounds() to get a cairo region for the outer bounds of the frame of a window, and modify the frame handling code to notice changes to the frame shape and discard a cached region. meta_frames_apply_shapes() is refactored so we can extract meta_frames_get_frame_bounds() from it. https://bugzilla.gnome.org/show_bug.cgi?id=635268 NOTE: Applied only partially, compositor part is still missing... upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/0f2e32d1
Rather than sharing a single style context between all frames, use a default style and one style per encountered variant. The value of the _GTK_THEME_VARIANT property should determine which style is attached to a particular frame, though for the time being the default style is used for every frame, as the window property cannot be accessed at the time the style is attached. This will be fixed in a later commit. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/04d8135f
This method allows forcing a style update of a particular frame from the core, so that it can pick up style variants. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/97554dc4
There were actually *two* MetaFrameGeometry structs: one in theme-private.h, one in frame.h. The latter public struct was populated by a mix of (void*) casting and int pointers, usually pulling directly from the data in the private struct. Remove the public struct, replace it with MetaFrameBorders and scrap all the pointer hacks to populate it, instead relying on both structs being used in common code. This commit should be relatively straightforward, and it should not do any tricky logic at all, just a sophisticated find and replace. https://bugzilla.gnome.org/show_bug.cgi?id=644930 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/72224a165 NOTE: Patch copied from metacity and adapted for marco.