graphics properties (was: Re: Yet Another Plotting System for Octave)

[John W. Eaton]

On 18-Jan-2007, Alexander Barth wrote:

| Where exactly do you want to draw the line of separation? Do you
| want to store the properties' values as global octave structures and
| the graphics package would lookup their values in octave's symbol
| table?

Sort of.  You can find a draft/prototype of what I've been thinking
about if you checkout the "graphics-branch" from CVS and look at the
scripts/plot directory.  Everything there is .m files and it uses
gnuplot as the backend.  It is not really fast, but performance is not
horrible (it was when I had the global variables stored in a script
file, but now they are coded directly in the files that need them
and performance is much better).

I'm not sure the properties should be in global variables since that
makes it possible for users who know their names to access and modify
them without going through get and set, which could cause trouble.
Also, as Octave currently implements global variables, "clear all"
will clear them, and that will definitely confuse the graphics system.

So now I think the property database should be stored in some internal
variables in Octave that are only accessible via get and set at the
scripting level, and that can't be cleared.

We still have to decide whether the properties should all be stored as
octave_value objects, or as "native" C/C++ data types.  I have been
wanting to store them in octave_value objects because I think much of
the graphics system can (and should) be written in the scripting
language.  But I think it might turn out to be a lot of trouble for a
C/C++ backend to have to always be extracting data from octave_value
objects.  It might be better in that case to be able to rely on the
C/C++ type system to provide some guarantees about the types of the
properties.

jwe