On Thu, 12 Nov 2015 14:42:23 +0100 Thomas Lübking <thomas.luebk...@gmail.com> said:
> 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) errr hmm doesn't sound too useful to me then? another property for this that can then specify whatever it likes - even yes an EXPLICIT $name-$pid right in the property (app sets it). it could use a scheme of $name-$instance too then (just start at 1 for instance and go up until it finds a free slot, or use any other scheme to come up with uniqueness - pid is one of the easy ones). > 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.) that's what we use :) > > 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. not saying the client can know easily or not - the spec wording pretty much says it should use abs paths only for custom desktop files and no path for system ones. > > 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. actually some commercial apps do this kind of thing - install desktop files in... fun places ro replicate the windows standard "do you want me to add this icon to your desktop?". :) > PS: all wine and many java clients fail on WM_CLASS as well (just ftr ;-) > Did anyone check open/libreoffice? i have come to the conclusion long ago that the group words java, x11, and client mix well with the word fail. :) i gave up long ago. > Cheers, > Thomas > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > https://mail.gnome.org/mailman/listinfo/wm-spec-list > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
