Hello All, I'm going to start referring to the abstraction layer as the "FLA" unless there are any objections. It's less typing ;-).
We have been thinking about the best way to approach creating the FLA without also creating a huge confusing mess. The list below represents an approach that we believe will lend itself to a clear and orderly code transition. It will allow us to work somewhat independently with collaboration occurring at the API review/analysis points. We plan to provide the API spec. for each phase. This will allow the FLTK devs to have full visibility and input to the entire process. This plan may represent a little more effort than the "all guns blazing" approach, but we think it will more than pay for itself in the end. 1. Identify all functions that contain platform/device specific code blocks. 2. Move the function code to an FLA wrapper function and replace with an FLA function call. Each function will initially be contained in it's own source/header file under the fltk/src/fla directory. This will form the initial C wrapper API. 3. Test FLTK against the new wrapper. 4. Analyze the wrapper API reworking as required for design and consistency requirements. This is the point where we can look at things like code redundancy, API naming, granularity, etc. 5. Test FLTK against any wrapper changes. 6. Break down the code in each wrapper function duplicating and reworking code as necessary to create an FLA function(s) for each platform/device. Each function will initially be contained in it's own source/header file under the fltk/src/fla/<platform> directory. We would like to use a different naming prefix for these functions (ie; fld, flp, etc.). 7. Test FLTK against the new platform API 8. Analyze the platform/device API reworking as required for design and consistency requirements. This is the point where we can look across several potential ports, increasing the API granularity where necessary. 9. Test FLTK against any platform/device API changes. 10. Generate documentation for the new APIs. Note1: A call tree and change log will be maintained throughout the process. Note2: The initial source file per function convention will allow us to work with self contained units of change. The analysis step would surely group these in ways that make sense. Once we have completed the analysis step, we could place the result under revision control. Note3: We are sure that the FLA APIs will continue to be refined over time. We are just trying to create the initial foundation to start building on. Your feedback is welcome. Thanks, Gerry _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
