Hi developers,

I have prepared in development branch-1.3-Fl_Printer a new device hierarchy
according to the idea suggested by Matt. It's as follows, starting from Matt's
own description:

    Fl_Device
       |
       +-> Fl_Surface_Device
       |    | * points to a Window Manager  (not implemented)
       |    | * points to possible Graphics Devices  (one graphics device per 
surface)
       |    |
       |    +-> Fl_Screen_Device (named Fl_Display_Device)
       |    |
       |    +-> Fl_Printer_Device (named Fl_Paged_Device)
       |    |    |
       |    |    +-> Fl_System_Printer (named Fl_Printer)
       |    |    |
       |    |    +-> Fl_Postscript_Printer (named Fl_PostScript_File_Device)
       |    |
       |    +-> Fl_Bitmap_Device  (not implemented)
       |    |
       |    +-> Fl_Clipboard_Device   (added)
       |
       +-> Fl_Window_Manager  (not implemented)
       |      * points to a list of System_Windows
       |      * System_Windows can have their own Graphics Device
       |
       +-> Fl_Graphics_Device  (named Fl_Graphics_Driver as suggested)
            | * contains all FLTK rendering functions
            |
            +-> Fl_Bitmap_Graphics_Device  (not implemented)
            |
            +-> Fl_Cocoa_Graphics_Device  (named Fl_Quartz_Graphics_Driver)
            |
            +-> Fl_X11_Graphics_Device (named Fl_Xlib_Graphics_Driver)
            |
            +-> Fl_GDI_Graphics_Device (named Fl_GDI_Graphics_Driver)
            |
            +-> Fl_OpenGL_Graphics_Device  (not implemented)
            |
            +-> Fl_DirectX_Graphics_Device  (not implemented)
            |
            +-> Fl_Cairo_Graphics_Device  (not implemented)

 You can see the full Doxygen html doc of the API downloading
 
http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3-Fl_Printer/doc/html.zip
 unzippping it, and opening file index.html therein.

 You can checkout the source code with
 svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3-Fl_Printer/ 
Fl_Printer

>From Albrecht:
" Manolo, whatever you do, please try to avoid changing the class
hierarchy depending on the platform this time. A clean class
hierarchy is better than any trickery with #ifdef's and faking
something different for documentation (#ifdef FL_DOXYGEN). IMHO
it would be better to have all platform dependent classes on all
platforms, even if they are compiled to be "empty" implementations. "

The hierarchy is now much cleaner than before with apparent
platform-specific graphics drivers. But I'm unable to do a
universal hierarchy for the Fl_Printer class. It's still
a subclass of Fl_PostScript_File_Device for the Xlib platform
and of Fl_Paged_Device for others.
Any suggestion welcome to do better than that.

Another benefit is that new devices can be easily added to the
hierarchy without requiring changes to pre-existing classes.
This is illustrated with class Fl_Clipboard_Device that can be
removed just by not compiling files Fl_Clipboard_Device*.*

I would suggest to include this hierarchy in FLTK-1.3 because
the present one has serious defaults, and because this one
is ready for much further developments (e.g., completely
separating platform-specific graphics drivers, adding
GL driver). These developments could be done after the 1.3 release.


_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to