Dozens of incomplete stuff in Desktop Entry Standard

[Koblinger Egmont]

Hi!

I just started to write a small utility that takes .desktop files as input
and creates menus for many old-fashioned window managers in many
languages. Hence I had to study the exact specification of these .desktop
files.

Unfortunately, after having read the draft document several times, I have
many-many questions that are unanswered by this document. This document
seems to be a guideline rather than an exact specification to me, which in
some cases might even lead to incompatible implementations. Some of my
comments/questions that'll follow soon might seem to be very trivial and
stupid, but I do believe that they have to be addressed in such a
standard.

It's a little bit sad to see that this document hasn't been maintained for
two years now, but I do hope that after a big cleanup it will be released
as 1.0. With this mail I hope I can help in reaching it. I really do hope
that this standard is not a dead one (as lots of others which are not even
marked as draft rely on it) and will be maintained in the near future.

Strange too, but version 0.9.2 is available on www.freedesktop.org, though
according to the CVS changelog 0.9.3 was committed a fey days later.


After this intro let me tell you my problems:


2. Basic format of the file

- It isn't mentioned anywhere how empty (or blank-only) lines should be
handled, whether they are allowed before the [Desktop Entry] line, whether
they should be preserved across reads/writes of a file.

- Whether a file that doesn't end in a newline should be tolerated (with
or without ignoring the last line) isn't specified either.

- Spaces around the equals sign are mentioned. What about spaces at the
beginning or at the end of a line? If I write "Icon=asdf.png " (with a
space at the end) then does the desktop have to show "asdf.png" or
"asdf.png "? What about TABs? Should they be carried across reads/writes
or can they be dropped?

- What about multiple spaces? Are they collapsed into a single space or
not? E.g. if I write "Icon=asdf  qwer.png", then will "asdf  qwer.png" or
"asdf qwer.png" be opened?

- Should CRLF-style newline be accepted? Should CR's be carried across
reads/writes or can they be silently dropped?

- Is there any kind of general escaping (that applies to all lines) so
that values beginning/ending with a space or similar can be specified?

- What if multiple "=" signs appear in a line? It should be specified that
the first one is the delimeter, other ones are simply part of the value.


3. Possible value types

- "value for a string key must contain only ASCII characters". A typical
key that takes a string is Exec or Icon. It's clear that these take string
instead of localestring: the value is not shown to the user in
human-readable form but is only used for verbatim copying, opening a file,
execing something. However, filenames might contain accented characters,
and I do want to be able to open or exec them. Hence I recommend that
values to the string should be able to contain 8-bit characters. They
should be treated as-is without any charset conversion, without even
requiring it to be valid UTF-8 or anything similar.

- "Some keys can have multiple values; these should be separated by a
semicolon. Those keys which have several values should have a semicolon as
the trailing character." -- sorry, it's not clear to me: if a key can have
multiple values but does only take one value in a particluar line of a
particular file, then does it have to be terminated by a semicolon?
Furthermore, the specification itself is buggy in section 8, Example
Desktop Entry, having a line "Actions=Edit;Inverse" where this trailing
semicolon is missing. Actually, what's the purpose of it, and what should
an implementation do if it isn't there? Wouldn't it be simpler to just
forget this trailing semicolon?


4. Recognized desktop entry keys

- Which keys may be suffixed by [lang]? It isn't clear to me, though I
believe that it is legal to write Exec[hu]=... Icon[hu]=... or
SortOrder[hu]=... and they might even have a sane meaning (there might be
an application which gets its language in a command line argument hence I
want to write "Exec[hu]=foobar -lang=hungarian", "Exec[fr]=foobar
-lang=french" etc... For the icons I might prefer a Hungarian flag for a
keyboard-swithing utility or a dictionary, though French users probably
prefer a French flag there.) Some others, e.g. Terminal[hu]=true,
Terminal[fr]=false might not have any sense. I'd really like to see it in
the specification whether these have to be supported by an implementation
or not.

- Should lines such as Encoding[hu]=Legacy-Mixed be supported? This would
have the meaning that all Key[hu]=Value lines are encoded in ISO-8859-2
but it doesn't specify the encoding of other languages.

