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 <[email protected]> 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 [email protected] , [email protected] _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
