I was wondering if there are plans to implement a common program menu in gentoo that is updated when new packages are emerged. Nothing fancy, the same basic categories as are in /usr/portage, except links to the files placed in an executable location like /usr/bin.

Debian does a pretty good job of this, as do a lot of other distros.. Is it feasible for gentoo? I'm reasonably proficient in Python, does this sound like a trivial addition?

Perhaps the best way to go about it would be an XML file describing the entries with flags like system, console, X, gtk, qt, in a format like this:

So you get the idea. It seems like it would be simple enough to make a small program that would parse /var/db/pkg and build the menu by looking for items placed in /usr/bin, but I'm not sure if it could have the ability to discern which packages need to be in the menu (abiword), and which do not (modprobe). The menu file could be parsed easily enough by seperate scripts (or XSL?) to generate menus for the chosen WM (*box, gnome, kde...)

Any ideas, nitpicks, or support?_________________Spikkle,

It's like what forms at the corners of your mouth while you sleep, only softer, wetter, and with more substance.

I like this idea. What would be really good, is if it was fully part of portage, but optional, perhaps with a USE flag to enable its use. That way it can easily be enabled or disabled. Any time a package is emerged, if appropriate it is added to the menu. Its position within the menu could be specified within the package's ebuild.

And the menu layout would have to be brilliantly designed, or really customizable!

I like this idea. What would be really good, is if it was fully part of portage, but optional, perhaps with a USE flag to enable its use. That way it can easily be enabled or disabled.

<situation type="hypothetical">
I have it disabled because I'm the only one using my box and I don't use a windowmanager with menus.

I move to a shared house and the other person there has no computer. I have two, but the second one is too slow to run any reasonable operating system at a reasonable speed in this day and age, so I hook it up to my main box as a dumb X terminal.

Having showed the other person my desktop and Gnome (being the only two options I have compiled on my box, having no need for anything else), they choose Gnome. So I add "menu" to my USE flags, but I already have a fully working desktop box.
</situation>

Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?

I've been experimenting around with this idea ... it's relatively easy to do (it seems, so far). Concerning updates, you could either work with portage or put an update script in a crontab. However, I don't really see a reason for making it a part of portage._________________Apocalypse now!

Having showed the other person my desktop and Gnome (being the only two options I have compiled on my box, having no need for anything else), they choose Gnome. So I add "menu" to my USE flags, but I already have a fully working desktop box.

I would think it would be more suited for a "make.conf" option rather than a USE flag.

Quote:

Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?

That depends on the implementation. Best case scenario, it would be part of portage, and since portage "knows" what it has and where, it would simply insert the appropriate menu entry when you emerged an application. So unless a recursive checking mechanism was there, the only thing you would have in your menu is gaim. However, it would not be difficult at all to provide a stand-alone "update-menus" script that could be run in user space to generate a menu.xml file. This method would collect all the program entries from your portage installed database (in /var/db/pkg) and put them into the menu. From there you could use a simple transform to generate the menu for your WM of choice, potentially only containing items you wanted, in the arrangement you desired.

Anyone have ideas for a "rule-system" to control item placement?

Here is the problem: how do we discern program types that need to go into the menu from those that do not in the update-menus case? Would it be as simple as referencing back to the .ebuild and looking at the USE flags to see if it needed X, or curses, or.... ?_________________Spikkle,

It's like what forms at the corners of your mouth while you sleep, only softer, wetter, and with more substance.

Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?

Why not have the menu entries always added/removed when (em|un)merging packages (/etc/globmenu.conf?) and then have a "globalmenu" package that enables/disables it?

Better yet, how about a script that crawls the portage tree (a la qpkg from gentoolkit) and creates the conf/xml file for menu use? Then, it's just a matter of converting it to kde/gnome/.*box/.* menu format for use/inclusion in the WM of choice.

In that case, it would be quite nice to incorporate menu generation into the emerge command. Possibly have some sort of special emerge option, for example emerge gentoo-menu. This could then read your USE flags to determine which environments you want to generate a menu for. For example, if you have -kde set, then you don't generate a KDE menu. Once the menu has been created you could then have emerge -u menu to update your menu with packages you have installed since the last menu generation. Also, I think it would be nice to include menu locations in ebuilds.

I don't think you want to generate menus without the user saying to though. How irritating would it be if once a week any changes to your menu that you made manually were killed by the menus updating automatically. Either way though, I think this is worth someone investigating In some form or another it would be a useful tool.

In some ways I like the customisability of linux, but I do not think that I necessarily go about making things accessible for myself on my computer. I quite like having someone else thinking about the best places to include various pieces of software in menus

Stu

kesuari wrote:

stustill wrote:

