Hi,
Let's say I have an object, that is presented with (present ...) on a pane. It is then drawn on the pane with (define-presentation-method present (...) (draw-arrow (start-of object) (end-of object) ...))
The arrow is used to represent the speed and direction of some external object (like the wind)
Then the wind speed and direction changes, so the object is updated. Now I need to update the presentation to reflect the changes in the object.
How can I update just that object?
"Knut Olav Bøhmer" bohmer@gmail.com writes:
Then the wind speed and direction changes, so the object is updated. Now I need to update the presentation to reflect the changes in the object.
I don't think you're supposed to do that. IIRC, output presentations should not be associated with objects that mutate a lot.
How can I update just that object?
Since presentations are output records, you could define a method on REPLAY-OUTPUT-RECORD and call REPLAY on the appropriate presentation object, but it's not exactly elegant.
Troels Henriksen wrote:
"Knut Olav Bøhmer" bohmer@gmail.com writes:
Then the wind speed and direction changes, so the object is updated. Now I need to update the presentation to reflect the changes in the object.
I don't think you're supposed to do that. IIRC, output presentations should not be associated with objects that mutate a lot.
How can I update just that object?
Since presentations are output records, you could define a method on REPLAY-OUTPUT-RECORD and call REPLAY on the appropriate presentation object, but it's not exactly elegant.
This is actually a question of considerably interest to me. It sounds like Knut and I may have similar interests.
The CLIM UI model maps nicely onto conventional document-oriented applications. There's an artifact out there (I'm probably overly constraining things by calling it a document), and the user manipulates it with various commands, and the display updates to reflect the changed state of the artifact.
I have found it much more difficult to figure out how to take this UI model and map it onto process control applications, which are of primary interest to me. In such applications, there is an external process, operating asynchronously with the program, that sends (conceptually, at any rate) updates that should be reflected on the display, so that the user remains aware of the state of the process.
Such applications seem to map less cleanly onto the CLIM model, and *may* fit more nicely onto constraint-based UI frameworks like Garnet and whatever that cells thing is...
There's probably a way to create an observer process that will capture the state updates, update the various objects and cause them to be redisplayed, but I don't know of a way to do this that elegantly captures the behavior.
Speaking of which, I'm not big on the design patterns stuff --- is there a design pattern, analogous to model-view-controller, that captures what one does when writing a process control UI?
Best, R
I have found it much more difficult to figure out how to take this UI model and map it onto process control applications, which are of primary interest to me. In such applications, there is an external process, operating asynchronously with the program, that sends (conceptually, at any rate) updates that should be reflected on the display, so that the user remains aware of the state of the process.
Such applications seem to map less cleanly onto the CLIM model, and *may* fit more nicely onto constraint-based UI frameworks like Garnet and whatever that cells thing is...
All you really have to do is modify your object and get REDISPLAY to run. This happens by default when :incremental-redisplay is true and the object modification is the result of a command (including some command invoked by define-presentation-to-command-translator).
Look at Examples/stopwatch.lisp to see how an external process can cause the display to be updated.
Paul
Thank you for all the useful input. The stopwatch demo looks like a good example. But I think my problem here now is that I'm trying to update some arrows during the feedback function in drag-output-record. Maybe some update/refresh functionality is suspended during this function?
On 24/05/07, Paul Werkowski pw@snoopy.mv.com wrote:
I have found it much more difficult to figure out how to take this UI model and map it onto process control applications, which are of primary interest to me. In such applications, there is an external process, operating asynchronously with the program, that sends (conceptually, at any rate) updates that should be reflected on the display, so that the user remains aware of the state of the process.
Such applications seem to map less cleanly onto the CLIM model, and *may* fit more nicely onto constraint-based UI frameworks like Garnet and whatever that cells thing is...
All you really have to do is modify your object and get REDISPLAY to run. This happens by default when :incremental-redisplay is true and the object modification is the result of a command (including some command invoked by define-presentation-to-command-translator).
Look at Examples/stopwatch.lisp to see how an external process can cause the display to be updated.
Paul
mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
On 24/05/07, Knut Olav Bøhmer bohmer@gmail.com wrote:
Thank you for all the useful input. The stopwatch demo looks like a good example. But I think my problem here now is that I'm trying to update some arrows during the feedback function in drag-output-record. Maybe some update/refresh functionality is suspended during this function?
I have attached my code. What I want to do, is to update the arrows while I'm dragging the circles (places).
A common mistake (IMHO) of people new to CLIM is them trying to force everything into a presentation. Presentations are very powerful abstractions but they are NOT the be all, end all of UI paradigms. CLIM has a full set of graphics routines that can be used to display information in addition to the presentation mechanism.
A common CLIM "pattern" is based upon the Controller-Model-View GUI paradigm. (I can't believe I've used "paradigm" twice in one Email! Probably spelled it wrong too!) In CLIM, you can use an application pane as the viewer, using all of CLIM's graphics routines. An interactor pane is often used as the controller, using an application specific command table to provide more complicated interactions than simple GUI elements can provide. A hbox pane is often used as a button box/menu bar for those simple interactions ('Start', 'Stop", 'Emergency Core Shutdown') that don't require additional arguments.
I guess what I'm trying to say is that CLIM has enough power and flexibility to handle most kinds of GUI models. Don't get stuck on just presentations.
Mike McDonald mikemac@mikemac.com
-
Knut Olav Bøhmer -
Mike McDonald -
Paul Werkowski -
Robert Goldman -
Troels Henriksen