From octave-graphics-request at bevo dot che dot wisc dot edu Tue Nov 11 08:33:16 2003
Subject: Octave graphical objects (was: Handle Graphics implementation in Octave.)
From: N Smethurst <nick dot smethurst at free dot fr>
To: octave-graphics at bevo dot che dot wisc dot edu
Date: Tue, 11 Nov 2003 15:34:42 +0100


Le Mardi 11 Novembre 2003 09:47, Ole Jacob Hagen a écrit :
> Visualisation-application should also be able to
> change values of handle graphics objects.  
> This will have some drawbacks, since handle graphics
> objects are stored in two applications, both in Octave
> and visualisation-application.

This is an interesting point. Did you take a look at my page at 

http://kvisualiser.free.fr/dev/octavegraphics.html

specifically the second part about graphical object types? The idea goes like 
this.. 

I cannot see much point in duplicating data between Octave and the vis-app. 
The Octave end of things doesn't really do anything with the information 
unless the user requests it with an access instruction, and that is something 
that happens infrequently (relative to other processes).

Octave would not be responsible for generating any intermediate visualisation 
data of the low level graphical object types, since this is the job of the 
visualisation application.

Conclusion: why not just make the low level graphical objects in Octave simple 
communication stubs to the visualisation application? Then the only 
duplicated data would be an object ID. The only other information stored in 
the Octave graphical objects would be functionality unique to the Octave end 
such as callback function names for example. Similarly, this data stored in 
the Octave end would not need to be stored in the vis-app.

There's a very simple conceptual example in this file:

http://kvisualiser.free.fr/images/octave/graphicalobjects.h

I have included one or two object properties in each graphical object type. As 
you can see, there's not much there at all. The classes have no attributes 
apart from the ObjectID and an example callback string in the base class. All 
the classes do is relay the information to the comms language plugin, and 
return whatever it returns. The language plugin provides the correct syntax 
before the information packet is send to the vis-app. A simple graphical 
representation of this information path is on the octave page on my website, 
along with a class diagram.

Thus what would be the need for doubling up information that is essentially 
redundant in one of the two applications?

Nic