I've been trying to compile a real-size application with FLTK 3 using its FLTK 1 compatibility. Most things work remarkably well, except those parts that use application-defined drawing surfaces and graphics drivers. This appl. defines several drawing surfaces (Fl_SVG_File_Device, Fl_PDF_File_Device, Fl_Clipboard_Device) and graphics drivers (Fl_SVG_Graphics_Driver, Fl_PDF_Graphics_Driver, Fl_PICT_Graphics_Driver) so it can draw in SVG and PDF files and in the clipboard.
I have found that a very simple writing of the FLTK1 compatibility header files makes this appl. compatible with FLTK3: replace the entire contents of files Fl_Device.H, Fl_Paged_Device.H, Fl_PostScript.H, and Fl_Printer.H by these few lines #include <fltk3/Device.h> typedef fltk3::GraphicsDriver Fl_Graphics_Driver; typedef fltk3::SurfaceDevice Fl_Surface_Device; typedef fltk3::DisplayDevice Fl_Display_Device; #ifdef __APPLE__ typedef fltk3::QuartzGraphicsDriver Fl_Quartz_Graphics_Driver; #elif defined WIN32 typedef fltk3::GDIGraphicsDriver Fl_GDI_Graphics_Driver; #else typedef fltk3::XlibGraphicsDriver Fl_Xlib_Graphics_Driver; #endif #include <fltk3/PagedDevice.h> typedef fltk3::PagedDevice Fl_Paged_Device; #include <fltk3/PostScript.h> typedef fltk3::PostScriptGraphicsDriver Fl_PostScript_Graphics_Driver; typedef fltk3::PostScriptFileDevice Fl_PostScript_File_Device; #include <fltk3/Printer.h> typedef fltk3::Printer Fl_Printer; This completely bypasses the logic of FLTK1 compatibility employed for all other FLTK classes. But it's very simple. Is it acceptable? Before going this way, I had followed the way used for other FLTK classes, and defined classes fltk3::GraphicsDriver_I and fltk3::GraphicsDriverWrapper, and made Fl_Graphics_Driver a subclass of fltk3::GraphicsDriverWrapper. The appl. worked well too, but I dont see if there's a benefit in going the more elaborate way. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
