From kentilton at gmail.com Mon Jun 5 02:09:39 2006 From: kentilton at gmail.com (Ken Tilton) Date: Sun, 4 Jun 2006 22:09:39 -0400 Subject: [cello-devel] Cello and Celtk? Message-ID: 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. 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. 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... 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. 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. 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. Aside from Cello you will need Cells, Celtk, and CFFI. Also DLLs out the wazoo. kzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Mon Jun 5 05:00:15 2006 From: kentilton at gmail.com (Ken Tilton) Date: Mon, 05 Jun 2006 01:00:15 -0400 Subject: [cello-devel] Cello and Celtk? Message-ID: <4483BA5F.9080105@gmail.com> Not really. The Cello/Celtk merger, I mean. 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. The simple approach of using Tk as if it were a glorified Freeglut did not seem to leverage Tk enough. Blending Cello with Tk looked nasty. 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. 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... 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. This will be a Tk (Celtk, that is) application with the Togl widget slowly picking up tricks from the Cello code. That lets me get to work on the commercial app functionality sooner, which I really need to do. 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. 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. Aside from Cello you will need Cells, Celtk, and CFFI. Also DLLs out the wazoo. Write if you need help with this. kzo -------------- next part -------------- A non-text attachment was scrubbed... Name: kentilton.vcf Type: text/x-vcard Size: 171 bytes Desc: not available URL: