Backport invisible resize borders #503
Conversation
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.
Just a quick little commit to help clean things up for when we add invisible borders. Additionally, do a little housekeeping in preview-widget as well. https://bugzilla.gnome.org/show_bug.cgi?id=644930 NOTE: Patch copied from metacity and adapted for marco. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/7d519b3f
Since version 3.0, GTK+ has support for style variants. At the moment, themes may provide a dark variant, which can be requested by applications via GtkSettings. The requested variant is exported to X11 via the _GTK_THEME_VARIANT property - support this property, in order to pick up the correct style variant in the future. https://bugzilla.gnome.org/show_bug.cgi?id=645355 NOTE: Patch is adapted for marco. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/341d0945
To associate frames with the correct style variant, the UI will need access to the window's theme variant property. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/5c7403cc
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
When the _GTK_THEME_VARIANT property changes, rather than just updating the window's theme_variant property, update its frame style as well, so that the window decoration reflects the requested variant. As the initial properties of a window may be read before its frame is created, there will be cases where the change is not picked up initially. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/8a779ab9
Like the setting of new frames' background is delayed until the frame is associated with its window, delay attaching the initial style, so that the correct style variant is picked. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/ee056853
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
meta_frames_destroy() was not safe to be called multiple times, which was causing a crash on exit due to something else changing somewhere that makes it get called multiple times. https://bugzilla.gnome.org/show_bug.cgi?id=654489 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/e35be641
We were relying on GTK+ emitting GtkWidget::style-updated during widget initialization to create the GtkStyleContexts used for window decorations. A recent GTK+ update broke this assumption, so do the necessary initialization ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=671796 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/e4fde7b0
Based on a patch by Thomas Jaeger <ThJaeger@gmail.com> upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/03e8e63d
… widget The style context of the widget is rarely what we want. We won't fix this to be a MetaFrames style context yet; this just changes the internal API. https://bugzilla.gnome.org/show_bug.cgi?id=690317 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/76aa0704
Commit https://gitlab.gnome.org/GNOME/metacity/commit/c3a04bf unintentionally broke XShape handling. By studying the code extremely carefully, I found this inconsistency with the code that was there before. https://bugzilla.gnome.org/show_bug.cgi?id=635268 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/2b1c6443
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
Since window->frame_bounds is used as a cache we need to invalidate it when destroying the frame. https://bugzilla.gnome.org/show_bug.cgi?id=660773 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/330ff9b5
|
@flexiondotorg, thanks for testing. I see that black artifact on I will address as a separate pull request. |
|
Been using this PR all day. Working great! |
|
Sorry I've been busy for a while. |
|
I am 👍 on merging. |
|
I filled out a ticket for compiz-reloaded because compiz doesn't start any more. https://gitlab.com/compiz/compiz-core/issues/148 |
|
@vkareh @lukefromdc |
|
@raveit65 there are several. I will take a look, but it's not a trivial fix for compiz, it seems |
|
I will try to find the relevent compiz 0.9 commits myself and attempt a backport.
Meanwhile, setting compiz to use Emerald should allow it to run, will tesr that
today. Same things happened with compiz 0.9 with changes in metacity.
…On 6/5/2019 at 1:00 PM, "Victor Kareh" ***@***.***> wrote:
@raveit65 there are several. I will take a look, but it's not a
trivial fix for compiz, it seems
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#503 (comment)-
499169122
|
|
In my test the first commit was enough to prevent a new build of compiz,
would have had to.restart gtk-window-decorator to see runtime berakage
but was sure it would occur as that was a total change of what varialbles
were expected by marxo.
…On 6/5/2019 at 12:39 PM, "raveit65" ***@***.***> wrote:
@vkareh @lukefromdc
Do you know exactly which commit breaks to gtk-decorator?
This is the stacktrace
https://www.dropbox.com/s/bisqevb687h3ice/compiz-backtrace-with-
marco-invisible-border?dl=0
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#503 (comment)-
499161694
|
|
@lukefromdc - I started last week, but gave up, since I wasn't sure whether it was working (because I've never used/compiled compiz-reloaded before, so I didn't know how to test it). I suggest starting here: And backport those one by one starting from the bottom 😞 The main issue I had was that Compiz has all the components in separate files, whereas compiz-reloaded are all in the same file, so it was really hard to backport and know whether I was doing it right... |
|
I've got an existing build of compiz-reloaded running right now with this installed and Emerald replacing gtk-window-decorator until we get this fixed over at the compiz-reloaded project. The first commit of the compiz-0.9 series is a do-over as compiz 0.9 uses cmake and 0.8 uses autotools. Also, you can build compiz-reloaded against this right now without marco support (gtk-window-decorator does not use or follow metacity themes) by passing --disable-marco . You can also disable the entire gtk window decorator by passing --disable-gtk |
|
That first one at the bottom is probably not necessary... |
|
Turns out we already have the --disable-marco switch in configuration and it works: building with this switch set gives a version of gtk-window-decorator that ignores Metacity themes but works. Running it now for test purposes. Does not match my theme of course, but I have an emerald theme that is an almost exact match using the pixbuf engine and segments of screenshots of marco with my normal theme. You can also disable the entire gtk window decorator by passing --disable-gtk and that should also work. In that case of course emerald is required. |
|
@raveit65 - could you test/confirm what @lukefromdc is doing ☝️ ? If so, would it then make sense to merge #518 and update your spec files for compiz-reloaded? |
|
@vkareh @XRevan86 |
|
One other issue with a backport is this: it is an ABI break without incrementing
the major veraion number, and updates to things like an updated compiz-reloaded
would have to be provided by distros.
That said, GTK3 used to break compatability on minor versons (e.g themes broke at
1.14 and majorly at 1.20) so we won't be the first at breaking with this convention. We
could of course release a 1.24 version early to get this out as well.
…On 6/6/2019 at 10:33 AM, "raveit65" ***@***.***> wrote:
@vkareh
Yes, i know this build options --disable-marco, but this poor
vanila gtk-decorator is not something what you want to use on a
modern linux box.
And yes, compiz has a second decorator (emerald) which can be used.
But my problem is that if i want to update f29/30 with a new 1.22
release which use invisble-borders, than we break the compiz
expierience for users.
Same for OpenSuse which have also compiz-reloaded in official
repos.
And a new 1.22 release should be use for all distros.
I know we want to bring it in ubuntu-19.10. But i think we have a
bit time for fixing compiz-reloaded, or not?
You can also test running emerald decorator in your f30
installation.
Use `fusion-icon -n` to start a tray applet where you can start
compiz with emerald as decorator.
@XRevan86
I hope you read the notifications?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#503 (comment)-
499520424
|
|
@vkareh @lukefromdc |
|
I'd be quite happy with we released a 1.23 snapshot including this and other recent improvements and ship that in 19.10. |
|
Should we close #518 then? |
|
No, let it open. |
|
https://gitlab.com/compiz/compiz-core/merge_requests/140 for compiz-reloaded brings the ability to resize from the shadow area to compiz, but I have yet to figure out how to compensate for the shadow area for tiled windows or windows being moved/resized to the top of the screen. Any help appreciated with this. |
|
@lukefromdc |
|
Thanks, a quick effort at that on my end last night while I was
working on resize from the shadow area ran into problems
On 6/17/2019 at 4:01 AM, "raveit65" wrote:
@lukefromdc
I did a MR with updated version_checks for marco.
https://gitlab.com/compiz/compiz-core/merge_requests/141
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
So far I'm happy with the result of this. It's a sequential backport of Metacity commits to get invisible resize borders working. I've made sure to preserve Marco's own HiDPI logic this time.
Fixes mate-desktop/mate-themes/issues/249
Fixes #481
Fixes #248