Re: handle graphics

[John W. Eaton]

On 13-Jul-2005, Rafael Laboissiere wrote:

| Another important issue is the specification of a clear interface for the
| backend plotting engines.  This could be implemented as a C++ class
| allowing for additions in the future.

What I have in mind is to do as much as possible in the Octave
scripting language.  For example, I think Octave could just call a
"update_graphics" call periodically, and expect that the graphics
backend(s) would then do the right thing for each currently displayed
object.  For efficiency, this may mean that the graphics backend(s)
would have to queue requests to avoid and process a batch of them to
avoid "flashing" effects on the screen.  We could also have an
"update_graphics_and_redisplay_now_for_sure_i_really_mean_it_this_time"
function to force the graphics backend to flush its queue of updates
(otherwise, implementing something like a movie might not work quite
right).

Also, Octave will need to periodically call a function to get events
back from the graphics engine and perform the actions requested.

I think the key thing is that we separate the management of the data
structure that describes the graphics objects and properties from the
display of that information.  Otherwise, it will be very hard to
switch from one graphics or GUI toolkit to another later on.

But I'm not an expert in graphics and gui tools, so if this is bad
design, someone should say so, and please explain why it is bad and
(in simple terms) what would be better.

Thanks,

jwe