MacArthur, Ian (SELEX GALILEO, UK) wrote: >> 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?
Yes, more or less. The Fl_Device abstraction layer is the harder part, whereas the printing support is a simple addition that "works or not". > 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. 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. > If we go with the current implementation, is it extensible enough for > things we have not thought of yet? Never. IMHO. This will never be given. We must live with it. This means that new devices or other greater changes will probably break the ABI, and we will need to release a new 1.x (or 3.x) version. See below for more. > 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. > And I need to test the offscreen behaviour is still OK, as I use that a > fair bit... I don't expect anything wrong with this, but better testing it now than later... Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
