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

Timothy Moore moore at bricoworks.com
Wed Dec 29 10:37:54 UTC 2004


On Dec 28, 2004, at 10:41 PM, rpgoldman at 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




More information about the mcclim-devel mailing list