On Sat, 2003-10-25 at 15:17, Paul Davis wrote: > >> > 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. The definition that GTK+ makes: MOD1 *is* Alt (the modifier used for accelerator bindings, etc.) works much better than any attempt to look at the keysym does. Everybody wants Mod1 to pop up their menus, virtually everyone has Mod1 immediately adjacent to the spacebar. But sometimes that key is Alt, sometimes it is Meta. Alt would not be a virtual modifier, because that just creates more problems than it solves. The interesting virtual modifiers are Super and Hyper. (We'd also have NumLock and ScrollLock because they are easy to do, if less useful.) Regards, Owen _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
