matthiasm wrote: > FLTK 1.3 is now available via SVN to developers.
Nice. Thank you and all the core developers for finalizing 1.1.8 and going on to 1.3. > These are the tasks for 1.3: > > * verification of 1.2 STRs and possible push up to 1.3: there are 58 > STRs associated with FLTK 1.2. Most of these are probably fixed by now, > but we will have to read through each of them and apply them to 1.3 if > needed. How can we help? AFAICS there are some STR's that seem to target similar problems (e.g. more than one STR about fl_ask and friends: 1873, 1626, 334, 275). Should we wait until one of those who have the access rights will move the STRs, or maybe add new STRs for 1.3, with references to the old STRs? > * better typing: we can finally break the binary interface, so we will > change some types in FLTK 1.3. Widget coordinates will be 32 bit, for > example. At this time, we will also weed out some other limitations that > could not be fixed due to ABI issues. Also API changes? E.g. change Fl_Scroll::position() to another name so that it doesn't overload Fl_Widget::position()? And maybe others? Should we file STRs for such API issues? > A few words on stability: > > Please don't ask us to push tons of tiny features into the new FLTK. We > will have toime for that later. 1.3 will contain the most desperatly > needed features in what is hopefully going to be a very short time and > without ever losing the focus on stability. As soon as the features > above are tested and OK'd, we will move on to 1.4 quickly. 1.4 focus on > reorganisation of the source tree and the demo application. A stable 1.4 > will then be the base for a systematically approach to integrating more > excotic features without losing the F or L in FL ;-) . I appreciate this very much. Making more small steps will be much better than one big step that takes 2 years. > A few words on versioning: > > FLTK has a quite convoluted version numbering. FLTK 1.3 follows FLTK > 1.1. FLTK 1.2 is retired, but some of its features will flow into 1.3. > FLTK 2 uses a quite different API and is not touched in this whole > discussion. Both version will remain incompatible for quite a while, > until a merge of APIs and code base may become feasible. This point is very important for me. I will be able to test and use 1.3 as long as it doesn't change its API (too much) so that I can follow the development without major source modifications. I'm not sure if this will be possible with utf-8, however. Looking forward to FLTK 1.3 development :-) Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
