Having thought about this, I believe I have come up with the solution.

People pointed out the following problems:
- Some DEs/WMs have their own structured menus eg KDE
- Some people would want their own menus and not automatically generated ones
- Having ebuilds determine the menu leaves a lot of work to be done with existing ebuilds

So I propose the following:
- Have a file 'menu.mask' in /usr/portage/profiles/ which will be the axis of generating the menu.
- Packages not in menu.mask will be ignored
- The user can have an optional menu.mask with settings to override as desired those in menu.mask
- The mask file specifies both menu structure and application placement within the menu structure
- Packages are specified as [package name][min version] [exception list]
- If, for a given package, an installed wm or de is not specified as an exception, then it is applied to that wm's or de's menu
- If there is a specified exception then the package is applied to the menu as per the rules of the exception or, if no rule is specified, is ignored for the particular wm or de
- If a package appears in the users' menu.mask then it is ignored in /usr/portage/profiles/menu.mask and the settings in the users' menu.mask are used. (btw why can't you do this is package.mask!?)

Eh...I remember reading somewhere (though I can't remember where) that automatic menus was already under development. If so, you may want to jump over to gentoo-dev on IRC and see if you can find out more about it there.

--kurt_________________The problem with political jokes is that they get elected

It would be really a good think... because actually I think it's difficult to choose to activate masked package...
If you put ACCEPT_KEYWORDS="~arch" you have no control about masked package... I don't like that...

I had a bad experience with that...I put it in my make.conf file... and made sometimeslater ... emerge system -u (and gcc was updated to gcc-3.2-rc2 , now I am returning to gcc-3.2-rc1)

I get the impression it's not as customisable as the option I've offered here. Plus here you can add your own custom entries to your menus very easily, and the menus are customised according to the WM.

I'm going to see if I can hack a 'proof of concept' version once my ADSL link comes through at home, and see if it's warmly accepted.

I've still not had a chance to do this yet, although that doesn't mean I no longer plan to.

I've just got to find an evening to put aside to hammer out a proof of concept and give it to somebody. That and Seemant told me to wait for the new XML oriented portage to be finished up and done._________________Want Free games?
Free Gamer - open source games list & commentary

I think it would be better to build functionality into portage to make it more automatic. Then you could USE "menu" and have them automatically put in KDE or Gnome, at least to start. You could have a menus.conf that would say in KDE a graphics program -> Graphics menu. A similar form to charlieg's, but have each ebuild classify itself, then allow you to tell which menu gets what type. This system would require newer versions of ebuilds but that is bound to happen.

I really think that the lack of functionality hurts gentoo and if an intelligent system-wide menu system were implemented it would be a great boon._________________What Larry was saying is that if you make it too easy for programmers, then poor programmers will be able to do things best left to good programmers, and will inevitably do them poorly. Everyone will suffer in the long term as a result." - Tom Chance

So are there any efforts of putting such a menu system in gentoo. I would like it, because it's really annoying to put all this apps into the icewm menu.

But for the structure I propose a different one. There are .desktop files and they are the base of the menus for both, kde and gnome. So I think every app should supply such a .desktop file and than we need some wrappers for the other windowmanagers like icem or fluxbox.

I really don't care which menu system gets implmented, as long as we can TURN IT OFF. I have played with Debian in the past and have found it very, very difficult to disable their menu system (or even hide packages from their menu system).

The only thing I ask is that whatever system we decide to use is OPTIONAL and, by default, not included in the base install.

I think that can easily be done by setting a useflag or a portage option. But somebody should start to code such a system. I can also help in doing this but it should be something official so that it will be included in portage.

OK, it's like this. We played around with debian/drake's menu system. Didn't like it, really, the syntax is -- well "um" is probably the best way to describe it. Then we threw around the idea of XML'ifying menu entries. Then, Alastair Tse (liquidx) pointed out that GNOME and KDE are already confroming to the freedesktop.org standards. Now, that's something that we can handle -- since all the desktop entries for those DE specific apps are/will be in that format anyway. So, it remains then to create transformer scripts to convert that format to <insert your favourite wm here>'s format. Apart from that, if users really think it should be OPTIONAL, then we''ll introduce a USE flag for it to be done in postinst() for the packages. So, consider me your point man for this, and fire away ideas, scripts, etc into bug 18638. In my plan, this was not going to be a part of the 1.4 release. So we're looking at 1.5 or whatever release comes next.

I love the idea of using the freedesktop standard and I really think this menu entries should be optional, it would be no problem at all and could be set as standard If you need help with scripting, I'm here

Alastair Tse (liquidx) pointed out that GNOME and KDE are already confroming to the freedesktop.org standards.

As nice as it is to adhere to the freedesktop.org standards, it's always nice to have it customisable, especially so with a menu.

You might even want a different menu layout according to whatever DE you are using... or even whatever user you are logged in as._________________Want Free games?
Free Gamer - open source games list & commentary

If you want a different menu according to your DE, you can unset the menu useflag and manage it completly on your own.

Actually, it wouldn't be particularly difficult to produce a better method.

I've talked to seemant about this, but I've yet to follow through on it (but, as ever, planning to do so as soon as I have some decent spare time).

Basically, I've drafted up a layout xml/dtd and a definition xml/dtd, where layout is the layout of the menu (the menu layouts of each of the des, including dirs and subdirs) and the definition is the definition of which packages go where in the menu, done in a similar way to packages.mask (eg >=mozilla-1.3 to match mozilla 1.3 and above), and these will exist in /usr/portage/profile, and be optionally overridden by something in the users home dir.

My next step is to write some basic python that inspects the world file, and generates the corresponding menus for each de and user according to what's installed.

The advantages to this approach are 1) it's highly flexible, 2) it requires absolutely no changes to portage/ebuilds, 3) it's fairly simple, architecture-wise and 4) the xml is easy enough to edit manually so you don't have to be a genius to modify your menus. For 95% of users the default menus, defined by the gentoo dev team, will probably be good enough._________________Want Free games?
Free Gamer - open source games list & commentary

