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!
I haven't looked into exactly what would be involved to do this, but how about tearing out the whole "compose key" system for non-X (well, OS X at the moment) and replacing it with the system supplied one? Has it been considered and abandoned because of technical difficulties? Simply historical baggage and not tried because of lack of time? Some philosophical or design objections? 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). This may be much trickier to integrate, I don't know yet. An increased use of native widgets is certainly a change of direction for fltk, but as I see it using native widgets when available is fast and light because it completely removes code. It's probably not compatible with all the custom box drawing stuff and "themes" but that's another thing I personally wouldn't mind completely removing... _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
