On 28.03.2008, at 16:20, Albrecht Schlosser wrote:
> matthiasm wrote:
>> * 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?

We must categorize them into
1: fixed already in 1.1.8
2: does not apply to 1.3, only to a feature in 1.2 that won't be ported
3: must be fixed in 1.3

If you have the time to do this and send me a list with short  
comments, then I will apply the changes to the STRs accordingly.

>> * 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?

Absolutely yes, and yes, unless there is already a 1.2 STR.

>> 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.

:-P and hopefully much less frustration.

>> 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.

The API will change wherever it is required for technical reasons  
(double naming, like you mentioned for Fl_Scroll, make a method  
virtual, or going from private to protected). I don't plan to do  
cosmetic API changes. As for UTF-8, if you never used more than ASCII,  
UTF-8 will look exactly ASCII to you. As for a few Umlauts, unless you  
added specific code for umlaut handling, all you have to do is to  
import your source code using the Western code page into a UTF-8  
capable editor and save it as UTF-8 code again.

Matthias

----
http://robowerk.com/