In search of consistent menu generation

[doopdoop]

I've been looking at various methods of keeping a consistent menu trough the different window managers und to ease the burdens from the package developers to enlist themselves in various config files. Here is what I found so far - but nothing is really satisfying. So maybe someone can give further directions.
My requirements:
- consistent way to create menus across lightweight wm's. Should support:
- icewm
- fvwm2/95
- fluxbox
- jwm
- small (e.g. no dependency on full-blown python or perl)
- easy for package maintainers (installation and removal)

1. The "Standard" way: xdg menus
xdg is a standard of freedesktop.org which defines a common format for menufiles. The standard is feature-rich (and complex).
The drawback: it's good, when implemented in the wm's - but somebody has to do it. Even GNOME and KDE do not support it fully, IceWM and fvwm95 don't give any reference to it (have I overlooked something ?).
Maybe there are tools for it to create wm-specific menu files that I could'nt find. (MenuMaker and xdg-menu from SuSe depend on Perl).

2. The Red-Hat way: wmconfig
Small (about 95k), support for fluxbox,icewm and fvwm95, very easy menu file format.
Drawbacks: no support for deep menu structure (e.g. Apps -> Internet -> Browsers), only support for built-in wm's

3. The Debian way: update-menus ("menu" package)
Clever design of file format; customizable through scripts for every wm; deep menu structure,;many ways for the user to control the menu structure; automatic subdivision of submenus, if they get to big.
Drawbacks: big (500k). I am a little bit reluctant to devote so much space in a lean distro like puppy for such relatively simple tasks.

4. Custom solution.
We could do something tailored to our needs. e.g. make a icewm2fvwm script which automagically synchronizes menu files.

Any suggestions ?

[Flash]

There have been other discussions in the forum, about this problem. As far as I know no one has found a solution - yet.

[rarsa]

Something that's on my list of things to do (seems to be getting larger) is a prototype implementation of what I think should be done:

Here are the principles in a nut shell:

- Include an 'addmenuentry' script with each of the Window managers PupGet/DotPups. This script would receive as parameters the information required to setup a menu entry. This list of parameters is what I call the script 'API' and will be the same list for each window manager. (Entry text, description, icon, execution command, etc)

- Include a file with the menu parameters in each of the DotPups. This file will be stored somewhere in puppy as part of the Installation registration process. (maybe in a xdg menu file)

- Add a step to the DotPup installer to run the addmenuentry script for each of the Window Managers

- The Window Manager installation script shoul also include a step to cycle through all the registered applications and execute the addmenuentry script.

As you can imagine, technically speaking, this is quite simple to implement, the problem would be having everybody writting well behaved DotPups.

The scripts I'm envisioning are less than 5 lines of code each.

Toughts?

[doopdoop]

Yes, this is exactly what update-menus is doing. But I doubt it can be safely done in 5 lines each if you are having a little more complex menustructure and want to take care of user customizations (I do not want to have my customized menu overwritten everytime I install some dotpup). But prove me wrong, I would be happy

[Flash]

Here's another thread discussing how to add a menu entry for a Pupget package

[Nathan F]

I have made a couple of dotpups that add menu entries automatically. I have also played around with a couple of different tools for this purpose in Icewm. Having said this I think that having a standardized and scripted way of doing it would be great. The big problem is that we have fvwm95,jwm,icewm,flxwm,evilwm, and pawm all in use. I don't have experience with all of them, but the one's I have used all have different formats for their menus. This is not an insurmountable problem and in fact would be easier handled if there was one script to do it which would run during the dotpup install. It's just a whole lot of extra work to make a dotpup that will do it automatically for all the WM's. Unleashed packages should already be in the menu waiting to be installed, or if they are new they will be there by the next release.

Said script might be better run from the dotpup.sh rather than modifying the actual dotpup installer, as not all apps would need a menu entry. As an example, any of the command line utilities which are just run from a terminal window. Another option would be to change the dotpup handler so that it would ask if you wanted to run the menu editor or skip that step. It should also be available seperately in order to be really useful. That way it could be used to customize the menu.

[rarsa]

I have a suggestion:

