Re: New keybindings draft

[Tim Janik <timj gtk org>]

On 1 Apr 2001, Owen Taylor wrote:

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

i'd rather have them say "wow, cool" even including a
preceeding "@#!#!$" experience, than forever letting them
stay in their constrained everything-behaves-like-windows
view of the world.
besides that, i don't mean to screw experienced gtk+ users
of which we should have quite a few at this point.
so for users like chema who really dislike this, i want
to reply "read the FAQ on how to opt-out" and be done.

besides that, for non-US-keyboard users, many accelerators
are useless untill you rebind them, though we'll improve
that situation, you know we can't 100% solve it.

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

waitasecond, this later thing is a matter of control-center
defaults, i'm not talking about that but just the internal
gtk default.

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

there's only a problem if a program comes with an M-F mnemonic
and a locked M-F accelerator (on why, read below), and that's
essentially a programmer error.

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

you mean accelerators conflicting with mnemonics. yes that is right,
but you hopefully remember the outstanding todo item i mentioned
to alex "need support to list mnemonics of windows" and my personal
one from last weeks irc sessions "fix accelerator negotiation".

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