> IMHO you're missing an important point here: FLTK's cross platform > compatibility. If we would use native Fl_<something> widgets on one > platform, you couldn't derive your own widgets in a cross platform > way. My own application, for instance, derives own widgets from > Fl_Input and uses handle() to filter keypresses and does some more > things. What, if the Mac version would use a native widget "under > the hood" of Fl_Input?
Yes, well ideally the system part would be able to coexist with that. In the same way that fltk's compose feature is transparent to people extending Fl_Input, the IME should also be transparent. I would certainly expect a native text widget to be driven by the fltk event system, so you should still be able to override handle(). > Not to speak about identical behavior of the same app. on different > platforms, but that's a question that can't be answered generally. > Dependent on the user base, someone who has more experience on a > Mac would more like the Mac way, but someone who knows an app. on > Windows (or works with the same app. on different platforms) would > probably want it to behave identically on all platforms. I know that > there are reasons to add platform specific stuff (like system > menus, native file chooser, etc.), but probably better not in such > essential widgets like Fl_Input (and Fl_Text_Display/Fl_Text_Editor). Well, wrt to IME, I don't think anyone expects it to be identical on all platforms. An IME is a lot of work by a whole team of people, so I wouldn't expect fltk to ever have its own. So it's either use the system one or not be able to enter text at all in that language, so not so much a question of "different behaviour" but "exists or not". If it turns out to be not so hard to integrate the IME protocol with a non-native widget, then that's a good way to go. Otherwise I think the native version should be customizable enough to respond to the same configuration as the fltk one. But I'm not sure without looking more closely. Fl_Text_Display is in a similar position, since it's too slow to be usable. The combination of Fl_Text_Display and Fl_Text_Buffer presents a rather fat interface but hopefully it would be possible to tear out the complicated insides and replace all the "insert x text" methods with dispatches to the underlying system buffer. Again I don't know for sure without looking into it in detail, but unless there are intractable impedence mismatch issues then this would be a nicer approach to trying to maintain your own independent text rendering system. It may turn out to be more expedient to simply tweak the fltk version to make fewer expensive calls, but I feel this may merely delay the inevitable. As the "basics" get more complicated over time, they are taken over by the OS because it's too hard for each app or library to maintain its own implementation. This means libraries must move to a higher level, which has been a long term trend. The tricky part about a cross platform library is that different platforms move at different rates. But I think it can be done all the same. Maybe over-optimistic? _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
