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 <mgraess...@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 <mgraess...@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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
