> We developers all don't want to have another "dead" project like > FLTK 1.2 and now obviously also FLTK 2, so that we should be > absolutely sure that > > (a) the code is okay and works as expected > (b) it is the right way to go > (c) it is possible to extend it later > (d) it is accepted by the developer community.
This is about the Fl_Device abstraction layer, in effect, rather than printing support in general? I think it is the right way - I thought that way back when Roman started on his original experiments... So on that basis, I'd say we want to do it. But... Do we want to do it for 1.3 though? I can not say. If we go with the current implementation, is it extensible enough for things we have not thought of yet? Will adding to it break the ABI in some nasty way if we have to change it once 1.3 is out? I assume that "routing" everything through virtual methods buys us some flexibility here (at a slight performance hit) but...? And I need to test the offscreen behaviour is still OK, as I use that a fair bit... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
