Progress report: Aqua back-end
mikel at reactivity.com
Wed Oct 8 21:28:28 CEST 2003
> 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
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.
More information about the mcclim-devel