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". Cheers, Thomas [1] https://tronche.com/gui/x/icccm/sec-4.html _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
