Horror of menu editing...

Have You ever had the need to edit your application menu or create new links to it? Click... Click... Drag... Drop.. Save! Thats how you would do it in KDE kiosk mode. As a result you get a custom menu file that represents the applications menu. Now in Gnome it isn't that easy - you need to create the .desktop file manually with your favorite menu editor (as gnome does not have a kiosk mode nor a menu editor). Ok so far so good - You have just created a new menu application link with that nice custom menu icon and the nice parameters that will run the app just nice.

How about when you want to create an sub menu or two? So you have already created the .desktop files with the right categories - lets assume we need to create sub menu under applications "SubA" and under that a sub menu "SubB". So the .desktop links have categories "Applications;SubA;SubB". Simple eh? Well not really. You also need to create the .directory entries. What they are useful - I don't know - possibly to just add a comment to the menu, or maybe to just add the icon to the folder. Nop! They contain the category tag. All that hassle to just get a category tag?!?!?

So You have the .desktop and the .directory files in place, but the menu is still not showing the right subtree and the icons come under "Other" menu. So whats missing? The menu file! Who would have guessed that you need to create another file JUST to get the sub menus! Ok, you create the xml menu file structure consisting of applications->SubA->SubB menu directories. so now you have 4 files: 1 for the application, 2 for the directories and 1 for the menu. With anticipation you expect to have a new sub menu structure created and with even bigger bitterness You will discover that the menu does still not show up!

The missing link is the inclusion of the menu into the APPLICATIONS.MENU?!?!?!?!? this is just crazy - why can I just create a menu file and it would be included into the menu structure automatically??? Well it seems there is "start-here.menu" witch includes the rest of the menus. So to finally get the menu structure you want you edit the applications.menu file and add to the end this line "<MergeFile>my-custom.menu</MergeFile>". With the greatest anticipation you log out, for insurance kill the X server (I recommend this as several times the gconfd daemon did not die after just plain old log out so ->Ctrl+Backspace), log back in and with anticipation open the applications menu. Woala - our SubA and SubB menus are there. Now the horror is still not over - we need to make a script that checks if our menu is included in the menu on entering run level 5 or on boot. The simplest way was not with some xml parser but a simple perl script that would read the menu file into array, join the array into an long string and with regular expression look if the string contains the menu file, if not do a little preg_replace known merge file and add our line. Woala - now the process is complete. Btw - in KDE there is a merge directory from where you can automatically merge menu files into the tree...

So if You have red so far You might ask why the hell I'm going into all this trouble with the menu's and files - well how else you can put the files into an RPM. Again You might ask why would someone need to do this ever? And again I would answer - to deploy this menu structure on around 1000 workstations. RedHat and Novell enterprise linuxes are excentric on gnome, so I don't understand why??? They promote gnome because gnome is absolutely minimalistic, so the end user cant mess things up with "accidental" configuration. I use KDE on all my computers and I have never run into problems running and packaging KDE in kiosk mode.

So here are some useful info on menu editing and structures: basic, example, .menu file structure, .desktop files, .directory files and menu file structure.

Here are some suggestions on how to improve the "functionality" of the menu editing from the enterprise level:

1) as gnome seems to be all in for the xml - make handlers for xml based desktop and directory links - it isn't as fast as stream parsing a file, but still computers are fast enough so they can be parsed once and put into the memory.

2) drop the stupid menu hierarchy with all the inclusions and stuff. The start-here.menu can be there but it should contain only folder links to folders that contain the desktop files (remember - they are in xml so they can contain their own menu structure!!!). This would obsolete the need the create 5 files to just create a link into sub menu of a sub menu - I know its against the Gnome philosophy to keep everything minimalistic, but from the enterprise point of view it would be minimalistic. We could just point the start-here menu to look for the menu structure from another location and woala - perfection!

3) if the 1. suggestion is too much work, the menu file in it self could be put together from the xml files - merging xml files is simpler than building 1 stream parses for desktop files and another for directory files. This way we can join the directory entries and the desktop links into one folder so managing them would be easier.

Too long... Too boring... Maybe useful...

technorati tags:Gnome, KDE, Applications, Menu, Deirectory, Desktop, editing, RedHat, Novell, CentOS, Debian, Ubuntu

Blogged with Flock