[mcclim-devel] question about display functions and control apps

[rpgoldman at real-time.com]

I'm afraid I'm restarting an old discussion, but I've had it on the
backburner, and now that I'm moving forward, I'm not quite sure how to
finish out the solution.

>>>>> "AH" == Andy Hefner <ahefner at gmail.com> writes:

    AH> What I might do is run a separate thread from the GUI that monitors
    AH> external conditions. It can close over your frame event queue, and
    AH> communicate changes to the GUI via events as necessary. Just define
    AH> your own event subclasses and write handle-event methods for them,
    AH> which will run in the GUI thread and can perform the necessary
    AH> updates. McCLIM itself already works in this fashion on threaded
    AH> platforms, events are collected from CLX in a background thread which
    AH> queues them up for the applications to handle.

I think this is the right solution for control applications.  One has
a second thread, which gets status updates and latches them into
slots in the application frame, and then we queue up an event.  Here
are a couple of follow-ons, though:

1.  Do I just make an event that will translate into setting
    frame-needs-redisplay?

2.  How do I ensure that the slots that I'm latching into are stable
    over the redisplay?  I imagine I make a clim-sys:lock object to
    make the update process and the redisplay process mutually
    exclusive, but can anyone give me a little guidance about what to
    protect in the CLIM code?

    I have been thinking that I should make a method for
    redisplay-frame-pane for my application that will hold the lock
    and (call-next-method).  Is this the right level of granularity?

Thanks!
Robert