Re: handle graphics

[jswensen]

I actually started a few months back on a handle graphics implementation as
native Octave types.  I didn't get a lot of it coded, but had the design
basically done.  Mine was tied intrinsically to GTKMM, but this didn't seem to
be a problem as I did my simple test on Cygwin(with X), Linux, and OSX. 
Basically, here is how I designed the implementation.

Every handle type derives from a base 'handle' class which in turn 
derives from
'octave_base_value'.  The 'handle' class defines two static STL maps of
<string,funcptr_get_property_handler> and 
<string,funptr_set_property_handler>.
  For a given class, this map is filled with the property names and their
associated handler member function.  Since I didn't have time to implement all
of them at the time, the 'handle' class has a default
unimplemented_set_property_handler and unimplemented_get_property_handler.

My initial tests only implemented the 'figure' class with the ability 
to set the
size and title.  I also implemented a 'uicontrol' (only with label and button
capabilities) to prove I could place it on the 'figure'.

I think my design should be good with one exception, caused by GTKMM.  
It has no
way of re-ording widgets, other than removing them an placing them on the
container again in the desired order.  This kindof looks weird (causes the
screen to flicker), but I figure the changing the z-order of widgets is not a
common thing to be done after startup.

With respects to plotting, I had talked with maintainer of the Octave<->VTK
plotting stuff and intended to use the VTKCanvas addon to GTKMM to do 
plotting.
This handles both 2D and 3D graphs quite well.

If anyone is interested in helping/continuing my work, I will send them what I
have so far.  I just got really busy at work and haven't touched it in about 4
months.  I had intended on showing it once I had a few handle objects fully
implemented (or nearly-fully implemented), but haven't got around to it.  I
think the design I gave will allow random people to implement unimplemented
properties, without breaking existing functionality.

I would appreciate anyone's comments on both the design and to measure 
the level
of interest.

John Swensen
address@hidden

Quoting "John W. Eaton" <address@hidden>:

> [I'm copying this to the graphics list, but since that is mostly
> dormant now, I'd prefer to discuss this on the maintainers list, so
> please reply there.  --jwe]
>
> Is anyone actively working on implementing handle graphics for Octave?
>
> I've been thinking about this recently.  My first thought was to
> create a structure array to describe the figure windows.  For example,
> something like
>
>  figures, a 1-d structure array.  Each element of the structure
>           array would contain all the information for a given figure
>           window and would contain the following fields:
>
>    title
>
>    ...
>
>    subplots, a 2-d structure array.  Each element of the structure
>              array would contain all the information for a given
>              subplot.
>
>      axis, a 1-d structure array.  Each element of the structure
>            array would contain all the information about the given
>            axis (element 1 is the x axis, element 2 is the y axis,
>            etc.) and would contain the following fields:
>
>        label
>        tics
>        ...
>
>      line, a 1-d struct array.  Each element of the structure array
>            would contain all the information about the given line in
>            the subplot and would contain the following fields:
>
>        style
>        width
>        label
>        data
>        ...
>
> This data structure would be stored in a global variable and would be
> manipulated by the various plotting functions.  For example, if the
> first plotting command were
>
>  plot (x, sin(x))
>
> then the global structure would be initialized to default values and
> filled in with the data for a single figure window with a single
> subplot area (filling the window).  The data for the sin(x) curve
> would be stored in the structure along with the plot description.  If
> the next command were
>
>  legend ("sin(x)");
>
> then the data structure would be modified to store "sin(x)" as the
> label for the first line of the current plot and the current figure
> would be redrawn given the data in the structure.
>
> Using this, we could implement various graphics backends, but all
> would share the same common set of functions to manipulate the global
> data structure that describes the state of the figures on the screen.
> Experimenting with various backends would be fairly easy (you would
> really only need to implement the function that takes the global data
> structure and displays it on the screen).  I imagine that it might
> even be possible to implement a backend using gnuplot.
>
> Next, I started looking at the properties for Matlab handle graphics
> so that I could see whether this could be done entirely in M-files or
> whether we would need a custom data structure and functions written in
> C++.  I was hoping to be able to do it all in M-files because it might
> be simpler to implement and debug.  Unfortunately, it doesn't seem
> that it would be easy to do.  For example, a call like
>
>  set (h, 'property', value)
>
> changes the value of the 'property' field in the data structure
> pointed to by the handle h.  So we can't pass the actual data
> structure around (because of the call-by-value semantics of
> Matlab/Octave).  It seems that Matlab graphics handles are some kind
> of pointer value encoded in a double object.  Using only the scripting
> language, how can we use something like that to lookup the location in
> a complex structure array?  One possibility would be that each
> graphics handle object type would have a ID field, and we could
> traverse the global data structure looking for the ID that matches.
> But that is likely to be slow.  Any ideas?
>
> Thanks,
>
> jwe



----------------------------------------------------------------