Proposal for ExecComment field inside .desktop files

milosz derezynski internalerror at
Sun Nov 13 06:59:02 PST 2005

Hey Everyone,

I'd like to propose an addition to the .desktop file spec.

My proposal is a key of the name "ExecComment" in the main [Desktop]
First just an example:

[Desktop Entry]
Comment=Play music
ExecComment=Play File

The intention of this is so file managers can show instead of (using
Nautilus as example here now):

[GTK STOCK OPEN] Open with BMPx...

something like:

[BMPx ICON] BMPx (Play File)

Just for the sake, another example might be:

[Desktop Entry]
Comment=View Images
ExecComment=View Image

In these particular examples it might seem like Comment= would be usable for
that, but it's actually not, since Comment= describes the application, not
what happens on Exec (which is the exact point of ExecComment). Couldn't
come up with an example off hand that has a rather different Comment= field
than ExecComment= would be, but i guess you get the semantic difference

I talked with dobey for a few minutes on that topic in #freedesktop, and he
argued about 2 things (alledgedly, i somehow talked him either into boredom
or annoyance so we didn't proceed with the discussion, sorry again at this
occasion). In any case, he said:

1) This is improper use, since this would be an action
But i argue that this is nothing different than the current "Open with..."
just more verbose, and easier for the user to pick since he's faster at
finding an icon visually rather than reading all the "Open with $APP_NAME"
entries. If the current "Open with..." is not an "action", what is it then?
(To put it this way around).

I'm aware about the [Desktop Action ...] spec part, but this is another
case, where one might even argue whether this spec makes much sense, since
in the context of the whole desktop environment, opening a file with a
particular app already constitutes an action in the very sense of the word,
and one might argue if the distinction between [Desktop] and [Desktop Action
...] really makes sense, or if it's not just a hack-on onto broken or just
inherited and wildly-grown semantics from over the past few years.

2) The icon adds visual noise
I don't think this is the case here. It will much rather help the user to
pick his desired application faster. (Sorry for the irony, but you might
then as well remove the icons from the gnome-panel menu and replace them

Ok so far for my proposal, what do you think about it?

Milosz Derezynski

------------------------ | In theory, theory and practice are the same.
In practice, they're not!
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the xdg mailing list