> FLTK 1.3 is now available via SVN to developers.

Yay!

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

Good idea - I hadn't even considered that...

> * UTF-8 support: we will apply the existing patches and test them  
> thouroghly until we have a stable and internationally usable version  
> of FLTK.

I might have to hide until this is working... ;-)

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

This will include making some of the base class methods virtual, and
moving some things around from the public/private domains, etc.?

> * Doxygen manuals: only *after* utf-8 is fully implemented and types  
> are changed, we will move all documentation into the FL 
> header files,  
> using the Doxygen syntax. Doxygen is a widely accepted standard for  
> library documentation with an insane ammount of options to create  
> documentation just the way we like it. Please note: Doxygen 
> docs go in  
> the headers. Documentation about the internal workings of 
> FLTK go into  
> the source code. I will provide some sample doxygenization in 
> the next  
> days.

Can this not be started "out of order" too? (If there's someone willing
to get started on it...)
As I understand it, the API will be documented using doxygen comments on
the header files.
The implementation details and internal workings will be documented in
the c/cxx files - also using doxygen comments? Or not?


> * Tree widget: (this can be done out of order) A yet to be 
> determined  
> tree browser widget will be integrated into FLTK. Alternatively, the  
> existing Browser will be rejuvinated and extended quite substantially.

I use Jason Bryan's FLU tree widget a fair bit - but I don't know how
appropriate that is for our needs now.

> * Printing support: (this can be done out of order) It is 
> allready in  
> Fluid, so why not open up printing to the rest of FLTK. We 
> need a good  
> API and some tweaks for the printing UI.

There was some work on this in 1.2 I think? (But using a very different
approach from the printing support in fluid, IIRC.)


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

What are we going to call fltk-config and the libs themselves?
During the transition I (and I guess others) am going to have
fltk-1.1.8, fltk-2 and fltk-1.3 around... At present, I have the
following:

Fltk-1.1   : fltk-config, libfltk.a, etc.
Fltk-2     : fltk2-config, libfltk2.a, etc.
Fltk-utff8 : fltk-utf8-config, libfltk-utf8.a, etc.

Where will fltk-1.3 fit in?

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