Re: Proposal: add a _NET_WM_DESKTOP_FILE

On Thu, 12 Nov 2015 14:42:23 +0100 Thomas Lübking <thomas luebking gmail com>

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"

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.

wm-spec-list mailing list
wm-spec-list gnome org

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com

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