Re: gtk_window_get_accel_group()

[Karl Nelson <kenelson ece ucdavis edu>]

> On 27 Jun 2000, Havoc Pennington wrote:
> 
> > 
> > Hi,
> > 
> > Why not add an "accel_group" field to GtkWindow and then provide:
> > 
> > GtkAccelGroup*
> > gtk_window_get_accel_group (GtkWindow *window)
> > {
> >   /* Lazily create it */
> >   if (window->accel_group == NULL)
> >     {
> >       window->accel_group = gtk_accel_group_new ();
> >       gtk_window_add_accel_group (window->accel_group);
> >     }
> > 
> >   return window->accel_group;
> > }
> 
> there's no such a thing as the _one_ accelerator group for
> a window. things like menus (menu bars, popups) come with
> accelerator groups, or a set of buttons that you want to
> activate with keys. depending on which windows these are
> used in, their accelerator groups have to be added to those
> windows.

I don't understand why you don't want to allow a default accel
group for a window.  Yes, you should certainly allow more than
one accel group per window and there should be feature which
allows you do activate or deactive accel groups in mass.  However,
it at least in the case of gtk+ has been of some benefit to define
some functions which add a default accel group so that you can add 
accelerators for various functions to a class quickly.  Otherwise
you get the case that every little accel key must be made into its
own little accelgroup.  

> 
> using one accelerator group per window would provide quite some
> clashes, imagine two windows in an application that share a
> popup menu:

I don't think he was suggesting that there be only one per window,
just that having a window with a default one does not hurt.

> { "Select All         <C-P>",
>   "Invert Selection   <C-I>",
>   "Select None      <S-C-N>" }

> but have their own "Dismiss" buttons with <C-D> or menu bars
> with different items.
> within a window, accelerator propagation has to be done for
> the window's menu (or the "Dismiss" button) bar and the popup,
> and upon accelerator changes, clashes have to be resolved per
> window.
> so window one has e.g. "Undo Operation <C-Z>" and window2
> has "Zero Region <C-Z>" in their menu bars.
> with one accelertor group per window, you could use <C-Z>
> (or <C-D> for the button) for either of them but not both.
> that would be essentilly _one_ accelerator assignment space
> per window group that share accelertors for some reason (such
> as a common popup).

Okay here is where I thing the current accel model makes no sense
what-so-ever.  For gtk-- I had to practically rewrite the entire
thing so that I didn't need propagation method.

Instead of propagating the keypress though the accel group
we instead made an accel group for each menushell which contained
the navigation keys for that subwindow.  We placed the acceleration
keys in the toplevel windows default group (or we could have placed
a subgroup just as easily.)   I ended up doing this because quite
simply I could not figure out how to make accel groups work without
the item factory.  The method used by gtk-- is quite simple but gives
the same result of the item factory without the convolution.

Also why constantly add and remove an accel group to give and take
the keys away.  Wouldn't it be best to just have a gtk_accel_group_disable
and gtk_accel_group_enable?

--Karl