Re: Improving panel menu code: proposals

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

Ter, 2004-09-21 às 08:34 +0100, Mark McLoughlin escreveu:
> 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.

  BTW, it would be nice to have the panel menu pickup newly installed
desktop files.  I really hate logout or killing the panel to see newly
installed applications in the menu.  It shouldn't, be too difficult to
just stat() 2 dirs (system + user) at menu popup time, and compare
modification times to see if anything has changed since last popup.
IMHO, this feature should receive higher priority than anything else you
guys might want to do in the panel for 2.10.

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.