Re: Improving panel menu code: proposals

[Mark McLoughlin <markmc redhat com>]

Hi Christian,

On Wed, 2004-09-15 at 18:20, Christian Neumair wrote:
> In an effort of improving the panel menu code, I've created a simple
> patch [1], introducing some cleanups. Now, I'm planning to do some more
> of them for 2.9/2.10.
> Current situation: We have menu info, dir info and file info structs,
> all suitable for storing the backend data that menu/menuitem widgets are
> generated from. I don't like this at all, because it looks like each
> application/gnome menu has its very own data structures. Besides, it
> simply doesn't look clean (menuitem->name is dup'ed from menu info-
> >name).
> 
> Proposals/Improvement Approaches:
> (1) Maintain separation between GUI-related and backend-related code,
> but add hash table for (menu|file) info<->(menu|file) path association.
> That way, we could first try looking up an URI before a menu/menuitem is
> generated from it, saving additional allocs for additional menus. I'm
> not sure how rare having multiple application menus is.
> (2) Assign all backend attributes to GtkMenuItem/GtkMenu-derived
> classes, including URIs etc.. Instead of sorting files, and then
> creating GtkMenuItems of them, we'd create menu items directly when
> reading a directory and insert them into a list in a sorted manner.
> 
> Pros and cons:
> While (1) allows to have many menus open at the same time without
> loosing much backend-related performance, (2) seems to be the most clean
> architechture, although each frontend would still have its own backend
> allocations. Maybe (2) can be combined with some hash-table based
> approach, although I don't think this will work for GtkWidgets.
> 
> Comments, suggestions?

	The approach I'm hoping to take is that we'll remove the gnome-vfs
method for doing menus and instead move the code[1] into a new library
which will have an API that returns a tree of (Name, Description, Icon,
Desktop File Path) laid out according to how the menu should be laid
out. The panel won't interact with the .desktop files when creating the
menus and we'd remove menu-fentry.[ch] completely.

Cheers,
Mark.

[1] - Well, the code for the new menu spec in desktop-file-utils