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

[Shai Ayal]

On 1/19/07, John W. Eaton <address@hidden> wrote:
> 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

OctPlot's system is to store everything in a c++ hierarchy,  where you
have objects and properties. properties are accessed by name using
std::hash. It has provisions for post and pre set operations (for
error correction and consistency checks). The properties are native
c++ types -- I have colorspec, scalar, string , handlevector, radio
and matrix. more property/object types can be added. Octplot supports
default settings for all properties.
Although in octplot this structure is tightly coupled to the rendering
-- each object has a "draw method" which draws it, I think it would be
relatively easy to separate this -- just take out the draw method from
the objects, and you have a "pure" object tree with hierarchy.
Than, take all the draw methods and put them in a tree-walking
algorithm and you have pure rendering solution.
Couple this with the 3D code in yaope -- not too hard because they
both use OpenGL -- and you have nice 3D graphics with a
document/viewer architecture. I think I could do it within 6 months,
and maybe even sooner depending on the help I get and on how busy I am
in the "real world"

I am willing to start this thing if it is acceptable by the community.

Open questions/problems:
1) socket comm: I did this in octplot because I did not think it was
possible to to do without octplot running as a separate process. Now I
know better :)
2) octplot was written by me as a way to learn c++. It shows :( -- a
lot of code cleanup will have to be done
3) Inset your own here ....

Shai