Dozens of incomplete stuff in Desktop Entry Standard

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 26 June 2003 19:31, Koblinger Egmont wrote:

Let me provide you with information about KDE's implementation.

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

KDE drops trailing whitespace.

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

They should be kept as is.

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

I assume we drop it.

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

KDE uses "\s" to escape spaces at the start/end of values. Other escape 
sequences used are: \t, \n, \r and \\

I don't think that trailing or leading spaces in any of the values found in 
.desktop files is really appropriate though. KDE supports \s because our 
.desktop file parser is based on our generic config file parser, and there we 
need to be able to handle every possible string.

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

KDE doesn't support that. The only non-ascii filenames that we probably handle 
right in this context are valid utf-8 filenames when running in a utf-8 
locale.

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

I agree with that and KDE does not require it.

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

KDE supports it for every key. 

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

KDE ignores the Encoding lines and uses heuristics on a per-key basis to 
decide if a value is valid UTF8, if it is not valid UTF-8 it assumes 
Legacy-Mixed. KDE uses UTF-8 for all its own files. Files installed with KDE 
include an Encoding header, but I suspect that .desktop files created during 
runtime may actually miss such header. (Sorry :)

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

KDE doesn't care, see above, although I can imagine that implementations 
expect it to appear before entries affected by it.

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

true and false have more meaning of themselves than 0 and 1.

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

KDE doesn't support that at the moment.

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

KDE assumes system() syntax. We make sure to add quotes to the %f-like 
substitutions, taking into account the situation where the %f is shell-quoted 
already. 

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

Oswald may be able to comment on that.

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

%f, %u, %d, %n may expand to 0 or 1 argument.
%F, %U, %D, %N may expand to 0, 1 or more arguments.

All others always expand to 1 argument.

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

Don't do that ;-)

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

Oswald may be able to comment on that.

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

I think we support that yes. Not sure since how long.

> 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,
Waldo
- -- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE++1cXN4pvrENfboIRAk72AJ9UwBQE4AM0Sc/18BhyZGSh0lhtnACeOAQH
L3XAWiw0nFmq7GzKN6E+Mg4=
=QHBo
-----END PGP SIGNATURE-----