A package should provide a menu file
/usr/lib/menu/<package-name> that contains information about
each program it likes to make available in the menus.
Here is an example to describe the syntax of such a file:
?package(gnuplot):\ specifies what packages need to be installed
needs=text\ what kind of terminal this command expects
needs=X11: if this program runs only on X11
needs=text: if it only runs on text terminals
(the window manager should spawn
an xterm or rxvt in this case)
needs=vc: runs only at linux console
needs=wm: this starts another window manager
section=Apps/Math\ in what section this menu entry should be
title="Gnuplot"\ the title of the menu entry
(please make it short!)
command="/usr/bin/gnuplot" the command to run.
A program like gnuplot which can be run on X11 as well as on a text terminal
should not have an extra entry with needs=X11 because it
will then be next to impossible to configure the window managers to spawn
rxvt instead of the default xterm.
On the other hand, if a program (like emacs) can be run as real X
application as well as in a terminal, two entries should be listed, otherwise
the program will always be run in an xterm (or rxvt).
In the menu entry files, you can use "#" as comment (like in shell
scripts).
You should add a line like this to your postinst script
if test -x /usr/bin/update-menus; then update-menus; fi
and the postrm script should get the line
if test -x /usr/bin/update-menus; then update-menus; fi
(that is, the same line in postinst and in postrm).
Here is the authoritative list of Debian's menu structure. If you
have a package which does not fit in here or if you have any suggestions how to
improve this structure, please send an email to the maintainer of the
menu package, Joost Witteveen joostje@debian.org. If you have
more general remarks about restructuring the menu tree (or adding an entry that
may require discussion), the best thing to do is to go to
debian-policy, and start a discussion there. I (Joost) will
without hesitation change the structure of the menu-tree if a decision was
reached on debian-policy, but I'm very reluctant to changes without prior
discussion.
Please do not put your packages into any other sections without asking
for permission first!
Apps - normal apps
Editors - editors (run it in xterm, if nothing else)
Emulators - dosemu, etc.
Graphics - xpaint, xfig, xtiff, etc.
Hamradio - Anything relating to ham radio.
Math - gnuplot, octave, oleo, etc.
Net - mail, news, web, irc, etc.
Programming - debuggers, etc.
Tools - other tools: xclock, xmag, xman, etc.
Technical - technical stuff.
Text - text oriented tools other than editors.
Shells - bash, ksh, zsh, etc.
Sound - TkMidity, etc.
Viewers - Picture viewers, gs, etc.
System - system administration and monitoring tools
Games - games and recreations
Adventure - walk around virtual space, zork, MOO's, etc
Arcade - (any game where reflexes count)
Board - Like: Gnuchess, pente, gnugo
Card - solitaire, etc
Puzzles - Stuff from xpuzzles, ...
Sports - Games derived from "real world" sports
Strategy - Build your world (Games like lincity, freeciv)
Tetris-like - games involving falling blocks
Toys - (oneko, xeyes, etc.)
Screen -
Lock - xlock, etc.
Save -
Root-window - things that fill the root window
WindowManagers - (change between fvwm, afterstep, etc)
Modules - fvwm modules, etc.
XShells - shells (like xterm, rxvt, ...)
Hints have been added starting from this version of menu. There needs to be
some discussion about them first, but if you want to try them out, simply add a
hints="Myhint,Herhint,Hishint" definition to the menu entry file.
For example:
The above hints will case menu to consider grouping
emacs together with other editors that are marked similar. For
example, if vi on your system has a hints="Small,Expert"
definition, and there are too many entries in the /Apps/Editors menuentry, then
menu will consider creating a /Apps/Editors/Expert submenu, and put both
vi and emacs in it. (of course, only if you have
hint_optimize=true in your /etc/menu-methods/menu.h file).
Please, make sure the icons you specify are always available on the system.
So, if you want to have an icon with your menu entry, the preferred method is
to supply the icon with that package. Also, to prevent the distribution of
icons files to turn too much into a mess, please put all icon files in the
directory /usr/X11R6/include/X11/{bitmaps,pixmaps}.
Debian package maintainers should ensure that any icons they include for use in
the debian menus conform to the following points:
The icons should be in xpm format.
The icons may not be larger than 32x32 pixels, although smaller sizes are ok.
The icons should use only the 24 colors present in cmap.xpm, which comes with
the menu package.
The background area of the icon should be transparent, if possible.
If you have Imagemagick installed, you can make your icons meet requirements 1,
2, and 3 with the following command, but you will need to edit the icon
afterwards to clean it up and make the background transparent:
If you, as a system administrator, don't like the icons in the menus, simply
remove the $%{icon} from the files in
/etc/menu-methods/$wm, and run update-menus.
It's also possible to specify an icon for a sub-menu. However, if each package
would supply its own icons for the sub menus we can never be sure that the icon
files are available. Thus, only the menu package is allowed to
specify icons for sub menus. The syntax for this is:
The problem with the stuff in the task bar is that all items are displayed all
of the time. So, if 1500 debian packages all were to register a button, the
buttons would quickly fill the screen, making the exercise useless. The few
applications that are considered important enough to be listed in the task bar
usually vary widely on each system, making it impossible to select a ``happy
few'' apps that are allowed there on every debian system. If you (as a local
system administrator) want your fvwm2 to have a few buttons, you
can install files for those packages in /menu/$package, containing
a menu entry like this: