On Tue, Apr 30, 2013 at 1:44 PM, Matthew Mondor <mm_li...@pulsar-zone.net> wrote: > On Tue, 30 Apr 2013 11:42:12 -0700 > Jason Sewall <jasonsew...@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 ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