I like this idea. What would be really good, is if it was fully part of portage, but optional, perhaps with a USE flag to enable its use. That way it can easily be enabled or disabled.

<situation type="hypothetical">
I have it disabled because I'm the only one using my box and I don't use a windowmanager with menus.

I move to a shared house and the other person there has no computer. I have two, but the second one is too slow to run any reasonable operating system at a reasonable speed in this day and age, so I hook it up to my main box as a dumb X terminal.

Having showed the other person my desktop and Gnome (being the only two options I have compiled on my box, having no need for anything else), they choose Gnome. So I add "menu" to my USE flags, but I already have a fully working desktop box.
</situation>

Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?

If you look into the eutils eclass, there is already a function to create .desktop files for gnome/kde and put them into the proper locations. I could modify this more to add support for other window managers, but it'll take some time. As it is now, it would be up to the maintainer of each package to update the ebuilds to call this function.

If you look into the eutils eclass, there is already a function to create .desktop files for gnome/kde and put them into the proper locations. I could modify this more to add support for other window managers, but it'll take some time. As it is now, it would be up to the maintainer of each package to update the ebuilds to call this function.

Right now I don't see a compelling reason to have the maintainers of the packages attempt to conform to a menuing standard. I'm very much in favor of "Reasonable Defaults", and I feel it is the user's responsibility (especially in a meta-distro like Gentoo) to create their own menu. However, there is no reason not to give them a good starting point and the tools necessary for them to customize it to their liking.

Looking through portage, it almost leaps out at you the potential for menus and submenus, as such:

So each submenu would contain the list of installed items, matched for the USE flags in the ebuild for their "worthiness" of being included in a menu. This worthiness would be configurable by the user, as would the placement of each category and sub-category. In this way, the menu.xml file could be built to the specifications of each user, without requiring a "standard" structure for the menu itself, and user space tools could turn that menu into commonbox, gnome, kde, windowmaker, etc.. style using another script or even XSL transforms.

I guess what I am saying is (as pointed out by stustill) we need a "gentoo-menu-generator" program that we can emerge and then each configure to our likings. I am very willing to work on this myself, but I would like to hammer out the details in the forums so that we can make it as good a utility as any other, a not an "evening hack"._________________Spikkle,

It's like what forms at the corners of your mouth while you sleep, only softer, wetter, and with more substance.

I own a linux-based gaming center/internet cafe based on gentoo. It would be *really* nice to have some form of centralized storage for menu items that both kde and gnome will use (since all my customers hvae their own accounts and can use oether kde ansd gnome). I'm *always* adding applications and games, and setting up the menus for both desktops is the small hassle.

One thing that would make it expecially useful for me is the ability to add (by hand is fine) an application to the (xml?) config file. This would be useful for the few apps/games that get installed by other means rather than portage (winex games come to mind).

Greg_________________"Life would be so much easier if we could see the source code"

I don't think a single menu configuration file is the way to go. A directory hierarchy could be used to represent the menu, with a file (I prefer .desktop) for each item - the same approach that the /etc/*.d directories use. This would make it easy for packges or administrators to modify some items without disrupting others.

For people who don't like their distribution choosing what goes in their menu, a USE flag could disable automatic menu modifications; if it's enabled, each package would install as many items as it needs. The menu generation program would be in its own ebuild, and when run it would insert all the items in the shared menu into the menus for each window manager and desktop environment installed (perhaps a seperate menugenerators.d directory could hold scripts, installed by the WM ebuilds, to do this).

An important question is whether the system should control the menus completely, or if the items should be merged with the existing menus. Simply merging the items would make it more difficult to handle removal, but it would involve less work and maintenance.

I don't mean to interrupt your theoretical studies, but I think this doesn't have to be a very elaborate script/app and neither do we have to bother all ebuild maintainers with changing their files. I've written a very rough (meaning, all the features have yet to be added) test of the principle as far as getting the data into XML format goes. Do any of you know XSLT and would write stylesheets to convert the XML for the window managers?

(1) System wide updates, for all users, without user intervention
(2) Administrators do not need to go binary filename hunting when new software is installed.

Points I would suggest:

(1) Allow an administrator created file / set of files to add to and remove items from the menu.

