[Gardeners] GUI fun (was: Re: CLISP in one EXE file...)

[Rob Myers]

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.