The examples I have seen of display functions and McCLIM, it seems like there are two dominant models: one where the user does some commands, and the application pane's display function stays in synch by updating at every command loop (I suppose this is the MVC model); and another where we write code in the commands that directly display stuff (and have to tell the application pane NOT to redisplay itself).
Question: what about the case where you want to watch something "out there" that is not under the control of the command loop. I'm thinking in particular about controls applications, where you might want to update a display that shows the current state of the plant. Typically, there will be some process sampling the world at some rate, and wanting to asynchronously update the state display. Has anyone built an application like that using CLIM? Any suggestions for the right model?
Thanks! R
rpgoldman@real-time.com writes:
The examples I have seen of display functions and McCLIM, it seems like there are two dominant models: one where the user does some commands, and the application pane's display function stays in synch by updating at every command loop (I suppose this is the MVC model);
Section 7 "CLIM: Presentation Based Interfaces" (page 31) of this paper:
New Architectural Models for Visibly Controllable Computing: The Relevance of Dynamic Object Oriented Architectures and Plan Based Computing Models ftp://publications.ai.mit.edu/ai-publications/2004/AIM-2004-005.pdf
briefly describes the relations between CLIM and MVC.
Question: what about the case where you want to watch something "out there" that is not under the control of the command loop. I'm thinking in particular about controls applications, where you might want to update a display that shows the current state of the plant.
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
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.
More precisely, I meant `com-run-simulation' and `com-time-100-steps'.
Paolo
"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! :->
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
| | > Question: what about the case where you want to watch something "out | > there" that is not under the control of the command loop. I'm | > thinking in particular about controls applications, where you might | > want to update a display that shows the current state of the plant. | | 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:
I do this sort of thing quite a bit and it took some experimentation to get it to work right. At least part of the trick (in LWW CLIM at least) is to do (setf (pane-needs-redisplay pane) t) prior to redisplay-frame-pane. But, to do this, you can't have :display-time :command-loop active.
You probably also want to manually manage the output-recording options to avoid a surprise when pane may be re-exposed at a later time. Like this:
(setf (pane-needs-redisplay pane) t) (with-output-recording-options (pane :record t) (redisplay-frame-pane frame pane))
Paul
-
Paolo Amoroso -
Paul Werkowski -
rpgoldman＠real-time.com -
Timothy Moore