[PATCH] Menu Spec - Desktop specific menus

[Waldo Bastian]

On Tuesday 12 September 2006 23:19, James Richard Tyrer wrote:
> Bastian, Waldo wrote:
> > This change codifies how to use different .menu files for different
> > desktop environments. Some distributions currently already do this. This
> > change will require them to set $XDG_MENU_PREFIX accordingly. They
> > should also check that their distribution picks up the
> > applications-merged directory correctly.
> >
> > Current:
> >
> > $XDG_CONFIG_DIRS/menus/applications.menu
> > 	This file contains the XML definition of the main application
> > menu layout. The first file found in the search path should be used;
> > other files are ignored. This implies that if the user has their own
> > applications.menu, it replaces the system wide one. (Though the user's
> > menu may explicitly merge the system wide one.)
> > Other menu files may exist, but are not specified in this document.
> >
> > $XDG_CONFIG_DIRS/menus/menu-file-basename-merged/
> > 	The default merge directories included in the <DefaultMergeDirs>
> > element. By convention, third parties may add new <Menu> files in this
> > location. menu-file-basename means the "applications" from
> > "applications.menu" for example. So the merge directory would be
> > "applications-merged".
> >
> > Proposed:
> >
> > $XDG_CONFIG_DIRS/menus/${XDG_MENU_PREFIX}applications.menu
> > 	This file contains the XML definition of the main application
> > menu layout. The first file found in the search path should be used;
> > other files are ignored. This implies that if the user has their own
> > ${XDG_MENU_PREFIX}applications.menu, it replaces the system wide one.
> > (Though the user's menu may explicitly merge the system wide one.)
> >
> > Systems that offer multiple desktop environments and that want to use
> > distinct menu layouts in the different environments can use differently
> > prefixed .menu files. In this case the $XDG_MENU_PREFIX environment
> > variable must be set by the system to reflect the .menu file that is
> > being used.
> >
> > For example if a system contains both the GNOME and the KDE desktop
> > environments it can decide to use gnome-applications.menu as the menu
> > layout in GNOME sessions and kde-applications.menu as the menu layout in
> > KDE sessions. To correctly reflect this, it should set the
> > $XDG_MENU_PREFIX environment variable to "gnome-" respectively "kde-".
> >
> > Implementations may chose to use .menu files with other names for tasks
> > or menus other than the main application menu. Such usage is not covered
> > by this specification.
> >
> > $XDG_CONFIG_DIRS/menus/applications-merged/
> > 	The default merge directories included in the <DefaultMergeDirs>
> > element of application.menu files. By convention, third parties may add
> > new <Menu> files in this location to create their own sub-menus.
> >
> > Note that a system that uses either gnome-applications.menu or
> > kde-applications.menu depending on the desktop environment in use must
> > still use applications-merged as the default merge directory in both
> > cases.
> >
> > Implementations may chose to use .menu files with names other than
> > application.menu for tasks or menus other than the main application
> > menu. In that case the first part of the name of the default merge
> > directory is derived from the name of the .menu file.
> >
> > For example in a system that uses a preferences.menu file to describe an
> > additional menu, the default merge directories included in the
> > <DefaultMergeDirs> element in the preferences.menu file would become
> > $XDG_CONFIG_DIRS/menus/preferences-merged/
>
> I don't see the need for the environment variable since KDE knows that
> it is KDE and GNOME knows it is GNOME.

The need is there when a third party application wants to understand which 
file to look at for a description of the menu. Or even when a GNOME 
application wants to do something with the menu while running under KDE, or 
vice versa.

> I still prefer my proposed solution which is to have multiple
> ".../xdg/menus/" directories with a suffix:
>
> 	.../xdg/menus.kde/
>
> 	.../xdg/menus.gnome/
>
> and a global:
>
> 	.../xdg/menus/
>
> directory which would be used as a backup and/or for all desktops.  That
> is:
>
> 	.../xdg/menus/applications.menu
>
> would be used if there wasn't one:
>
> 	.../xdg/menus.<desktop>/applications.menu
>
> and the contents of the directory:
>
> 	../xdg/menus/applications-merged/
>
> would be used for all desktops.

Yes, that's of course a valid alternative solution but so far distributions 
have chosen to use a scheme that only changes the name of the 
applications.menu file.

> I suggest this since it is possible that there would still be conflicts
> in the files in:
>
> 	.../xdg/menus/
>
> Currently, GNOME has:
>
> 	.../xdg/menus/applications.menu
> 	.../xdg/menus/preferences.menu
> 	.../xdg/menus/settings.menu
>
> and the second and third are not GNOME specific names.
>
> However, KDE does have KDE specific names:
>
> 	.../xdg/menus/applications.menu
> 	.../xdg/menus/kde-information.menu
> 	.../xdg/menus/kde-screensavers.menu
> 	.../xdg/menus/kde-settings.menu
>
> If we aren't going to have separate directories, perhaps the prefix
> requirement should apply to all files in the directory.

All other files in this directory are desktop specific so far I don't think 
there is a strict need for such requirement but it would be good practice to 
prefix any desktop specific .menu files, yes. 

> It is also possible that it might be necessary to merge different sets
> of applications-merged files for different desktops.  How do you propose
> to address that?

If you have a desktop specific applications.menu file you can specify 
addtional merge dirs in the .menu file for that specific desktop.

Cheers,
Waldo
-- 
Linux Client Architect - Channel Platform Solutions Group - Intel Corporation