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