Progress report: Aqua back-end

[mikel evins]

> In fact, the only CLIM apps that use simple-event-loop are the McCLIM 
> demo apps that were written before much of the CLIM spec was 
> implemented.

Check; no wasting time on simple-event-loop.

>
> I've alluded before to rewriting the pane and gadget code to handle 
> (or have the ability to handle) events in the "main" thread, but this 
> will take some work. I recommend that you get started with the single 
> threaded mode of McCLIM. This doesn't mean that you can only have one 
> thread in OpenMCL, obviously, merely that there will be only one 
> McCLIM thread (and only one McCLIM application running). As you write 
> the code that passes events to panes and handles them you might think 
> about how it would be structured if you had to pass an event message 
> off to another thread for handling.

Each thread has its own event queue; the real issue is that the 
WindowServer won't enqueue user events anywhere but on the 'main' 
thread's event queue (and then only if it has a bundle). I can look 
into whether the 'main' thread can pull events and then manually 
enqueue them on other threads' queues.

>
>> Any McCLIM app that is to act like an Aqua app must have not only a 
>> distinguished event-handling thread, but also a bundle--that is, a 
>> directory whose name is of the form "Foo.app", and which contains 
>> certain distinguished files and subdirectories. You can fool OSX 
>> using an environment variable that points to some proxy bundle, and 
>> that might be useful during the development of an app, but any 
>> delivered app will have to have its own bundle (I'm working on some 
>> simple tools to build a suitable bundle when saving a lisp image).
> Right, well this is probably more a delivery issue for Lisp apps in 
> general than a McCLIM issue.

You bet, but I've already figured out how to do it, both for McCLIM and 
for a non-McCLIM toolkit more suited to game programming.

>> (define-objc-method ((:void :send-event e) clim-window)
>>   (process-event-in-current-window-context self e))
>>
>> ...which presupposes that my back-end code uses the Cocoa/Objective-C 
>> frameworks. I have also built a minimalist Carbon/C-based framework 
>> that does not rely on the Objective-C runtime and messaging system 
>> (but that does not rescue me from the requirement to have a bundle 
>> directory, in case anyone was thinking it might).
>>
>> I'd be interested in any advice or guidance any of you my care to 
>> offer at this stage about how best to interface the McCLIM and Aqua 
>> event-handling models. Also, sometime soon it would probably be 
>> appropriate to start checking some of this work in, so that list 
>> members can see it and complain about it, or fix it, and so that I 
>> don't have to hack the system definition every time I update McCLIM. 
>> (The CVS system definition really wants to load CLX; with an Aqua 
>> back-end in place that's not the right thing; the system definition 
>> needs to be able to leave CLX unloaded if it's building for Aqua.)
>
> Hmm. Will it not build without CLX loaded (never mind what the 
> defsystem says)?
>

It builds fine, actually, I just don't want to be altering the system 
definition every time to prevent loading it.

--me