From octave-graphics-request at bevo dot che dot wisc dot edu Wed Nov 12 16:16:06 2003 Subject: Re: Octave graphical objects From: N Smethurst To: octave-graphics at bevo dot che dot wisc dot edu Date: Wed, 12 Nov 2003 23:18:11 +0100 > 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)* ? 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.