[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

VFolder .desktop Files Proposal Version 1.5

Here is an updated version of the proposal.  Note that I've added a bunch of
categories (keywords) and also added a few examples at the bottom which
should make some things clearer I think.

Havoc: Can you place this onto the freedesktop.org site?


George <jirka 5z com>
   Patriotism is your conviction that this country is superior
   to all others because you were born in it.
                       -- George Bernard Shaw
VFolder .desktop Files Proposal

Version 1.5

- Update the keyword (categories) list, added Screensaver, Education,
  KDE, QT, GNOME, GTK, Motif, ConsoleOnly, Emulator, Shell, PuzzleGame,
  SportsGame, StrategyGame, BlocksGame, TerminalEmulator, Math,
  HamRadio, Viewer, Astronomy, Physics, Chemistry
- Added some examples at the bottom.

Version 1.4

- Updated the keyword (categories) list, added Merged, AdvancedSettings,
- Where a list is written with semicolons, it is written in the format
  required by the .desktop spec (ends in semicolon)
- A note about extending keywords and the X-GNOME-Sawfish keyword

Version 1.3

- Actually use 'Categories' in the whole document
- Other minor fixes

Version 1.2

Changes: (updated from feedback on mailing lists)
- Use 'Categories' instead of 'FolderKeywords' as that sounds better
- Added further rationale for env var (PAM)

Version 1.1

Changes: (updated from feedback on mailing lists)
- Use 'FolderKeywords' instead of 'Keywords', 'Keywords' is apparently used
  in KDE already (though not in the standard) and so would be confusing.
- Changed Multimedia to AudioVideo, Editor to TextEditor, added more Game
  types, added RasterGraphics, addedSystemSetup and PackageManager
- More rationalle for env var for the path.
- Removed FIXMEs
- Add a note about why standardizing the VFolder setup itself is not


There are two main problems with the way current .desktop files are handled.

  1) No standardized location
  2) Structure of a menu/display is set by the location on disk

This proposal is to extend the standard to allow a VFolder like capability
to .desktop files and add a standard location to read desktop files from.

Why are these a problem?

1) is a problem because 3rd party developers don't know where to install
their desktop files for them to be picked up by the menus and filemanagers of
the respective desktops.  Right now there are some somewhat standard
locations (such as Redhat's /etc/X11/applnk) but those are distribution

2) is a problem because it is not possible to change the layout of the menus
without adversly affecting 3rd party developers.  It is also not possible
for users and system administrators to edit the menu layout and still allow
new applications to add themselves at the proper location.  Imagine for a
moment that we would suddenly aquire 50 new xeyes type applications which
previously lived in Applications/.  It would be nice to have new versions
of each desktop come with an Eyes/ menu subdirectory, but 3rd party xeyes
will still install in Applications/ leaving the user rather confused.

1) Standard location

All .desktops are to be installed in a single directory:


Optionally if this is not possible, an application can install in a

The paths to the directories should be given by the DESKTOP_FILE_PATH
enviromental variable if other directories then /usr/share/applications/ are
needed.  This environment variable has the same format as the PATH
evironment variable, ':'separating entries.  If DESKTOP_FILE_PATH is present,
/usr/share/applications is not checked by default, and thus shoul dbe included
in the path.

The reason for an envarimental variable:  Some people have expressed concerns
that env vars are hard to change in a consistent manner, however this env var
is not intended to be changed by the users themselves (unless a user installs
applications in his/her own prefix, in which case he/she has to already modify
PATH, so it would make sense to modify DESKTOP_FILE_PATH at the same
instance).  The env var is to be set up by the system integrator, that is the
operating system vendor, according to their layout on disk.  There needs not
be any GUI or a standard way to modify this path and it can be setup in the
same way as other global env vars are set up on this system.

Further reason for an env var is that PAM allows this to be set and controlled
by the system administrator in various ways.  This means that a sysadmin could
manage who gets what .desktop's installed depending on their "credentials".

The reasons for not using a standard file such as say /etc/desktop-files is
two fold.  1) The system integrator cannot 'clean up' their etc directory,
and if they do they would create the problem we are trying to solve in the
first place 2) A user cannot add directories or override standard directories
easily if he/she installs applications in their own prefix (because the user
doesn't have root access for example).

A third party application wishing to work on any system would check the env
var on installation and install in the first writable directory, or in
/usr/share/applications/ or <prefix>/share/applications if that fails.
However since this path is set by the system integrator such as Red Hat,
Red Hat packages could always install in /usr/share/applications/.  This
would make things easier on the packaging system although it would make the
package only work correctly on systems which have the same disk layout (which
is already the case anyway).

This way third party developers can easily install their .desktops in a
standard location and not have to worry about this or that desktop finding
their application. 

2) VFolder setup

Instead of hardcoding the layout on the disk in the place of installation
of the desktops.  The layout of the menu is left up to the application
displaying them.  To aid in creation of of this layout 2 fields would be
added to the .desktop standard.

The first field would be "Categories" which would be a required key for
applications in the the .desktop standard and would be a list of strings.
These would be keywords which describe the application.  These keywords would
not be free form.  They would be one of keywords in this standard, or
optionally a keyword prefixed with X-PRODUCT-.  The PRODUCT can be either a
name of the application or project this application is part of, or the name of
the company that makes this application.  The list of standard keywords is
attached on the end of this proposal.  The .desktop file should include all
the relevant keywords.  If there is a general keyword and a specific one, the
.desktop file should include both (e.g. Game and CardGame).

