Menus

[Jasper Huijsmans]

Botsie,

I feel your pain. This all seems like a terrible kludge. If only these
people could agree on something it would at least not be a wasted effort
to implement it.

Comments below ...

On Tue, 28 Jan 2003 11:38:24 +0530
Biju Chacko <botsie at myrealbox.com> wrote:

> Hi,
> 
> This is just an attempt to get all my thoughts straight. I figured
> expaining them would clarify them for me too. ;-)
> 
> I have come to the conclusion that the freedesktop menu spec is a
> complicated solution to a real problem. The problem is that distro
> makers and application makers need a consistent way to present menus
> to users. Unfortunately, the current menu spec is *very* complicated
> and is a moving target as well.
> 
> However, I don't think we can afford to ignore it completely. We need
> *some* way to represent all the applications installed on the system,
> and this is the most promising way.
> 
> There is also the issue that hierarchical menus are not really
> compatible with the way XFce works. Many people (eg tom at unhooked.net)
> prefer small simple menus that are easily edited.
> 

I fully agree with your assesment of the situation.

> So, what needs to be done?
> 
> Here is my initial solution:
> 
> * Menu parsers are implemented as plugins. Example plugins would be:
> xfdeskmenu rcfile, old-style menu directory and freedesktop menu spec.
> Distros could implement their own plugins for their own system menus.
> 
> * Each parser would have an interface of a minimum of three functions:
> 
> 	* get_menu() -- returns a data structure representing the menu.
> 	* add_menu_item(path, data) -- adds or replaces the item at 	
> 	'path'
> using 'data'
> 	* del_menu_item(path) -- deletes the item at 'path'
> 
> * Menus returned by the plugins would be merged by the parent  
> application.
> 
> * The parent application would be a library, so that consistent menus
> can be displayed by xfdesktop, xftaskbar and xfce-panel.
> 

A library with plugins, now there's someting new :) But I don't think
the panel and the taskbar should use this menu, really. Plugins to
generate different types of menus are of course perfectly alright.

> * Menu editing would be integrated into menu display similar to how  
> popups in xfce-panel behave.
> 

Nice, but perhaps unnecessarily complex. I think having the plugins only
provide a get_menu() function and have a separate menu editing app will
be a lot easier to implement.

> OTOH, this may be overly complicated for something as trivial as menu
> display. The other alternative would be to have something with similar
> functionality to xfdeskmenu. It would be simple to begin with, but
> difficult to add features to.
> 
> Comments, flames, etc?
> 

Good write-up, botsie. I'm really not sure about the best solution here.

The easiest solution perhaps would be to copy the xfce3 behaviour and
have our own simple menu (something like xfdeskmenu) that is editable
and have other menus as an add-on. For simplicity we could just ignore
user modified gnome and kde menus, since they would bring the real
complexity of the VFolder spec. 

At least I feel the multiple editable menus solution is overly
complicated. We should decide either to just use the VFolder spec and
use the GNOME/KDE menu or we have a simple editable menu of our own with
non-editable GNOME/KDE/DEBIAN menu.

This is not easy to decide. I'll think about it some more. Don't know if
that will do any good though ... :)

	Jasper


-- 
IRC channel: #xfce on irc.freenode.net