Re: Oplot

Hi, again.

Octave and octave-forge provides a set of high level functions today, 
and almost all are using gnuplot.

This have to change if we get what we want. :-)
But gnuplot doesn't support handle graphics out of box, but we could 
always make a wrapper, where octave handles this as an exception. But 
this is only done with gnuplot.

Both Octplot and Oplot are using graphics properties in a very different 
fashion.
I don't know if you understand how Oplot is using Props?
In general our implementation works in the same way. You have also made 
a hiearchy of your graphics objects. Actually the same hiearchy as Props 
is. ;-) But their behaviour is very different.
Oplot is using callbacks that are "raised"  from msg-type, while  
OctPlot is running code based on received msg-type. And they both are 
using unix sockets. ;-)

I believe that OctPlot could use Props....
It would be nice to prove the concept. ;-)


Cheers,

Ole



Shai Ayal wrote:

>Ole,
>
>What I meant is that the visualisation application
>should handle "grphics properties" internally not
>using a common library like props.
>
>The common interface from octave to all these
>applications should be the set of core functions,
>mainly set,get,line etc...
>
>  
>
How can you implement this, when unix domain sockets and pipes can be 
used as comm-interface?

>octave (or octave-forge) will provide high level
>functions like plot,contour,freqz_plot which all call
>the core functions. These high level functions can be
>shared between all visualisation applications.
>
>This way we have a simple interface which is very
>documented and can be accesed from m-files. Your way
>is going one step towards the application and in that
>it involves a complicated c++ interface, which is as
>yet undocumented.
>
>If anyone wants to use the props library they can just
>borrow it from oplot and use it as a basis for their
>new visualisation application.
>
>shai
>
>  
>