[ltk-user] [OT] Re: Mysterious breakage

[Daniel Herring]

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