Let's create a 'project' or 'task force' to solve this.

- We can recruit volunteers for the different tasks identified. Bear in mind that not all tasks are technical tasks.
- We can create a Wiki page to coordinate the project and use this thread (or a newer one) for discussion.
- We can consult with Barry on his own preferences when we have insurmountable differences of opinion.

I've read a lot of good suggestions, it may be time to choose the best ones and put them into practice. There are very good techniques to sort them out objectively.

[Flash]

Have you considered asking JohnM to create a Usergroup? Right now there are none. Only John (or, more generally, a forum Administrator) can create them, but Usergroup moderators (whom he appoints) control membership and so forth after that.

A developers Usergroup might be useful too.

[rarsa]

ejem ejem ejem... I was not being as ambitious, I was thinking in a Task Force for implementing a solution for the menus.

[Flash]

It seems to me that a Usergroup is a perfect fit to accomplish what you want to do; not overkill at all.

As I understand it, a Usergroup is just an addition to the forum. I think the phpbb software John has installed already contains everything required to implement them, and the moderator(s) would take care of administering each Usergroup.

[doopdoop]

I think, I found a solution for our problem. It works with menu files following the XDG standard

From a filesystem view

/usr/share/applnk contains the menu structure as a directory tree (e.g. subdirectories like "Graphics", "Network" or "Games/Arcade")
For system-specific utilites (like wizards) we should make an extra directory (like /usr/share/applnk-sys) to ease separate menu creation.
For each menu entry there is a file with the suffix ".desktop" in the appropriate position in the menu tree. Here is simple "xine.desktop" as an example for such a file:

Code: Select all

[Desktop Entry]
Name=Xine Video Player
Comment=Video Player
Exec=xine
Icon=xine.xpm
Terminal=0
Type=Application

From a package developer view:
Installing a menu entry is easy. Simply copy an appropriate "xine.desktop" in the right place. Uninstalling simply works by deleting it.
The xdg definition is very powerful and allows multiple languages, different types of applications (e.g. X or Console), ... and it's standardized.
There are also generic categories defined in the standard. We should obey these, so that there will be as little menu clutter as possible.

From a window manager point:
There are two ways toi integrate the menu
a) menu file generation at X startup.
We need scripts for this.
b) dynamically generate the menu from the menu structure
This works at least for fvwm95, fvwm2 and icewm (jwm probably not "out-of-the-box", haven't looked at fluxbox)
For fvwm-based WM's we need "fvwm-menu-desktop" from the fvwm2 distribution, for icewm there is icewm-menu-gnome2 from icewm distribution (both currently not included, about 250k total)
To create a submenu called "Applications" from all the definitions in that directory, we replace the whole menustructure in the WM config files with the following.
For fvwm(95)

Code: Select all

PipeRead 'fvwm-menu-desktop /usr/share/applnk --name Applications --title Applications

or in icewm

Code: Select all

menuprog "Applications" folder icewm-menu-gnome2 --list /usr/share/applnk

From a user point of view:
Adding, deleting and rearranging is transparent to the user (simply add, delete or move a file in a directory tree). Writing an GUI for it should not be that hard, too.

[rarsa]

Although it contains similar concepts as what I was proposing, I like your proposal of dynamic menu generation at start-up time instad of at installation time as I was proposing 9 post above.

I like your suggestion.

Clean, flexible and standard.

The word Standard is key here. That means that we may even be able to use an existing editor if there is one good enough or we could write a very simple one for puppy

When do we start? Oops, we have already started.

So... who signs off for the project?

I'm a developer with most of my experience in data processing and UI.

Based on your list we can agree on a list of task we can start working on and assign so we don't dupplicate effort.

Great! Ready, set, go

[doopdoop]

Actually, the tasks are not that big.
The first thing: it must be "barryfied". If he does not take it, it is not worth going on
Then tasks to do:
1. Define Menustructure (work already in progress)
2. Make a package developer package
a) example .desktop file
b) Documentation: Tutorial, Defined Categories
c) maybe helper scripts
3. Adapt window manager configs for fvwm and icewm
4. Add support for further windowmanagers

