Re: setting gdk display



>> > - Support for modifiers beyond control/alt/shift, with some sort

afaict, there is no support for alt anyway. see below.

>> >   of "virtual modifiers" approach.
>> 
>> dubious unless you make it possible to interrogate what keycodes
>> and/or keyvals are bound to a modifier.
>
>? The real modifiers wouldn't go away; event->state would typically
>contain *both* the real modifier (MOD3 or whatever) and the virtual
>modifier (Hyper or whatever).

the specific problem with the relationship between keyboards and X
modifiers is that X imposes no policy on bindings. its become "normal"
for Alt to be bound to mod1, but there is no requirement that this be
true, let alone that Alt_L and Alt_R should necessarily be the same
modifier.  documentation for all X programs these days talks about the
"Alt key", not the "mod1 key". if you want to do the right thing in a
program, you need to know about the mapping between these. perhaps you
are suggesting that "Alt" would be a virtual modifier, which is not a
bad idea. there still needs to be something that binds the key
engraved with "Alt" to this modifier, however, and its not necessarily
true that it will be have been run for any given execution
environment.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]