> I can confirm that in OS X the IME does *not* work. Yes - I did a lot of the early work to support UTF8 on OSX in fltk, and I didn't understand how the OSX IME was meant to be hooked in, so I suspect all of that is essentially missing...
Unless Manolo, who has done a lot of good stuff in the OSX layers, has managed to fix that up at all? > 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. I did a little testing way back when, and (ignoring the wrapping problem) the slowness is substantially worse on OSX than on other hosts. I think (but am not sure) that we "rescan" far too much text, maybe even the whole block, in the text widgets when we redraw them, and that this accounts for the slowness. If we could contrive to only "rescan" the text that is visible (and some suitable boundary before/after the visible segment) I think it would be much faster - this is the way nedit was supposed to work, but we don't seem to have got this right... Or I could be talking nonsense again. > 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. Supporting native text widgets would be one option - but how would this work cross-platform? I guess for X11 hosts we'd stick with our own nedit-based widget since there is no "native" widget there, so we need to fix the wrapping issues anyway for that use-case. For OSX, the native widget would bring a lot of advantages but might be tricky to integrate into fltk in such a way that the API would look like the fltk API... Not sure what to do about the winXX hosts - I don't much like the MS text widgets, but they certainly could be used like the OSX ones... I don't know what's best. So... Rather than outright replacing the nedit based widgets, we would perhaps add an Fl_Native_Text_[widget] family, which on OSX (and maybe winXX) would wrap the OS widgets, in much the same way that FNFC does, and on X11 would fall-back to the nedit based widget as at present. I imagine that Fl_Native_Text_[widget] would only expose the minimum lowest-common-denominator API, not the full API we currently expose for the nedit widget. Anybody who needed fancy control of the widget would acquire some suitable "handle" to the widget and them use platform specific coding using the native API. Something like that? Volunteers to implement this welcome! (Now I Have to go meet the builders again - work is "ongoing" at the house, but we are having issues. Very old buildings can be tricky!) -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
