Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 02 Sep 2014, 22:32
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
In search of consistent menu generation
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 2 [19 Posts]   Goto page: 1, 2 Next
Author Message
doopdoop

Joined: 28 Jul 2005
Posts: 48
Location: Magdeburg, Germany

PostPosted: Wed 03 Aug 2005, 11:59    Post subject:  In search of consistent menu generation  

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 ?
Back to top
View user's profile Send private message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 11034
Location: Arizona USA

PostPosted: Wed 03 Aug 2005, 12:58    Post subject:  

There have been other discussions in the forum, about this problem. As far as I know no one has found a solution - yet.
Back to top
View user's profile Send private message 
rarsa


Joined: 29 May 2005
Posts: 3053
Location: Kitchener, Ontario, Canada

PostPosted: Wed 03 Aug 2005, 14:01    Post subject:  

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?
Back to top
View user's profile Send private message Visit poster's website 
doopdoop

Joined: 28 Jul 2005
Posts: 48
Location: Magdeburg, Germany

PostPosted: Wed 03 Aug 2005, 14:20    Post subject:  

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 Razz
Back to top
View user's profile Send private message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 11034
Location: Arizona USA

PostPosted: Wed 03 Aug 2005, 18:57    Post subject:  

Here's another thread discussing how to add a menu entry for a Pupget package
Back to top
View user's profile Send private message 
Nathan F


Joined: 08 Jun 2005
Posts: 1760
Location: Wadsworth, OH (occasionally home)

PostPosted: Fri 05 Aug 2005, 11:28    Post subject:  

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.
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger 
rarsa


Joined: 29 May 2005
Posts: 3053
Location: Kitchener, Ontario, Canada

PostPosted: Fri 05 Aug 2005, 13:01    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 11034
Location: Arizona USA

PostPosted: Fri 05 Aug 2005, 16:39    Post subject:  

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.
Back to top
View user's profile Send private message 
rarsa


Joined: 29 May 2005
Posts: 3053
Location: Kitchener, Ontario, Canada

PostPosted: Fri 05 Aug 2005, 17:04    Post subject:  

ejem ejem ejem... I was not being as ambitious, I was thinking in a Task Force for implementing a solution for the menus.
Back to top
View user's profile Send private message Visit poster's website 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 11034
Location: Arizona USA

PostPosted: Fri 05 Aug 2005, 17:33    Post subject:  

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.
Back to top
View user's profile Send private message 
doopdoop

Joined: 28 Jul 2005
Posts: 48
Location: Magdeburg, Germany

PostPosted: Tue 09 Aug 2005, 19:44    Post subject:  

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:

[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:

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

or in icewm
Code:

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.
Back to top
View user's profile Send private message 
rarsa


Joined: 29 May 2005
Posts: 3053
Location: Kitchener, Ontario, Canada

PostPosted: Tue 09 Aug 2005, 21:26    Post subject:  

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
Back to top
View user's profile Send private message Visit poster's website 
doopdoop

Joined: 28 Jul 2005
Posts: 48
Location: Magdeburg, Germany

PostPosted: Tue 09 Aug 2005, 21:54    Post subject:  

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
Back to top
View user's profile Send private message 
rarsa


Joined: 29 May 2005
Posts: 3053
Location: Kitchener, Ontario, Canada

PostPosted: Tue 09 Aug 2005, 22:17    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
doopdoop

Joined: 28 Jul 2005
Posts: 48
Location: Magdeburg, Germany

PostPosted: Tue 09 Aug 2005, 22:39    Post subject:  

rarsa wrote:
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.
Quote:

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.
Quote:

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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 2 [19 Posts]   Goto page: 1, 2 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0941s ][ Queries: 11 (0.0038s) ][ GZIP on ]