>> > - 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. _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
