Re: Octave graphical objects

Hi, Nick. 

You mentioned two scenarios here, but I believe we are talking around
eachother. 

I'm aware of that I said the following sentence: 
 "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." 

I guess I need to explain it once more. 
What I really mean is that Visualisation-application controls handle
graphics objects, but Octave can be used for both inspection and
changing of handle graphics objects' values. 

They don't appear as global structures in memory, and doesn't occupy
any memory inside Octave, however they are viewable as a struct
(viewAll), or octave_value as one (ViewOne). 

Which means that scenario number 2 is the closest solution, so let's
work on that? Scenario number 2 is also the best solution, and might
also be the fastest?

I don't think Octave should handle "handle graphics objects". I believe
this should be left to the visualisation application to handle. In this
way, we accomplishes five things:

1. A flexible interface to different visualisation applications, where 
   all needs to use one well-defined communication protocol for   
   receiving/transmitting messages, such as handle objects. 

2. We have separated the "real handle graphics" from Octave to the 
   visualisation application.

3. No need for typechecking inside Octave for messages received from 
   visualisation application. A message sent from Octave to 
   visualisation application will be set up correctly from Octave-side,

   inside transport-class. 

4. Easy in the future to merge handle graphics code into a 
   GUI-frontend, if this is made later on. If Gui-frontend should be 
   handlings graphics objects as well. Which means that our work is 
   not a waste of time. 

5. Easy to maintain code.


Is this good?


For some basic information about creating dynamical loadable
types/functions, you can look at
http://octave.sourceforge.net/coda/c50.html


Cheers, 

Ole J. 


Cheers, 

Ole J. 







 --- N Smethurst <[email protected]> skrev: > Le Jeudi 13 Novembre
2003 02:25, Ole Jacob Hagen a écrit :
> > On Wed, 12 Nov 2003 23:18:11 +0100
> >
> > N Smethurst <[email protected]> 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
> 
>  

______________________________________________________
Få den nye Yahoo! Messenger på http://no.messenger.yahoo.com/
Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så morsom