[rarsa]

you are missing the following (not in any particular order)

5. Dynamic menu refresh program for Window Managers
6. Search and evaluation of existing Menu editors
7. Development of light menu editor (if none of the existing ones is deemed fit for puppy)
8. Test each of the components
9. Maintain the project wiki page (lobster, did I hear you volunteering? )
10. Define and prioritize the wish list for each task. This needs to be done both by the developers and by model users*
11. Define roles so we can invite people to join in an open anouncement.

*Model user: Someone that will be using the deliverable. E.g. Non technical users should help define the menu structure, packagers should give ideas for the PD-package.

I have very clear ideas for the Package-developer package and for the Dynamic menu refresh program and light menu editor.

I am starting right now with the Dynamic menu refresh program documenting it for the Package-developer package (we need to find a non tongetwisting name for the package)

If by the time I have something 'releasable' noone has taken the rest of the PD-package I can complete it.

Then I can work on the Menu editor if none was found fit.

I also have experience and training writing technical documentation (Manuals, help, briefing) and coordinating agile projects. So I can also pitch-in editing and proofreading the documentation.

Take into account that the tasks listed are at a very high level, We should create a wish list for each one and we should prioritize that wish list. For that we will need 'model users' to keep the developers in ckeck,

So, who else is IN?

You don't have to be a developer, there are tasks for every one. If you want to do development, you don't have to be an expert, you'll be mentored through out the project.

[doopdoop]

you are missing:

5. Dynamic menu refresh program for Window Managers

Not needed for the main WM's as I said. It IS implemented for the most important one's, we just have to activate it. That is the winning point for me.
The only one from the core distribution is JWM that needs a script.

6. Search and evaluation of existing Menu editors

