Peter Verswyvelen wrote: >>> Several libraries define their own codes for they keyboard >>> (GLFW, GTK, GLUT, etc) >>> Maybe it would be nice to agree on a standard datatype >>> for keys? >>> ...The Windows API has virtual key codes for this.
I wrote: >> X windows key symbols... >> are found in the X11 package > But should we use X11 as the standard library then, > even on Windows or Mac? Certainly not. X11 has its own philosophy of key virtualization. You would likely encounter serious impedance mismatch on other platforms. > Maybe splitting these keys into a separate package would > be a good idea? No, they are an integral part of X. I would assume the same is true for WinAPI VKeys, and whatever the corresponding thing is on the Mac. That probably explains why each graphics framework defines its own concept of key mapping, to match its own concept of platform dependence. Here's an example: suppose you want ^C to be "copy" in your app. Well, what if the user currently has a Dvorak layout - do you really want ^C, or do you want the third physical key to the right of the left shift key? And what if the current keyboard layout is Russian - which Cyrillic letter should be "copy"? And what if we happen to be on a mobile device or a tablet? Etc. Each platform addresses these issues in its own way, so the concept of a "key code" doesn't necessarily translate directly from one to the other. I don't think that key binding is so complicated that it's impossible to come up with a reasonable "one ring that binds them all" library. But it's not so simple as just lining up key code charts with one another. -Yitz _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe