On 14 Feb 2010, at 1:18, Evan Laforge wrote: > So from looking around in Fl_cocoa.mm I couldn't help but notice fltk > has this whole complicated system for handling non-ascii text input > that seems to be incompatible with the system provided one. That > probably made sense for X which has (or had, I don't know about now) > no system of its own, but it seems counter productive on OS X and > windows. The result is that I know how to type in chinese on every > app on my system except my own... the fltk one!
Is it not the case that the whole "compose key" is largely independent of the "proper" input of non-LGC languages, though? Hmm, that question seems opaque now I read it back; I'll try and ask it again but making more sense this time... Using fltk-1.3, on linux and win32 systems, when I want to input Japanese or Chinese text, for example, I invoke the host system's IME and enter text in that. The IME then sends the composed UTF8 sequences to the foreground (fltk) window and all seems to be well. Fltk's own, historical, compose key mechanism does not seem to me to be involved (indeed I suspect that mainly handles the typing of LGC glyphs that don't appear on a your keyboard, e.g. me typing ß on a UK keyboard that has no key for it...) I am not familiar with the Apple IME, so don't know if that works - I assume that it does, though? Or are you saying that it does not? > In fact, it might be nice to completely replace the text input widgets > and get standard editing commands in the bargain (I'm always surprised > when command-a doesn't select all). Hmm, CMD-A seems to work for me on this Mac (just tried a few simple widgets though.) Where is it failing for you? -- Ian _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
