FLTK 3 will experience a couple of upgrades and changes. By using the wrappers, we can change FLTK 3 APIs and implementations without losing compatibility. Not all classes.need to be wrapped though. I don't know about these particular classes at the moment as i don't have a pc for 8 more days.
Manolo Gouy <[email protected]> schrieb: >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
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
