GNOME Bugzilla – Bug 729769
Double decorated windows
Last modified: 2018-04-15 00:12:19 UTC
Created attachment 276121 [details] Left window started with compositing, right window started without compositing Steps to reproduce: 1. Run KWin 2. Disable compositing (Alt+Shift+F12) 3. Start gtk3-demo 4. Enable compositing (Alt+Shift+F12) 5. Start another gtk3-demo Actual result: gtk3-demo from step 3 has double decorations, gtk3-demo from step 5 has only CSD deco (see attached screenshot) Expected result: Windows should not have a double decoration, compositing should not change feature set.
I don't consider runtime changes of compositing to be a very high priority; it would be nice to handle better, certainly.
(In reply to comment #1) > I don't consider runtime changes of compositing to be a very high priority; it > would be nice to handle better, certainly. that's a common usecase in a Plasma setup, though.
Xfce also has double decorated windows without compositing. It's shameful that this happens at all, if CSD isn't done right then it should be disabled outside GNOME.
(In reply to comment #0) > Windows should not have a double decoration, compositing should not change > feature set. CSD requires an ARGB32 window, so we disable it if we can't find one. We shouldn't show a close button in these apps if CSD is disabled, and I certainly wrote some code for this. Does this still happen?
(In reply to comment #4) > (In reply to comment #0) > > Windows should not have a double decoration, compositing should not change > > feature set. > > CSD requires an ARGB32 window, so we disable it if we can't find one. at least in KWin compositing is run-time changeable. We always (since 2008) use ARBG visuals for windows which could make use of translucency and just repaint the window if the compositor becomes available or is removed. It might be worth to consider whether that makes sense for GTK, too. > We > shouldn't show a close button in these apps if CSD is disabled, and I certainly > wrote some code for this. Does this still happen? which GTK+ version should I test? I'm limited to what Debian provides, though.
(In reply to comment #5) > at least in KWin compositing is run-time changeable. We always (since 2008) use > ARBG visuals for windows which could make use of translucency and just repaint > the window if the compositor becomes available or is removed. It might be worth > to consider whether that makes sense for GTK, too. Well, what do we do when RGBA disappears? We can't really show a shadow anymore, or have rounded corners at the top. Really, not having alpha blending from a windowing system in 2014 is beyond stupid. I'm going to asy "we require compositing, the end". I'll check today why Matthias removed the _NET_SUPPORTED check for _GTK_FRAME_EXTENTS.
(In reply to comment #6) > (In reply to comment #5) > > at least in KWin compositing is run-time changeable. We always (since 2008) use > > ARBG visuals for windows which could make use of translucency and just repaint > > the window if the compositor becomes available or is removed. It might be worth > > to consider whether that makes sense for GTK, too. > > Well, what do we do when RGBA disappears? We can't really show a shadow > anymore, or have rounded corners at the top. yes it keeps the shadows. I also reported a bug for that. Btw. we support that since 2008 with runtime switching in Plasma (exchanges the rendering, adds shapes) and we also took that into Plasma 5. In fact we even have three different ways: * no compositing * compositing * compositing with blur effect enabled And at least we still make strong use of it, e.g. to allow our users to disable compositing while playing games. I've also heard of Blender or CAD users who don't want any GL in the windowing system to "own" the graphics card. Whether that's a really valid use case, I'm not sure, but at least we have users who appreciate the option.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new