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@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