From octave-graphics-request at bevo dot che dot wisc dot edu Thu Nov 13 05:26:23 2003
Subject: Re: Octave graphical objects
From: N Smethurst <nick dot smethurst at free dot fr>
To: octave-graphics at bevo dot che dot wisc dot edu
Date: Thu, 13 Nov 2003 12:28:13 +0100

Le Jeudi 13 Novembre 2003 02:25, Ole Jacob Hagen a écrit :
> On Wed, 12 Nov 2003 23:18:11 +0100
>
> N Smethurst <nick dot smethurst at free dot fr> wrote:
> > 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.
>
> Handle graphics objects, should be available inside Octave, since the
> handle graphics objects are a struct array. This is when you list all of
> them, but if you list one of them, they can be viewed as an octave_value, I
> guess. Therefore we should be able to list values of handle graphics
> objects inside Octave. Changing and getting handle graphics objects, should
> be available from the visualiser.

Heres two scenarios:

Scenario 1 - graphical object data stored in Octave structs.

Setting data: 

The user calls an object via one of two methods, e.g.:
    set(objHandle, 'TickDir', 'In');
    objHandle.TickDir = 'In';

Action: The object struct data is thus changed. The struct must then forward 
this information to the vis-app.

Getting data: 

The user calls an object via one of two methods, e.g.:
    direction = get(objHandle, 'TickDir');
    direction = objHandle.TickDir;

Action: The object struct data is accessed to obtain the information. What 
happens then? One of two things are needed. Either 1/ the struct will first 
need to verify with the vis-app that the property has not changed; if it has 
it would need to ask the vis-app for it again; Or 2/ the vis-app has 
additional code in the property setting methods that send all modifications 
back to Octave, unless it was Octave that sent the change (thus it needs to 
differentiate between properties changing via its own object browser, and 
properties changing from Octave.


Scenario. 2 - graphical object data stored in vis-app only, non visualisation 
properties stored in Octave graphical object stub.

Setting data: 

The user calls an object via one of two methods, e.g.:
    set(objHandle, 'TickDir', 'In');
    objHandle.TickDir = 'In';

Action: The graphical object forwards the information to the vis-app.

Getting data: 

The user calls an object via one of two methods, e.g.:
    direction = get(objHandle, 'TickDir');
    direction = objHandle.TickDir;

Action: The graphical object requests the property from the vis-app.

OR

The property is local to Octave (i.e. callback names) and thus it is just 
returned without communication with the vis-app.



Which is the simpler? In scenario 2 there is no need for any checking code in 
either of the applications since only one application is responsible for 
object properties.

Maybe the best thing to do here if you wish to implement scenario 1 and I wish 
to implement scenario 2 is for us to work from a common template of 
dynamically loadable Octave types which we can adapt for our own needs. These 
types could be chosen at Octave startup (via as you said an environment 
variable or suchlike), and thus the external behaviour of our different 
implementations would be the same to users.


My question is thus: is there any documentation explaining how to create 
dynamically loadable types in Octave? I didn't find much info on this 
subject, but I haven't looked for some months.

Nick