On Friday, December 30, 2005, at 10:34 am, Rob Myers wrote:
> On 29 Dec 2005, at 22:43, C Y wrote:
>
>> --- Frank Buss <[EMAIL PROTECTED]> wrote:
>>
>>> I think instead of using wxCL it would be interesting to use
>>> the low-level Windows GDI functions and built some framework
>>> on top of this.
>>
>> Agreed. Dan Stanger has the beginnings of code to do this in Clisp, I
>> think called gdi. I think the correct long term course for "pure"
>> lisp
>> graphics is to create cl-gdi which will be to Windows what CLX is to
>> X11.
>
> But this would be non-portable and work against sharing tutorials and
> code. Let's not have a ghetto of Windows Lisp GUI programmers and a
> Ghetto of MacOS X GUI programmers and a ghetto of UNIX programmers
> unable to help each other. No walled gardens, just one big garden.
> One of the major complaints against the various common lisps is their
> non-portability, and adding platform non-portability to this is a bad
> idea for getting more people started with Lisp (not necessarily for
> industrial strength use of Lisp) IMO.
>
I agree with this point; 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.
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).
>> There is a partial
>> backend for McCLIM called Beagle which tries to interface with Cocoa
>> for MacOSX, but IIRC ran into some fairly fundamental conflicts.
>> Perhaps adapting it to Carbon would meet with more success.
>
> I started the MacOSX DUIM in Carbon because of the comments the Apple
> Java team made about writing AWT in Carbon rather than Cocoa. But AWT
> later switched to Cocoa. Do you have a reference for what the
> conflicts were?
>
Off the top of my head the main struggles were related to both Cocoa
and CLIM wanting to do a bunch of the same things but in ways that
don't quite work well together. I thought until a couple of days ago
that NeXT probably ripped a bunch of stuff off of CLIM, but having read
a book I got for Christmas ("Revolution in the Valley") I now think
that both these libraries can trace their lineage back to Silica as the
common ancestor (but I'm still just speculating about this...).
That basically means that both CLIM + Cocoa want to be responsible for
passing events out to specific UI elements (sheets in CLIM, NSView
instances in Cocoa), including redrawing dirty parts of windows. Both
implement arbitrary affine transforms. Both split all the UI elements
up onto 'sheets' (CLIM) or 'views' (Cocoa). Both CLIM and Cocoa want to
delay drawing, and they want to be responsible for managing it too.
There's some other places they fall over themselves too but I can't
think of the specifics right now.
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. When CLIM is in the driving seat the
Cocoa side runs like molasses (I'm guessing a few optimisations are
being short-circuited), and a bunch of stuff that you should get for
free don't really work at all (like generating PDF output from a
window's contents - Beagle only uses drawRect: to inform CLIM of dirty
window events). I still think these are surmountable problems but a few
things I was going to try would have meant quite a bit of upheaval in
the non-backend McCLIM code which I didn't really want to risk breaking
(even working on a separate branch would have necessitated at some
point a merge which could well have broken a bunch of things people
were using, and it didn't seem worth it at the time just so I could use
a Mac native L&F with 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).
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).
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.
-Duncan
> - Rob.
> _______________________________________________
> Gardeners mailing list
> [email protected]
> http://www.lispniks.com/mailman/listinfo/gardeners
>
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