Quite unlikely they exist (all I know are WM-specific).The difference is, that we do not modify a single configfile, but have a directory structure. Modification can be done in ROX. One thing that would be nice is a template (like GuestToo's "Script" and "Webpage" templates).
If someone wants to modify the structure only for their specific windowmanager, they can use the existing solution (like IceMC or IceWm Control panel), as long as they don't remove the dynamic menu line.

7. Development of light menu editor (if none of the existing ones is deemed fit for puppy)

If you are ready to go, I will not block you. But before you start developing, we should fix the specs. This is just a proposal.

[rarsa]

rarsa wrote:
5. Dynamic menu refresh program for Window Managers


Not needed for the main WM's as I said. It IS implemented for the most important one's, we just have to activate it. That is the winning point for me.

Great! one done, a few more to go!

Quite unlikely they exist (all I know are WM-specific).

Wrong! That's the beauty of using standards. There are a few, There is one in particular that seems to be favored by the major distros xdg-menu.

So maybe two done? two less to go?

Woow, we are fast!... No, not so... xdg-menu is a perl script, so we may have to either translate it to puppyfy it or just take the best ideas and start from scratch, or look for another one. (that's the kind of investigation I was talking about)

If you are ready to go, I will not block you. But before you start developing, we should fix the specs.

When I said I'll start right away I meant of course writing the wish list. Once we prioritize the wish list we can actually have the specs for each one as we require them.

[jcoder24]

My idea for a solution is to use the fvwm95 or jwm menu as a template and have a script that parses the 'template menu' to generate the other wm menus. This script would also be able to add and delete menus for any of the wm it supports. This script can be a combination awk/sh script which should help to keep it small.

When we want to add a support for a new wm, we would add a template for that wm to the 'wm_menu' script which would 'teach' it how to generate menus for the new wm.

Maybe applying awk and shell scripts to the 'filesystem view' instead of perl should help to keep size down.

[edoc]

I have made a couple of dotpups that add menu entries automatically.

I tried to use the code from your Dillo dotpup building better dotpups from 08Jun2005 to create a thingamablog dotpup as follows:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/bin/sh

# installs thingamablog and registers with pupget
# dotpup made August 2005 by David Colburn using code by Nathan Fisher

# this script automatically runs after the dotpup file is unzipped
# it can rm, mv, cp files and dirs
# it can ln or rm symlinks
# it can run programs

# unzip the files using absolute paths
# paths relative to $HOME might be better

tar -xzP --no-same-owner -f dotpup.tar.gz

# registering with pupget
# dillo_patched.files & dillo_patched.keyword are included in tarball

# I commented out the next two lines because I didn't understand what it was doing!

# echo '"dillo_patched" "dillo_patched: extended version of dillo" on "extended version of dillo" \' >> /root/.packages/alienpackages.txt
# sleep 1

# this part of the script will register thingamablog in the fvwm95, jwm, and icewm menus

### register in the fvwm95 menu
# entry is placed just above smm
FVWM95RC="/root/.fvwm95rc"
if [ -f $FVWM95RC ] ; then
# this option is used to prevent the entry from going in more than once
grep "/usr/local/bin/thingamablog" $FVWM95RC
if [ $? -ne 0 ] ;then
cp -f $FVWM95RC /tmp/DOTfvwm95.thingamablog.backup
EDITTEXT="s/^\(.\+Exec smm\)/+ "thingamablog javablogapp%thingamablog.xpm%" Exec exec \/usr\/local\/bin\/thingamablog\n\1/"
sed -e "$EDITTEXT" $FVWM95RC >/tmp/thingamabloginstall.tmp
mv -f /tmp/thingamabloginstall.tmp $FVWM95RC
sleep 1
fi
fi

### register in the jwm menu
# entry is just above smm
JWMRC="/root/.jwmrc"
if [ -f $JWMRC ] ; then
# this option is used to prevent the entry from going in more than once
grep "/usr/loca/bin/thingamablog" $JWMRC
if [ $? -ne 0 ] ;then
cp -f $JWMRC /tmp/DOTjwm.thingamablog.backup
EDITTEXT="s/^\(.\+Program label="SMM email prefilter.\+$\)/<Program label="thingamablog javablogapp" icon="thingamablog.xpm">exec \/usr\/local\/bin\/thingamablog<\/Program>\n\1/"
sed -e "$EDITTEXT" $JWMRC >/tmp/thingamabloginstall.tmp
mv -f /tmp/thingamabloginstall.tmp $JWMRC
sleep 1
fi
fi

### register in the icewm menu
# entered just above smm
ICEWMMENU="/root/.icewm/menu"
if [ -f $ICEWMMENU ] ; then
# this option is used to prevent the entry from going in more than once
grep "/usr/local/bin/thingamablog" $ICEWMMENU
if [ $? -ne 0 ] ;then
cp -f $ICEWMMENU /tmp/icewmmenu.thingamablog.backup
EDITTEXT="s/^\(.\+prog "SMM email prefilter.\+$\)/\tprog "thingamablog javablogapp" thingamablog \/usr\/local\/bin\/thingamablog\n\1/"
sed -e "$EDITTEXT" $ICEWMMENU >/tmp/thingamabloginstall.tmp
mv -f /tmp/thingamabloginstall.tmp $ICEWMMENU
fi
fi

# opening thingamablog

/usr/local/bin/thingamablog
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Then in rxtv I performed the following steps:

# cd /root/thing
# ls
dotpup.sh thingamablog-1.0.2
# cd thingamablog-1.0.2
# ls
README.txt lib templates
dictionaries license.txt thingamablog.jar
# md5sum dotpup.sh *.* > md5sum.txt
# rm -f thingamablog.pup
# zip -9 thingamablog.pup dotpup.sh *.* md5sum.txt
updating: dotpup.sh (deflated 65%)
updating: README.txt (deflated 48%)
updating: license.txt (deflated 62%)
updating: md5sum.txt (deflated 33%)
updating: thingamablog.jar (deflated 12%)

I then opened rox went to ~/thing/thingamablog-1.0.2 and clicked on thingamablog.pup and ran it.

Nothing seems to have happened that I can identify and there were no error messages.

What hath I wrought?

Thanks! doc

[rarsa]

Apparently this thread lost steam very quickly. Good news are. I've revived it.
http://www.murga.org/~puppy/viewtopic.p ... highlight=

There are some tasks that require your help.

I asume that if you were following this thread is because you care for a solution.