Re: Proposal: add a _NET_WM_DESKTOP_FILE

["Jasper St. Pierre" <jstpierre mecheye net>]

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



-- 
  Jasper