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. > 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. 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. > Cheers > Martin > >> >> On Wed, Nov 11, 2015 at 11:22 PM, Martin Graesslin <mgraess...@kde.org> > wrote: >> > On Wednesday, November 11, 2015 11:21:44 AM CET Allison Ryan Lortie wrote: >> >> I understand that this doesn't correspond exactly to your original >> >> intention with this addition, >> > >> > no it's worse: it makes the part which I wanted to fix impossible. Which >> > would mean that: >> > a) I scratch what I wanted to fix >> > b) willfully break the spec >> > c) add a KDE specific additional property to get what I wanted in the >> > first >> > place >> > >> >> but I think your original intent is >> >> unrealisable: you will either have many apps that provide nothing at >> >> all, >> > >> > which is fine! This is an optional flag. It's not a requirement. The >> > proposal (after Thomas update) will say that the window MUST NOT specify >> > the desktop file if it doesn't know it. If it cannot be matched to a >> > desktop file: that's fine. >> > >> >> or you will have some apps that provide something other than the >> >> desktop file name. >> > >> > This would be a clear violation of the spec. Adding a requirement to add >> > DBus to it, will not fix windows ignoring the spec and passing in wrong >> > data.> >> >> This is the same problem as the previous attempt to solve this problem: >> >> there was a proposal at some point that the wmclass should be equal to >> >> the name of the desktop file. For many apps this was true, but coverage >> >> was never 100%. >> > >> > Right, because you cannot change the meaning of an existing property and >> > then assume that it will work. Because of that I propose a new additional >> > protocol applications can opt-in to when they can provide the >> > information. >> > >> > Cheers >> > Martin >> > _______________________________________________ >> > wm-spec-list mailing list >> > wm-spec-list@gnome.org >> > https://mail.gnome.org/mailman/listinfo/wm-spec-list -- Jasper _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
