manolo gouy wrote: > The why is briefly explained in my other post "New hierarchy of > Fl_Device subclasses". > > The new hierarchy is : > > Fl_Device (all present and future devices) > Fl_Graphics_Device (Quartz, GDI, or Xlib depending on the platform) > Fl_Display_Device (above graphics system applied to display) > Fl_Printer (above graphics system applied to printing) > (Fl_Clipboard_Device -- would come here if it's adopted) > Fl_PS_Device (PostScript backend) > Fl_PSfile_Device (PostScript used in printing) > > > Fl_Abstract_Printer (a page-structured device) > Fl_Printer (a page-structured printing device) > Fl_PSfile_Device (a page-structured output sent to a local file)
What I would do is: 1. Put all the "printer" commands on the basic Fl_Device. For non-printers calling these can be no-ops or cause an assert, it depends on the function. 2. Instead of a subclass called "Fl_Printer", there would instead be an API called "give me the printer device". This will return a subclass of Fl_Device, programs should not have to care which one. Therefore if it is a subclass of the PS device on some platforms and the GDI device on others it does not matter. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
