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

debian menus


As you may have heard, I'm working on the debian menu-package.

This mail contains first a brief description of the 
  - menu-interface (please read this if you mainain "menuentryable" packages)
  - current status
  - one problem still unsolved.

*** menu-interface

This package is basically the same as the "install-fvwm2menu"
from the fvwm2 package (this allows other packges to register
a menuentry with the fvwm2 windowmanager), but allows the
menuentries to be re-used by other window mangers too (and even
pdmenu, a textbased menu from Joey Hess).

install-fvwm2menu used one single file to record all the menu-data,
but Ian (and the fvwm2 maintainer) remarked that this would be
"a  recipe for desaster", so the menu-package doesn't use this
(any more). Instead, each package that likes to register a
menuentry, puts a file in /usr/lib/menu/$package with this menu entry in it.
Then, the system admin can configure the local menus by putting
a file in /etc/menu (and users put their override files in ~/.menu).

The menu-files look like this: 
  type menu-section   entryid  icon  text  command
(axe, an X-only editor:)
  X11 Apps/Editors axe none Axe /usr/bin/X11/axe
(vi, a text-only editor:)
  text Apps/Editors vi none Vi /usr/bin/vi
(emacs, supports both text and "real" X:)
  X11  Apps/Editors emacs none Emacs /usr/bin/emacs
  text Apps/Editors emacs none Emacs /usr/bin/emacs

All of these menu-files are read by "update-menus" (from the
menu package). update-menus checks if the packages really are
installed (the /usr/lib/menu ones always are, but the /etc/menu
ones may not be), and then calls the install-function for each
window manager, in /etc/menu-methods like this (for pdmenu):
  /etc/menu-methods/pdmenu --install-files /usr/lib/menu/octave /usr/....
(and also for removal, with --remove).

So, each window manager (or text menu programme) should provide a
"install-method" in /etc/menu-methods.

Appart from providing the menu-file in /usr/lib/menu, each package
that wants to register itself with the menu system also should
call "update-menus" in both the postinst and postrm, like this:
  if test -x /usr/bin/update-menus; then update-menus; fi

*** Current status

All the above is implemeted in update-menus.

To speed up the generation of the menu entries, I also supplied
a directory /usr/lib/menu/defaults with the package, that has
some 50 menuentries. (of cource, the /usr/lib/menu directory overrides
any defaults that I put in my package).

Menu/Window managers that currently support the menu-package:


Also, the menu-package /usr/doc/menu/examples directory contains
a few files that, if installed, make the following window managers 
support it:
  fvwm, fvwm2, twm, ctwm(*), afterstep

The only window managers that I know of that currently don't work
at all are 9wm (probably never), and gwm (my lisp is very bad).

(*) Well these files are the same as for twm, and will be in the next
version of the menu package

*** One problem still unsolved (icons).

I need your help::

Although in the menu-entries listed above I say that the icon
is simply the 4th entry on the line, surely this cannot be
true: For example xterm will never be sure of the presence of 
_any_ bitmap on the system, and thus should always specify "none",
to be safe.

This could be solved by adding the following types:
and so on, so that xterm could have several menuentries, each
with different bitmap entries. Then, the fvwm window manager
would choose the x11.fvwmpix entry if available, and the plain
x11 one if that is the only entry available.

So far so good. But, just like install-fvwm2menu, the menu-files
can only register commands. This means that I don't have any way
of giving a "submenuentry" an icon (for example, all the 
menuentries in the mainmenu).

Especially for fvwm95, this is rather bad, as I'm sure the fvwm95
(upstream)maintainers main goal was these icons in the menus.

I would like to suggest adding a type like
  menu     (Well, probably menu.fvwmpix, menu.gwmpix, ...)
for menuentries that only start another menu. This would then have
an empty command.

To summerise, this is what I'm thinking of:

For the Apps/Editors entry icon 
  menu.gwmpix  Apps/Editors gwm/editors /usr/X11R6/lib/gwm/App_write.xpm
  menu.ctwmpix Apps/Editors ctwm/editors /usr/X11R6/lib/ctwm/images/xedit.xpm
and so on.

For the Emacs menuentry:
  X11.ctwmpix  Apps/Editors emacs&ctwm /usr/X11R6/lib/ctwm/images/gnu-emacs1.xpm Emacs /usr/bin/emacs
  X11          Apps/Editors emacs none Emacs /usr/bin/emacs
  text         Apps/Editors emacs none Emacs /usr/bin/emacs
and so on.

Well, I'm rather convinced this is the only way out, but I'd be interested
to hear suggestions from other people.

joost witteveen
Use Debian/GNU Linux!

This message was delayed because the list mail delivery agent was down.

Reply to: