Re: Handle graphics again

[John W. Eaton]

On 13-Feb-2006, Sebastien Loisel wrote:

| On 2/13/06, John W. Eaton <address@hidden> wrote:
| >
| > OTOH, we seem to also be developing N implementaitons of the code that
| > manages the handle graphics data.  I would much prefer to have Octave
| > manage this data in one consistent and mostly Matlab-compatible way.
| >
| 
| Ok, a real quick comment.
| 
| I just looked at your tarball. I don't know if I'm shooting for the same
| thing as you, you tell me. I would like my code to be structured like yours,
| except that:
| 
| a) I don't want to parse gnuplot, so all the fprintf and fputs are replaced
| by calls to functions in oct files.

Any part of my example handle-graphics code that interacts with
gnuplot is part of the "graphics backend" and is not really what I
want to discuss right now.  The part that will be common to all
graphics and GUI tools, and the part that I think should be written
just once, and be a part of Octave, is the part that manages the data
structure that defines the plot.  This is what is manipulated by the
set and get functions.

Currently in my code, the drawnow function opens a connection to
gnuplot directly, but this is not quite what I want.  Instead, it
should call a backend-specific drawnow function that handles plotting
for the currently active graphics backend.

| b) To reduce the number of such oct files, I was going to put all those
| things you're printing in a cell array, and then call one master C++
| function that parses the cell array and displays the plot.

I think that is essentially what I have now, except the data structure
is a struct array instead of a cell array (it turned out to make more
sense to me to have a struct array).  The data that goes in the
structure array is just the properties and data that describe a plot.
None of it should be specific to a particular plotting package.

jwe