--- /dev/null
+ 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 for which the
+ Debian menu system currently applies should provide a .desktop
+ file. Applications providing a .desktop file should not
+ provide a Debian 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 all of the information 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
+
projects / debian-ctte.git / commitdiff