Re: Proposal: add a _NET_WM_DESKTOP_FILE

So you'll have to add an API to Qt for this new use case (specifying
the desktop file). Why not have Qt set the default WM_CLASS of newly
created windows when you call this new API?

Don't get me wrong, I'm totally in favor of cleaning up matching
semantics, but I'm not sure adding *yet* another property and
heuristic is a good way to do it.

On Thu, Nov 12, 2015 at 1:07 AM, Martin Graesslin <mgraesslin kde org> wrote:
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>
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":

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


other example, from KDE/Qt world:
class from xprop:
WM_CLASS(STRING) = "kate", "kate"

started through


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



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