On Thursday, November 12, 2015 12:27:50 AM CET Jasper St. Pierre wrote:
On Wed, Nov 11, 2015 at 11:42 PM, Martin Graesslin <mgraesslin kde org>
wrote:
On Wednesday, November 11, 2015 11:25:15 PM CET you wrote:Is there a use case where the WM_CLASS would be different from the desktop file name in practice? I'm not aware of any applications which weren't able to adapt to the new WM_CLASS matching rules once told about them -- we should just document it.Erm, sorry. You cannot change the meaning and expect legacy applications will adopt to it. That just doesn't work. And yes I tried and the first application I checked has a mismatch between desktop file name and WM_CLASS. I picked xterm.The latest version of xterm ships an xterm.desktop, and the default class is "XTerm": https://github.com/tkztmk/xterm/blob/master/main.h#L58 Seems like it works fine to me.
all right, so my debian's version is outdated :-) Anyway found a different example: class from xprop: WM_CLASS(STRING) = "chromium-browser", "chromium-browser" started through /usr/share/applications/chromium.desktop other example, from KDE/Qt world: class from xprop: WM_CLASS(STRING) = "kate", "kate" started through /usr/share/applications/org.kde.kate.desktop That's btw. the case for all Qt applications: Qt doesn't know anything about desktop file names (new in Qt 5.7).
Oh and there are also windows belonging to applications which don't have a desktop file at all. I can think of hundreds of test applications which just don't install on the system in any meaningful way. What's their WM_CLASS supposed to be?When they create their .desktop file, they should give it the same name as WM_CLASS. I don't see how this is in conflict. If they're test applications that don't require .desktop files, then I don't see how your _NET_WM_DESKTOP_FILE proposal helps that use case either.
The difference is: with WM_CLASS you don't know what it is. It might be the desktop file name or it might not. You just don't know. With the dedicated one you know what it is: if it's set it's the desktop file, if it's not set you at least know that there is no desktop file.
We already have too many different kinds of identifiers for applications (package name, binary name, .desktop file name, well-known DBus name, WM_CLASS). I am strongly in the interest of moving towards one identifier.Sorry, I think that's just wish-full thinking to be able to update ICCCM section 4.1.2.5 and everybody adopting to it.WM_CLASS is already used as an application identifier for ~/.Xresources -- that's part of the reason it was introduced. I see no reason why we can't use that same application identifier for .desktop files as well. GNOME has done this in practice for well over 5 years at this point without any major issues.
I'd rather have a clear semantics instead of a property which might or might not contain a desktop file name. We cannot (!) reinterpret the meaning of an established standard. How would anybody know about it? Who's going to update ICCCM? Sorry ICCCM is one thing and NET_WM has always been about adding additional hints for things ICCCM cannot provide. I want to get rid of heuristics like oh let's see whether this WM_CLASS property might be a desktop file. I want a clear "that's a desktop file!". If people prefer to stay with heuristics that's fine with me, then I'm going to withdraw the proposal. Cheers Martin
Attachment:
signature.asc
Description: This is a digitally signed message part.