[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#741573: Two menu systems

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

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.


--- Keith's proposal:


   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.


   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

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

      menu	.desktop		Notes
      ?package	TryExec			[0]
      title	Name / GenericName	[1]
      needs	Terminal		[2]
      section   Catagories		[3]
      command	Exec
      icon	Icon			[4]
      hints	Catagories		[5]


      [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

      [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

      [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

       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 

Reply to: