I see Keith has committed a draft to git. As discussed, I disagree
with this approach. This amounts to nonconsensually abolishing
someone's work when it is still being maintained, and the global cost
is minimal.
But I'd like to make some specific comments too. (I'm reading
24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a
copy.)
Firstly, there is no talk of a transition plan. There is AIUI
currently a mixture of programs which provide both kinds of entry and
programs which provide only one or only the other. A resolution
saying that these things should be unified needs to either contain the
transition plan, or say that someone (who?) should write it. If the
transition plan is to be written later, the resolution should also say
what should happen in the meantime.
Secondly, it doesn't discuss how these menus will be organised or
displayed. In particular, it doesn't discuss how to manage the
distinction between:
- Menu consumers who want to display a comprehensive menu along
the lines of the traditional Debian menu;
- Menu consumers who want to display a curated or filtered menu
along the lines of the desktop system menus.
And, of course, the corresponding distinction between the different
kinds of program.
At the very least the resolution needs to acknowledge that these
distinctions exist and say that they are not being abolished. Or, if
they are, say which of the two uses is being abolished.
Thirdly, IMO the resolution needs to acknowledge (in the "whereas"
section) that consuming a trad Debian menu entry is simpler and easier
than consuming a .desktop file.
Thanks,
Ian.
--- Keith's proposal:
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
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21420.20318.360154.559...@chiark.greenend.org.uk
