Dozens of incomplete stuff in Desktop Entry Standard

[Havoc Pennington]

On Thu, Jun 26, 2003 at 07:31:07PM +0200, Koblinger Egmont wrote:
> 
> 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.

Note that "desktop-menu-tool" in freedesktop.org CVS already does
this. (It generates old-style gnome/kde hierarchy from the new menu
spec, and I also have a patch pending from Matthew Miller to generate
WindowMaker.)

You may want your own tool anyhow, but if you didn't know one existed
maybe you can save time. ;-)

> 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.

Agreed. The thing that would be most helpful would be to propose
patches to the XML/SGML in diff format, so we can simply apply those
changes.

A lot of these issues have been discussed a good bit in the archives, 
if you dig around in there.

> 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.

It will be maintained insomuch as people maintain it; it's very much
not dead, as .desktop file incompatibilities between gnome/kde are
actively addressed (Red Hat Linux breaks if you do anything
incompatible for example), but the spec does remain vague due to lack
of time.

If you send me a login and crypted password I'm happy to give you CVS
access to freedesktop.org, and then it will be easier to generate
patches and you can do things like update the web site.

Another thing that would certainly be helpful would be a test suite
that had valid and invalid desktop files, so implementations could
check that they accept and reject the right things.

I'll go through and give you my take on the answers to some of these
questions in case someone is inspired to patch the spec:
 
> - 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.

Blank lines are ignored/insignificant, afaik. 

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

In general all the current .desktop parsers are very liberal and most
likely accept this, but I think it'd be right to have the spec say all
lines must end in newline.

> - 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?

I would say that trailing or embedded whitespace (including tabs) are 
preserved, and that the statements about spaces around the equals sign
also apply to tabs.

> - 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?

No, not collapsed.

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

I would say that \r\n or \n should be accepted, but it's fine to
mangle this across a read/write.

> - 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?

IIRC there isn't, but I don't remember. It's possible that
backslash-escaping works.

> - 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.

Yes.
 
> 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.

The reasonable options for any text data are:

 - defined to be ASCII always
 - defined to be specific Unicode encoding always
 - in some way encoding-tagged 

Anything else is basically broken, because you can't display it in a
UI or text editor or do anything else with it.

It does seem right to use UTF-8 here but presumably that breaks for 
some legacy unix setups.

> - "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?

The point here is about lists, examples are:

 Key=value1;value2;value3;
 Key=value1;

empty list is presumably either ';' alone or just nothing.

> 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?

Current implementations tend to accept a missing semicolon, I don't
remember any rationale for it. desktop-file-validate does complain if
it's missing though.
 
> - Which keys may be suffixed by [lang]? 

The ones that are given as "localestring"

> - 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.

No.

> - Does an Encoding field specify the encoding of all the lines in the
> file, even the preceding ones and the lines of other groups?

It's undefined what any group other than the [Desktop Entry] one
contains. Said groups are totally defined by whoever makes them up.

> 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?

I would say anywhere.

> - 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?

None of the rest of the file format is internationalized, neither are
most formats such as HTML. This has been decided on for a while, not
worth changing now.
 
> - 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.

This problem also exists for lots of apps other than the terminal, I
don't think we should special case terminals.

The normal way to handle this is to have two desktop files with
OnlyShowIn, such that the right one for each desktop appears.

> 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:

There is a long thread or threads in the archives about this.  I
believe right now GNOME and KDE both do a shell-like parse without
actually using the shell, but they do it in slightly different ways.

Havoc