On 13.07.2011 02:17, [email protected] wrote: > With regard to new development, I guess I'd want to upgrade if > I thought I needed styles, tablet support or shaped windows. > I don't, so I wouldn't, but YMMV.
So this would be the point to attract users to follow 3.0: new features that are not available with 1.3 and/or 2.0, plus the (hopefully) stability of 3.0 (as opposed to alpha state of 2.0). > Again, I want to emphasize that I don't necessarily think that > this fltk3 plan is a bad one, just that it's very developer-centric > as opposed to user-centric. I don't think that this plan is developer-centric: it is motivated by the need to get most (if not all) current users to use the new development (fltk 3 and later). As long as there are alternatives (fltk 1 vs. fltk 2), there are chances that the user community is split between the two versions. As has been said already, no one can guarantee that users don't keep their old versions as long as they fit their needs - and that would be even longer if the transition to a new version would "hurt" in the sense that it needs much effort to change their source code. Therefore the first step must be to make it easy for *users* to migrate their source code to the new code base - hence the compatibility layer(s). This is very much user-oriented and not developer-centric. In fact it would not be necessary for any developer who might say "well, I can migrate _my_ code, and then I can develop the best new features in that new fltk 3/4/5...". (Maybe this was one of the greatest faults of fltk 2.) Now, if we could attract the majority of users to use the new fltk version (and migrate their code to use the "real" fltk 3 API and not the compatibility layers eventually), then there is no need for developers to invest more time and efforts in fltk 1/2, and we could bundle all our energies on the new fltk development. This would (hopefully) improve stability and development speed of the new fltk, and this again would improve user experience and maybe attract more users. And, last but not least, where would the users be without the developers? From this POV, we *must* find consensus among the developers to get the best (and only one) version for the future. If this is developer-centric, then I vote for having a developer- centric plan. ;-) So far the theory, and AFAICT this is almost done and proved to work (somehow at least) for fltk 1.3. We can only hope that it will also succeed for fltk 2, so that we can drop fltk 2 development and focus on fltk 3. However, if this didn't work, then all the efforts to develop a fltk 2 compatibility layer would be wasted. IMHO this is the main point we need to decide, and personally I'm not convinced that fltk 2 compatibility can be achieved w/o much trickery and maybe ugly (and not well maintainable) code. But, whatever we decide about compatibility layers or not, one of the most important points IMHO is to make clear that fltk 3 is the newest, best, stable, and *maintained* version of fltk, so that new users won't try fltk 2 by accident and then be disappointed about existing bugs and lack of support. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
