Re: broken accelerator changes

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Tue, 19 Feb 2002, Owen Taylor wrote:
> 
> > > - the majority of gtk+1.2 bug reports about accelerators have been
> > >   taken care of with the new code, we fixed conflict resolution etc.
> > >   there's no need to break runtime changes of them as some bugzilla
> > >   comments suggest, they were based on misunderstandings about the
> > >   bugs involved.
> > 
> > This doesn't correspond with my knowledge of the situation. There
> > were two problems:
> > 
> >  1) Accelerators were changeable in contexts where it didn't make
> >     sense.
> > 
> >  2) Accelerators were accidentally changeable by users.
> > 
> > We fixed 1). We didn't fix 2), and in fact, we made 2) worse since
> > as we agreed, we now always allow unmodified accelerators, where
> > we used to turn them off most of the time.
> 
> this is a somewhat odd line of reasoning, first you vote for extending
> changability and then for disabling the feature alltogether because it's
> impact broadened?

I'm saying, there are two types of users:

 a) Users who know about changeable accelerators, and want them
   to be active.

 b) Users who don't know about them, or don't want them to be active

If you mix these groups of users together, then you have to cripple
accelerator changing and still have a good potential for confusing
users.

> > In some cases, no-consensus-means-no-change is acceptable. In some cases,
> > it doesn't make sense because there _is_ a better answer, and it isn't
> > always what we did for GTK+-1.0.
> 
> disabling accelerators is _not_ a better answer. granted, it may cause
> confusion for new users, but it's not like we're causing unrecoverable
> damage to them, indeed deleting an accelerator via delete/backspace is
> pretty intuitive, once you figured that pressing keys on menu items
> affects the accelerator, so this is simply part of the inital learning
> curve in using a new operating system or toolkit.

This sounds like the adventure game theory of user interface. It completely
neglects the fact that the user may have no idea what they did to change
the accelerator at the point they discover they've changed the accelerator.
(Or that they may not even figure out that they changed the accelerator,
just that some keys,  key combinations stop working.)

> what weights far stronger here is that other users simply require changable
> accelerators to have usable shortcuts available. default-disabling that
> feature is a bad idea as it factually removes that feature for the majority
> of non-guru users, while they could cope with hitting backspace, they do
> not create ~/.gtkrc-2.0 files and put settings in there which are burried
> in a megabyte of API documentation.

Or going to a nice configuration dialog? If the majority of users can't
figure out to turn this on, they aren't going to be able to figure out
how to change their fonts or switch themes either. Perhaps in 2.0.1
we should ship a simple configuration tool for GTK+ users who aren't
running a desktop.

> > > - the "users might be confused by being able to change their accelerators"
> > >   argument is a weak one. first, they can easily remove their accidental
> > >   settings by pressing another key or backspace/delete which is intuitive
> > >   enough to be figured by people who know what backspace/delete are about.
> > >   second, users who already know gtk+ would be just as confused about not
> > >   being able to change accels anymore. and third, this argument has to be
> > >   considered in relation to non-US users not being able to facilitaty
> > >   accelerators at all, mild confusion about new users is the lesser evil here.
> > 
> > You think that the average user is going to make the leap from:
> > 
> >  - I can't type 'n' in XChat
> > 
> > To:
> > 
> >  - I need to open up my menus, find the one that I accidentally changed
> >    to have 'n' as the accelerator, and while holding the menu open,
> >    press backspace over it.
> > 
> > ?
> 
> if at all, then this is indicative for either not allowing non-modifier
> accelerators or to provide API for certain apps to disable this.

You would completely _break_ the GIMP if you disabled non-modifier
accelerators. And when the issue of an API came up, you didn't want
one. It's past time for API additions for 2.0.0.
 
> > > - at last, the "windows doesn't do this" is a non-argument, developers who're
> > >   out aiming at a clone of some MS windows version are better off joining
> > >   the KDE project, microsoft is not the end-and-all of it in all its
> > >   usability decisions.
> > 
> > Nobody is arguing that we should do mnemonic changing by default "because windows
> > doesn't do it." We're arguing that we shouldn't turn it on by default:
> > 
> >  - Because it is very confusing for users if it gets triggered by accident
> 
> it's still easy to unset, and for our current user base it's just as confusing
> to not be able to change accels at all anymore.

Most of our current user base:

 - Only has a vague idea of what GTK+ is, if it at all
 - Has no idea you can change accelerators dynmically

[ An unsustained assertion, yes, but one I'm pretty confident in ]
 
> shipping 2.0 without accel changing has a bunch of inaccaptable impacts that
> i'm not seeing you considering (beyond what i already mentioned):
> 
> - non-US users still need to change accels even with the new key hash, as that only
>   fixes some of the symptoms of locale dependant accelerator setups. 

Any properly designed app (and no, the GIMP isn't properly designed, though
it's very useable for experienced users) will have access to key items
using <Alt>F/S type mnemonic navigation. Which is what most users will
use for most menu items.

>   your own
>   email on the key hash change has the details on why we can't perform greedy
>   fallback match attempts.

While I can construct examples where this matters with some work, in practice
this just isn't an issue. 

> - the key hash can't account for accel setups which don't hold due to
>   menu item/abbreviation translations.

When we asked the GNOME translation teams, (GTK+-1.2 era) they've
said, they don't want translation of accelerators.... most accelerators
are reasonably arbitrary anyways.

> - application authors will not account for making their applications properly
>   deal with runtime accel changes, simply because they don't see and test
>   a feature that's there but not enabled.

I don't want to confuse users to avoid finding some other way of educating
application authors...

Let's get 2.0.0 out and then look at ways to:

  - Deal with the "I don't have a desktop, but want to configure GTK+" issue.

  - Present more explicit key configuration GUI's to users along the
    lines of what Havoc described. (Or as context menus on menu items
    as was suggested on this list a while ago.)

Regards,
                                        Owen