Owen wrote: >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. As I see it, and as the original X Window docs see it on my reading, Mod1 is NOT a key and Mod1 is most definitely not a position on a keyboard. Mod1 is a just a semantic-free tag bound by a user to a key. GTK doesn't make the definition that "Mod1 is Alt". It defines Mod1 as the modifier used for certain operations. I can bind another key to Mod1, and presto, it now does the same things that any other key bound to Mod1 does. There is no special relationship between Alt and Mod1 other than a convention that seems to have emerged in XFree86 and/or distributions that this should be the default binding when X starts up. That convention could be broken next week by XFree86 or a distributor and GDK could do (almost) nothing about it. >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.) i generally find persistent modifier keys to be more or less useless as modifiers. and in fact they quite often cause problems sometimes by confusing users: "why isn't this key working the way it used to?" (this is very noticeable in emacs; accidentally press numlock, and all of a sudden many of your finger-memorized keystrokes in emacs cease to work). >From Havoc: >On Sat, 2003-10-25 at 15:17, Paul Davis wrote: >> 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. > >The basic idea is to have applications refer to hyper and super, and >GTK+ deals with the whole which-modifier-bit-is-that issue. See what happened to meta? i personally think this is all semantics. X defined a number of modifiers and gave them meaningless names with no particular bindings specified. it feels as if what you're proposing is an identical scenario, only replacing the meaningless names like "modN" with ones like "hyper". until you go as far as windows or the mac does, none of this really makes life easier for users or developers. on those platforms, everybody knows that the key marked "FOO" does the job known as "foo". i know this task is much more difficult for linux, because of the diversity of the hardware involved. but i also think that replacing X's semantic-free, generic modifier names with GDK semantic-free, generic modifier names isn't changing the situation in any meaningful ways. owen noted that "hyper" etc. are to be considered "virtual modifiers", yet "mod1" etc. are already virtual modifiers that are specifically not associated with specific keys. i can't reliably tell a user that they should press <key>-<button1>, because X (and GDK) doesn't give me keyboard state along with button events. it gives me buttons and modifiers in the event->state field. until the key<=>modifier binding is defined and cast in stone, i still can't predict with true confidence what <key> will cause a certain bit to be set in the event->state field. and i note that the linux world doesn't even have a standardized name for the key engraved on most keyboards with a "windows" logo. is it "hyper", "super", "start", "windows", "logo" - i've seen all these names used. what key do i press to get mod5 or mod4? to be honest, none of this will likely affect me soon, because i think that ardour is going to adopt a radical new UI model from another system called protux [sic]. we're taking it a bit further, to the point that every key can function as either a mouse button (as one of the developers commented "no mouse ever has enough buttons") or can be a mouse button modifier. this requires that we track keyboard state ourselves, which we already do, and that we forget about the event->state field entirely (it won't contain enough information). that's why i mentioning this now, because i think that in a couple of months, i won't care anymore :) --p _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
