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

[Tobias Anton]

> Yeah, switching one desktop environment is certainly
> simpler than switching one shortcut. 

Unless you are willing to take the time browsing the millions of config
options of KControl each time you updated KDE, the Windows CD might be
nearer at hand than the official KDE's user interface design guide.

Those changes that go into a few releases and are removed again later are
especially unwelcome in corporate environments, where for example many
people work with the same preinstalled configuration. Let a person-hour cost
50$, then a KDE update on an installtion for 100 people can quickly cost as
much as 15.000$, if the people complain for one hour, dig KControl for
another and finally get curious and start playing with screensaver settings
for yet another hour, only because a default setting was changed without
notice.

If this happens two or three times, the company will perhaps decide to stop
updating KDE or even switching to a more settled desktop environment, i.e.
where the expected rate of backward-incompatible behavioural changes is
lower. For example in Windows, most user interface concepts exist unmodified
since 1995, and if one was changed, it was always done in a
backward-compatible manner.


> Since we've done this already several times in the past one 
> kinda has to wonder how come we still have users.

Maybe we haven't been bold enough up to now. And, do you know how many users
we actually did lose because of that?

> No other modifier. Modifiers are so often used keys that using them 
> for something else than just being modifiers is asking for trouble. 

Come on. I have made a specific proposal. Your argument, however, involves
just a general rule of thumb that IMO is not even applicable here. Please be
precise: What problems do you see if the implementation would allow to use
the system as described? How would you do it and why would it be better?

Tobias