Hi All, Why I think I can talk: I don't do much GUI work, but when I want a little utility for myself I turn to fltk.
Comments are interleaved below. 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. > I applauded on hearing this. > > 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. > A single release is good, even if it has compatibility layers - fixes and new features will help everyone instead of a chunk of the users. > 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. > There has to be a decision to stop new work on the old branches. Bug-fixes yes, new features - not unless they are back-ports from the new code being made to the old branch as tide-me-overs until stability is achieved. > > 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! > I read your reply to Edzard Egberts and I have an idea/suggestion that may not make sense: Make the wrapper support (the if (wrapper) sections and extra members) conditionally compiled in so that it only has any impact (overhead) at all if it was requested at compile time. Therefore the built version of the library on a system may not support code written around the wrappers. It isn't a perfect solution, but would allow building of a compatibility library that was a little less light-weight while still keeping the core of fltk3 on a diet. > > 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 > This seems to say to me that it should be full steam ahead. > > 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 > > > So, to answer the question(s) 1: short term solution. no-one happy. 2: would work, wastes all work and learning from F2 and F3 3: abandons the stable version in favour of the experimental. No-Go, not until F2 is stable. 4: Possible direction, aiming to make F3 rapidly stable and usable while adding in new features. 5: This seems to be where you are going already - F3 based on a stable (core of, if not API of)F1 and with the new features introduced by F2 rolled in. A base for the future. All in All, I favour forging ahead with a single core code with a native API (F3) plus wrappers around this to allow legacy code (F1 & F2) to use the same core of work, even if the actual binary they link against is (in API) different. I also feel that consideration should be given to using stl types in favour of creating new, function duplicating types (I'm not accusing FLTK of this at the moment at all, but wxString and QString are two examples of types that just shouldn't exist in my world view. std::string is there and should be used when it doesn't add too much overhead. If std::string is too heavy, so are the replacements. Also consider the use of new options that C++1x might one-day introduce). I hope that this has been of some value to someone and let me once again state that it looks to me like you are heading in the right direction. Thanks for the hard work and dedication you've placed into this. -- -Edward Hull _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
