Hi all, The following are my thoughts (for what they count) on the issue, (from a 2.0 standpoint!)
> THE STATUS > ============ > > I converted the FLTK1 source code into FLTK3 namespace and added a tiny bit > of FLTK2 code. The result is a fully working virtually bug free version of > FLTK 3 (which at this point is FLTK 1 in new clothes). > > I added a wrapper that makes FLTK 1 source code compile with the FLTK 3 > library. This is a true wrapper, not just some #define list of new names. I > have started a very minimal wrapper that makes FLTK 3 source code compatible > to FLTK 2 as well. To verify the effort, all FLTK 1 tests compile and mostly > run in this wrapper mode. There are still a lot of bugs though! > > > THE FINDINGS > ============== > > a: FLTK 1 and FLTK 2 are still quite similar in their basic structureFWIW, > this point can work majorly in FLTK3's advantage, if it is decided that we > keep both the 1.x and 2.x compat layers (and depending on the coding approach > taken). To this end, only a fairly small part of the code really needs to be > added and changed - the rest can almost just rely on the 1.x compatibility > layer, as this is what a major section of the 2.x code currently does anyway > - it attempts to just be 1.x with flashy new names. > b: there are some differences that make life hard - if those features were > usedWell, assuming all of us get on board, many hands etc. etc.> [snip] > I want to get an idea if FLTK 3 is worth the effort, and if we need the F1 > layer and/or the F2 layer. IMO, it's worth keeping (or at least attempting) the 2.x layer. Even from these mailing lists, I've seen enough interest and use in 2.x to probably warrant this attempt, and I'd imagine there are other users out there who don't follow these lists that also use it for their programs. At the very least, it makes it easier to coerce users to follow the development train! > So here are my options: > 1: keep F1 and F2 development active, forget about F3I feel that things > need to be joined back together. If FLTK is ever to take off as a viable GUI > toolkit for large-scale use, there needs to be one clean option that everyone > here supports and follows, not a myriad. > 2: abandon F2, continue with F1, forget about compatibilityIt's probably > time for a fresh start in terms of getting everyone back together. Plus, lack > of compatibility could also force current users to abandon FLTK due to old > code being un-maintainable. > 3: abandon F1, continue with F2, forget about compatibility See above. > 4: merge F2 into F3, forget about the compatibility layersSee the second > half of answer 2. > 5: merge F2 into F3, continue with the compatibility layers In terms of the workload that it will create, this is no doubt the least enticing option, but I feel that in terms of keeping the FLTK community together it's probably the best one. Plus, with all of us (hopefully) on board, it shouldn't be such a difficult proposition either.Maybe that's just youthful optimisim.... Whilst the above are from a very 2.x-biased standpoint (being a 2.x developer and all), it is really probably the best way to get everyone back together. It also saves a tremendous amount of work for us all - there are bug reports that exist for 2.x that aren't fixed (or critical, for that matter) for the 1.x tree (because of the large codebase that has been borrowed/taken from 1.x) and there are a *bucketload* of bugs in the 2.x branch that have already been fixed in the 1.x series. All of us working on the one branch together means we can all find these bugs and fix them -- and then start moving FLTK forward for the benefit of everyone. 2.x made an attempt at the whole compatibility thing (a relatively poor attempt, but an attempt nonetheless), but really the best way to go about this from here is really with a clean tree and a whole pile of enthusiasm. Regards, Ben _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
