Roman: >I believe that it is important that it should be possible to change > underlying "device" (at least these which are relevant) not only at > link time but also fast changing device at RUNTIME ...
This is an example of what we are thinking about with dynamic library loading support (see my previous post). Roman: > Pure "C" library would have advantage that it would be easier to > use/link in other projects. "C++" has some nice syntactic-sugar... It is one of our major goals to approach the abstraction with same "building blocks" concept that the FLTK widgets are built around. Roman: > However these few new features MUST be implemented for existing platform > devices so that fl_draw.H should be the ONLY required api for fltk core > widgets as existing fltk code is much faster/smaller than cairo one. This is exactly the thinking behind the wrapper. The wrapper would control how and what low level functions are exposed to the widget layer. This allows the lower level api to be as granular as necessary to achieve consistency across platforms. I'm fairly sure that the wrapper will expose some new functionality not currently used by the widget layer, but in no way require it's use. Any new functionality would form the basic building blocks for creating new types of classes/widgets. Thanks, Gerry _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
