Re: broken accelerator changes

[Tim Janik <timj gtk org>]

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?

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


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

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

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. your own
  email on the key hash change has the details on why we can't perform greedy
  fallback match attempts.
- the key hash can't account for accel setups which don't hold due to
  menu item/abbreviation translations.
- 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.
- some applications (the gimp, beast) will implement their own hackery to
  enable runtime changable accels by default because their users need it
  and are used to it. this leads to gtk+ applications behaving inconsistenly
  and probably session/desktop wide settings to not take effect in some
  applications.

> 
> Regards,
>                                         Owen

---
ciaoTJ