"Paolo" == Paolo Amoroso <amoroso@mclink.it> writes:
Paolo> Paolo Amoroso <amoroso@mclink.it> writes: >> If I understand correctly, in this case you may call >> REDISPLAY-FRAME-PANE, typically from an application command or some >> state updating function. A program that uses this approach is: >> >> KYTRON on the Moon >> http://artm-friends.at/rm/kytron/kytron-clim.html >> >> Check the CLIM 2 version: >> >> http://artm-friends.at/rm/kytron/kytron2.lisp.txt >> >> See for example the commands for adding a new element--crater, >> mountain, ecc.--to the environment. Paolo> More precisely, I meant `com-run-simulation' and Paolo> `com-time-100-steps'. 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). Andy suggests weird-irc as another model, but it seems not to be thread-safe. I will look into that further now. I hope that this design question is of sufficient generality to be of wide interest, and that I'm not wasting everyone's time.... Best, r Footnotes: [1] Out of force of habit, I almost typed "without loss of generality" here! :->