Improving panel menu code: proposals

[Christian Neumair <chris gnome-de org>]

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?

regs,
 Chris

[1] http://bugzilla.gnome.org/show_bug.cgi?id=152733