Re: #52434 - Lock accelerators by default

Tim Janik <timj gtk org> writes:

> On 21 May 2001, Owen Taylor wrote:
> > > 1) support accel locking globally throguh rc-files
> > > 2) runtime accel changes on menus honouring mnemonics in conflict resolution
> > > 3) default locking of menuitem accelerators that got no accel group
> > >    through item factory (or equivalent mechanism)
> > > 4) nuked the global default accel group (NULL)
> > 
> > I don't really understand. What are you saying we don't need?
> a lock-all-accels-on-this-widget flag, rather i don't understand
> why you want it.

The flag is not new functionality. It's just reimplementing 
gtk_widget_lock_accelerators(), but doing it without the two
signal connections.
> > 1) This patch adds a GtkSetting for this
> > 2) Doesn't seem related.
> well, it's one of the problems that people run into that might
> cause them to want per-widget accel locks.
> > 3) How do you find out if a widget has an accelerator or not? (Other than
> >  checking to see if accelerators are locked for the widget or not.)
> that can be determined from whether the item factory handles this menu
> (and tehrefore if accel changes can be saved).
> havoc outlined this on gtk-list (and maybe on gtk-devel even).

If you want to say that changing accelerators can only ever be handled
by the item factory, then sure you could do it that way. I'm not
going to complain.
> > 4) Doesn't really seem related.
> it is, without a default accel group currently runtime
> changable menuitems that don't have an accel group (e.g.
> from an item factory) wouldn't be changable at all.

Whether the menu item has an accelerator group or not is not really
the important issue. You can have accelerator groups without
having the necessary code to make changing accelerators meaningful.

(E.g., BonoboUIHandler)


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