Gerry: > 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
This is clearly the best short term approach, but I would really like to see as few #ifdef sections in the code as possible, and hope that the FLA will enable us to clean out the current platform #ifdefs in the main code. > 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. The concept of a self-contained FLA works for me, but I wonder whether it should really be a separate library to be downloaded from a different [FLTK-forge :-)] location. It is specifically the FLTK abstraction library after all, no? Could it not be a separate library directory within or parallel to the FLTK sources? Maybe some extra mojo would be needed so that it could be exported and released separately if required. > 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. I think this introduces a level of complexity that would not be required once you were up to speed and had that history. > 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. This is where I would disagree. Maybe you set up temporary local directories for the initial design spike and investigate how to integrate it into the build process, but I think it would really be better to work in an FLA subdirectory of the FLTK-1.3.x source as soon as possible. You would gain better integration, feedback, use of the STR system, etc. > 5. We/I will continue the current level of communication [and/or] > 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. See my comment on 4. above. Use the FLTK source tree Luke :-) > 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. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
