3 1. The Debian Policy Manual states (ยง9.6) that 'The Debian menu
4 package provides a standard interface between packages providing
5 applications and "menu programs"'. It further states that 'All
6 packages that provide applications that need not be passed any
7 special command line arguments for normal operations should
8 register a menu entry for those applications'.
10 2. All details about menu system requirement are delegated to the
11 Debian Menu sub-policy and Debian Menu System manuals (the
12 "Debian menu system").
14 3. An external specification, the Freedesktop Desktop Entry
15 Specification (the ".desktop spec"), with native support in many
16 X desktop environments, has appeared since the Debian Menu
17 system was developed. The .desktop spec offers a fairly strict
18 super-set of Debian Menu system functionality.
20 4. The .desktop specification has significant technical benefits
21 for users over the Debian menu system. The .desktop
22 specification works together with the freedesktop.org mime type
23 and icon specifications to provide operations expected by
24 desktop users from other environments, such as Mac OS X or
25 Windows. As such, applications must provide a .desktop file to
26 operate well in most desktop environments.
28 5. The Debian Technical Committee has been asked to resolve a
29 dispute between maintainers of Debian Policy over a change that
31 i. incorporates the description of the FreeDesktop menu system
32 and its use in Debian for listing program in desktop menus
33 and associating them with media types
35 ii. softens the wording on the Debian Menu system to reflect that
36 in Jessie it will be neither displayed nor installed by
37 default on standard Debian installations.
41 1. The Technical Committee resolves that packages for which the
42 Debian menu system currently applies should provide a .desktop
43 file. Applications providing a .desktop file should not
44 provide a Debian menu file.
46 2. We further resolve that "menu programs" should not depend on the
47 Debian Menu System and should instead rely on .desktop file
48 contents for constructing a list of applications to present to
51 3. We recommend that the maintainers of the 'menu' package update
52 that package to reflect this increased focus on .desktop files
53 by modifying the 'menu' package to use .desktop files for the
54 source of menu information in addition to menu files.
56 4. Discussion of the precise relationship between menu file
57 section/hints values and .desktop file Categories values may be
58 defined within the Debian Menu sub-policy and Debian Menu
61 The following information is an informative addition to help describe
62 the motivation for this policy change.
64 A. The .desktop spec provides more functionality:
66 a) Associating mime types with applications
67 b) Support for more icon image formats
68 c) Translation of menu items
69 d) D-Bus application activation
70 e) StartupNotify support
73 B. Support for the .desktop spec is widely provided as part of
74 upstream packaging for desktop applications.
77 C. A .desktop file describe in the .desktop spec captures
78 essentially all of the information present in the Debian menu
83 title Name / GenericName [1]
85 section Catagories [3]
92 [0] ?package uses Debian package names, TryExec offers a
93 system-independent mechanism using a special program or
94 mode of the existing program to query whether the
95 dependencies to run the application are satisfied
97 [1] GenericName can offer a brief functional description of a
98 program, much like the Debian alternatives for things like
101 [2] needs adds 'vc' and 'wm' classifications, a .desktop file
102 does not anticipate running applications on virtual consoles
103 as a separate notion from within an X. I'll note that the
104 only package on my system with needs="vc" is psmisc for the
105 pstree application, which runs just fine in any X terminal
106 emulator. Also .desktop files do not expect people to switch
107 window managers during a session.
109 [3] The menu file requires that the package define the entire
110 menu path to the entry, while the .desktop file defines only
111 the Catagories within the menu, which allows the user
112 environment to construct its own presentation method
114 [4] Menu files allow only for xpm format icons while
115 .desktop files support a wide variety of image formats,
116 including png jpg and svg. Menu files also limit the size of
117 icons to 32x32, which can be painfully small on higher
118 resolution monitors, or less detailed when scaled to large
121 [5] Because the .desktop specification does not enforce a
122 particular layout of menu entries, applications are
123 encouraged to specify as many 'categories' as they like and
124 have the menu system pick where to include them. This can
125 easily include policies like that described for the hints
126 field in the Debian menu.
128 D. .desktop files also provide additional fields not present in
129 the Debian menu system:
131 Type Application, Link or Directory. The latter two
132 provide a common format for storing references
133 to non-application objects within the desktop
136 NoDisplay An artifact of the ability to handle
137 content-based application launching; a
138 NoDisplay entry isn't shown in the menu
139 system, but is available for handling Mime types.
141 Comment Offered as a tooltip to the user, providing
142 additional details about the application.
144 Hidden An artifact of the implementation allowing
145 users to selectively disable system menu entries
147 OnlyShowIn/ Allows desktop-system specific applications to not
148 NotShowIn appear in other desktop environments, such as
149 desktop system preferences systems.
151 DBusActivatable Whether the application supports standard
152 D-Bus messages to control the application, including
153 the ability to direct applications to open
154 additional files or perform other operations
156 Path The starting directory for the application. I
157 haven't found any .desktop file using this
158 feature, but it is replicates functionality
159 present in Mac OSX and Windows.
161 Actions Similar to a mechanism provided on Windows
162 where you can list many different operations
163 available from a single application, such as
164 "open", "print", "play", "frobnicate" and
165 Windows automatically adds these to the
166 right-click menu from within explorer.
168 MimeType The mime types supported by the
169 application. This allows the wider system to
170 find a application suitable for
171 viewing/modifying specific content, such as a
174 KeyWords Provides tags to allow for some degree of
175 search-ability/categorization of menu
176 entries. I'd be able to explain this in more
177 detail if I could find any examples of it in use.
179 StartupNotify/ Announces that the application supports the Startup
180 StartupWMClass Notification Protocol Specification, which
181 allows the desktop environment to detect when
182 the application has successfully launched so
183 that it can disable the waiting cursor.
185 URL Used in 'Link' .desktop files to reference an object.
187 E. .desktop files cede significant authority over menu
188 organization to the user agent presenting the overall
189 application menu. This is already a reality as many desktop
190 environments show *none* of the menu file data at all; having
191 applications which currently ship a menu file change to
192 shipping a .desktop file will bring them into uniformity with
193 other pieces of the desktop environment by incorporating them
194 into the existing desktop menu system
196 F. The .desktop specification and other Freedesktop.org
197 specifications relating to mime types and icons are all interrelated
198 and work together to provide a system capable of implementing
199 common desktop operations. Not providing a .desktop file
200 significantly reduces the functionality of the overall
201 environment, and so any desktop application must provide the
202 full suite. Also delivering a Debian menu file would end up
203 duplicating information in potentially conflicting ways.