Updated menu proposal (v1.1)

[George <jirka 5z com>]

Here's a slightly updated version of the proposal answering some of the
concerns posted on the two lists.  However note that we are not discussing a
change and will not change the format of the .desktop files, nor do any
drastic changes, so such discussions are really blue sky only.  We are
discussing ammending the current standard slightly by adding two fields
and a standard location.  Anything more is really for another proposal.  We
need conclusion on the two issues at hand quickly.

George

-- 
George <jirka 5z com>
   You have the right not to be killed,
   Murder is a crime!  Unless it was done by a policeman or an aristocrat.
                       -- The Clash

VFolder .desktop Files Proposal
-------------------------------

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

Problem:
--------

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

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:

/usr/share/applications/

Optionally if this is not possible, an application can install in a
<prefix>/share/applications/

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.

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 "FolderKeywords" which would be a required key in the
the .desktop standard and would be a list of strings.  The 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).

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.

Compatibility:
--------------

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		Keyword(s)
/			Application;Core
Applications		Application
Development		Application;Development
Editors			Application;TextEditor
Games			Application;Game
Graphics		Application;Graphics
Internet		Application;Network
Multimedia		Application;AudioVideo
Settings		Application;Settings
System			Application;System
Utilities		Application;Utility

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

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

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

List of Standard FolderKeywords:
--------------------------------

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

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' keyword)
RasterGraphics		- Raster based graphical application (should also
			  include 'Graphics' keyword)

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
Settings		- Desktop settings applications (not system setting
			  application, those should be System;SystemSetup)

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

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