FLTK 1.1 is reaching its final state. 1.1.8 has become a wonderful piece of software, incredibly stable, very fast, and still very fast. Thank you very much to everyone who contributed! Very few OpenSource projects survive ten years!
So what is next? Technically, I have a pretty long list of things that I would love to see in FLTK. Much of it already exists in one way or the other and needs only integration work. Some would need some restructuring. Anyway, I'll add a list in another mail. The bigger question for me right now is, where is FLTK heading? How many users do we have currently, and how many do we want to attract? How do we want to compete with the Qt's out there? And do we want to compete at all, or stay in our niche? Or do we attract additional niches, like the embedded developers? Whatever we do, we must re-bundle our energy. Splitting developers between 2.0 and 1.1 is a drag! But how can we get our commercial developers to agree on, and use the same version? "Nuke" has been with 2.0 for a long time now and can not "downgrade" to a 1.1 style interface. "Rush", Greg's software is still on a patched 1.1.6 because 1.1.8 is missing UTF8, but 2.0 is not stable enough. As for myself, I would only switch to 2.0 if I can keep the source code mostly intact. 500.000 lines of interwoven FLTK code are not easily changed to a new API. But that brings me to my biggest issue with 2.0: the 2.0 bug list it full of bugs that I fixed for 1.1, and I have no intention to fix the same stuff again for 2.0. Yeah, I would like UTF-8 support and some of the label functions of 2.0, and yes, the interface is cleaner, but that doesn't help my existing code. So here are three possible solutions. Please comment and add solutions if you have any ;-) Matthias 1. continue separate development of FLTK1 and FLTK2: This would mean that 1.1.8 becomes the base for a new attempt at FLTK 1.2. We would then apply the UTF-8 patch and change the API to finally bring FLTK 1 up to par with other GUI libraries. FLTK2 would remain in Alpha stage until someone puts the effort in to fixing the STR's. 2. wrap up FLTK1 and concentrate on FLTK2: This would mean the end of the FLTK1 branch, leaving it in a very stable condition, a great tool for those not needing international text. All developers could put their efforts into bringing FLTK2 to where FLTK1 already is, gaining the additional features that FLTK2 already has, like better structure and internationalization. Will FLTK1 developers change over to FLTK2? Are the compatibility headers powerful enough for a simple switch? 3. wrap up FLTK1 and FLTK2, and start FLTK3: This would leave FLTK1 and FLTK2 just where it is. Developers are free to add simple fixes to FLTK2, but FLTK1 would be final. We would spend some time listing all features of 1 and 2, combine them in a sensible way, and then merge the source code to generate FLTK 3.0 with all features needed for a future GUI library. Compatibility layers for FLTK2 and FLTK1 would be designed in from the start, so that existing apps can be converted without much trouble. So, um, what do you guys think? ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
