Probably the best starting point is abstraction of fltk drawing functions/primitives as it is relatively easy just by removing #idfef-s, later adding abstraction to input devices and "event sources". So I will focus only on drawings in this post.
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 eg by changing the pointer to the function table or the pointer to a class instance for "C++" implementation mentioned below. This run-time change would also allow: - printing capability and output the fltk drawings to pdf/postscript/svg/(insert alternative fornmat) or through a cairo device to any format known by cairo - switching to OpenGL device eg when drawing widgets within OpenGL window/context > We've started digging into the abstraction layer task. We need a naming > convention for the abstraction layer code. We are considering a file/function > prefix of fal_/FAL_ (FLTK Abstraction Layer). The plan is to create a C api > that will represent the abstraction. If fast runtime device switch should be available, the "C" implementation would require some function pointer table. This is effectively the same (also performance-wise) as lookup through vtable of virtual functions in "C++" class abstraction implementation. Such abstraction attempt is available in obsolete branch 1.2 where the abstraction is performed through Fl_Device class where the platform-specific code is implemented within the virtual functions of the subclasses. Pure "C" library would have advantage that it would be easier to use/link in other projects. "C++" has some nice syntactic-sugar eg you can easy extend existing device - like for printing device you can add paging, page positioning/scaling (or whatever additional capability particular device has) as additional methods. > We also plan to move platform specific files to their own sub-directories > under the src directory (ala FLTK2). The goal is to end up with a well > defined api that can be used to create other ports. Each port would > implement the FAL api interface as a separate library (ie; libfal_win32 > etc.). Yes, and this is also similar approach to src/xlib src/win32 src/carbon src/psprinter src/gdiprinter directories in fltk-1.2 although the makefiles did not yet build devices as separate libraries (most of the files from these directories were just included from another files not to break makefiles from the start). > This would actually be a two layer abstraction. The platform api and a thin > wrapper between the platform api and the widgets. This will provide some > additional insulation in case the platform api would ever need to change. I do not think that widgets require additional abstraction. The exception are Fl_Image classes where drawing is implemented in draw() methods of Fl_RGB_Image, Fl_Bitmap and FL_Pixmap. I think platform-specific code should be removed from these image classes: we already have fl_draw_image(), fl_draw_pixmap() functions which do essentially the same so we should add something like fl_draw_bitmap(), do some cleanup and just redirect the image drawings to Fl_Offscreen and use these external functions during building the image caches. Things like colour averaging, desaturation and even scaling (bilinear interpolation would probably do better job that closest neighbour method used now) can be done by "chaining" relatively simple callback functions passed to the above mentioned fl_draw_*() functions. > > Why separate libs? > > This would allow someone to work with a particular port without the need to > worry about the other ports at all. We believe this will lead to better, > cleaner, and lower maintenance code. This would also serve to isolate > programming errors. Amen. > > Why an additional wrapper? > > Over time, the various ports will continue to evolve. OS updates, new > features, api changes, etc. These types of changes are being driven by a > particular port and not the widget library. This will provide some additional > flexibility to accommodate these changes without impacting the widget > library. If the API abstraction border is chosen at the level of fltk primitives (essentially what is in fl_draw.h) then there should not be necessary to define additional API abstraction level because that is all what widget use. Should more reach possibilities be required, with any additions I would go close to cairo API because this itself is the abstraction level which already has implementation for many platforms/formats so generic "cairo device" can be used as a base for additional ports. 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. R. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
