Debian have a menu package that include automatiquely every single useful program in the menu of all the installed wm. From Debian: The menu package was inspired by the install-fvwm2-menu program from the old fvwm2 package. However, menu tries to provide a more general interface for menu building. With the update-menus command from this package, no package needs to be modified for every X window manager again, and it provides a unified interface for both text- and X-oriented programs. More information can be found here: http://www.handhelds.org/~nelson/menu/ The packages provide a menu description that is used to generate the menu entries, and the wm provide a menu method file in /etc/menu-methods I take a look in the debian fvwm-crystal package. I think at the etc/menu-methods/fvwm-crystal file (first in the list) can be used as it. http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=fvwm-crystal&version=unstable&arch=all and hoppefully, it will maybe be the same with the other wm. menu from the debian source package did compile and run, but it need both some extra files in /etc/menu from menu_2.1.31_i386.deb and the menu description provided by each packages. For those description file, dpkg install a database with all those files and call install-menu. In consequence, for this package to do something in gentoo, it will be needed to add a new functionnality (eclass?) in emerge. Cheers, Dominique
(In reply to comment #0) > menu from the debian source package did compile and run, but it need both some > extra files in /etc/menu from menu_2.1.31_i386.deb It is files in /etc/menu-methods Dominique
Something's wrong w/ FDO's specification and .desktop files? [1] Gnome, KDE, XFCE and now even E17 uses them; I'd say FVWM does something wrong? :P [1] http://standards.freedesktop.org/menu-spec/latest/
Also, there's x11-misc/genmenu for *box, WindowMaker, and Enlightenment (e16); doesn't say anything about FVWM, no idea how things are supposed to work there.
The Debian menu package is more flexible and work with any wm. It is no fault with the FDO specification and .desktop files. The problem is at not all the wm use it and not all the programs have a .desktop file so it just doesn't work in many cases. After years with kde, I give a try with fluxbox, xfce4, fvwm and fvwm-crystal. Both fluxbox and xfce4 have the capability to edit the menu or to generate it. But fvwm or fvwm-crystal is just better in term of flexibility so I use the lsat one for now, and it is very time consuming to add all the programs by hand. And even with kde, you will always get some programs that need to be added by hand. With this program, it will be just as in window$, you install the program and it will be in the menu of our favorite wm. The extra file in the debian package for a given program is very simple. As exemple, for qsynth, /usr/share/menu/qsynth look like: ?package(qsynth):needs="X11" section="Apps/Sound"\ title="qsynth" command="/usr/bin/qsynth" hints="MIDI Synth"\ icon="/usr/share/pixmaps/qsynth.xpm" It can even be included in the ebuild, as exemple with a few new variables or an echo statement. The advantage of the echo statement is at it is no need for a new eclass, it will directly create the file. But new variables will be cleaner.
Another advantage of this program is at it work with any application, even console application as mc that doesn't have and will never have any .desktop file.
It seam at it would be possible to do such a menu system by adding 2 variables in the ebuilds and in /var/db for each program. No such variables -> no menu for this ebuild. A first variable to know if it is a X or a console application. A second variable to get the name of the executable. (This can be a group of variable in case of more as one executable in a package) After, a script can do the job. Or a compiled program will be faster. The no such variable option made possible not only to test for the necessity of a given program in the menu, but also to introduce such a system without the need to stress all the developpers to upgrade their ebuilds. Oh, and I almost forget, a new function will be needed in portage if we want at emerge install the menu when merging a program.
I just see at it is many programs and some ebuilds that have .desktop files and at such .desktop files have the needed variables: Type, Exec (or TryExec). And we can get the category from portage tree, so it must be possible to do such a function without too much difficulties.
I just see at this bug repport have the same goal as the glep 16: http://www.gentoo.org/proj/en/glep/glep-0016.html
We could focus on improving one of the existing menu generators like denu, rather than reinventing the wheel or using a second format for desktop entries when we already have a good one.
Closing as WONTFIX. We won't adopt a second desktop entry format. If you have a proposal about .desktop handling open a NEW bug.
It is fine for me. I done a huge bash script for fvwm-crystal (fvwm-crystal.generate-menu) and it is now included in fvwm-crystal-3.0.5. And 3.0.5 is already in portage. This script search for all or for a specific .desktop file and generate the corresponding crystal menu entries if they don't exist. It search and generate the icons too (it was the easy part). I don't know if it can be adapted for another wm and have no time for that.
