MacArthur, Ian (SELEX GALILEO, UK) wrote: >>> Do we want to do it for 1.3 though? I can not say. >> Yes, that's the main question. We have some kind of catch-22 >> situation: >> We can't get full (PS) printing support w/o device abstraction, but we >> must be sure that we want it (now). Last Friday we didn't have it at >> all, but Manolo's great work gave us the opportunity to use it now ... >> >> As it is now, it would also be more difficult to roll it back and use >> the partial printing support (w/o PS printing), because this would >> need more sort'n'merge work (cherry picking) than the full blown >> current printing branch (a simple merge with the main branch would >> do it). That's why I would like to get a decision ASAP, before we >> (mainly Manolo) add more work in a branch that won't be used, or that >> needs to be done again later. > > Though I doubt any work Manolo checks in will be wasted - it may just > have to wait for 1.4 / 3.0 / n.n before we actually deploy it.
Yes, of course, as "the work" it will be there, and it can wait... But the longer we develop other things in the FLTK 1.3 branch, the more difficult will it be to apply the changes to the main branch. > For example: Roman's original Fl_Device stuff has been waiting for a > good while now, but it seems that we have reused a lot of it this > time...? Reused: maybe (at least all the _new_ stuff like PS printing). But IMHO the base work on device separation/abstraction was mostly hand work. But we should ask Manolo about this... >>> 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...? >> Yes, some additions will break ABI compatibility for sure. If we add >> new device capabilities (e.g. Cairo drawing) then this will probably >> need some new methods or at least more status info (member variables) >> etc. that didn't exist before. This will probably need to extend the >> base class, maybe Fl_Device and will introduce member variables and/or >> virtual methods - and that *will* break the ABI. > > So we can not have a 1.3 release based on this, that we are confident > will be ABI stable? > Or am I missing the point? Maybe? IMHO, the point is: as long as we go on developing like in FLTK 1.1 with moderately adding new (non-virtual) methods, this would be as (ABI) stable as it was with FLTK 1.1. But we had long standing RFE's (and maybe some bugs) that could not be implemented/fixed because of ABI stability. Note: The FLTK 1.1 branch was started in Aug. 2001, FLTK 1.1.0 was released in Oct. 2002, and FLTK 1.1.10 in Dec. 2009. That's a long time of ABI stability. If we release 1.3.0 with the current or slightly modified Fl_Device abstraction and don't touch it in any ABI breaking way, then we can again have 8 years of ABI stability. But if we want to add functionality after the 1.3.0 release that would involve e.g. extending Fl_Device (adding member variables and/or more _virtual_ methods), then this would break the ABI. And since Fl_Device only has virtual methods ... The consequence would be to have better planning, a roadmap for ABI changes, shorter release cycles (with changing minor version numbers like 1.x) and (as before) the possibility to break the ABI with each minor version number change. IIRC this was all on our roadmap anyway... :-) Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
