Heino: There's quite an active discussion regarding Gentoo-customized desktops that seems to have focused on unified menus happening on ML gentoo-dev at the moment. You may want to check it out and add your ideas to the mix!

It would cause the same discussion as in the last thread "python vs. bash rule files", some people will heavily disagree with this idea and come up with another, it wil end in a flame-war, but the people are not going to do anything to get their system working ..

Svyatogor and me are doing something, working on this system, we had not much time in the last two weeks, but we will continue to work on it to get it finally done

It would cause the same discussion as in the last thread "python vs. bash rule files", some people will heavily disagree with this idea and come up with another, it wil end in a flame-war, but the people are not going to do anything to get their system working ..

I see your point! The thread did degenerate rather quickly, didn't it.

Quote:

Svyatogor and me are doing something, working on this system, we had not much time in the last two weeks, but we will continue to work on it to get it finally done.

Do you have any documented game-plan? I would like to help, simply as it's something I'd like to use. However, I had a look at the CVS and I couldn't see a logical next step - probably because my Python skills are about as good as my heiroglyphics knowledge! But, hey, there's no better way to learn that by doing, right?

I do really like this menu-generation thingy. And I could also make a patch to fluxbox, so that it would support the freedesktop.org "standard" _________________The md5sum of the above post is 06280ccd85ef9deb49c336e7945f4b5c

2)
small util displays this list and allows check/uncheck for menu desired programs and creates a mask file user_menu.mask, also checks user_menu.mask for previous editing to avoid tedious reselection of menu items.

3)
system_menu.mask file made to automatically remove items known to have no function on the menu.

4)
each new program auto added to menu when util is run, has a switch for simple update to aviod selection and just add new items to menu.

cat, grep, less, etc have no use on a menu, so they are in the menu.mask file and never show on the menu. the util provides an easy way to remove unwanted items from the menu and remember this selection.

they are sorted my app type as in portage, ie. x11-base has X, net-fs has samba and so on

so you need a directory listing of each program
each programs fold has a file CONTENTS, which has all the paths to everything that ebuild installs. this file 'CONTENTS' has lists starting with 'obj' which are the installed binaries for the program

so in the zsnes folder, in CONTENTS, this is

dir /whatever
dir /thisorthatdoesn't matter
obj /usr/games/bin snes9x

we need to pull that obj line and add that to the menu.

--

so we need a script to traverse all the /var/db/pkg directories and then find 'obj' lines in each CONTENT file. put this into the menu sorted but the top level directory in /var/db/pkg such as anthing in app-emulation should be sorted to the emulation menu item, and games-fps should be in the games folder. an so on.

i think thats a start.

chashab, if you are doing the coding, i will do any reasearch you need.

i will whip up some scripts for testing. is there an appropriate place around here to post them?

regarding icons, wouldn't it be handy to have the full set of icons available for download individually using portage? example, our script comes to the conclusion that it needs 4 new icons, it calls on emerge to yank them from a local mirror.

thoughts?

also, i'm assuming we might as well continue discussing here, rather than jumping into some mailing list.

for icons yes, but I think we need to focus on simplicity and then add features.

maybe we could use an exsisting icon set and have the script choose the icon based on the name of the program. for instance, KDE has an icon named the same as all the KDE programs. so if you get a kaffeine menu entry, then the script can say to use the icon /usr/kde/3.2/share/icons/crystalsvg/32x32/apps/kaffiene

also, build the script right in this thread and post it here, maybe that will draw attention and we can get a larger interest.

just taking a look through a CONTENTS file. there are quite a few lines starting with obj.

i recal reading earlier that someone suggested having each e-build specify what menu category it should fit under, and what the binaries are. this was idea was killed as all the e-builds would have to be remade.

i'm thinking that binaries are added to a directory that is known to be in a path. so the script should search of obj lines that contain files in known binary directories.

on my machine root shows path as being:

Code:

/sbin:/bin:/usr/sbin:/usr/bin

and a user has the path of:

Code:

/usr/local/bin:/usr/bin:/bin

are these gentoo defaults? should i hard code to look for these directories?

i'm using to create a new binlist whenever the script is run and the adding to that same list in line 2, I'm not sure if their is a more elegant way to do this. but i'm a poor coder so this is my best.

--

now i'm not sure where the kde menu is located so I can't look at it to see the format or anything..

i'm don't think there is an advantage in comparing directories. for instance

Code:

diff /var/db/pkg /usr/portage

shows many directories in only /usr/portage, but it shows no directories in only /var/db/pkg. the reason for this is that you don't have any e-builds emerged from the categories that are only directories in /usr/portage.

it should be noted !JAPH (i am not a perl hacker). suggestions are welcome. but this is more just proof of concept.

to run save it, chmod appropriatly and ./binfind.pl like any script. by default it prints binaries that have been installed into a set path, namely the one i have hard coded. this could be changed to print binaries that are installed into the current users path, if desired.

you can also run it as:

Code:

./binfind.pl simple

which will print all binaries that are in a directory that has /bin/ in the name. one suggestion is to run

i've been doing a lot of thinking while i coded this up, and the current method we are persuing has several drawbacks. we can categorize things to some extent, so that seems to be ok.

but what about those extra binaries that aren't needed? having a mask setup was suggested, and at first i thought this was resonable, as we might be able to get away with masking out whole categories. then it occured to me that there is going to be apps that install some binaries for people to run, and other binaries for apps to run. and so we would need to get app specific, and that is going to be really tedious and high-maintence!

finally when the time to properlly do icons comes along, we would have to maintain a list of what binary uses what icon. again, not very fun.

the way to properlly go about a Gentoo Common Menu is to have each e-build specify what binaries are to be listed in the menu, and for each binary provide:

the user-friendly name of the binary

the path to the binary

the category and sub categories for the menu tree

the icon name/source of some kind

this info could then be put into an appropriate file somewhere.

to be honest, i see no way of properlly managing this info outside of having each ebuild specify it.

if it should be this way, i guess the next step is to develop a proper plan of where this info should be stored, and lobby those in charge accordingly.