startup-notification patch for APPLICATION_ID

[Colin Walters]

On Mon, Mar 22, 2010 at 6:05 PM, Lubos Lunak <l.lunak at suse.cz> wrote:

>  I have trouble coming up with a case where this would actually apply. The
> protocol itself should provide all the information needed, so there's no need
> to read anything from the .desktop file. So you'd need the .desktop file only
> to be able to identify it, but if you don't know about it, you don't need to
> identify it anyway.

When an application is launched by a process external to the shell, we
need to know the .desktop file.  Simple example, you right click on a
file in Nautilus and launch GEdit.  What should happen effectively
*immediately* is that the "GEdit" application button in the shell UI
lights up; i.e. not when the gedit process has mapped a window and we
can read the WM_CLASS.

The application button is based on the .desktop file.  Now - we could
certainly do heuristic matching on the other things included in the
startup-notification message like the binary, icon, or description,
and try to figure out what .desktop file was launched (and I might
consider this), but ultimately, it's far better if the launching
process just tells us what it did.

>  But anyway, if you want the full path, how about then just 's/name/full
> path/' in what I wrote above? If you can't tell if others will be able to
> find the .desktop file or not, then it doesn't make sense to guess and
> include the path only sometimes.

You're absolutely right here, and I meant to make that change before,
but I attached an old patch previously =/  How about this one?

Thanks again for the review!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-APPLICATION_ID-key.patch
Type: text/x-patch
Size: 6366 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20100325/dfaa34e8/attachment.bin>