Not really. I got confused between wanting to leverage Tk and not wanting to give up on the GUI once purely implemented in OpenGL with (minimal) Freeglut window management.<br><br>The timing thing with Tk is a big problem. I wanted to try making a Cello-classic row with layout coming from Cello geometry instead of Tk "packing", but that then I cannot let Tk decide a button size, because the Cello layout wants to know how big are the things it is laying out JIT after calling make-instance on them, but we have to wait for the client queue to run, which is when Tk gets asked to create instances, only after which it will be happy to tell us widget dimensions.
<br><br>It started to look like another week of "tool building", and it is not even clear that I should not just be letting Tk do all this, so...<br><br>This release is a punt. I will be using Celtk and esp. Togl on the commercial app I am building and let Cello evolve therefrom naturally.
<br><br>How bad a punt? Cello.asd is a joke. I made an effort to eliminate the several files that got cut from Cello, but I think I forgot completely to create an ASD for the new GUI-GEOMETRY package. That got carved out of Cello and installed as a subdirectory of Cells. As always, consult LPR file types to find out how I build software.
<br><br>Cello.lpr now includes nehe-06.lisp. That includes test function (nehe-06::nehe-06). Over here, I open and build Cello.lpr in AllegroCL, and test with nehe-06. That demonstrates OpenGL, GraphicsMagick, FTGL, and OpenAL, as well as a little Lisp history.
<br><br>Aside from Cello you will need Cells, Celtk, and CFFI. Also DLLs out the wazoo.<br><br>kzo<br><br><br>