Re: Proposal: add a _NET_WM_DESKTOP_FILE



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]