Gerry: > We have been discussing what would be the best way to position the > FLA work relative to current FLTK development. It would seem that > (just minutes ago) 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 >
Sorry. I intended to move this to a new post with a more appropriate subject. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
