Re: Access to variables internal to Octave

[jswensen]

Quoting Ole Jacob Hagen <address@hidden>:

> 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.

After looking at the glplot code, my implementation is very similar.  The only
real difference (Ole, I think the version of code of mine that you looked at
was one iteration old) is that I have separated the handles from the UI.
If anyone wants a more recent look, go to
http://www.swenmac.homeip.net:8080/svn/handle_graphics

As to Shai's question, in fact a ui_* class would need implemented for each
handle type to port mine to a different toolkit.

I suppose the setup I have right now could be modified slightly to be morphed
into a Document/View design.  Basically all the ui_* portion of the code would
be split off (rather than derived) and the only data passing between the
'handle' portion and the 'ui' portion would be the Document.

John

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