Re: broken accelerator changes

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes: 
> it's not a good idea to have all keypresses propagate directly to all
> applications of that same type, as you might have temporary state in
> changing things here which you wouldn't want to propagate immediately
> (kinda like when editing an entry).

You may not agree, but the GNOME UI guidelines are that everything
instant-applies.

> so, you should actually propagate settings on demand (e.g. by pressing
> an "Apply" button in the config dialog), once you're there though,
> propagating accel changes doesn't require "a whole bunch of code",
> basically you dump the accels in one instance into a string and read
> that string back in in another application.

That makes the gconf representation unusable with
gconf-editor/gconftool, and makes it inefficient. You need a different
config key for each keybinding.

> nope, it's broken to limit accelerator changes to yet another menu
> API.

Accel changes need not be limited to a new menu API.

We can extend the accel map API to make it possible to easily write a
more generic accel editor, at least potentially; the accel map needs
notification of changes, and it needs human-readable names for the
accel paths. If it had those then you could edit it directly with an
accel editor dialog.

Right now notification of accel path changes involves a mess of code
to create a fake accel group full of fake accel closures, and a
reverse map from the fake closures to accel paths.

> gnome can have it's own default within some session wide configuration
> mechanism like the control center. it's pretty poor your going to disable
> this for RH RPMs though, as stated earlier, non-US users often _have_ to
> change accels for them to make sense, ignoring that fact is just stubborn
> blindness to demands of users of other countries.

I guess that's why KDE is so popular in Germany, and why Windows
offers no way to configure keybindings at all for most bindings.

Seriously, I have never gotten a request to add or fix this feature
for any app, that I can remember. I've sometimes gotten requests for a
way to configure keybindings, though.

Users can't find the in-place editing feature. If you want universal
ability to change keybindings, you need to provide it in a way that
users can find it.  The in-place-editing thing is not a solution,
because it is invisible.

If your argument is that some apps don't use the new menu API or don't
have the accel editing dialog or whatever, then we have to fix those
apps. Just because the in-place-editing feature happens automatically
for all apps doesn't mean it's solving the problem for all apps -
because most users do not see this feature.

Havoc