Gerry Weaver wrote:
>> 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.
So in other words, this would be a use of the fla lib without
fltk? ie. being able to use the fla code from a pure C program
on an embedded platform that doesn't have C++ at all, implying
a non-fltk program?
Sounds neat, kinda like what the svgalib was for linux,
so one could still draw without X windows.
So this might almost be its own subproject, with its own
docs on how to use it from application code without fltk?
>> 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.
I see -- sounds good to support it when building fltk dynamically.
But when building fltk's static libs, it would seem to make sense
the fla code be archived in with the fltk's static libs (fltk.lib
and fltk.a), since if I understand correctly, once fla is implemented
into fltk, fltk will be entirely dependent on it for drawing.
Many of us here release binaries to end users (commercial software),
There's been many discussions here as to why this is, suffice it to say
"to avoid dll hell".
What many found is that if you release two files that depend on
each other (execs + dll/so's), end users will find fascinating ways
of separating them that are sometimes really hard to troubleshoot.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