An example of a project specific keyword is the X-GNOME-Sawfish keyword
currently being used in the GNOME implementation of vfolders so that the
Sawfish settings can be separated to a different folder.  It would not be
appropriate to add this keyword to the standard list as it is specific to
an application.

The application displaying the menu would be free to do layout in any way
it wishes to do so, and it can use these keywords for this purpose.  A
proposed implementation follows:

  A set of directories is defined in the application, each with a query
  on the keywords which would select the .desktops that belong to this menu
  directory.  The user/system administrator can change these queries by some
  appropriate GUI.  Then a new application installed would automatically
  be placed in the appropriate directory of the menus, no matter how
  customized the layout is.

  An alternate implementation would be to store the location of every
  .desktop file in the menu layout in the application and use the keywords
  for initial placement in the hierarchy.  This would allow a setup and UI
  more like the current one.

A second key would be an optional key "OnlyShowIn" which would be
again a list of strings of products, such as "GNOME" or "KDE".  The reason
behind this entry is that some entries are inherently desktop specific,
such as a desktop's control center, which has no need to be shown in any
other desktop.  If this key was not present in the file, this .desktop should
show up in all desktops.

Note that a standard file with the VFolder setup would be desirable, but
not necessary.  There is no problem in adding this in the future.  Currently
more important is standardizing where .desktop files are put.  3rd party
developers install .desktop files but do not change the VFolder setup.
Agreeing on this would take a lot more time and thus can be deffered to a
later juncture.  Not to mention that first trying several implementations in
the wild would more likely yeild results as to which setup is supperior,
rather then arbitrairly deciding now.


The implementations should provide compatibility code for reading the old
menu hierarchies as well.  When reading the these files they should select
a list of keywords appropriate based on their location, according to the
following list:

Location		Categories
/			Application;Core;Merged;
Applications		Application;Merged;
Development		Application;Development;Merged;
Editors			Application;TextEditor;Merged;
Games			Application;Game;Merged;
Graphics		Application;Graphics;Merged;
Internet		Application;Network;Merged;
Multimedia		Application;AudioVideo;Merged;
Settings		Application;Settings;Merged;
System			Application;System;Merged;
Utilities		Application;Utility;Merged;

Gnome specific files, these should include a "OnlyShowIn=GNOME;"

applets/Amusements	Applet;Amusement;Merged;
applets/Clocks		Applet;Clock;Merged;
applets/Monitors	Applet;Monitor;Merged;
applets/Multimedia	Applet;AudioVideo;Merged;
applets/Network		Applet;Network;Merged;
applets/Utility		Applet;Utility;Merged;

Optionally the application can have a list of known applications to which it
assigns keywords, such as assigning RasterGraphics to GIMP.

List of Standard Categories:

Merged			- Keyword that the vfolder implementation may
			  add to .desktops merged from old locations.

Core			- Important application, core to the desktop
			  such as a filemanager or a help browser
Application		- A standalone application
Applet			- An applet that will run inside a panel or another
			  such application, likely desktop specific
Screensaver		- A screensaver

TerminalEmulator	- A terminal emulator (such as xterm)

Development		- An application for development
GUIDesigner		- A GUI designer application
IDE			- IDE application

TextEditor		- A text editor

Office			- An office type application
Spreadsheet		- A spreadsheet
WordProcessor		- A word processor
Presentation		- Presentation software
Calendar		- Calendar app
Email			- Email application
TODO			- TODO maintanance
ProjectManagement	- Project management application
Graphics		- Graphical application
VectorGraphics		- Vector based graphical application (should also
			  include 'Graphics' category)
RasterGraphics		- Raster based graphical application (should also
			  include 'Graphics' category)
Viewer			- Something that is only a viewer of some file
			  types (gv, eog, etc...)

System			- System application
SystemSetup		- System setup application, hardware installation,
			  hardware clock setup, kernel setup, etc..
			  (e.g. X server setup)
PackageManager		- A package manager application, should include the
			  System keyword as well

Utility			- Small utility application such as a calculator

Settings		- Desktop settings applications (not system setting
			  application, those should be System;SystemSetup)
AdvancedSettings	- Advanced desktop settings
Accessibility		- Accessibility settings

Network			- Netowork application such as a webbrowser
Clock			- A clock application/applet
Monitor			- Monitor application/applet for some reasource
AudioVideo		- A multimedia (audio/video) application
Emulator		- Emulator of something, such as wine, dosemu, etc...

Amusement		- A simple amusement
Game			- A game
3DGame			- A game in 3D
ArcadeGame		- Arcade style game
BoardGame		- A board game
CardGame		- A card game
FirstPersonGame		- First person perspective game
PlatformGame		- Platform style game
PuzzleGame		- A puzzle game
SportsGame		- Real sports simulator game
StrategyGame		- Turn based strategy game
BlocksGame		- Anything that looks like tetris :)

Education		- Educational software
Math			- Mathematics software (gnuplot, octave, ...)
Astronomy		- Astronomy software
Physics			- Software for physics
Chemistry		- Software for chemistry (chemtool, etc...)
HamRadio		- Ham radio application

KDE			- KDE based application
QT			- Qt (but not KDE) based application
GNOME			- GNOME based application
GTK			- GTK (but not GNOME) based application
Motif			- Motif based application
ConsoleOnly		- Text/console based application.

Shell			- A console shell


For example the .desktop file for eog would include the following Categories


A .desktop file for running octave would have (with Terminal=true of course):


A .desktop file for a GNOME specific calculator (since KDE for example has
it's own calculator) would have:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]