Re: Access to variables internal to Octave

[Shai Ayal]

I think that if you want a generic handle graphics interface, the
Document/Viewer approach outlined by jwe on the previous thread is the
way to go.

Is someone working on it?

I don;t have enough knowledge on octave internals to produce the new
octave type needed for the handle graphics tree, but if someone were
to do that I'll be willing to do other stuff in this project (subject
to my scarcely available free time).
I can do c++ & m-file

Shai

On 8/17/05, Ole Jacob Hagen <address@hidden> wrote:
> Hi,
> 
> I have looked at the source code by John Swensen.
> It seems to me that it's inspired by GLPlot at sourceforge,
> http://sf.net/project/glplot.
> I knew I had seen this implementation before.
> 
> Besides of a qt_figure, you'll need to make dedicated classes to
> different widget and opengl-library.
> 
> Using qt and opengl
> qt_figure, qt_axes, qt_text, qt_line, qt_patch, qt_surface,
> qt_ui_figure, qt_ui_menu
> 
> Using qt and vtk:
> qt_vtk_figure, qt_vtk_axes, qt_vtk_text, qt_vtk_line, qt_vtk_patch,
> qt_vtk_surface.
> 
> Using WxWidgets, tcl/tk, gtk and other widget libraries will also
> require their own implementation.
> 
> How can we configure Octave using different widget-libraries? Should
> this be used runtime by using octaverc, or be done during
> compilation/building of Octave?
> 
> I don't think Octave should be responsible of shipping octave-qt,
> octave_qt_vtk, octave_wxwidget, and so on.
> I think this should be maintained as an external library. Octave can
> ship a template how handle graphics properties can be implemented by
> giving a small example.
> 
> 
> Cheers,
> 
> Ole J.
> 
>