- Does an Encoding field specify the encoding of all the lines in the
file, even the preceding ones and the lines of other groups? Can it occur
anywhere in the group (even after the Names and Comments encoded in the
charset mentioned here) or does it have to occur before the very first key
of type localestring?

- Terminal: false or true. As a legacy stuff 0 and 1 should be supported,
says the docs. I'd personally prefer 0 and 1 since these are world-wide
values, while true and false are English words. Why prefer English where
the same can be done with international symbols? Furthermore, 0 and 1 are
easy to remember, but with the English words it's harder to remember
whether it is true/false, True/False, yes/no, enable/disable, On/Off etc.

- Single terminal: Every desktop file could contain "Exec=xterm -e foobar"
instead of "Exec=foobar" and "Terminal=true". I guess the reason why
requiring a terminal is handled as a special case must be that each
desktop environment has its preferred terminal emulator. However, how do I
create a .desktop file which simply launches the preferred terminal of my
desktop environment? "Exec=bash" and "Terminal=true" might be a solution
if everyone used bash, however, it is not the case. I suggest that a
Terminal=true line and no Exec line at all had the meaning of launching a
terminal on its own.


6. List of valid Exec parameter variables

- Finally: My biggest problem with the specification is that it doesn't
say a single word about _how_ the value of the Exec key should be
interpreted. I divide this question into subquestions:

  - If you get a string and have to execute the command specified there,
  basically you have two choices under Unices: system() and execve().
  They behave completely differently and both of them might have
  variants (For the system() approach: should you call system() or
  ``sh -c ...'' or or ``/bin/sh -c ...'' or ``getenv("SHELL") -c ...''?
  For the execve approach: where should you split the value and what are
  the possibilities for escaping?) Whether redirections (>/dev/null), env
  variables, pipes etc. can be used does highly depend on this choice.
  (Note: Window Maker has two different keywords: EXEC and SHEXEC for
  these two possibilities.) Using system() and allowing %f-like
  macros would lead to big security holes, e.g. if you receive a file called
  'foo; rm -rf something; bar.doc' and double-click on it which launches
  'kword %f' it would remove your files. Fortunately it seems to me that KDE
  and Gnome follow the execve() interpretation. However, as long as I haven't
  checked all the desktop environments, I am afraid that some of them use
  system() since it's a big fault in the .desktop specifications that it
  doesn't tell how the value should be interpreted.

  - Okay, let's assume that we follow the execve() approach. How should
  the command line be split into arguments? At spaces, or spaces and TABs?
  What to do with adjacent or trailing spaces? Are there any escaping or
  quoting possibilities? If yes, what are they? Is there a way to pass an
  argument that itself contains a space? Is there a way to pass an empty
  argument?

  - About the Exec parameter variables: it is completely unclear to me
  which one of these %f %F and friends may expand to at most one, exactly
  one, at least one or any number (including zero) command line arguments.
  For example, will %f disappear or substitute to an empty argument if I
  launch the application from a menu entry? Will %c disappear or be an
  empty argument if there's no Comment key in the .desktop file? And if
  there's a "Comment=" line in the .desktop file (with no value)?

  - In case the meaning of %f %F %c etc. were defined precisely:
  what's their meaning if they don't appear on their own? E.g. if %F might
  expand to multiple arguments, then what happens if I write foo%Fbar in
  the file? Will the first filename be prefixed by foo and the last one
  suffixed by bar? Will all the filenames be prefixed and suffixed by
  these? What does this expand to if %F expands to zero filenames? Or do
  they only have special meaning if they appear on their own? This later
  would contradict the following phenomenon:

  - In KDE plenty of the .desktop files have something like this:
  ``Exec=kscd -caption "%c" %i %m'' However, I don't see the double quotes
  in the process listing which would be trivial if the system() method
  was be followed by KDE, but since KDE follows the execve() method I
  don't have a clue who and when swallows those double quotes. So: when
  and how should the double quotes be substituted to something?

  - How to pass a % sign to the application? Is %% (like for printf) okay?




I hope that all these questions will be answered and clarified in the
specification in the not-so-far future, discussed here first if necessary.
I've joined this mailing list, and waiting for your kind comments.


Cheers,


Egmont Koblinger
developer of UHU-Linux distribution