Thanks for the interesting thread.  I was considering using clim for an experimental openGL application I'm writing, but I didn't get too far with it (on Darwin platform).  So, I'm using OpenGL and GLU only for now. See link below for more details.   Since I'm at a point where I need some high-level UI gadgets like pop-menus and things, it would be nice to fit what I have into a lisp framework, since the toplevel of what I have is written in lisp (image proceessing stuff is in C++).<br /><br />http://kevinmichaelsmith.posterous.com/<br /><br />I'm interesting in learning more about the benefits of clim and if that could work with an openGL canvas using mac backend for UI look and feel.<br /><br /><br /><br /><br /><br />On Nov 19, 2010 8:21pm, Craig Lanning <CraigL@sc.rr.com> wrote:<br />> On Sat, 2010-11-20 at 01:10 +0000, James Ashley wrote:<br />> <br />> > Hi, all.<br />> <br />> ><br />> <br />> > I've been programming for close to 30 years now, and I've been trying<br />> <br />> > to find a good excuse to really learn common lisp (as opposed to just<br />> <br />> > dabbling) for the past 3 or so.<br />> <br />> <br />> <br />> I've been programming in Lisp (first Zetalisp on a lisp machine, then<br />> <br />> Common Lisp on Unix, Windows, and Linux) professionally for 25 years and<br />> <br />> I find it to be the best language for just about anything.<br />> <br />> <br />> <br />> > I think I've finally come across a project that feels like the right<br />> <br />> > "fit." The basic idea is a collaborative 3-d client-side application<br />> <br />> > server with a built-in IDE that persists the state off all its<br />> <br />> > applications between all its program runs.<br />> <br />> <br />> <br />> You need to be aware that CLIM doesn't have any 3D concepts in it so you<br />> <br />> will need to add those abstractions.  The good thing is that CLIM is<br />> <br />> layered so if there are no high level facilities that do what you need,<br />> <br />> you can build them up from the lower level facilities.<br />> <br />> <br />> <br />> > This is total vaporware at the moment...I'm just trying to do some<br />> <br />> > basic research and pick the right tools. I've been involved in way too<br />> <br />> > many where we started out in one environment, got a proof of concept,<br />> <br />> > then realized there were some fundamental limitations that kept us<br />> <br />> > from moving forward, so we essentially had to start over from scratch<br />> <br />> > (or wound up layering ever-more-unmaintainable pieces on top of an<br />> <br />> > unsustainable architecture).<br />> <br />> ><br />> <br />> > Right now, I'm thinking off "applications" being developed on at least<br />> <br />> > 4 different levels. One would be raw common lisp, that interacts<br />> <br />> > directly with the "interpreter." Another would really be creating<br />> <br />> > custom frame managers (I think...I'm just scratching CLIM's surface)<br />> <br />> > to provide eye candy effects (since I'm planning on targeting the<br />> <br />> > masses, I've learned that it's pretty much all about the eye candy).<br />> <br />> > Yet another would be something like the HTML/CSS/Javascript paradigm<br />> <br />> > to create 2-d "applications." And the last would be the actual 3-d<br />> <br />> > world where the users interact.<br />> <br />> ><br />> <br />> > A combination of Open Cobalt and World Forge seemed like the "proper"<br />> <br />> > mix at first. But, the more I dug into smalltalk, the less impressed I<br />> <br />> > was. I kept thinking "If only I could write a macro to do all this..."<br />> <br />> ><br />> <br />> > The more I dug into it, the more I realized just how big and ambitious<br />> <br />> > this project is.<br />> <br />> <br />> <br />> One thing I've found is that I can build applications much faster in<br />> <br />> Common Lisp and they are much more robust.  You may find that as you<br />> <br />> become more proficient in CL that your project doesn't take as long as<br />> <br />> you thought.<br />> <br />> <br />> <br />> >  If I'm going to be dedicating 10 years (or more) to<br />> <br />> > something, and forcing my users to download some obscure runtime<br />> <br />> > anyway...why not go with a language that left my jaw on the floor and<br />> <br />> > my head spinning? I realize common lisp isn't perfect, but what is?<br />> <br />> > (Clojure's tempting. I downloaded it, spent about 20 minutes to get a<br />> <br />> > REPL, and finally gave up. It may be mature and "ready for the big<br />> <br />> > leagues" before this project is, but...common lisp's there now.<br />> <br />> > Racket's similarly tempting, but I just don't seem to fit with the<br />> <br />> > Scheme community).<br />> <br />> <br />> <br />> I currently use SBCL as my free CL of choice and LispWorks as my<br />> <br />> commercial CL of choice.<br />> <br />> <br />> <br />> > The ideas behind McClim seem to feel like it's the right "fit" for the<br />> <br />> > GUI part of the project. Not all the eye-candy pieces, of course.<br />> <br />> > Just...conceptually. I've been digging my way through the old mailing<br />> <br />> > list archives (the check-in comments are a lot more educational than I<br />> <br />> > realized at first. I'm glad they got archived that way), and I see<br />> <br />> > that there's been speculation about an OpenGL backend for ages now<br />> <br />> > (and at least an experimental stab at writing one).<br />> <br />> ><br />> <br />> > Conventional wisdom seems to dictate using something like one of the<br />> <br />> > GTK bindings for the UI. But it seems to me that, if I started there,<br />> <br />> > I'd just wind up re-implementing tons of CLIM to get to an abstraction<br />> <br />> > level where I could forget about that and get down to real work. It<br />> <br />> > seems to me that my time would be better spent helping get the GTKairo<br />> <br />> > working solidly.<br />> <br />> <br />> <br />> It's interesting that you should mention "re-implementing tons of CLIM".<br />> <br />> I have watched (mostly) and participated (a little) in the development<br />> <br />> of XEmacs for many years.  As they discussed the various target user<br />> <br />> intefaces (Win32, GTK, etc.), I noticed that they were implementing<br />> <br />> parts of CLIM in C.<br />> <br />> <br />> <br />> Actually, one of the nice things about using CL and CLIM is that you get<br />> <br />> to define your UI separately from the implementation, thus, allowing you<br />> <br />> to more easily port your application to more systems.  CLIM can have<br />> <br />> multiple backends: GTK, OpenGL, Win32, XLib, etc.<br />> <br />> <br />> <br />> > Either way, I'll wind up duplicating the work to switch to some crazy<br />> <br />> > gadget set built entirely on some 3-d engine or other.<br />> <br />> <br />> <br />> > I see one of the fundamental programs being a traditional "form<br />> <br />> > builder" kind of drag-and-drop thing along the lines of VB. Probably<br />> <br />> > with some kind of tree view (or maybe boxes) to hide the fact that the<br />> <br />> > code's actually being written in lisp.<br />> <br />> ><br />> <br />> > Am I barking up the wrong tree? Like I said...I've been going through<br />> <br />> > the old mailing list archives. I've normally have wrapped that up and<br />> <br />> > at least gotten more than a passing acquaintance with actually writing<br />> <br />> > McCLIM code (at this point, I'm just digesting that ancient CLIM<br />> <br />> > "walk-through" referenced first on the home page) before de-lurking.<br />> <br />> > But I ran across someone else today who seems to be thinking on at<br />> <br />> > least vaguely parallel lines to mine, and I figured this was the best<br />> <br />> > place to check before I wasted his time with my ideas.<br />> <br />> <br />> <br />> I say go for it.  I haven't found a project yet that I wouldn't rather<br />> <br />> do in Lisp.<br />> <br />> <br />> <br />> Craig<br />> <br />> <br />> <br />> <br />> <br />> <br />> <br />> <br />> <br />> _______________________________________________<br />> <br />> mcclim-devel mailing list<br />> <br />> mcclim-devel@common-lisp.net<br />> <br />> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel<br />>