On Dec 28, 2004, at 10:41 PM, rpgoldman@real-time.com wrote:
Actually, if I understand Hef's comments correctly (and I haven't misunderstood the kytron code), this isn't really the right model. The problem is that the kytron is still really a synchronously operating simulation: the sim does one step, then you call clim:redisplay-frame-pane, repeat.
The problem with control apps, is that there will be a separate thread that will be latching state updates, and will not be working in synch with the UI. So you might get something unpleasant happening if you invoke clim:redisplay-frame-pane from that separate thread (assuming[1] that the clim redisplay function is not thread-safe).
...
I hope that this design question is of sufficient generality to be of wide interest, and that I'm not wasting everyone's time....
... Not at all; this is an interesting issue that has occupied a lot of my brain cycles without much success. A further complication is that recording panes are not at all thread safe in McCLIM; I don't know whether they are in Classic CLIM. It would be very nice to have a simulation ---especially in 3D using OpenGL --- running in an application pane while at the same time one could continue to use the interactive command loop with typed commands, sensitive presentations, etc.
McCLIM does have some nascent support for timer events, but this is way below the level of command processing. One approach might be to extend this to "throw" a redisplay command when a timer or other update event arrives. Right now that would destroy the state of command line editing in the interactor pane, so some work would have to be done to preserve the state of the input editing stream. Some examples of how to do this are in the accepting-values code in dialog.lisp.
The situation is not so dire because the easiest way to write a CLIM application is to follow an MVC approach of update the model, redisplay it, and let CLIM take care of optimizing the redisplay. That means that the redisplay and the command processes --- the interactive command loop, plus whatever else might change the state of the model -- could operate asynchronously from each other as long as they use some kind of mutual exclusion mechanism. An interactive command could cause the pane to be redisplayed, or one might let the next timer event, vertical retrace event or whatever force the redisplay. The remaining complication, then, would be the handling of sensitive presentations and pointer documentation. The CLIM command loop would have to know about the mutex protecting the view and also be alerted that presentations may have moved, appeared, disappeared, etc.
None of this is very helpful for an application developer wanting to do something right now, but I hope it is food for thought for McCLIM developers and users alike.
Tim