MacArthur, Ian (SELEX GALILEO, UK) wrote:
> And: Should we even be maintaining our own GIF decoder now? The (LZW)
> patents have lapsed, so we could maybe incorporate libgif (or similar)
> as we do libpng et al, and thus gain the ability to read and write GIF
> files, and process animated GIF and so forth...?
I believe one reason for the internal gif is to allow
FLTK to be compiled without dependence on external libs.
It sucks when people can't even build the toolkit without
first having to build a bunch of other potentially bloated libs,
and find they can't match up the versions for one reason or another,
due to the mix of OS/compiler dependencies.
Things got a lot easier when just the simple image readers
were pulled into the distro. The idea is anyone wanting more
would simply link against other libs.
The HTML widget is a tough one, because it can potentially
be dependent on many, many libs. Sound, network, plugins..
FLTK is supposed to be light, so we don't want the internal
dependencies to get large.
I figure anyone wanting real web browser capabilities
should use external browser libs for that, since that
gets complex quickly, and link them into their FLTK apps.
There are several out there, but I don't use them.
In my case, when I want browser capabilities that's more than
Fl_Help* can provide, I use fl_open_uri() to open the local web browser.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
