On 30 Dec 2005, at 12:06, Duncan Rose wrote: > a generic higher-level toolkit will suffice > for probably 90%+ of applications that require a GUI. This library > would be the equivalent of AWT/Swing/SWT in Java I guess.
Yes. It's important to lower the entry barrier for learning and using Lisp. When people are happy hacking in AWT they can move on to Swing. Uh, whatever the Lisp equivalents are. > Lower-level libraries will still be needed however I think (either > that > or the platform specific / back end code for the high level library > will have to get involved in FFI). I agree, but they should not be the initial focus for any Gardening. And basing higher-level toolkits on a specific platform toolkit embodies platform-specific assumptions in the higher-level code. > The conflicts in the above are that Cocoa works pretty well when its > left to manage all the UI elements, but then CLIM never got to find > out > about a bunch of stuff that was going on and the higher-level > facilities of CLIM didn't work. Hmm. Maybe subclassing the Cocoa widgets would help keep track of things. > CLIM). Even something simple like drawing text > becomes very inefficient; Cocoa wants to use NSTextView for this which > is a complicated edifice (but does pretty much everything you'd > want it > to, if you were writing in Objective C), but that doesn't fit in with > CLIM wanting to do the management of text itself (my understanding is > that the NSString drawAtPoint: or drawInRect: mechanisms are an > expensive way of achieving the appropriate end). Possibly the Aqua Emacs implementations will have some clues. > Finally, and I'm not sure if this is a problem with CLIM's design, the > McCLIM implementation, or the Beagle back end (but if I had to put > money on one I'd put it on Beagle) I ran into problems dealing with > multiple windows in the same application. It looks like there's some > code somewhere that relies on asynchronous interactions with the > window > server whereas Cocoa does a bunch of stuff synchronously (or seems to) > leading to the application hanging (this may actually just be related > to the way mp is handled by Beagle -- just starting up new OS threads > is insufficient for threading Cocoa apps). I don't know enough about run loops to say how synchronous Cocoa is, but it was a pain trying to update the UI from a thread reading from a socket in a project I did recently. > IIRC Mikel Evins did some experimentation in the early days of the > Beagle implementation and worked out that OpenMCL -> Carbon turned out > more nimble apps than OpenMCL -> Cocoa but back then I figured that > the > more abstract nature of Cocoa would be a win (and I don't *think* the > difference was that significant). I still haven't fully made up my > mind, when I come to repeat the experience, whether to pick Carbon or > Cocoa. The optimum solution may well be to mix and match both Cocoa > and > Carbon pieces in the same library. Carbon would allow CLIM to grab the reins, and wouldn't break each time Apple change AppKit (until OpenMCL fixes that), but I think cracking Cocoa would help make CLIM a real peer GUI toolkit on the Mac. You can get the CF run loop and the like out of the Cocoa stuff and use that where needed. - Rob. _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
