>> In each case, the environment pops up a little input window for the >> input to go into, and it then gets passed to the app. This sort of >> worked OK, though the pop-up is maybe meant to be modal for the window >> receiving the input and I'm not sure that worked right on my ubuntu >> trials. Also the pop-up window seemed to have the wrong "decorations" >> and I couldn't figure out where it was meant to be placed - it popped up >> in what seemed to me to be the "wrong" place. > > I can confirm this. I remember that I tested the Windows IME support when I > fixed a bug (but Windows (XP) only). I remember that the IME popup window > appeared at the "right" place (as I expected) in normal Fl_Input widgets, but > not in multiline input widgets (they appeared at the wrong line or character > offset). I tested with Japanese characters, and all seemed to work well (as > far as someone who can't even read Japanese can tell ;-) ).
Interesting! The candidate window must exist at a lower level than the input widget. I can confirm that in OS X the IME does *not* work. BTW, the other motivation for me to want to use the native text widget for OS X is that the fltk 1.3 one is too slow, and wraps incorrectly. There's a STR for this, but no one (including myself) seems eager to get into the text display code, so I figured trying a native widget could kill two birds with one stone. The second one is actually the main showstopper for me so when it's time to start hacking fltk I'll likely start because of that reason, rather than the IME reason. Of course simply fixing the text display to not be slow is also a perfectly reasonable approach, but it wouldn't solve the IME problem. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
