Greg: > fal_ or fla_.. I don't have an opinion, but others here might. We don't really care either. We just need something that all the devs agree on. The fla_/FLA_ was just a suggestion to get the ball rolling.
Greg: > BTW, is there a reason you proposed a C api over C++? Just curious. There are actually several reasons behind this. 1. In keeping with the "fast" and "light" tradition, we have a dream about a pure C implementation. A scaled down version primarily for embedded development. 2. We believe that using C would provide a bit of enforcement to the code separation over the longer term. It would be a little harder to create a catch all function than a class. 3. Many of the lower level libs either have only a C api or a C api with a C++ wrapper. We would choose the C api in the latter case. We don't see a need to create a C++ wrapper around a native C interface, when that is essentially what the widget layer would already be doing indirectly (ie; fltk::). Greg: > I think as long as the FAL lib can be combined with FLTK lib in the end > so that users don't need to link with a separate lib, that should be fine. One of the ideas here would be to support dynamic loading of the FAL/backend. This would allow an FLTK based app to select an appropriate backend at runtime. We planned to include a wrapper function that would enumerate the available backends on a given platform. (ie; X11, SDL, etc.). It would also allow patching the FAL/backend separate from the widget lib proper. This would need to be an optional build configuration of course. Perhaps the two can coexist. Greg: > Sounds reasonable. > After getting the naming convention, probably proposing or evolving > an internal API as the next step, and then go from there. That may take > a bit of hands on research to do it. This will take some time and a fair bit of research/thinking to get right. We have gone through the source (FLTK1.3.x) and identified all of the files that have any type of platform dependencies. There are more than 100 files that fall into this category. We plan to use these platform specific code blocks to fashion the beginnings of the top level wrapper and then flesh it out from there. The lower level api spec. would be driven more from the bottom up. The wrapper implementation will provide the platform independent glue code to put the widget level and the FAL level together. This will allow us to focus more on consistency across platforms with the opportunity to do the fix up in the wrapper. While we plan to use SDL as the test case, we also intend to hold the low level api spec up to a lot of different potential ports. Thanks, Gerry _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
