Hello All,

We have been discussing what would be the best way to position the
FLA work relative to current FLTK development. It would seem that
we have reached a consensus on how we would like to proceed. The following is a 
brief summary.

1. All changes to the existing fltk.1.3.x code base would include a
#ifdef making the original code the default.

#ifdef USE_FLA

   fla code
   ...
#else

   original code
   ...
#endif

2. The FLA would be a library like any of the other libraries FLTK
currently makes use of (ie; zlib, jpeg, png, etc.). The FLA would
just have a higher level of integration.

3. We don't believe that we have enough history with FLTK to be full  fledged 
development team members (at least on this project). We would  appreciate it 
very much if someone would step forward to act as a
liaison to the development team proper.

4. We would setup our own SVN repository for the FLA library (only).  All 
changes made to the existing FLTK code base to make use of the
FLA library would be submitted as patches to the liaison for team
review and (hopefully) integration. The changes to the existing FLTK  code base 
should be rather innocuous, considering they would all be
#ifdef.

5. We/I will continue the current level of communication/
collaboration regarding the design and implementation of the FLA.

6. We will stay in sync with the latest fltk1.3.x svn code as long as  our 
patches are being integrated. We simply don't have the bandwidth  to engage in 
a cycle of re-applying/updating patches to stay in sync.


Note: The FLA is a pretty big change. We think it should be
positioned as an optional feature (at least at first). We want to
proceed in a fashion that will afford the FLTK development team the
most time and flexibility in deciding whether to integrate it. It
should be fairly easy to write a script that would purge all of the
#idefs out of the code at some point, if need be. We would ultimately like to 
see the full integration of FLA with the FLTK code base.
However, we don't believe it to be the best choice to start off with.

Thanks,
Gerry

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to