Re: handle graphics

[Shai Ayal]

 would like to sum up the ideas presented in this thread as I see them
up to now:

In order to present the idea we can think of the tree structure as a document.

Octave will maintain the document, i.e.  the whole handle graphics
tree. Octave will be responsible for the consistency of the tree, e.g.
check that property values are legal etc....  A graphics front (GF)
will have to be 3 things:

1. A "viewer": Given the document from Ocatve GF will display it.
2. An "editor", since it can change the document e.g. by using a mouse
to zoom-in which changes the limits property of the current axis. This
will have to be done through octave functions so that consistency will
be maintained.
3. A source of events, in the case of calling callbacks for UI objects.

So to make this work we need:
1 A way for thr GF to read the document -- duplicating it and sending
it over a socket will not be good since it could contain a large set
of data to be plotted. Shared memory seems the most natural, but I'm
not sure it quite works on cygwin.
2 A way for the GF to execute octave commands, either for changing
properties or for calling UI callback functions

I see two separate projects on the octave side of this:

1. the octave<->GF communication layer - care has to be taken that
this will work on all major platforms, e.g Linux/Unix, OSX, cygwin
2. maintaining the document. To me this is a huge and quite tedious
project -- mostly checking input arguments and such. references for
the document structure can be found at:
http://www.mathworks.com/access/helpdesk/help/techdoc/infotool/hgprop/doc_frame.html
of course it can be implemented incrementally.

Shai

On 7/14/05, John W. Eaton <address@hidden> wrote:
> On 14-Jul-2005, Shai Ayal wrote:
> 
> | One note on properties: I think some of them need to be new octave
> | types. The types of properties I am already aware of:
> |
> | types which exist in octave:
> | scalar
> | vector
> | matrix
> | string
> | bool
> |
> | types which don't exist in octave yet:
> | * multiple choice or radio button type: where you can choose one of a
> | limited sets of values
> | * color: can be either a RGB vector or a basic color name (e.g.
> | "r","g","b","c",...)
> | * a combination of the above two: e.g. something which can be either
> | "none" or a basic color or a RGB vector
> 
> I don't think we really need new primitive data types for these.  We
> can express them using existing primitive types.
> 
> | This also raises the following question: Who will be responsible for
> | checking the values of the properties? will octave do it before
> | passing it to the GUI or will the GUI do it?
> 
> I think Octave should verify the properties and ensure the
> consistency of the data structure that describes the graphics.
> 
> jwe
> 
>