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

Definite menu code rewrite

Ok.  Now that my aims have changed from creating an implementation of
"menu" that doesn't suck to a menu system implementation that has some
extra wins, here's the plan (as I see it):

1. Implement a new menu handler package.  Call it "debmenu" for now.
   debmenu will have support for existing
   /usr/lib/menu:/etc/menu:~/.menu entries and new-style menu entries under

2. New-style menu entries will comply with the .desktop file standard,
   v0.9.2 or later, with the VFolders extension, and Debian-specific
   extensions (to be documented as they arise).  Unlike GNOME and KDE
   menus, we will not overload the filesystem for the menu hierarchy;
   instead, we will adopt the Categories= convention from VFolders and
   retain a flat directory.  Also, debmenu will only support
   non-legacy encodings (in practice, this means Debian .desktop files
   must be UTF-8 and declare a Version of 1.0 or later.)

3. Old-style menu entries will be supported by converting them as
   needed when update-menus is called.  The converted entries will
   live in /var/lib/debmenu/legacy.

4. A transition to .desktop menu entries should be encouraged for
   woody+2.  The debmenu package will include a utility to
   automagically convert menu files to .desktop format.  Packages that
   provide legacy menus in /usr/lib/menu and .desktop files in
   /usr/share/debmenu are encouraged for woody+1, and debmenu will use
   .desktop files in preference to legacy entries if both are installed
   by a package.

5. Debian will need to establish a policy for our .desktop files; in
   particular, some optional items in the .desktop specification may be
   required in Debian.  We may also wish to retain our
   lowest-common-denominator icon policy (24 colors, fixed palette,
   32x32 max size), although IMO this is worth rethinking,
   particularly since many Debian packages are not following it anyway.

6. Helper tools will need to be modified to recognize Debian-specific
   .desktop files and install them in /usr/share/debmenu.

7. New code to replace /etc/menu-methods will have to be written.
   This may be the most challenging part of the project.  The upside
   is that not many of these need to be written, and I hope to come up
   with something much easier to use than the bizarre language
   install-menus uses.

8. It'd be nice if debmenu was Priority: standard for woody+1.  Our
   menu system has always been one of our strengths and IMO it's one
   that should be preinstalled by default.  But that's just me.

New features we gain:

- i18n.  .desktop files are UTF-8, and any localized part
  (description, comment, a few other things) can be translated into
  any locale (language or language_country).

- Interoperability.  Making a Debian menu for a KDE or GNOME
  application will be trivial - just add whatever Debian-specific bits
  we require, if needed.

- More extensibility.  The format is designed to be extensible and
  more easily parseable.

Future directions (i.e. don't expect this right away, though hopefully
in time for woody+1):

- Role-specific entries.

- Some sort of expertise-level indications.  (aka does Mom need
  rpncalc next to GNOME Calculator/kcalc)

- Special flags for "needs root" or other needed capabilities.

What we won't probably see right away (maybe never):

- Hints, at least in their present form.  I think the Categories thing
  in VFolder is probably flexible enough.  But I can be persuaded
  otherwise if I'm wrong.

Chris Lawrence <lawrencc@debian.org> - http://www.lordsutch.com/chris/

Attachment: pgpL5AbN2RhRC.pgp
Description: PGP signature

Reply to: