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 729721 - (CSD) CSD compatibility issues
(CSD)
CSD compatibility issues
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.13.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 729794 (view as bug list)
Depends on: 698762 705825 707167 708431 708857 709413 727693 729767 729769 729772 729773 729777 729780 729781 729782 729783 729784 729786 729788 729792 729793
Blocks: 722652 736772
 
 
Reported: 2014-05-07 15:16 UTC by David Edmundson
Modified: 2018-05-02 16:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (6.22 KB, patch)
2014-05-07 15:16 UTC, David Edmundson
none Details | Review
screenshot1 (29.72 KB, image/png)
2014-05-08 02:38 UTC, Matthias Clasen
  Details
screenshot2 (31.92 KB, image/png)
2014-05-08 02:38 UTC, Matthias Clasen
  Details
screenshot3 (29.78 KB, image/png)
2014-05-08 02:39 UTC, Matthias Clasen
  Details
Check windows manager supports CSD before enabling (6.29 KB, patch)
2014-05-08 16:20 UTC, David Edmundson
none Details | Review
Only use CSD if supported by the window manager. (8.45 KB, patch)
2014-05-08 19:11 UTC, David Edmundson
rejected Details | Review

Description David Edmundson 2014-05-07 15:16:46 UTC
Created attachment 276074 [details] [review]
Patch

Currently CSD causes numerous problems on other window managers; double borders, shadows in the previews and more.

We end up with images like https://lh5.googleusercontent.com/-pbnWrNbEWlk/U2jq5uQC9XI/AAAAAAAAB6Q/_jDVeep1PSw/w527-h542-no/dfeet1.png

This patch provides a hook in GDKScreen to query if the X11 window
manager supports CSD, currently by using _NET_WM_NAME and enables/disables CSD appropriately. 


Testing done:
 - ran kwin and bijiben and saw kwin's decoration
 - ran mutter and bijiben and saw only the original decoration
Comment 1 David Edmundson 2014-05-07 15:21:24 UTC
EDIT: that linked screenshot should be 
https://plus.google.com/photos/+Ivan%C4%8Cuki%C4%87/albums/6010311973653118369/6010311977566853522?pid=6010311977566853522&oid=110056595556118601349 to see the double decoration.
Comment 2 Emmanuele Bassi (:ebassi) 2014-05-07 15:27:48 UTC
we actually already have feature negotiation for this stuff: it's called Motif WM hints. we ask for the window manager to not add a title, but still add a border to CSD decorated windows.

sadly, it seems that in 20 years not many window managers bothered with those (see also XFWM4).

I highly doubt that maintaining a white list in our code is going to scale; for instance, attachment 276074 [details] [review] already keeps out Metacity, which is capable of rendering CSD windows.
Comment 3 David Edmundson 2014-05-07 16:26:16 UTC
I agree it won't scale, I was hoping this would evolve into a discussion on a better approach, possibly an atom hint on the root window; but the current hints aren't enough.

Supposing kwin honoured everything perfectly (and there's some discussion about whether the hints are sane which I won't pretend to understand / side with) we still have problems.

Motif hints can tell the WM not to draw borders, but it doesn't tell the WM that it is drawing it's own shadows and tell the WM how to ignore these shadows. 

This screws up our snapshot app, the expose effect / window previews, and window snapping as we include the shadows in the window size.

