Re: Proposal: add a _NET_WM_DESKTOP_FILE

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

On Thu, 12 Nov 2015 08:11:56 +0100 Martin Graesslin <mgraesslin kde org> said:

> On Thursday, November 12, 2015 7:53:17 AM CET Carsten Haitzler wrote:
> > On Wed, 11 Nov 2015 11:20:35 -0800 "Jasper St. Pierre"
> > <jstpierre mecheye net>
> > said:
> > > Given that most applications already have the WM_CLASS trick
> > > correctly, why can't we just say that users should try to match
> > > WM_CLASS to their desktop file correctly? I don't see a reason to add
> > > a new field when WM_CLASS already does what we want.
> >
> > this is what we've been doing for years. use _NET_STARTUP_ID as a definitive
> > (we launched this and thus we know the desktop file that was associated
> > with that launch - so just use that desktop file and ignore all else" or
> > fall back to _NET_WM_PID (track child pid from launch of desktop file) and
> > if that doesn't work - guess-o-rama based on WM_CLASS. it works really well
> > 99% of the time in regular desktop usage.
> >
> > i see this property as yet another bit of info to add into the guessing
> > pipeline above. likely throw it in after the startup id matcheroo or the
> > pid match (as i'd prefer to use that first for the cases that people make
> > custom desktop files with different icons that launch the SAME binaries but
> > with different options, and using what the process provides is less
> > accurate here)
>
> yeah, my motivation was triggered by stumbling over some of our matching code 
> and thought "we can do better". As Wayland has such a hint I thought it might 
> be helpful for everybody to have it on X11 as well.

i totally get your motivation. it seems decent. i do not see it as something
that supplants other mechanisms - but it is a useful extra bit of info to be
"better at this". :) don't try and tie it to other stuff like dbus - that's
just tying together functionalities that do not belong together. the whole idea
that every process will own a specifically named dbus service is not so great.
what do we do with multiple process instances now? first guy in wins and gets
an interface and everyone else loses? we mandate that no gui app can ever use
multiple process instances ever again like unix has been able to for 20+ years?
no. doesn't belong. if some apps CHOOSE to do this - then fine for them. but
making all apps rely on this model is broken. stick to specifying the desktop
file.

i'm actually wondering though if the file path should be allowed to be absolute
OR "a search path element" at apps will. why NOT provide a full path to a
"system desktop file" (/usr/share/applications/myapp.desktop)? is there really
something wrong with that, but it's OK to
provide /home/user/Desktop/myapp.desktop or such?

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