Re: Proposal: add a _NET_WM_DESKTOP_FILE

On Donnerstag, 12. November 2015 11:38:16 CEST, Carsten Haitzler wrote:

> what do we do with multiple process instances now? first guy in 
> wins and gets an interface and everyone else loses?

See my reply to Allison on this - basically the dbus name isn't the service, we'd have to mandate a service pattern like $name-$pid on top of that to actually make use of the service.
The intention seemed less to link the dbus service, but to formalize "where does the client know it's desktop service? answer: it knows it's dbus name and that's *perhaps* also the desktop service" (ie. completely crossing Martin's original intention)

Imo the answer is: we don't care.
Either the client knows it (because the installation provides such service and if downstream alters that, downstream needs to fix the property as well) or it doesn't at all. In the latter case we can still make use of the feature because the WM has a legit property to set from the NET_STARTUP_* message stuff when the client initially gets managed (and that property can be read by other/restarting WMs later on as well as taskbars etcetc.)

> why NOT provide a full path to a "system desktop file"
>  (/usr/share/applications/myapp.desktop)? 

pre-knowledge on this should be hard to get from the client (unlike from the launcher) - neither does it know where it will get ultimately installed (the build scripts would have to wire that down) nor (showstopper) whether the service is shadowed by a user-local copy.

> provide /home/user/Desktop/myapp.desktop or such?
This is actually the exception - It might be nice to allow, but I'd not have a usecase at hand either.


PS: all wine and many java clients fail on WM_CLASS as well (just ftr ;-)
Did anyone check open/libreoffice?

Cheers,
Thomas