After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 750343 - CSD enabled unconditionally for windows with titlebar
CSD enabled unconditionally for windows with titlebar
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-06-03 13:49 UTC by Jussi Kukkonen
Modified: 2018-05-02 16:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window: Check if we can use CSD before enabling them (3.42 KB, patch)
2015-06-03 13:53 UTC, Emmanuele Bassi (:ebassi)
rejected Details | Review

Description Jussi Kukkonen 2015-06-03 13:49:04 UTC
Quoting Emmanuele:
"The change in 03213b9509fc1df16c66194ea168aed6c15110e9 changed the rules
as to when CSD can be enabled, but it also unconditionally enables CSD
with the implicit assumption that client-side shadows were the real
issue, and that we could work around that by drawing our own borders.
This also means that setting a titlebar for a GtkWindow will enable CSD
unconditionally.

In reality, some window managers (like Matchbox) *only* support
server-side decorations, and will ignore all hints to the contrary, to
the point of drawing decorations at random locations on top of the
window."


(it's not actually window decoration but a panel that draws where the WM believes is a good spot to draw on top of the SSD titlebar, but the end result is the same)

I'll let ebassi attach the patch himself. I've tested it and it works for me. We can patch it in yocto as well if it doesn't seem appropriate here: I realise the use case is a bit obscure and the solution is still band-aid over WM problems.
Comment 1 Emmanuele Bassi (:ebassi) 2015-06-03 13:53:45 UTC
Created attachment 304516 [details] [review]
window: Check if we can use CSD before enabling them

The change in 03213b9509fc1df16c66194ea168aed6c15110e9 changed the rules
as to when CSD can be enabled, but it also unconditionally enables CSD
with the implicit assumption that client-side shadows were the real
issue, and that we could work around that by drawing our own borders.
This also means that setting a titlebar for a GtkWindow will enable CSD
unconditionally.

In reality, some window managers (like Matchbox) *only* support
server-side decorations, and will ignore all hints to the contrary, to
the point of drawing decorations at random locations on top of the
window.

Since CSD are enabled unconditionally, the GTK_CSD environment variable
is also not a suitable escape hatch.

In the grand tradition of asking ourselves if we should do something
just because we can, we should split the environment checks from the
checks on what the user requested; by doing that, we can also check
when enabling client-side decorations, and ideally bail out if needed.
Comment 2 Matthias Clasen 2015-06-03 14:48:52 UTC
Review of attachment 304516 [details] [review]:

ok
Comment 3 Emmanuele Bassi (:ebassi) 2015-06-03 15:07:58 UTC
Attachment 304516 [details] pushed as c5e5ee6 - window: Check if we can use CSD before enabling them

The result is not spectacular, but at least it shouldn't be any more broken.
Comment 4 Emmanuele Bassi (:ebassi) 2015-06-22 13:24:58 UTC
Had to revert commit c5e5ee6 as it pretty spectacularly broke the default sizing of empty GtkWindows, as well as exposed a bunch of invalid sizing inside GtkWindow.
Comment 5 Christoph Reiter (lazka) 2015-06-22 19:19:03 UTC
I've opened bug 751341 with a potential fix for the default size issue.

On the reverted patch: It also has the side effect that normal windows without a manually set header bar use CSD while they didn't before. Is this really on purpose?
Comment 6 GNOME Infrastructure Team 2018-05-02 16:36:53 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/557.