Whereas: 1. The Debian Policy Manual states (ยง9.6) that 'The Debian menu package provides a standard interface between packages providing applications and "menu programs"'. It further states that 'All packages that provide applications that need not be passed any special command line arguments for normal operations should register a menu entry for those applications'. 2. All details about menu system requirement are delegated to the Debian Menu sub-policy and Debian Menu System manuals (the "Debian menu system"). 3. An external specification, the Freedesktop Desktop Entry Specification (the ".desktop spec"), with native support in many X desktop environments, has appeared since the Debian Menu system was developed. The .desktop spec offers a fairly strict super-set of Debian Menu system functionality. 4. The .desktop specification has significant technical benefits for users over the Debian menu system. The .desktop specification works together with the freedesktop.org mime type and icon specifications to provide operations expected by desktop users from other environments, such as Mac OS X or Windows. As such, applications must provide a .desktop file to operate well in most desktop environments. 5. The Debian Technical Committee has been asked to resolve a dispute between maintainers of Debian Policy over a change that i. incorporates the description of the FreeDesktop menu system and its use in Debian for listing program in desktop menus and associating them with media types ii. softens the wording on the Debian Menu system to reflect that in Jessie it will be neither displayed nor installed by default on standard Debian installations. Therefore: 1. The Technical Committee resolves that packages which provide applications customarily designed for use within a desktop environment should provide a .desktop file conforming to the Freedesktop Desktop Entry Specification. 2. Packages may provide menu files at the pleasure of the maintainer, but packages providing a .desktop file shall not also provide a menu file. 2. We further resolve that "menu programs" should not depend on the Debian Menu System and should instead rely on .desktop file contents for constructing a list of applications to present to the user. 3. We recommend that the maintainers of the 'menu' package update that package to reflect this increased focus on .desktop files by modifying the 'menu' package to use .desktop files for the source of menu information in addition to menu files. 4. Discussion of the precise relationship between menu file section/hints values and .desktop file Categories values may be defined within the Debian Menu sub-policy and Debian Menu System. The following information is an informative addition to help describe the motivation for this policy change. A. The .desktop spec provides more functionality: a) Associating mime types with applications b) Support for more icon image formats c) Translation of menu items d) D-Bus application activation e) StartupNotify support B. Support for the .desktop spec is widely provided as part of upstream packaging for desktop applications. C. A .desktop file describe in the .desktop spec captures essentially the same information as that present in the Debian menu system: menu .desktop Notes ?package TryExec [0] title Name / GenericName [1] needs Terminal [2] section Catagories [3] command Exec icon Icon [4] hints Catagories [5] Notes [0] ?package uses Debian package names, TryExec offers a system-independent mechanism using a special program or mode of the existing program to query whether the dependencies to run the application are satisfied [1] GenericName can offer a brief functional description of a program, much like the Debian alternatives for things like www-browser [2] needs adds 'vc' and 'wm' classifications, a .desktop file does not anticipate running applications on virtual consoles as a separate notion from within an X. I'll note that the only package on my system with needs="vc" is psmisc for the pstree application, which runs just fine in any X terminal emulator. Also .desktop files do not expect people to switch window managers during a session. [3] The menu file requires that the package define the entire menu path to the entry, while the .desktop file defines only the Catagories within the menu, which allows the user environment to construct its own presentation method [4] Menu files allow only for xpm format icons while .desktop files support a wide variety of image formats, including png jpg and svg. Menu files also limit the size of icons to 32x32, which can be painfully small on higher resolution monitors, or less detailed when scaled to large sizes. [5] Because the .desktop specification does not enforce a particular layout of menu entries, applications are encouraged to specify as many 'categories' as they like and have the menu system pick where to include them. This can easily include policies like that described for the hints field in the Debian menu. D. .desktop files also provide additional fields not present in the Debian menu system: Type Application, Link or Directory. The latter two provide a common format for storing references to non-application objects within the desktop environment. NoDisplay An artifact of the ability to handle content-based application launching; a NoDisplay entry isn't shown in the menu system, but is available for handling Mime types. Comment Offered as a tooltip to the user, providing additional details about the application. Hidden An artifact of the implementation allowing users to selectively disable system menu entries OnlyShowIn/ Allows desktop-system specific applications to not NotShowIn appear in other desktop environments, such as desktop system preferences systems. DBusActivatable Whether the application supports standard D-Bus messages to control the application, including the ability to direct applications to open additional files or perform other operations Path The starting directory for the application. I haven't found any .desktop file using this feature, but it is replicates functionality present in Mac OSX and Windows. Actions Similar to a mechanism provided on Windows where you can list many different operations available from a single application, such as "open", "print", "play", "frobnicate" and Windows automatically adds these to the right-click menu from within explorer. MimeType The mime types supported by the application. This allows the wider system to find a application suitable for viewing/modifying specific content, such as a file browser. KeyWords Provides tags to allow for some degree of search-ability/categorization of menu entries. I'd be able to explain this in more detail if I could find any examples of it in use. StartupNotify/ Announces that the application supports the Startup StartupWMClass Notification Protocol Specification, which allows the desktop environment to detect when the application has successfully launched so that it can disable the waiting cursor. URL Used in 'Link' .desktop files to reference an object. E. .desktop files cede significant authority over menu organization to the user agent presenting the overall application menu. This is already a reality as many desktop environments show *none* of the menu file data at all; having applications which currently ship a menu file change to shipping a .desktop file will bring them into uniformity with other pieces of the desktop environment by incorporating them into the existing desktop menu system F. The .desktop specification and other Freedesktop.org specifications relating to mime types and icons are all interrelated and work together to provide a system capable of implementing common desktop operations. Not providing a .desktop file significantly reduces the functionality of the overall environment, and so any desktop application must provide the full suite. Also delivering a Debian menu file would end up duplicating information in potentially conflicting ways.