Re: broken accelerator changes

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> hi.
> 
> the following change broke accelerator installation (again):
> 
> Sun Feb 17 21:30:49 2002  Owen Taylor  <otaylor redhat com>
> 
>         * gtk/gtkmenu.c (gtk_menu_class_init): Fix setting default.
> 
> @@ -259,7 +259,7 @@ gtk_menu_class_init (GtkMenuClass *class
>    gtk_settings_install_property (g_param_spec_boolean ("gtk-can-change-accels",
>                                                        _("Can change accelerators"),
>                                                        _("Whether menu accelerators can be changed by pressing a key over the menu item."),
> -                                                      TRUE,
> +                                                      FALSE,
>                                                        G_PARAM_READWRITE));
>  }
> 
> which i had recently fixed:
> 
> Wed Feb 13 13:26:39 2002  Tim Janik  <timj gtk org>
> 
>         * gtk/gtkmenu.c: fix figuring accel path and changing behaviour.
> 
> by setting the default to TRUE.

This wasn't accidental. I thought long and hard about whether to revert
you change to what I had checked in here, and decided my two options were:

 - Change it back, possibly starting a discussion on the issue

 - Quietly give in, fix the default in the Red Hat packages, and advise
   everybody else packaging GTK+ to do the same.

I didn't think that the second option really was honest and would still
end up with very many GTK+ users seeing things the way you didn't want.
 
> i can only reiterate the corner aspects of why it is a bad
> idea to break this:
> - for non-US users changing accelerators is an essential requirement
>   to use applications as their keyboard layouts are different and
>   application default accelerator setups are often unusable.

Requiring users to indivually figure out what accelerator changes are
needed to fix things for the keyboard seems a really poor way to
handle this.  The shift-level/modifier stuff I'm working on today
should help many of these situations.

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

> - gtk has offered runtime changes of accelerators since 1.0, and there
>   has been some arguing on gtk-devel on whether to change the default
>   behaviour or not. but since we have policy to not change behaviour
>   without consensus, the outcome of the related email and irc discussions
>   on this were to not alter behaviour for 2.0.

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.

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

?

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

 - Because even if you know what is going on, it's very easy 
   to trigger by accident if you use keynav. (I'm always accidentally
   changing accelerators in XChat.)

Regards,
                                        Owen