From graphics-request at octave dot org Wed Dec  1 02:57:53 2004
Subject: Re: Oplot
From: Shai Ayal <shaiay at yahoo dot com>
To: Ole Jacob Hagen <waterthrill at yahoo dot no>, graphics@octave.org
Date: Wed, 1 Dec 2004 00:56:59 -0800 (PST)

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...

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

--- Ole Jacob Hagen <waterthrill at yahoo dot no> wrote:

> 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.
>