AW: AW: AW: AW: AW: AW: making fallback access keys configurable

[Tobias Anton]

> When I press Ctrl it could be for any number of reasons,
> not necessarily to activate access keys.

This is reflected by my proposal.

> If they learned a shortcut they can learn another one - 

Wrong answer. If they learned a shortcut they will most probably refuse to
learn another but rather switch the desktop system. Unnecessary removal of
established usage patterns is plain poor software quality. Ever heard of the
"fragility of user trust"? 

> one that doesn't get in the way of everyone else...

The functionality need not get in the way of anyone. We could reach a state
of unintrusiveness without changing the modifier, but you don't seem to
believe that. Why don't you? Which other modifier would you propose? There
are only 8 combinations of three modifiers, all of which are in use at my
machine.

> Well you get a windowDeactivated event, but this is all a special case,
> there are tons of other things that people can do with Ctrl+something.

Just as every case is and just as they can do with every other key
combination.

It is a perfectly clean solution to enter the accesskeys mode as a reaction
to ctrl being pressed as a key*, as long as the KHTMLView is focused and
unless the fallback accesskeys supersede any application-specific shortcuts.

Long ago, I had a similar discussion when I wanted to use Ctrl+Tab in KHTML,
which was not possible then because it collided with non-configurable key
bindings of KWin. The argument was: "The keyboard combination is taken, we
can't simply reassign it". Now exactly this argument holds here, too, and I
don't understand why you don't second this if your annoyance is taken care
of.

In a perfect world, eve

Tobias
*= in contrast to "as a modifier", which can be detected by the immediacy of
ctrl-press and -release