Re: Octave graphical objects

> So you are thinking about letting the visualiser have handle graphics
> objects, and Octave can collect handle graphics objects by running
> gca_handle = get(gca)?

Well my idea is that the graphics objects are just black boxes to Octave. What 
goes on behind the scenes is nothing to do with Octave. After all, graphical 
object properties are used in the construction of graphical visualisations 
which is what the vis-app does, not Octave.

> So there will be no handle graphics inside Octave, except when user are
> running the get?

In a way no, but as far as Octave would be concerned yes. There would be 
graphical object representations in Octave which would be the comms stubs
(containing only an object ID and callback names).

I get the impression that you wish to implement a system where visualisation 
calculations and other processes go on inside the low level graphical objects 
in Octave. 

There would be no reason why we couldn't implement dynamically loaded 
graphical object types as well as dynamically loaded language and comms. My 
object types would be empty stubs apart from an object ID and callback names, 
whilst your objects would have functionality and OPlot would be responsible 
for less of the work.

My initial thought here is that placing functionality in the graphical object 
types in Octave would just be shifting visualisation code from OPlot to 
Octave. I guess it becomes a question of how abstract the information should 
be that gets transfered between Octave and the vis-app. I have been designing 
KV for high abstraction, where it is solely responsible for everything except 
for things that have nothing to do with visualisation (i.e. callback names).

> How are you transferring data's from Octave to kvisualiser and back to
> Octave? Have you defined a protocol like this one (which means that you are
> sending all h-g objects at the same time ): STX, HEADER, property(1),
> property(2), ......., property(N-1), property(N)* <checksum>?

This is where the language plugin comes in. KV has its own XML based language, 
and so the language plugin would format incoming information from the 
graphical objects into XML before sending it to the comms. 

How the language plugin behaves (for example, whether it sends commands one by 
one or whether it has a timer/flush thing) is the decision of the language 
plugin writer. Unless you decide that OPlot is going to talk KV's XML 
language (I am sure you have your own way of passing information between the 
applications), our development in this area will be separate, apart from 
defining a common API link at the Octave end. It wouldn't be necessary for 
you to write separate language and comms plugins like I indicated I wish to 
do if you would rather they were integrated into a single one.

Taking that train of though even farther, if you wanted you could even 
integrate everything from the graphical objects right up to the comms output 
if we had a common API for the dynamically loadable graphical object types.