Greg: > Indeed; I think just take a small piece on, submit as a patch, > and see what the response is.
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 _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
