startup-notification patch for APPLICATION_ID
walters at verbum.org
Thu Mar 25 07:23:40 PDT 2010
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...
Size: 6366 bytes
Desc: not available
More information about the xdg