Re: Proposal: add a _NET_WM_DESKTOP_FILE

On Freitag, 13. November 2015 01:07:15 CEST, Jasper St. Pierre wrote:

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.

One might very well push for "can WM_CLASS prettyprettyplease match your desktop service / application ID", 
but one can *never* rely on that information.

As Martin pointed out one cannot simply redefine a dead-old property and expect the result to somehow work:

"On POSIX-conformant systems, the following conventions are used:
If "-name NAME" is given on the command line, NAME is used as the instance name.
Otherwise, if the environment variable RESOURCE_NAME is set, its value will be used as the instance name.
Otherwise, the trailing part of the name used to invoke the program (argv[0] stripped of any directory names) is 
used as the instance name."¹

Let alone to expect "XTerm" could simply become "org.x.xterm" and expect no breakage.
Therefore the WM (or anything) cannot simply override WM_CLASS to match some desktop service name. That's 
unfortunate, but true.

=> To export a common idea about a link between a window and a desktop service one will need an additional property, 
which ideally *should* match WM_CLASS - but cannot "must".



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