Duncan: > In this proposal, you don't say whether you want to work only on > FLTK1 or on a common low-level library for both FLTK1 and FLTK2. > I assume from previous articles that you have plumped for FLTK1 > but we did have a discussion about a common low-level library for > both FLTK1 and FLTK2, so I thought I would ask for clarification > sake.
This is an excellent question. Unfortunately, I'm not sure I have a neat and tidy answer. I think that ultimately the goal would be to have FLTK1 and FLTK2 share a common FLA base. We chose to start with FLTK1, or more specifically fltk.1.3.x, because it seemed to be the best choice. We considered things like, active development, bug fixes, utf8, etc.. We also felt that the API spec for this version was more rigid and that preservation would be important. Having said all of this, I see no reason that a similar approach couldn't be used to put FLTK2 on top of the FLA. My guess would be that it may require a different wrapper API though. This was one of the important ideas behind the wrapper level. Duncan: > Second question: after you have teased out the C wrapper and the > underlying platform implementations, will you bundle them together > in a class to allow a complete interface object to be passed as > a context parameter to the code that needs it? E.g. Draw(screen), > Draw(bitmap), Draw(printer) etc. Yes. Once the initial wrapper is in place, it will most certainly undergo an extensive design review and rework. The FLA wrapper will definitely support a mechanism for dynamically changing contexts. We haven't yet discussed it in detail, but there is also the notion of an Fl_Window based device context that would be propagated to all child widgets of a particular Fl_Window instance. This would be completely independent of the global device setting. Duncan: > Third question: how high or low level will the wrapper layer be? To be honest, we're not sure yet. We felt it would be counter productive to make any assumptions about the wrapper layer prior to seeing the first pass api. This api being only what is necessary to liberate the platform specific code. Once we have the initial wrapper api, we can take a step back and look at it from a better perspective. Since we need to integrate the wrapper into existing code, that code will most certainly place certain requirements on the wrapper. The first pass will allow us to see these requirements laid end to end in the proper context. This should allow us to do a much better job organizing and defining the final api. Thanks, Gerry _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
