startup-notification patch for APPLICATION_ID

Colin Walters walters at verbum.org
Fri Feb 26 08:43:48 PST 2010


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.

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.
>
>  This talking about paths is rather vague. First of all I cannot find anything
> about normal application paths in the desktop file specification. Perhaps you
> meant the desktop base directory spec?

Yep, thanks.

> 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.


More information about the xdg mailing list