Handle Graphics and visualisation applications in Octave.

[Ole Jacob Hagen]

Hi. 

There is a lot of development going on in replacing Gnuplot as
visualisation application. 
There are following graphics systems available to Octave: 
1. Gnuplot
2. epsTk a postscript toolkit for octave and matlab. 
3. Kmatplot, renamed to Qmatplot. 
4. Knewplot  
5. Plplot 
6. Grace


And these are coming; 
1. KV (Kvisualizer, Nick Smethurst)
2. Octaviz (Dragan Tubic et. al)
3. Oplot++ (Ole J. Hagen, Hans O. Hagen)

Since KV, Octaviz and Oplot++ will support MATLAB's Handle Graphics, we
should collaberate in how to solve this matter. 
There is no point in re-inventing the wheel, and try to limit  Octave
to just one visualisation application. 
Limitation to just one visualisation application can cause panic and
forking of the existing Octave. 
I believe that an user should decide which visualisation application,
he wants to use, since taste and flavour is personal. 
Some are using Gnuplot, and others are using Grace. 

Therefore, we should collaberate in developing a good Handle graphics
solution in Octave. Even Gnuplot has some "handle-graphics"-similar
commands, which can be simulated to be Matlab Handle graphic objects.
Too bad, there is no two-way communication between gnuplot and octave. 

I am working out a little paper, with a suggestion how to solve this
problem. 
It is pretty much based on that: 
1. Octave treats handle graphic objects as cell/struct arrays         
   internally. 
2. Octave  gets h-g objects from visualisation application, since this 
   is most naturally. I believe that even Matlab is doing the same.  
3. Octave has a native  implementation of h-g objects.
4. Each visualisation application makes their unique high-level and  
   low-level drivers. 

Explanation of 4: 
What I mean that Octave could have a built-in variable called
use_plot_engine='......', 
 which can be changed runtime and can take the following values: 
 grace, oplot, knewplot,qmatplot, octaviz, and it's default value are
gnuplot. 
In my Octave-distribution I've got m-files for plotting in: 
/usr/share/octave/$VERSION/m/plot. 

What if each visualisation application creates following folder:
/usr/share/octave/$VERSION/graphics/<VisualisationApplicaton>.
Please note that graphics folder should be a new folder in
/usr/share/octave/$VERSION.  
This change is caused by that Octave searches recursively in it's
search path, and that /usr/share/octave/$VERSION/m/plot should be
replaced with
/usr/share/octave/$VERSION/graphics/plot
example:
use_plot_engine='octaviz'
octaviz: /usr/share/octave/$VERSION/graphics/octaviz 

use_plot_engine='kv'
KV: /usr/share/octave/$VERSION/graphics/kv

use_plot_engine='plot' // default value
Gnuplot: /usr/share/octave/$VERSION/graphics/plot 

use_plot_engine='oplot'
Oplot: /usr/share/octave/$VERSION/graphics/oplot

These folders should then contain high-level drivers, which calls the
low-level drivers for the visualisation application that are used in
present time.
I am developing Oplot++, which will, if accepted by community contain
same files in /usr/share/octave/$VERSION/graphihcs/oplot as in existing
/usr/share/octave/$VERSION/m/plot, but using different low-level
drivers. 
Example of low-level drivers could be: oplot_plot.oct, oplot_set.oct,
oplot_get.oct, oplot_title.oct, oplot_contour.oct and so on....

Then we need to solve h-g object creation and processing in Octave. 
This might be also be solved as a  low-level and high level driver
strategy, as done with plot.m which calls oplot_plot.oct to plot a
graph. 

This is not a very good solution, that each visualisation application
shall have their own h-g object implementation, since I believe that
Octave should have a native implementation of h-g objects itself. 
This can be done, if we rename set and get routines to be seth, and
geth, and makes a set.m and get.m, as high-level functions, which can
be found in  /usr/share/octave/$VERSION/graphics/oplot, if oplot is
used. 
The set.m and get.m, will then communicate with Oplot and refreshing
visualisation, and updating octave internal h-g objects. 

Suggestions?

Is this feasible John?

I will try to implement this. Hopefully it will work....
I'm very optimistic about it, though.

Thank you for reading this email.

Cheers, 

Ole J. 


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