Re: New keybindings draft

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 2 Apr 2001, Sven Neumann wrote:
> 
> > Hi,
> > 
> > Chema Celorio <chema ximian com> writes:
> > 
> > > I think this is a very non-user friendly feature of gtk
> > > and should be turned off for non techie users.
> > 
> > > This can be a big problem for a newbie since he has no clue
> > > what is going on. Personally i don't believe people shuold be
> > > able to set accelerators for their application, things work
> > > much better if there is one place where we define this.
> > 
> > I disagree. For The GIMP with hundreds of filters this feature
> > is a must-have. What I'd like to see is a way to hook into the
> > process of reassigning a shortcut so the application can tell
> > the user that it she is about to assign a shortcut that is 
> > already in use. The user could then decide if she wants to continue
> > or cancel that operation. Eventually this feedback dialog should
> > be in GTK+ itself.
> 
> i also disagree, strongly even. while i'm with havoc on having
> an rc-file property to be able to turn this off, the default
> should definitely be on, so as offer users opt-out, not opt-in
> behaviour.

Is it better for:

 - User to accidentally change keybindings, have things not
   work, figure out 3 weeks later what they did, either
   say @#!#!$, or "wow, cool".

 - user to see option in control center, "Allow dynamic menu
   changing", hit the help button, see an explanation, either
   "what a useless feature", or "wow, cool".

Despite the phrasing, above I'm not sure. I'm not a big fan
of lots of obscure config options. If something is the right
way thing to do things, its probably always the right thing.

> as for hooking into reassignments, there are two problems i see
> with this:
> 1) you can hardly popup a dialog while a menu is popped up (keyboard
>    and mouse are grabbed)
> 2) you would have to connect to every menu in the app to catch
>    all reassignments.
> 
> i'm pondering about a singleton in 2.2 to maintain accelerator
> bindings and serialization of them, that would get rid of (2),
> however i don't see an easy way to solve (1).

This makes me think of a problem I should have brought up
while debating when we were debating whether mnemonics are
accelerators. Currently, a user can set up an accelerator
for M-F, it will be displayed, but (assuming the order
we agreed on), it won't be obeyed. 

That is, because mnemonics are no longer locked accelerators,
there is nothing stopping the user from setting up conflicting
accelerators dynamically.

Regards,
                                        Owen