This would allow some software to be kept off the menus (e.g. all text editors bar one wouldn't appear, to keep things simple for users), or placed in a different menu location.

(2) Watch out for special applications, such as window managers. They might appear in the menu, but probably not as a "run me" item. They would go in a "Change to window manager" item. (e.g. [restart] in common box).

(3) Console applications should run using the users default TERM, not anything specific by the package maintainer.

(4) The format for storing the menu data should contain all the information used by any window manager. (E.g. some have a description field, some don't, but the shared menus format should have both).

(5) Sometimes different data may be desired for some menu systems, for example to specify a different icon for a window manager (e.g. KDE has system icons which change depending on the theme).

(6) The script to rebuild the menus can be run manually or at the end of an emerge (if USE flags are set). It should also be capable of being run by any user, targeting a specific window manager, and a specific file. This allows users to generate the latest menu then copy/paste chunks of it in to the manually maintained version.

(1) can as well be done by root using an editor :p
(2) results in a simple blacklist of things not to include in the menu plus a special script for the WMs' menu.
I haven't found a solution for (3) yet - how to automagically find out whether a certain application (moreover, a certain binary) needs a console or not Anyone?
(4) is easy
For (5), you'd have to go icon hunting for each app available in Gentoo. I'd rather drop this one for now.
As for (6), I'd let root run a script making an XML file, then give the users the opportunity to convert that to their favourite WM's format with xsltproc. When exactly the XML file gets updated should be root's decision, not ours _________________Apocalypse now!

Actually admins with custom entries could just write up a short .ebuild file (just defining DESCRIPTION and possibly dependencies) and a CONTENTS file (with only the interesting binaries) and put that stuff in /var/db/pkg resp. tell a script to make it so. Would make an automated menu-building script's life a lot easier.

Console apps - well, not even SuSE got it 100% right in the past (dunno about the current version). And _they_ were probably making their menu manually. For a start, how about assuming that the users won't be too disappointed if no window appears when they click on things?

Icon hunting - agreed. If the maintainers wish to provide icons, they can of course do so, e. g. putting the icon in /usr/doc/foo or /usr/share/foo and setting the path in the .ebuild, like APP_ICON="/usr/share/foo/app-icon.xpm"._________________Apocalypse now!

A package can optionally run update-menus after installation which inserts all its menu items in the various window manager menu files. (this could be controlled bu a use flag).

Theres more to it than this, but it seems well thought out. It is worth downloading the mandrake rpm menu package and looking at the man pages (mc is good for this).

I know it works as I have run debian and mandrake. the menu system is the one thing i really miss in gentoo. The difficulty is inserting the /usr/lib/menu/package file into every relevant ebuild. The good thing is that it is already done by many package managers, and the files already produced by others may only need minimal or zero tweaking. There also appears to be per user overrides.

Afaict, emerge has so far not been an interactive app. And that's a Good Thing, because it means you can go to bed and be reasonably sure that it manages the download and make of two dozen ebuilds without your intervention. Having to type y or n regularly would really spoil the rare sleep experience._________________Apocalypse now!

Afaict, emerge has so far not been an interactive app. And that's a Good Thing, because it means you can go to bed and be reasonably sure that it manages the download and make of two dozen ebuilds without your intervention. Having to type y or n regularly would really spoil the rare sleep experience.

Very good point and mostly true except for the occasions when you find that a variable such as VIDEO_CARDS has been added to an ebuild .

Anyway, I'm all for a voluntary menu system, it'd certainly beat my kportage/terminal combo system I use now.

The system could still be automatic. If the master menu file was automatically kept up to date, then the so called "client" menu-builders could be run at the user's discretion, to perform some sort of intelligent transform on the master file and build the menu for the WM the user requests.

I have been digging around for something like this, and I suggest everyone check out http://menumaker.sourceforge.net/. It is a pure python solution (nice) but currently has what I would call three limitations:

1) It relies on recognizing the binaries in your system by name
(this is fine for slackware or LFS, but it is a silly way to do it in gentoo
when we have the portage package database available)

2) It requires a unique definition for each program, so it cannot
automagically recognize brand new programs not in its list of definitions

3) The way the menus are made is hard coded, so customizing has to be
done afterwards, and there is no internal "rule system" so that a user
gets his own style of menu, every time.

However, it seems an excellent starting point, since only the core would have to be re-written (to be much simpler, I might add) to scan the portage database, and the transforms for basically everything except gnome and kde are already there.

Looks like a winner to me! And this way we don't have to re-invent the wheel, only the rim and a couple hubcaps!_________________Spikkle,

It's like what forms at the corners of your mouth while you sleep, only softer, wetter, and with more substance.

lack of kde & gnome support is an issue in menumaker, as many people will want to use kde or gnome (especially newbies, who may not find it easy to hand code menu items).

It seems to me that it is inherently more logical to use a system where each package determines what menu items are added, rather than some uber-program parsing packages and deciding "this is a binary, lets bung it in a menu" Not every binary in a package is suitable to run from a menu. how does the program decide what command line options should be added to the binary?

Leave it to the ebuild maintainers to define some menu entries for their package and include a USE variable to determine whether it is used.

as I have said twice, debian use this system already, and mandrake copied it. are gentooer's too proud or arrogant to adopt a system already in use and which works?