Adding menu entries to ebuilds is the best way to do it, although it is the most tiresome way for the devs, and the one they would not appreciate. However, when spikkle is finished his program, perhaps he could be granted access to update all the ebuilds, or ebuilds could just be updated as things are developed.

Either way though, parsing is a bad idea, if the goal is to produce user friendly menus. Adding every binary to a menu would just get ridiculous.

Menus should be entirely generated each time an emerge occurs, and should be generated for every wm installed. In my humble opinion anyway....

add a flag in make.conf for menu generation"MENU=TRUE" and update entries into this dir.

from this directory system scripts can be made to generate menu files for the various desktop environments easily. And to regenerate these files from the directory menu system every time a new peice of software is added for removed.

if you could get someone to maintain a list in portage for menu'able items vs. nonmenu'able items then this whole system could be skipped and a script could compile a list of commands available from /usr/bin and compare it the this menu'able list to get a final gentoo linux desktop menu. The list would be for which packages are usable from a menu and which are not of course, as Kedit should be on the menu and modprobe shouldn't. Even make this system variable based on the group settings of the user, so the list would have a structure like:

Adding menu entries to ebuilds is the best way to do it, although it is the most tiresome way for the devs, and the one they would not appreciate.

There aren't a lot (by comparison) of packages that install multiple binaries, and the ones that do use each binary for a seperate "program" (think openoffice, quakeforge). Still, I don't think forcing the devs to make menu entries is a wise option. That would just be extra work, the categories are already there in the form of /usr/portage. My earlier post shows an example of this. The idea is to make an easily parsable, structured list of installed applications and their pertinent characteristics that is updated in place (so manually inserted changes are kept) whenever programs are installed or removed. Then a *seperate* program would be configured by the user to put the applications they want in their menu (either specifically, by characteristics, or by wildcard) in the chosen location. This seperate program would be able to spit out "any" menu format.

stustill wrote:

However, when spikkle is finished his program, perhaps he could be granted access to update all the ebuilds..

BWAHAHAHAHAHAHAH!!.... oh... *ahem*.... hmmm..

stustill wrote:

Either way though, parsing is a bad idea, if the goal is to produce user friendly menus. Adding every binary to a menu would just get ridiculous.

Menus should be entirely generated each time an emerge occurs, and should be generated for every wm installed. In my humble opinion anyway....

This would lead to a serious usability problem. The user is the one who should choose if they want to see every binary, just a chosen few, or all binaries based on the kinds of programs they run. Ideally, this can be determined by examing the USE flags and/or dependencies of an application, and it can be decided at runtime for the client-menu generator. The master menu file should be updated (not regenerated) each time an emerge occurs, and the user should be able to specify if they want their specific menu to be updated along with it. Of course, the client-menu generator would respect the rules they already had in place.

nickrout wrote:

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). t 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"

See my earlier post.. Basically we (or I) just need to write a Gnome and KDE generator to go along with what is already in the MenuMaker source. The core itself would need to be rewritten to use the portage database instead of scanning for known executables. This way our menu generator can be dynamic in nature, and not require constant updates every time a new program is released or changes the name of its executable.

It seems like a lot of folks are misunderstanding that this master menu would be absolute or automatically blow away their hard work on their own menu. The master menu.xml file would simply contain the information needed to build any kind of menu the user needs for their WM, it would not be the menu itself._________________Spikkle,

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

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?

No, Gentoo users aren't "too proud or arrogant". It just seems logical that the developers should concentrate on making ebuilds, and the users should concentrate on configuring their systems to their own liking.

You guys have some crazy ideas... I have wanted an easily generated menu for a long time.

My ideal solution would have a common storage of menu items somewhere, and everytime you emerge an app that warrants a menu entry, they will be added to the common menu. This does require the admins, to update ebuilds, but it could be done over time and would be trivial to do...

