Matthias, In my opinion, any code injection and any run-time costs/features should be optional. I would suggest that you use templates (policy traits) to enable users to mix-n-match the things that they want. At least, I do not want any run-time code injection. If I want that feature, i can do that on top of fltk. Including this in FLTK would mean making it top-heavy. I have some performance requirements that I need to meet. Adding top-heavy features would factor out FLTK - if runtime features are to be added then they can be provided as separate library components. I don't think they should be bundled with the core FLTK lib.
OR, I think if this is to be incorporated then this can be done as a separate parallel proejct - FLTK with Runtime-CodeInjection - or something like that. Best regards, Asif On Mon, May 23, 2011 at 6:28 PM, Matthias Melcher <[email protected]> wrote: > > On 23.05.2011, at 11:16, MacArthur, Ian (SELEX GALILEO, UK) wrote: > > As it stands, fltk-2 is still a little more "bleeding edge" than > > fltk-1.3, so if you need a stable base then I'd suggest you use 1.3. > > Over time, fltk-2 should become stable (Ben's working on it!) and there > > is a background task to merge the fltk-1 and fltk-2 series back to a > > common (and bug free) codebase in the longer term. (See fltk-3 or > > fltk-123 project...) > > fltk-123 is the attempt to revers the unfortunate code fork of FLTK 1. FLTK > 3 takes the very stable FLTK 1.3 and transforms it into a more consistently > named API. This is mainly the introduction of the fltk3 namespace and the > renaming of a few types and classes. This will be done before the end of > this month. > > FLTK 3 will come with a complete FLTK 1 emulation layer. This layer should > make it possible to compile existing FLTK 1 projects without changing any > code. I hope to get this done by the middle of June. I am hoping that after > removing the quirks, most FLTK 1 users will at least try to compile their > projects with FLTK 3. > > Now comes the fun part: we will create a compatibility layer for FLTK 2 as > well. FLTK 2 has some great features that were never backported to FLTK 1. > Well, now is the time to put them into FLTK 3! This will make FLTK as stable > as possible while combining all the advantages of 1 and 2. > > With all this comes a "code injection system" that makes it possible to > interface FLTK 3 with any other language out there, including overriding > existing virtual functions at run-time, like "draw()", and all the other > FLTK features. > > What's the cost? Well, very little (except core developer time). The > overhead of wrapped functions calls is one indirection (reading one > variable) plus one int and one pointer for every wrapped class. Native FLTK > 3 code will have almost zero overhead. And yes, FLTK 1/2 and FLTK 3 code can > be intermixed. > > This means you can take your existing FLTK 1 or FLTK 2 project, compile it > in FLTK 3, and used all the new features and graphics (yes, there will be > new graphics), and continue coding in FLTK 3. > > - Matthias > _______________________________________________ > fltk mailing list > [email protected] > http://lists.easysw.com/mailman/listinfo/fltk > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
