OK, here's my take on this one...
> I liked the 1.1.x series. Yes, me too. The fltk-2 API is better, but fltk-1 works right now, and so I have to go with that. > Why after 1.1.7 is there 1.1.8 and 1.1.9. What's the > difference between them? 1.1.8 and 1.1.9 are bug-fix point releases of the 1.1..x series. I don't see anything out of the ordinary there, so maybe I'm missing the point of your question? FWIW, 1.1.9 is quite a bit better than 1.1.7, whilst remaining fully backwards compatible. > Why is 1.3.x now being developed in the SVN instead of effort > primarily into the 2.x.x series? Because there's considerable demand for a library with the same API (or at least substantially similar API) as fltk-1.1 but with support for a number of features (UTF8, larger co-ordinate spaces, new widget, etc.) that could not be added to the 1.1.x series without breaking it's much vaunted backwards compatibility. The people who are working on 1.3.x pretty much all have a massive investment (in terms of deployed code) in the 1.1.x API, so need a (sort of) fltk-1++, but retaining the fltk-1.1 series' long established reliability. There's still work on the fltk-2 tree, but largely by a different (albeit overlapping) team. My worry with the fltk-2 tree, and the reason I haven't been able to commit to it, is that the API is *still* in flux (after many years) and seems to be moving further away from the fltk-1 baseline, whilst not getting any more stable, or fixing any of the bugs. I don't have the time just now to commit to bug-fixing fltk-2, on top of the stuff I need to do, and it seems no one else has, either. > Is this legacy-gone-mad, or experimental branches? Oh, probably both. Flkt-2 is certainly still experimental. Fltk-1.3 will (hopefully) follow the 1.1.x pattern and be generally stable. But 1.3 is very new right now, so the ride might be a little rough, at least until we get the big "tweaks" bedded in. That said, it works right now. > Finally, was it decided to base future FLTK on OpenGL or Cairo? I don't understand this question. Fltk has always supported GL. Do you mean using Cairo or GL as the underlying rendering layer for the lib? At present, all fltk versions provide their own portable rendering layer. Yes, that does make porting the lib to another platform more work - but it is work that is done now (for the common platforms) and which works very efficiently. It is far from obvious that porting to run on top of Cairo, for example, would do add much (anti-aliasing?) and would currently be a fair bit slower (although the Cairo guys are making progress on that.) Indeed, I have a number of embedded targets where a Cairo dependency would *prevent* me from using fltk, where the "plain-old-X" layer works well. And finally, there is a Cairo option in the fltk-2 tree, so that is an option if you feel it brings advantages to your target applications. -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
