Gerry Weaver wrote:
>We need a naming convention for the abstraction layer code.
> We are considering a file/function prefix of fal_/FAL_ (FLTK Abstraction
> Layer).
Definitely seems a reasonable thing to resolve before starting;
good question!
fal_ or fla_.. I don't have an opinion, but others here might.
I don't suppose C++ "namespaces" could be used here to some good effect?
Since the FAL won't be exposed to users, it won't really be an API/ABI
issue, purely internal. And even if you use a C api, we'll still be
compiling it with the C++ compiler, so namespaces should be available.
BTW, is there a reason you proposed a C api over C++? Just curious.
> Why separate libs?
>
> This would allow someone to work with a particular port without the need
> to worry about the other ports at all. We believe this will lead to better,
> cleaner, and lower maintenance code. This would also serve to isolate
> programming errors.
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.
> Why an additional wrapper?
>
> Over time, the various ports will continue to evolve. OS updates, new
> features,
> api changes, etc. These types of changes are being driven by a particular port
> and not the widget library. This will provide some additional flexibility to
> accommodate these changes without impacting the widget library.
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.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
