startup-notification patch for APPLICATION_ID

[Lubos Lunak]

On Friday 26 of February 2010, Colin Walters wrote:
> Hi Lubos, thanks for the feedback!
>
> On Fri, Feb 26, 2010 at 1:42 PM, Lubos Lunak <l.lunak at suse.cz> wrote:
> >  What is actually supposed to be the improvement? I suppose this addition
> > might be useful, but I fail to see how it helps with tracking.
>
> There's actually two parts; I wasn't clear on this originally:
>
> * Knowing precisely what .desktop file was launched immediately (this
> is important for our UI)
> * Later when the application sends a startup completion message we
> know what X window that came from, and can then make a strong
> association between .desktop and X window.

 That says what it does, but still not why. I assume you want this for some 
kind of a launcher button that will also do other things when the application 
is running. But in this case that launcher already knows, and why should 
others need it?

> However my patch was only addressing the first part really.  Let me do
> both in one patch...I'll post a new patch soon.
>
> >  The ".desktop" part looks superfluous to me, "foo" should be sufficient.
>
> Well we keep the .desktop part in other parts in the stack (e.g. in
> Gio); I don't have a very strong opinion on this, but it does have the
> value that it's obvious to someone looking at it that it's talking
> about a .desktop file and not say the binary, window title or any of
> the 50 other similar-looking components that make up an application.
>
> >> +          When launching a .desktop file NOT in the paths, this should
> >> +          be an absolute path to the .desktop file.

> > If yes, then those paths are
> > configurable and it is even possible for them to not include /usr/. So
> > the value should always be just the name or the full path depending on
> > what usage of this item you expect.
>
> I had this thought that it would be easier implementation wise to
> differentiate these cases in the message, but actually just sending
> the full path and then figuring out whether it's in the current path
> (if the consumer needs to) is best.

 I think it's common in specs to use names rather than filenames, e.g. Icon= 
in .desktop files is just the icon name, and the icon field in the startup 
notification spec is the same, that's why I find the .desktop not belonging 
there.

 On the other hand, if it is sometimes necessary to include full path, then 
the extension should be there too. In this case however there is a conflict 
with the icon field, which just says icon name and expects it to be found in 
the usual paths, in that case maybe it'd be better to assume the same about 
the .desktop file. So we're back to the actual use case and why this 
information should be provided at all.

> +The following keys may be provided optionally in a "remove" message:
> +          
> +  COMPLETED_BY
> +
> +          identification of the top-level window in which the launch
> +          was completed.  The value is the X window ID of the window.

 Why is _NET_STARTUP_ID on such window(s) not sufficient for this?

-- 
 Lubos Lunak
 openSUSE Boosters team, KDE developer
 l.lunak at suse.cz , l.lunak at kde.org