On 8/17/05, Claes at work <[EMAIL PROTECTED]> wrote: > > The bottom line is that I think keys need to be configurable to suit > > different environments and user habits. Deciding that some common key > > combination MUST always be used for this and that will always create > > new problems for someone I believe. > > I also believe keys needs to be configurable, but I would prefer not > remapping single conflicting keys in individual applications. It would > be better if "modifier keyspaces" could be assigned, to avoid > conflicting behaviour between WM/Application/legacy keybindings. Such > modifiers could have standardized symbolic names, which are mapped to > physical keys separately. > > For example, the modifier key for application shortcuts would not be > tightly coupled to Control. Perhaps toolkits and applications could > check the environment for a specific environment variable to see what > key should be used as the application "command" modifier (name > borrowed from Mac here) , and if it is undefined, settle on Control_L > or Control_R as default? > > So setting "COMMAND_MODIFIER=Control_L||Control_R" would give current > behaviour, and setting "COMMAND_MODIFIER=Super_L||Super_R" would give > "non-conflicting" behaviour, using the Win key. On Mac hardware it > could be mapped to whatever the Mac control key returns, and if you > have Sun hardware, you can use something else. > > It may seem like a bad idea to introduce more configurability, but I > see this suggestion mostly as a transition mechanism. If such a check > was built into software from now on, perhaps in two years time it > would give a consistent behaviour if this variable was changed? > > Claes
I like your idea, and I believe some WM's already can do that (well, fvwm can do almost anything..), so there shouldn't be no problem implementing a "test system". Also, kde, for instance, currently offers a configurable interaction scheme. So windows users can use the windows shceme, while unix users can use kde shceme, etc. That could be extended to support the proposed modifiers definitions. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
