Re: Proposal: add a _NET_WM_DESKTOP_FILE

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.

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?

Sorry, I think that's just wish-full thinking to be able to update ICCCM 
section and everybody adopting to it.


On Wed, Nov 11, 2015 at 11:22 PM, Martin Graesslin <mgraesslin kde org> 
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

but I think your original intent is
unrealisable: you will either have many apps that provide nothing at

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

wm-spec-list mailing list
wm-spec-list gnome org

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]