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 /var/lib/debmenu/legacy:/usr/share/debmenu:/etc/debmenu:~/.debmenu. 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 -- Chris Lawrence <lawrencc@debian.org> - http://www.lordsutch.com/chris/
Attachment:
pgpL5AbN2RhRC.pgp
Description: PGP signature