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
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
https://mail.gnome.org/mailman/listinfo/wm-spec-list
