OK, this is my private view from a person using 1.x and tried a few times fltk2 - but never got impresses too much.
I would give fltk 1.x a chance to improve, maybe breaking more often binary compatibility (1.4, 1.5 ...) but keeping source compatibility intact. If there is great desire to move to 2.0 api please try to keep 1.x compatibility layer as close as possible - to the degree that great majority of custom widgets, custom draw() and handle(), custom boxtypes, images ... would work without change after recompile. I would definitely start from solid stable 1.x base, gradually moving compatible bits to fltk:: namespace with typedef(s) to Fl_* . If there is much better alternative solution with real benefit but impossible compatible implementation, I would not be afraid of certain redundancy and double implementations where new fltk:: version could behave differently than old fl_* or Fl_* ones (eg Fl_Menu_Item stuctures together with Fl_Menu_ derived widgets come to my mind). But I believe that in most cases a good compatible solution can be found - but it takes more time to figure it out to avoid breaking things in the name of clean api which might seem simpler. I think that this new api could go to along to the old 1.x tree, marked as experimental - that is it could change at any time until pronounced full-featured and complete. At this point the old incompatible bits (which do not share implementation with fltk::) could be moved to extra *fltkdeprecated* library against which old-style applications would need to link as well (hello, fltkforms!) and library can be called fltk NT^H^H 3. I understand your concern with keeping multiple (partially) incompatible branches - there was already this 2.0 problem and 1.2 mess (for which I take big part of the blame) and I agree that "there should be only one". I am afraid that if the compatibility in new branch won't be good enough or if there is long period without stable implementation people (including me) would stick with 1.x anyway. To me the continuity and stability is much more important than fancy API. Just my 2c R. On 10/07/2011 14:49, Matthias Melcher wrote: > > Dear users, dear developers, > > as you may have read, I have been trying to get the FLTK 1 and FLTK 2 branch > back together into a single FLTK 3 branch. > > > THE IDEA > ========== > > I am hoping to get the main features of both versions back into a single > release, effectively doubling the number of developers and users for FLTK 3, > assuming that we can abandon 1 and 2. > > But that's exactly where the problem lies. When FLTK 2 was released, only > half of the users made the jump, and the other half (including me) stuck with > FLTK 1. The last thing I want is splitting our energy once again by > supporting THREE versions. This is why I added a compatibility layer to FLTK > 3 which makes FLTK 3 source code compatible to 1 and 2. > > > 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 structure > b: there are some differences that make life hard - if those features were > used > c: a big search-and-replace list will get an FLTK 1 program 95% into FLTK 3 > code > d: a big search-and-replace list will get an FLTK 2 program maybe 60% into > FLTK 3 code > e: the compatibility layers work, but the F1 layer is still quite buggy, > the F1 layer will need a lot of work > f: merging F2 features into F3 will also be a lot of work > > > THE QUESTIONS > =============== > > 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. > > So here are my options: > 1: keep F1 and F2 development active, forget about F3 > 2: abandon F2, continue with F1, forget about compatibility > 3: abandon F1, continue with F2, forget about compatibility > 4: merge F2 into F3, forget about the compatibility layers > 5: merge F2 into F3, continue with the compatibility layers > > What is it going to be? > > I think this is a really important point for FLTK. If we decide wrong, and > split user groups even more, that would be a disaster! > > In the end, FLTK is OpenSource, and even if we were to decide to go FLTK 3, I > can not keep anyone from continuing with 1 or 2. So if we do decide to go 3, > we should all be on board, and all focus on it (possibly ignoring back > compatibility). If we ant to stick with 1 and 2, that's fine with me as well, > but I can guarantee that I will not make another attempt at FLTK 3. > > Any questions and opinions are greatly appreciated, > > - Matthias > > > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
