Re: gtk_window_get_accel_group()

[Tim Janik <timj gtk org>]

On Wed, 28 Jun 2000, Karl Nelson wrote:

> > 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.  


i'm not against creation of a default acel group per window, as you,
owen and havoc outlined, it does make quite some sense. i was
mislead by havoc suggesting gtk_window_get_accel_group () to have
_the_ accel group of a window, which is why i responded with

> > there's no such a thing as the _one_ accelerator group for
> > a window. things like menus (menu bars, popups) come with


> > 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.

yeah, fine, so we can have gtk_window_get_default_accel_group().

> > { "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.

then your code is broken. you will either allow the same accelerator
be installed multiple times in windows that share menus (maybe even
in the same window) and/or not auto-update accelerators for
equal menu items in other windows which have own instances of
such menu items.

> 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

inside menushell navigation is handled by gtk_menu_get_uline_accel_group()
and the GtkBinding mechanism, you shouldn't have your own accel group there.

> 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.

i bet that's not the case. in fact, i'm 100% sure you got it wrong,
simply because the propagation is required. the solution for you is
to actually use the item factory, as i pointed out to you at earlier
occasions. you don#t have to literally create your menu items with
the item factory to make use of it (in fact you probably wouldn't want
to), the propagation stuff is seperated, use:

void            gtk_item_factory_add_foreign        (GtkWidget      *accel_widget,
                                                     const gchar    *full_path,
                                                     GtkAccelGroup  *accel_group,
                                                     guint           keyval,
                                                     GdkModifierType modifiers);

like e.g. libgnomeui does it. with that, you also get to use

void            gtk_item_factory_parse_rc           (const gchar    *file_name);
void    gtk_item_factory_dump_rc        (const gchar            *file_name,
                                         GtkPatternSpec         *path_pspec,
                                         gboolean                modified_only);

like every sane gtk program should (libgnomeui handles this automatically
for the programmer).

> 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?

gtk (and gtk programs) isn't removing accel groups on the fly.
i don't quite get your point here.

> 
> --Karl
> 

---
ciaoTJ