In addition to the common menu, you need a client to edit your menu. Which would display your menu on the left and menu items you haven't added on the right. You could easily add or remove programs to the menu (even ones not added by portage into the master menu, root required). Also a use flag should be available to automatically add everything to the menu. (remember use flags can be enabled and disabled when you emerge an individual package) Users menus will be stored in ~/.menu or something that is only created once you start the menu editor.

With this solution, you could have nice custom menu in less than five minutes. Or you could ignore it all together and be stubborn and make your own menu.

I think this would be really easy to do (hardest thing is the menu editor). I would be willing to help (by helping update ebuilds, with the needed info)

ok ok I was just trying to point to a useful workable existing and probably adaptable system

It's certainly not a bad suggestion, and it may eventually become policy for new/updated ebuilds as gentoo evolves. The immediate problem, however, is that there are over 4,000 ebuilds which would need to be updated and I would rather not bother the maintainers with something that trivial when we can work out a solution that doesn't require changing the ebuilds themselves. As such, it can be a simple "drop-in" solution.

h3k70 has the right idea with his PHP script, but even though I write PHP for content management / MySQL, I can barely make heads or tails of some of the techniques he uses. (Hat's off to h3k70) I'd love to see a pure-python solution since that would not require any additional dependencies above portage. I've got my computer working again (hard drive crash) so I am going to get to work on one myself, as my first "real" python project.

In any case, constructive criticism is invited, so don't hold back if you have a good argument! _________________Spikkle,

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

There is a menu system already in gentoo, I use it but it's knowhere near as good as the system in debian. It may not be for all window managers but it covers a few, the package is genmenu I think it's masked.

handling 3 different menu formats in here is nasty but works. I dont want to try and understand the logic in here anymore

That's a good point in favour of an XML based system. Anyway, genmenu's approach is different from ours: it searches for some predefined binaries that it knows about; we'd like to have any (within reasonable limits) Gentoo apps in the menu._________________Apocalypse now!

My thoughts are this - could we somehow implement the ideas from freedesktop.org (specifically http://www.freedesktop.org/standards/menu-spec/)? This could be helpful for several reasons. The most important being that someday kde and gnome (and maybe others) will support this spec and we will no longer have to build this into gentoo - it will be automatic.

Any ideas?

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

The freedesktop.org spec is good. Now what we need is a script to make the creation of .desktop files as automatic as possible, because I don't think this will ever get anywhere if we wait for the ebuild-maintaining folks to make that stuff _________________Apocalypse now!

My thoughts are this - could we somehow implement the ideas from freedesktop.org (specifically http://www.freedesktop.org/standards/menu-spec/)? This could be helpful for several reasons. The most important being that someday kde and gnome (and maybe others) will support this spec and we will no longer have to build this into gentoo - it will be automatic.

Any ideas?

Greg

Hmmm.. Yes. But I would have to say that the "freedesktop" menu style should probably be an export option (i.e. - done by a translator of the gentoo master menu file) rather than the gentoo master menu file itself. The reason being that the freedesktop menu is pretty huge, so the parser that would convert it to the actual running menu would be pretty detailed. In addition, all of this extra stuff would be "wasting space" in cases where the user is running a WM that doesn't (and likely never will) conform to the freedesktop standard.. like Blackbox, Windowmaker, etc.

So the freedesktop menu is as good an idea as any on paper, I think it is a lot more than is really needed for the "Gentoo Common Menu" master file. As an export though (and eventually the common export format for both KDE and Gnome, I presume) it is certainly viable, and best left to the user to decide how it should be configured. My personal goal for this project is that the "Gentoo Common Menu" be as innert as possible, leaving all manner of customization to be done on part of a user modifiable rules system to generate the appropriate menu format for their WM of choice.

I'm about halfway through the proof of concept python program to generate the master file (sorry it takes so long, I'm learning python as I go.. I'm used to C and C++). Once we have established the proper structure and included data for the common menu, we can get to work on the translators.

Cheers._________________Spikkle,

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

heino:
Yeah, noticed it. But at the time of your first post cvs.cojobo.net was unreachable from where I sit
Anyway, the stuff you've got there looks cool (I'd like to say more but I can't really read Python (or whatever you use )). Does it work? Do you already have the .desktop files?_________________Apocalypse now!

Well the .desktop parser is working fine, it parses .desktop files, checks for syntax errors and has a nice api to access the files. The .menu parser still needs a lot of work to be done (help is always welcome).

[edit]
Yes, it's python
Regarding the .desktop entries for the apps, I would propose to create one for each app (they are only needed for gui apps) and include them in the files dir. But this should be done when we have the basic parser and converters for the different wm's working
[/edit]

I feel it is better to use a large XML master file or a folder & XML file organisation, so that existing parsers and more tools can be taken advantage of... But you're already doing that for menus. So, why not use XML for menu items as well? Why not use XSLT to create desktop files?

I've been following this discussion for the last week and last night the possibilites grabbed me. What I'm mostly interested in is trying to build the menu without knowledge of all the possible menu items. I've thrown together a small python program to test some of the ideas that were laid out on page 1. Currently, it looks over all installed packages via /var/db/pkg/, skips over any "masked" packages and then searches for binaries in specified directories. I added the spec. dirs bit after because the program was finding xpm files in /usr/share/icons/ and all sorts of things that probably shouldn't be executable. Anyway, forgive the coding style as it is my first attempt at python. Most of the variable names are self-explanatory but I got a bit impatient to think up nice names toward the end. Anyway, here 'tis:

As you can see, I masked gnome and kde as was talked about earlier, but also masked all the lib dirs as well as sys-* and x11-*. This is because the output for all the lib dirs was pretty much useless and the output for sys-* and x11-* was similar in nature to (but worse than) app-text or app-i18n below. Here's the created menu tree on my box:

As you can see, there's heaps of stuff in there that has no need to be in there at all. My original thought was that this could be fixed by masking specific packages, in the form of app-text/docbook for example, which is working already. However, looking at app-office, there are several entries created from gnucash which aren't needed.

I think this is the biggest stepping stone. Telling a console app from an X app could be accomplished using elf-utils to scan through the library dependencies looking for a link to X. Finding an icon for an app could be achieved by scanning through the CONTENTS file looking for an icon with a matching name to the binary. Making a generic menu in any format to be exported to others is piss easy (but a lot of work). It seems the most difficult thing (algorithmically) is figuring out what requires a menu item.

IamtheOne had an idea of a menu editing application but, even with a fancy gui, going through the generated menus above would still take several hours. By the way, adding in sys-* and x11-* generates >1000 more entries. I didn't want to include it as this post is already long enough.

Anybody have any ideas on how to limit the menu to useful stuff? Kind of reminds me of dealing with spam - want to get rid of as much as possible without losing anything that should be there.

I realise that the solution is not to make my own project. I'm sure you can tell from looking at what I have done that I don't have the experience. What I am trying to do is help others with their efforts. All the projects I have seen all require the ebuild maintainers to specify which application should have what icon and should go where. What I was interested in was the idea coming at the problem from the other side and attempting to build a menu without a knowledge of all the applications. I haven't read anywhere that the idea has been abandoned so I just threw together a little prototype to test the concept. In my previous post, I published the results.

You need help with the parser for menu files. I know this; you said it twice before. I can't offer too much help there. What I'm wondering, though, is where do these "menu files" come from? If it will require changes to portage, ebuilds, etc. then it will be a long time coming.

[edit]

Okay, I've looked back and see that you are planning on creating all the desktop entries for each application manually. I agree this is the best way, but who maintain's it?

The maintainers of the ebuilds should at least include a basic file (many gui applications already do this). I think this should be done simply with the next release of the package in portage. Then we need some i18n people to translate the descriptions, etc. I also think there would be no problem to get another (new) dev to do that.

jason:
The biggest obstacle to auto-detection of programmes is whether to run them in a console. And there just isn't a way that works for everything. Things like that really have to be done manually._________________Apocalypse now!