Re: [gtk-list] Re: Dynamic Menu Help

Raph Levien wrote:
> I ended up using menus directly in Gzilla, rather than using the menu
> factory. One problem with menu factories is that individual menu labels
> cannot contain the '/' character. I also needed to deal with dynamically
> creating new windows, each with its own menu. I found that menus are not
> actually difficult to program. The main thing I gave up is the .menurc
> capability. If I found I needed that, I'd probably add capabilities to
> menufactory to escape the '/' character when needed. (now that I've got
> commit privileges in Gtk, I needn't be so careful to always do things in
> a way that doesn't affect Gtk itself)


I haven't used the GTK menu factories yet, but I think they could be
implemented to eat less memory. For now, we have

{ "File/New/New Window", "<control>W", .... },
{ "File/New/New File",   "<control>F", ... },
{ "File/New/New World",  "<control>L", .... }

/* I'm writing this from memory, so please ignore the bad syntax */

First thing that pops to my mind is memory usage: substring 
"File/New/" repeated 3 times here. I know, I know, this wastes just 
some 20 bytes, but... what if I have loads of menus? And why waste 
them bytes anyway? The second thing is the modifiers in the 
accelerators. Similar thing: why not use "ctrl" instead of "control"?
Or probably even get away with "&", "@" etc. prefixes in the menu
entry name? (One might argue that this brings down the readability

I think that a quite good way to implement an alternate menu
factory would be this:

struct menu_entry {
    const gchar *name;
    struct menu_entry *submenu;

and in the program you go:

struct menu_entry file_new_menu[] = {
    { "&Window", ... },
    { "&File", ... },
    { "Wor&ld", ... },

struct menu_entry file_menu[] = {
    { "&New", ..., file_new_menu },
    { "&Open", ... },
    { "&Save", ... },

struct menu_entry application_menu[] = {
   { "&File", ..., file_menu },
   { "&Edit", ..., edit_menu },

This approach would probably make the menu factory more dynamic,
i.e. more alterable during runtime.

What do you guys think?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]