Re: Proposal: add a _NET_WM_DESKTOP_FILE

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Thu, 12 Nov 2015 14:42:23 +0100 Thomas Lübking <thomas luebking 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)    raster rasterman com