> And now comes the big trick: > - we create the F3 OS support and core by *moving* and > merging F1 and > F2 core files (see the list above). The trick is not to *copy* those > files, but to *move* them. That means that F1 and F2 will *loose* > functionality in its own core, but will regain an improved > functionality by linking back to F3.
OK - I could be convinced... When we do the merge, and we find differences between the nominally similar F1 and F2 implementations, how do we choose between them? For my money, I'd be inclined to weight the decision in favour of the F1 code, because on a number of occasions I've stumbled on problems in F2 ports of my code that seem to be problems in the F2 OS specific code, that *seem* not to be present in the F1 code. I guess the F1 code is more tested... Also, how do we decide exactly what the F2 API is, as it still seems to change...? Still, with this approach, maybe that doesn't matter so much... -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
