On Mon, 4 Oct 2010, Kenneth Tilton wrote:
This link might help: http://common-lisp.net/project/cffi/
It's time for LTk to lose the stream crutch. FFI isn't /that/ hard, and it only needs to be done by the LTk maintainers.
Yes Kenny, we know about the intarwebs and FFI. :) Re HTML: The HTML canvas owes a bit to its Tk ancestor. That said, none of the webkit implementations were ready for writing standalone apps last I checked (a few months ago); and I personally hate browser "apps". Somehow writing CL glue to a handful of nonstandard layers that sanitize the mass of overengineered, underperforming HTML technologies (including Flash) just doesn't appeal to me. For all that effort, one could write a better custom gui in C++ using the enjoyable Qt framework and implement a simple FFI layer for passing application-specific data. Plus its more reliably portable. For the squeamish, there are also bindings like CommonQt. Re FFI: There was a Tk interface that used FFI. http://www.cliki.net/Lisp-Tk Didn't cells have such a beast as well? The LTk design has some nice features over an FFI layer: - better portability across ABI changes (the TCL language is the standard API; the C interface is less so), generally easier to invoke wish than locate a library, etc. - it is trivial to install a small "thin app" and host all the functionality (including gui code and upgrades) on a remote server - it is trivial to bypass LTk and invoke Tk directly; this is useful when binding new features, or when the LTk interface is suboptimal - IMO it is generally easier to debug (echo the streams vs invoke gdb) Streams aren't a crutch. Port 80, maybe; but streams, no. If I were starting a new GUI toolkit today, I think it would be built on a lower, simpler substrate with more possibilities for novel widgets and user interactions: OpenGL/OpenAL and DirectX. :) - Daniel