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.

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.

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).

(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.

Created attachment 276114 [details]
screenshot1

Created attachment 276115 [details]
screenshot2

Created attachment 276116 [details]
screenshot3

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 ?

(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.

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.

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.

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.

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.

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

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?

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.

retitle as general tracker bug

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.

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.

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.

(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.

*** Bug 729794 has been marked as a duplicate of this bug. ***

-- 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.