On Sun, 01 May 2011 12:06:49 -0400, corvid <corvid@lavabit.com> wrote:
Globe Trotter wrote:
IMO, dillo's adoption seems to be negatively affected largely because of the uncertain pace and status of fltk.
Are there others that make a point of being fast and light?
I can think of a couple other light ones (FOX, among others), but I don't think any of them make it as high a priority as FLTK. They don't seem to be as well-maintained or documented, either. Of course, we could in theory program it against straight Xlib. I think Opera actually does that now, when Gtk+ and Qt aren't available (they apparently have a lot of free time on their hands). But that would be messy and a real portability nightmare. Or we could fork FLTK and ship it in our own source tree. A lot of larger projects -- OpenOffice.org and Audacity, for example -- include dependencies with their stable tarballs, especially when they're lesser known or require a specific version. That's essentially what I've done with the Windows port; where FLTK was broken, I went ahead and fixed it myself. Granted, Dillo's not a large project, and including our own FLTK would be kludgy to say the least. But then again, we'd always have a "known good" version, and we wouldn't have to wait for the FLTK people to get their acts together. The low-level APIs (Xlib, Win32, etc.) don't change too often, so there shouldn't be much worry about it breaking. (And we only have to do it in stable releases, not hg. Granted, it adds some size to the tarball, but not a ridiculous amount, and IMHO it's worth it if it could lead to more widespread Dillo adoption.) Just a thought. ~Benjamin