It would b a good stopgap at least for major apps.undefined_________________What Larry was saying is that if you make it too easy for programmers, then poor programmers will be able to do things best left to good programmers, and will inevitably do them poorly. Everyone will suffer in the long term as a result." - Tom Chance

Are people saying this should be done on the kde and gnome level and not on the distro level?

Yes they were, and I think this is wrong. Given how differently distributions work, I think it's really the position of the distro to be deducing what should be included in the application menu.

I'm reviving this thread because I just spotted Menu2WM, a nifty little application for generating WMs for most common WM menus from an XML source file._________________Want Free games?
Free Gamer - open source games list & commentary

Alastair Tse (liquidx) pointed out that GNOME and KDE are already confroming to the freedesktop.org standards.

As nice as it is to adhere to the freedesktop.org standards, it's always nice to have it customisable, especially so with a menu.

You might even want a different menu layout according to whatever DE you are using... or even whatever user you are logged in as.

I suppose I'm suffering from a lack of sleep, so maybe I'm not understanding what you're saying here. I would think the point of an automated menu generation system would be to have a consistent menu structure; custom menu structures could always be left as an exercise of the reader. Aren't flexible, per-DE per-login-session menus what we have in most WMs now?

The fdo spec provides for per-user, per-WM/DE customisation of menus (adding, moving, removing and rearranging items and folders). I really don't see the point of trying to reinvent the wheel when the fdo solution does what's needed.

The fdo spec provides for per-user, per-WM/DE customisation of menus (adding, moving, removing and rearranging items and folders). I really don't see the point of trying to reinvent the wheel when the fdo solution does what's needed.

+1

My comments were made a long time ago, before fdo was in full swing._________________Want Free games?
Free Gamer - open source games list & commentary