Re: Oplot

Hi, Shai.


I hope you are not suggesting that octave should handle "graphics 
properties" internally?
I would not in particular not agree on this strategy, since I think that 
graphics properties should be handled by each visualisation application.

What GNU Octave should provide is a common "graphics object properties" 
that every visualisation application can use (and abuse). This will 
strengthen GNU Octave flexibility in becoming the most configurable 
language for numerical computations AND visualisations. This is the main 
idea here.


Let say we include a graphics property library into octaveforge, that a 
visualisation application can use.
Then we should also say that octave provides the library, but each 
visualisation application must handle the  a duplex comm-interface, 
protocol, additionally they should handle how the visual representation 
should appear as well.


In Oplot we have implemented in almost this fashion.
We have made an external "graphics property"-package named Props, while 
Oplot handles the duplex communication, + there is some comm-source in 
src/octave/oplotcom.cc from octave-side. Octave is acting as a "server" 
while Oplot is a client.

We have also provided a set of m-files, as you mentioned Shai. Our 
m-files are:
oset.m, oget.m, ogca.m, ogcf.m, osubplot.m, otext.m, o<x,y,z>label.m, 
otitle.m, ohold.m, oishold.m, oline.m, ofigure.m, oimage.m, oaxes.m, 
oaxis.m, ocountour.m. 
osurf.m, omesh.m and opatch.m is to be made in a later stage of development.

The dispatch routine found in octaveforge, helps us in making "aliases" 
to these o-prefixed m-files, so they can be ran using, set, get, gca, 
gcf and so on.

We believe that Props can be used, but personally I think we should 
refactor the code a bit. But it should be quite ready, really.

Another thing is that the other higher level functions, such as e.g 
plot.m, gca.m, figure.m, they can actually be a part of an graphics 
property package, iff plot.m is using line-object. Since plot.m is found 
in octave-src/scripts/plot, it has to be either overloaded or the path 
to our vis.app's m-files should appear before the path to octave's own 
plot.m command. This means some fiddling with DEFAULT_LOADPATH, but this 
strategy is used in grace-package found in octave-forge.


Any comments?

Cheers,

Ole J.