> 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?
Indeed, that was basically my idea too. I haven't really looked enough at the OS X libraries to know if it's practical but the idea is appealing in theory. I thought only OS X had the wrapping problem but if X has it too then yeah, that makes the case stronger for fixing the nedit code. Since it's all volunteer basis anyway, no reason to not do both, eventually :) I'll have to check out the latest build to see how the IME stuff works. Many thanks (once again) to Manolo! Another nice thing about a native input widget is that it's somehow more jarring when input widgets don't conform to platform standards than other ui elements. Even once I get used to the fact that the app doesn't do the native style menus or whatever, I still expect command-a to select all and get surprised when it doesn't. > Volunteers to implement this welcome! Eventually I will need a better solution for my app, so I'll come back to the UI side of things, but it'll probably be a little while. > (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!) make clean && make... if only it were so easy :) _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
