[Ecls-list] ECL and UIs

[Jason Sewall]

On Tue, Apr 30, 2013 at 1:44 PM, Matthew Mondor
<mm_lists at pulsar-zone.net> wrote:
> On Tue, 30 Apr 2013 11:42:12 -0700
> Jason Sewall <jasonsewall at gmail.com> wrote:
>
>> I have a C library I have been working on and I'd like to use (Common)
>> Lisp to write a UI to go on top of it.
>>
>> I first seized upon ECL for the Lisp, since I could easily make an
>> interface to the library, and I had a notion at CommonQt might be a
>> good way to do the UI. Of course, I can put lots of UI material into
>> the C lib and export that to Lisp myself, but I'd really prefer to
>> leverage something that already exists.
>
> Other than commonqt perhaps of interest would be cl-gtk.  Some software
> also used mcclim or garnet.  On the other hand, if an HTTP interface
> could do, this might be the easiest to provide.

I am going to be doing some scientific visualization with fairly
low-latency requirements (moving pictures!). I suspect that HTTP isn't
going to cut it for that, alas.

>> Leaving the details of the individual hurdles I've come across aside,
>> I haven't gotten anywhere. It seems like every GUI toolkit for Lisp I
>> come across is poorly maintained and/or doesn't work with ECL.
>
> I agree, they often are one-person projects, with the most tested
> implementation being the one they personally prefer.  Another issue
> with GUIs is that for many users "native look" on their favorite OS
> seems to be important.

I don't care too much about that, although I'd prefer if things could
look reasonably modern. Motif doesn't really have the look I'm going
for :)

>> What would you folks do? Does anyone do this? It seems like building
>> the UI in lisp would be much more flexible and fun than doing it in C!
>
> If you're really willing to write yourself a widget system, then I fully
> agree and CLOS would suit very well.  If you're about to do this, you
> probably only need rather low level but flexible input/output though,
> so something like bindings for Cairo and Pango might be interesting.
> Cairo will deal with antialiasing and hardware acceleration when
> available, and can also output to Postscript which would allow a
> WYSIWYG system, and Pango can deal with text blocks and fonts.  Then
> again though, I have no idea about the state of cl-cairo, and if there
> exist Pango bindings.

I think you're misunderstanding me; I mean that I could skip writing
the UI, by which I mean the library calls, in Common Lisp, and just do
it in C with native calls to Qt or whatever, but that isn't really
what I want to do. Writing a widget system sounds tedious and my final
result would probably suffer; I can't possibly mange to duplicate the
features and stability of top-tier toolkits in the amount of time I
have to mess with it.

> The other alternative would be to use OpenGL only (possibly with
> limited SDL bindings to deal with the screen portably) and to build
> everything from scratch over it, including input methods/keymaps and a
> cairo-like output system for it, and freetype-based system for
> fonts...  If I remember the Blender project did this but are using
> Python as their high-level language.

While I like Blender and have become accustomed to its UI, most people
probably find it insane. Their general approach of 'here's a C library
that is exposed through a scripting language, with a UI written in
that language' more of less what I'd like to have here, however.

> If you want to use existing CL bindings as much as possible, it's
> unfortunately true that SBCL is likely to be more supported and tested,
> but CFFI is supposed to also work with ECL, so you might want to try
> CFFI-based bindings, it has various dependencies but with quicklisp
> this might be easy to install and try today.

That has something to do with the hurdles I glossed over. I haven't
been able to find a combination of ECL/commonqt (with quicklisp) that
works on my testbed (a modern x86_64 Linux system).

> If you want to use ECL as a "toolchain" to build distributable
> executables/libraries, and/or want to use C/C++ along with CL, then
> these are some of ECL's strong points.  It's of course also possible
> with ECL to use C libraries without having full-fledged clean CL
> bindings to the C libraries you want, by writing in C the parts which
> need to deal with them, and providing yourself only the higher-level CL
> interface you need instead of bindings for every function/structure a C
> library offers.  Another advantage of ECL here is that the garbage
> collector can also deal with C objects, unlike with most other
> implementations and their FFI, because it's the C GC (boehm-gc) that
> ECL also uses for its own objects.  ECL also supports native threads on
> every OS it supports.

I'm already sold on the ECL angle, except for the trouble with finding
good, working GUI bindings.

Thanks for your input; perhaps I'll try a little harder to get the
ECL/commonqt thing working, or perhaps I'll try cl-gtk.

Cheers,
Jason