[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Desktop Entry design standard
From:       David Faure <faure () alpha ! tat ! physik ! uni-tuebingen ! de>
Date:       1999-05-04 17:16:18
[Download RAW message or body]

On Mon, May 03, 1999 at 07:28:37PM -0400, pbrown@redhat.com wrote:
> 
> Historically these desktop entry files have had an extension of
> ".desktop" or ".kdelnk".  While this should continue to be supported,
> recognition of the file via "magic detection" is the preferred way of
> determining file type, and is the fallback when no file extension is
> present.
Problem is that the current mime-type autodetection checks for 
# KDE Desktop Entry
which is not part of this document.
So ... ah yes the solution is : to change the regexp in the magic file
so that it includes also [KDE Desktop Entry] and [Desktop Entry].

> If a file extension is used, it should be ".desktop";
> ".kdelnk" is deprecated.  Desktop entries which describe how a
> directory is to be formatted/displayed should be simply called
> ".directory".
> 
> The basic format of the desktop entry file requires that there be a
> "group" header named "[Desktop Entry]".  For backwards compatibility,
> KDE will also support the header "[KDE Desktop Entry]".  This "group"
> entry denotes that all {key,value} pairs following it belong in the
> Desktop Entry group.  While it is permissible for there to be other
> groups in the desktop entry file, this is the only group that
> explicitly needs to be supported. This group should also be used as the
> "magic key" for automatic mime type detection.  There should be
> nothing proceeding this group in the desktop entry file but possibly
"preceeding", you mean ? (i.e. "before", right ?)

[...]
> MimeType	the MIME type(s) supported by this entry	string(s)
When hacking kio, I had a thought about this.
Can we rename this to "Name" ?
In the mimetype kdelnk there is no "Name" field currently, and this would 
remove the need for yet another key. What's more, it makes .desktop files
more compatible one with the other (i.e. "Name" is always required).
Oh, I see a drawback : mimetype names should not get translated...
Hmm, maybe this is a wrong idea. Please tell me what you think.

> MountPoint	if FSDevice type of entry, the mount point
> 		of the device in question			string
> Name		name of the entry				string
> Path		if entry is type Application, the working 
> 		directory to run the program in			string
> Patterns	if entry is type MimeType, various file name
> 		extensions associated with the MIME type.	string(s)
> ReadOnly	if FSDevice type of entry, specifies whether
> 		or not the device is read-only
> numeric (2)
> SortOrder	if entry of type Directory, this may specify
> 		the order in which to display files		CSV string
> SwallowTitle	if entry is swallowed, title of window		string
> SwallowExec	program to exec if swallowed app is clicked	string
> Type		the type of desktop entry			string (1)
> Terminal	whether the program runs in a terminal window	numeric (2)
> TerminalOptions	
> TryExec		if specified value not found in path, do not
> 		display this entry in menus, etc.		string
> UnmountIcon	icon to display when device is not mounted
> 		Mounted devices display icon from Icon key	string
> URL		if entry is Link type, the URL to access	string
> 
> 
> Notes:
> 
> (1) possible values are Application, Link, FSDevice, MimeType
and Directory, from what you say above

> (2) possible numeric values are 0 or 1.  This should have been a
>     boolean entry, but for historic reasons, it isn't.  Change?
Yes !

> 3. Extending the format
> 
> If the standard is to be amended with a new {key,value} pair which
> should be applicable to all supporting parties, a group discussion
> will take place.  This is the preferred method for introducing
> changes.  If one particular party wishes to add a field for personal
> use, they should prefix the key with the string "X-",
> i.e. "X-Foo", following the precedent set by other IETF and RFC
> standards.
like the following ?
(konqueror_part.kdelnk)

X-RepoID=IDL:Konqueror/Application:1.0,
X-ActivationMode=shared  
X-ServiceType=FileManager 

ok, looks nice ;)

There has also been a demand for the option "don't show in panel" (for 
application desktop files). This way it's bound to files but it doesn't appear
in kpanel. Very handy for some application that need a file as input (e.g. less)
and also for ktalkd, which needs a kdelnk^H^H^H^H^Hdesktop file to appear in the
help system.
Should we make this option common with gnome or kde specific (and X-... based) ?
Oh, just noticed the TryExec field above... Do we support this already ?


-- 
David FAURE
david.faure@insa-lyon.fr, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]