[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Access to variables internal to Octave

From: Shai Ayal
Subject: Re: Access to variables internal to Octave
Date: Wed, 17 Aug 2005 14:03:54 +0300

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]