At a minimum we would need hints on your shadow extents and then update all of our code to subtract them in all our code (and every other WM / window using app).
Comment 4 Martin Gräßlin 2014-05-07 16:56:50 UTC
(In reply to comment #3)
> At a minimum we would need hints on your shadow extents and then update all of
> our code to subtract them in all our code (and every other WM / window using
> app).

which wouldn't fix the version out there right now. Such changes wouldn't have a chance for our stable version of KWin 4.11 (released July 2013).

If we at KDE would introduce a change like that we would add a proprietary atom to _NET_SUPPORTED like _KDE_NET_WM_CLIENT_SIDE_DECORATION and check for that from the toolkit. My suggestion would be to go that road as a short term solution and work on a proper NETWM extension.

Note that MWM hints are not sufficient. E.g. it doesn't handle shadows and it doesn't allow the window manager to opt out of it. Thus creating situations where it's double decorated because the window manager doesn't support MWM hints. There's no way to tell whether the window manager supports MWM hints.
Comment 5 Matthias Clasen 2014-05-08 02:38:17 UTC
Created attachment 276114 [details]
screenshot1
Comment 6 Matthias Clasen 2014-05-08 02:38:39 UTC
Created attachment 276115 [details]
screenshot2
Comment 7 Matthias Clasen 2014-05-08 02:39:02 UTC
Created attachment 276116 [details]
screenshot3
Comment 8 Matthias Clasen 2014-05-08 02:40:27 UTC
I've taken some screenshots myself, with kwin 4.11. Seems to be working more or less just fine with csd, on my system. What am I missing ?
Comment 9 Martin Gräßlin 2014-05-08 05:22:07 UTC
(In reply to comment #8)
> I've taken some screenshots myself, with kwin 4.11. Seems to be working more or
> less just fine with csd, on my system. What am I missing ?

Lots :-) I'll report independent bugs for all the issues reported. Be prepared 
for 10 to 20 incoming bug reports.
Comment 10 Martin Gräßlin 2014-05-08 07:40:40 UTC
First round of issues I found so far:

* 729767
* 729769
* 729772
* 729773
* 729777
* 729780
* 729781
* 729782
* 729783
* 729784
* 729786
* 729788
* 729792
* 729793

Note: most apply not just to KWin but to many other window managers, too, especially the tiling window managers.
Comment 11 Emmanuele Bassi (:ebassi) 2014-05-08 14:44:34 UTC
thanks for the bug reports, they are much appreciated.

I've gone ahead, and made this bug the tracker for the other ones that Martin 
opened.
Comment 12 David Edmundson 2014-05-08 16:20:10 UTC
Created attachment 276173 [details] [review]
Check windows manager supports CSD before enabling

Instead of whitelisting search for
_GTK_FRAME_EXTENTS in _NET_SUPPORTED on the window manager's hints.

This the hint used by the applications to tell the WM about the size of their shadows; if a window manager doesn't understand it we don't want to be painting our own shadows.
Comment 13 David Edmundson 2014-05-08 19:11:06 UTC
Created attachment 276192 [details] [review]
Only use CSD if supported by the window manager. 

Updated to also include implement the virtual method on broadway and windows backend.
Whether they should be enabled on windows or broadway I don't really know, feel free to change as appropriate.
Comment 14 Matthias Clasen 2014-05-11 13:40:20 UTC
Review of attachment 276192 [details] [review]:

No need to spread csd knowledge over all of gdk - we can handle it just fine in gtkwindow, as we're already doing
Comment 15 David Edmundson 2014-05-11 14:09:14 UTC
Do you mean you are going to leave things as they are, or do you mean you can move the WM detection support into GTKWindow?
Comment 16 Matthias Clasen 2014-05-11 15:30:53 UTC
if you look through the history, we actually had code that checked if _GTK_FRAME_EXTENTS is supported before using csd. I took it out because it seems better to have problems with shadows than problems with double headers. We can take another look at it, and try to figure out a way to make it so that we just don't do client-side shadows if _GTK_FRAME_EXTENTS is not there.
Comment 17 Matthias Clasen 2014-05-11 15:58:28 UTC
retitle as general tracker bug
Comment 18 Darren Salt 2014-06-17 19:43:10 UTC
Personally, I quite like being able to move windows belonging to unresponsive applications by using the WINDOW DECORATIONS PROVIDED BY THE WINDOW MANAGER.

Yes, shouty, I know, but I've just been hitting some problems with GTK+3 apps here (Xfce, xfwm4): no proper window decoration, just some seriously out-of-place client-drawn/handled stuff (resize, close, and a menu which is missing things like shading), and the window extents are some way beyond what's actually drawn (which makes edge-snapping look somewhat off).

I couldn't care less what you break or otherwise mangle in a full GNOME environment; just don't break it for the rest of us.
Comment 19 Martin Gräßlin 2014-06-24 05:49:32 UTC
What's the state of this? Is there any chance that the implementation will perform a supported check and check whether the window got decorations? I really don't want to release our KWin 5.0 with GTK applications broken all over the place due to shadows being part of the window or being double decorated. We don't have much time to add support and I don't want to have to enforce server side decorations to give our users working windows back.
Comment 20 John Lindgren 2014-08-03 02:26:15 UTC
Add to the list:
https://bugzilla.gnome.org/show_bug.cgi?id=734159

Some other window managers (tested xfwm4 and OpenBox) don't support the _NET_WM_STATE_FOCUSED property yet.  Hence, client-side decorations are drawn identically for focused and unfocused windows, which is confusing.
Comment 21 Martin Gräßlin 2014-08-11 07:54:50 UTC
(In reply to comment #20)
> Add to the list:
> https://bugzilla.gnome.org/show_bug.cgi?id=734159
> 
> Some other window managers (tested xfwm4 and OpenBox) don't support the
> _NET_WM_STATE_FOCUSED property yet.  Hence, client-side decorations are drawn
> identically for focused and unfocused windows, which is confusing.

The same is the case for KWin which also doesn't support _NET_WM_STATE_FOCUSED.
Comment 22 Daniel Boles 2018-03-30 11:34:20 UTC
*** Bug 729794 has been marked as a duplicate of this bug. ***
Comment 23 GNOME Infrastructure Team 2018-05-02 16:04:47 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/486.