New menu standard

[George <jirka 5z com>]

As many of you have already seen there was some talk about extending the the
.desktop stardard to fix a couple of major issues we are being faced with in
terms of menus.  Both for KDE and GNOME.  So here is the proposal to fix
these issues, if you've already seen it, nothing changed about it, I was just
too lazy to post it here for discussion yet.

What needs to be done

1) Polish up this thing, figure out possible weaknesses, or perhaps figure
   out a better way to do things altogether
2) Pick an exhaustive set of keywords, the ones I put in the proposal are
   just a start, if the vfolders are to be useful we need more

Havoc and others had some further ideas on this as well, so it'd be good to
post those here.

My feeling is that we can leave quite a bit up to the implementation, and
that way we don't loose flexibility in the future.  The three biggest things
are 1) giving concrete place for 3rd party developers to put .desktops in 2)
not depending on any set menu structure 3) properly merge KDE, GNOME and any
other menus.

I'd rather see a quick agreement happen rather then a large set of "it'd be
nice" ideas, so that we can all get to implementing the thing.

George

-- 
George <jirka 5z com>
   History teaches us that men and nations behave wisely
   once they have exhausted all other alternatives.
                       -- Abba Eban, 1970

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 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.  If a user installs his own personal software in another
prefix, they can set the DESKTOP_FILE_PATH variable to include this
directory.

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 "Keywords" 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 list of standard keywords
is attached on the end of this proposal.  The application should include
all the relevant keywords.

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.

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;Editor
Games			Application;Game
Graphics		Application;Graphics
Internet		Application;Network
Multimedia		Application;Multimedia
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;Multimedia
applets/Network		Applet;Network
applets/Utility		Applet;Utility

[ FIXME! Add KDE specific files ]

List of Standard Keywords:
--------------------------

[ FIXME!  This needs more work! ]

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

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

System			- System application
Utility			- Small utility application
Settings		- Desktop settings applications

Network			- Netowork application such as a webbrowser
Clock			- A clock application/applet
Monitor			- Monitor application/applet for some reasource
Multimedia		- A multimedia application

Amusement		- A simple amusement
Game			- A game
CardGame		- A card game
BoardGame		- A board game

[ I can't think of any more game types right now (well I can't remember what
  to name them:) ]