> Mac OS gives access to, in Cocoa parlance: > - keyCode, the rank of the physical key that was hit; > - characters, the text emitted by the key, which is the source > of Fl::event_text(); > - charactersIgnoringModifier, which gives the text of the key > without ctrl, alt or cmd modifiers, but which (unfortunately may be, > and contrarily to X11) doesn't ignore the shift modifier; > > Fl::event_key() could be built from the keyCode data, but then > one would loose any non-US keyboard remapping: press A on a French > keyboard, and get 'q' in Fl::event_key(). > > Fl::event_key(), therefore, is built from the charactersIgnoringModifier > data, with an additional trick that removes the shift, if there is one, > when the key is alphabetic, and puts a digit when a digit key > is pressed, even if the unshifted key doesn't return a digit > (as occurs with French keyboards). > It's not possible to apply this trick to non alphabetic nor numeric > keys without having FLTK know all national keyboard mappings, which > is not reasonable. > > My view is that Fl::event_key() is to be used only to detect/process > non-textual keyboard events (e.g., function keys, new-line, arrows, > backward or forward delete, escape), and if not, to use > Fl::event_text() that is very reliable.
Yeah, my guess was also that if you have some symbol, there is no general way of knowing if it's shifted or not, and of mapping it back to its unshifted form. Short of having maps for all the keyboards you use. I previously had lots of problems with Fl::event_key(), but they were probably bugs which have since been fixed, since it seems pretty reliable now. But one issue is that it's still inconsistent WRT symbols. For instance, on my keyboard, shift-/ yields shift-?. But shift-cmd-/ yields shift-cmd-/. It's not a disaster, but it means the keyboard mappings are a bit weird (i.e. the user has to know about that quick, lest he try to map cmd-? and wonder why it doesn't work). I agree fltk can't go building in a symbol map for every single keyboard but my app can do so for the small set of keyboards that matter for it. I imagine shift-cmd-/ is just what OS X gives you, so there's not much else fltk can do, but this is the sort of fiddly detail that a cross-platform library should really try to make consistent, or at least document well if that's not possible. Maybe there's an OS API to get physical keyboard layout, since there are other cross platform programs out there that bind commands to keys. I'll dig around a little and see if there's anything obvious. For me, I still think Fl::event_key() is appropriate, because commands are bound to unshifted/shifted pairs, and even if your keyboard puts symbols in different places I'd like the pairs to remain on the same keycap. But if I'm resigned to adding my own symbol <-> shifted symbol mapping anyway, I can use that with Fl::event_key() to get the X11 behaviour under OS X. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
