We're not setting _GTK_FRAME_EXTENTS because kwin tells us that it doesn't support this hint, by not including it in _NET_SUPPORTED.

There's other heuristics you can use to deterimine if an window is from a gtk3 application. We set _NET_OPAQUE_REGION, we use the _NET_WM_SYNC_REQUEST protocol and gtk applications put a bunch of _GTK-prefixed properties on their toplevels, such as _GTK_WINDOW_OBJECT_PATH, _GTK_APPLICATION_ID, etc.

As far I understand from the KDE developers, even if they were able to identify a GTK3 application, enforcing a window decoration would result in doubled title bars. This is also a not expected behavior and would confuse the users. Isn't there a possibility to disable the client side decorations? Otherwise, the usability of GTK3 applications under KDE is really bad, because of the missing window features (e.g. Always on top, Activities, etc.).

Client-side decorations are opted in by applications — i.e. the app developers decided to add a GtkHeaderBar and design/implement their UI via client-side decorations.

Some application developers opt to support both CSD and SSD; others may very well rely on environments to actually support CSD as well as SSD. We cannot "disable CSD" from the toolkit perspective. At most, you'd get applications with an "internal" title bar, and then the decorations from the window manager. That's why we ask the WM to disable the decorations in the first place.

(In reply to Markus Heß from comment #0)

> The issue was already discussed in the KDE bug tracking system:
> https://bugs.kde.org/show_bug.cgi?id=351037

I'd also appreciate if the KWin developers would refrain from comments like this:

"I have a feeling that our points are not considered as we are seen as people who just oppose the idea of CSD and are not forward oriented"

Every time this issue has been brought up on this very Bugzilla, we suggested actionable solutions for what we consider a window manager support bug, only to be shot down because they did not align with KDE's time table and release schedule. The only suggestion coming from KWin/KDE developers has been, pretty consistently, "do not use client-side decorations" — something we clearly are not willing to backtrack on, given that our system has been moving in that direction for the past few years.

On suggestion from KWin developers, GTK stopped using _GTK_FRAME_EXTENTS if not supported; now we should just expose it *again* even when unsupported in order for KWin to detect a GTK3 application?

This comment also does not make sense:

"""
They suggest to check for a gtk client by interpreting the gtk properties (like _GTK_APPLICATION_ID) but that doesn't cut it, because a gtk(2) client may be validly undecorated (eg. audacious/xmms)
"""

GTK+ 2.x applications do *not* expose "_GTK_APPLICATION_ID", nor they will ever expose them, and GTK+ 3.x that are undecorated are also going to use client-side decorations.

Emmanuele, thank you for your comment.

I'm of course very interested in finding a solution which works for all of us. Concerning the comment I stated, this is unfortunately the truth. I'm not sure how much it makes sense from our side to comment on CSD related issues, as you wrote yourself that it seems like "do not use client-side decorations" is our only suggestion.

This is of course not true. First of all I do not care what GNOME and GTK does on GNOME Shell. If you want to use CSD, fine with me, if you don't want to use CSD also fine with me. That's your area, I don't care about.

What I care about is if features break on our system. And I think I have done more than can be expected. I spent half a working day reproducing regressions and reporting them on your bug tracker. Unfortunately most issues haven't been resolved yet. So I don't see what else we can do?

We do not have the manpower to implement GTK's decorations in the way GTK would need it. It doesn't fit our internal design and our priorities are not in those areas. I'm sorry, but I'm not paid to work GTK applications work the way as they are working in GNOME Shell. In concern of the CSD implementation in GTK one of the main problems is that it assumes specific non-standardized behavior of Motif hints. This we have communicated. You can even find suggestions to replace the Motif hint with a standardized hint on NETWM mailing list suggested by KWin developers.

I'm very interested in having a standardized way to communicate with CSD based applications. To tell applications where to put which decoration button, which ones to expose. How to handle clicks on various areas, ensuring that features like middle click on maximize button works, etc. Also we would be very interested in having features like telling the application to not decorate itself. Not because we want to force SSD on them, but because we have features like no decoration for maximized windows (used by our Netbook shell). I think such specifications should be pushed by people wanting CSD, it should be announced in _NET_SUPPORTED. I don't have the time to push such a specification. This is something I expect from you guys. I also hope that GTK is interested in a good integration of their applications in other environments, to not have them look broken. Currently in all non GNOME environments that would be to disable your CSD. I'm especially not thinking about Plasma here, but rather about tiling window managers. I have heard lots of complaints from awesome users who come to me and thank me for discussing and raising the issues with GTK developers. To me the tiling window managers are an important part of the Linux ecosystem and I consider it important that applications work fine in them. I consider it very unfortunate that GTK broke the way how windows used to work without previous consulting other concerned parties. E.g. on the point of the Motif hints we could have told you that we do not implement them in the way you expected and that we will never be able to do so without breaking our ABI promise.

> This comment also does not make sense:

Yes it does.
GTK clients may be validly undecorated - whether it's 2 or 3 does absolutely not matter. Thus I put the number in braces. I don't need to know about where you set this unspecified property and, frankly you don't know whether it will never be used on any gtk2 client (the client could simply set it, you know?)

You might have noticed that the bug that triggered the suggestion is to use that hint to add a decoration *despite* there's a client side decoration in gtk3 and there's no guarantee, let alone specification, on whether a gtk3 window without a decoration will have a client side "decoration" (eg. what if something like xeyes used gtk3?)

I'll now not refrain from telling you the truth that ever since this "feature" has been handled like a hack on the gtk side - nothing else.
A hack, depending on undocumented behavior of specific window managers (which, on a  sidenote, does not match the MWM behavior either) and changes from day to day, apparently depending on your mood (what's ok, since there's no specified behavior - because it's a hack)

Leaving every technical aspects aside, your stance is that you hack around and everyone else has to please run after you.
That's not unprofessional, that's arrogant.

Specify the protocol properly, have it reviewn and then implement that. That's why we introduced the netwm protocol - which is btw. discussed on a gnome mailing list... Cannot be that hard, can it?

Of course this implies to think about the feature, challenge its pitfalls and notably how to deal with the situation, when no support is announced by the windowmanager - or there is none.

Otherwise simply state "we don't care about interoperability and other environments, gtk3 clients are designed to run on GNOME".
That would at least be honest to your users - and matches my current impression (as well as apparently your own strategy: https://lwn.net/Articles/562856/)

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