seventhguardian at gmail.com
Thu Aug 18 11:15:09 EEST 2005
On 8/17/05, Claes at work <claesatwork at gmail.com> 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?
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.
More information about the xdg