Access to variables internal to Octave

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Access to variables internal to Octave

jswensen
As I have been doing an implementation of handle graphics, I am nearing
completion of the 'root' handle.  I do have a few questions though

1) For the root object, there are properties for things like Echo, Diary,
DiaryFile, etc.  I cannot retrieve the state of these by calling 'diary' or
'echo' using feval.  Is there some octave-internal function I can use to
retrieve the following values: echo (on or off), diary (on or off), diaryfile(
string name), format( short, long, short E, etc)?
2) Is there an octave-internal function to retrieve the terminal width and
height used by Octave?

I could go source digging, but if some of you know it off the top of your head,
it would save me time looking and give me more time for working on the handle
graphics.

FYI, the framework I set up for handle graphics is nearing completion.
Currently only 'root' and portions of 'figure' are done, but I did spend the
time to abstract the UI toolkit away from the core 'handles'.  My plan is to
complete root, figure, uicontrol, then start work on axes (through vtk).  A
design document will be forthcoming (hopefully in another week or two) to
describe the framework.

John

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


Reply | Threaded
Open this post in threaded view
|

Access to variables internal to Octave

John W. Eaton-6
On 16-Aug-2005, [hidden email] wrote:

| As I have been doing an implementation of handle graphics, I am nearing
| completion of the 'root' handle.  I do have a few questions though
|
| 1) For the root object, there are properties for things like Echo, Diary,
| DiaryFile, etc.  I cannot retrieve the state of these by calling 'diary' or
| 'echo' using feval.  Is there some octave-internal function I can use to
| retrieve the following values: echo (on or off), diary (on or off), diaryfile(
| string name), format( short, long, short E, etc)?
| 2) Is there an octave-internal function to retrieve the terminal width and
| height used by Octave?
|
| I could go source digging, but if some of you know it off the top of your head,
| it would save me time looking and give me more time for working on the handle
| graphics.

I haven't looked, but I think these are all just static variables in
the files that contain the corresponding functions.  You could either
propose a patch that exposes the variables themselves, or some
functions to return them (perhaps better, because it prevents people
from modifying the internal values apart from the current functions).

| FYI, the framework I set up for handle graphics is nearing completion.
| Currently only 'root' and portions of 'figure' are done, but I did spend the
| time to abstract the UI toolkit away from the core 'handles'.  My plan is to
| complete root, figure, uicontrol, then start work on axes (through vtk).  A
| design document will be forthcoming (hopefully in another week or two) to
| describe the framework.

It seems you are doing this in C++?  If so, is that really necessary?
Could it perhaps be accomplished in the scripting language instead?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Access to variables internal to Octave

jswensen
Quoting "John W. Eaton" <[hidden email]>:

> On 16-Aug-2005, [hidden email] wrote:
>
> | As I have been doing an implementation of handle graphics, I am nearing
> | completion of the 'root' handle.  I do have a few questions though
> |
> | 1) For the root object, there are properties for things like Echo, Diary,
> | DiaryFile, etc.  I cannot retrieve the state of these by calling 'diary' or
> | 'echo' using feval.  Is there some octave-internal function I can use to
> | retrieve the following values: echo (on or off), diary (on or off),
> diaryfile(
> | string name), format( short, long, short E, etc)?
> | 2) Is there an octave-internal function to retrieve the terminal width and
> | height used by Octave?
> |
> | I could go source digging, but if some of you know it off the top
> of your head,
> | it would save me time looking and give me more time for working on
> the handle
> | graphics.
>
> I haven't looked, but I think these are all just static variables in
> the files that contain the corresponding functions.  You could either
> propose a patch that exposes the variables themselves, or some
> functions to return them (perhaps better, because it prevents people
> from modifying the internal values apart from the current functions).
>
> | FYI, the framework I set up for handle graphics is nearing completion.
> | Currently only 'root' and portions of 'figure' are done, but I did
> spend the
> | time to abstract the UI toolkit away from the core 'handles'.  My
> plan is to
> | complete root, figure, uicontrol, then start work on axes (through vtk).  A
> | design document will be forthcoming (hopefully in another week or two) to
> | describe the framework.
>
> It seems you are doing this in C++?  If so, is that really necessary?
> Could it perhaps be accomplished in the scripting language instead?
>
> jwe
>

OK. I will look at submitting patches to expose these variables through some
sort of function interface.

As to your question, I am implementing it in C++.  I guess it isn't really
"necessary", but it is a language I am most familiar with and I don't have to
deal with some strange SWIG or other interface mechanism (which I am not
familiar with) to allow access to the UI toolkit from octave.  It also allows
the interface to be distributed as a single OCT file plus symbolic links.  I
have also found it easy to build and run on multiple platforms (OSX,
x86 Linux,
Windows).

I have tried to keep tabs on the handle graphics discussions that have taken
place on the mailing lists.  It seems like there has been a lot of talk, but
little work on implementation of a complete system.  If there are distinct
advantages to doing this in a scripting language (whether that be TK or
octave-gtk+M files), rather than a C++ OCT file, let me know.  If the reasons
are compelling enough, I guess it isn't too late to jump ship.  I just want to
get something working (and working well).

BASIC DESIGN (only shows one handle type, but holds true for all)
-------------------------------------------------------------------
octave_value        ui_handle
     |                 |
     |             ui_figure
   handle              |
     |            gtkmm_figure
     |                 |
     ----figure---------

              Property
                 |
     -------------------------------------------------------------------(...)
     |                   |                    |                    |
StringProperty     NumericProperty    CallbackProperty    
StringOptionsProperty
                                                                   |
                                                              OnOffProperty
(etc)

It may look a little complex, but it really isn't.  When a handle is under
development usually only the specific handle's class and the ui specific
handle's class are being edited.  Most of the others are pretty static.  All
classes except gtkmm_figure depend only on octave libraries.  Since the
interface is defined by the ui_figure class, implementing using a separate
toolkit (e.g. wxWidgets, QT, etc) is as simple as implementing a wx_figure or
qt_figure class.

I have been dedicating about an hour a night to this, and intend to keep up at
this pace if at all possible, so if anyone has suggestions I am open to
anything (including the possibility of switching to a scripting language).

John

P.S. Sorry for the essay.

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



Reply | Threaded
Open this post in threaded view
|

Re: Access to variables internal to Octave

Shai Ayal-2
I read you essay and there is something I don't understand:

you say that figure will have to be reimplemented for each graphics
toolkit. What about the lower level graphic objects (line,text etc...)
-- they will certainly have to differ between different toolkits

On 8/16/05, [hidden email] <[hidden email]> wrote:

> Quoting "John W. Eaton" <[hidden email]>:
>
> > On 16-Aug-2005, [hidden email] wrote:
> >
> > | As I have been doing an implementation of handle graphics, I am nearing
> > | completion of the 'root' handle.  I do have a few questions though
> > |
> > | 1) For the root object, there are properties for things like Echo, Diary,
> > | DiaryFile, etc.  I cannot retrieve the state of these by calling 'diary' or
> > | 'echo' using feval.  Is there some octave-internal function I can use to
> > | retrieve the following values: echo (on or off), diary (on or off),
> > diaryfile(
> > | string name), format( short, long, short E, etc)?
> > | 2) Is there an octave-internal function to retrieve the terminal width and
> > | height used by Octave?
> > |
> > | I could go source digging, but if some of you know it off the top
> > of your head,
> > | it would save me time looking and give me more time for working on
> > the handle
> > | graphics.
> >
> > I haven't looked, but I think these are all just static variables in
> > the files that contain the corresponding functions.  You could either
> > propose a patch that exposes the variables themselves, or some
> > functions to return them (perhaps better, because it prevents people
> > from modifying the internal values apart from the current functions).
> >
> > | FYI, the framework I set up for handle graphics is nearing completion.
> > | Currently only 'root' and portions of 'figure' are done, but I did
> > spend the
> > | time to abstract the UI toolkit away from the core 'handles'.  My
> > plan is to
> > | complete root, figure, uicontrol, then start work on axes (through vtk).  A
> > | design document will be forthcoming (hopefully in another week or two) to
> > | describe the framework.
> >
> > It seems you are doing this in C++?  If so, is that really necessary?
> > Could it perhaps be accomplished in the scripting language instead?
> >
> > jwe
> >
>
> OK. I will look at submitting patches to expose these variables through some
> sort of function interface.
>
> As to your question, I am implementing it in C++.  I guess it isn't really
> "necessary", but it is a language I am most familiar with and I don't have to
> deal with some strange SWIG or other interface mechanism (which I am not
> familiar with) to allow access to the UI toolkit from octave.  It also allows
> the interface to be distributed as a single OCT file plus symbolic links.  I
> have also found it easy to build and run on multiple platforms (OSX,
> x86 Linux,
> Windows).
>
> I have tried to keep tabs on the handle graphics discussions that have taken
> place on the mailing lists.  It seems like there has been a lot of talk, but
> little work on implementation of a complete system.  If there are distinct
> advantages to doing this in a scripting language (whether that be TK or
> octave-gtk+M files), rather than a C++ OCT file, let me know.  If the reasons
> are compelling enough, I guess it isn't too late to jump ship.  I just want to
> get something working (and working well).
>
> BASIC DESIGN (only shows one handle type, but holds true for all)
> -------------------------------------------------------------------
> octave_value        ui_handle
>      |                 |
>      |             ui_figure
>    handle              |
>      |            gtkmm_figure
>      |                 |
>      ----figure---------
>
>               Property
>                  |
>      -------------------------------------------------------------------(...)
>      |                   |                    |                    |
> StringProperty     NumericProperty    CallbackProperty
> StringOptionsProperty
>                                                                    |
>                                                               OnOffProperty
> (etc)
>
> It may look a little complex, but it really isn't.  When a handle is under
> development usually only the specific handle's class and the ui specific
> handle's class are being edited.  Most of the others are pretty static.  All
> classes except gtkmm_figure depend only on octave libraries.  Since the
> interface is defined by the ui_figure class, implementing using a separate
> toolkit (e.g. wxWidgets, QT, etc) is as simple as implementing a wx_figure or
> qt_figure class.
>
> I have been dedicating about an hour a night to this, and intend to keep up at
> this pace if at all possible, so if anyone has suggestions I am open to
> anything (including the possibility of switching to a scripting language).
>
> John
>
> P.S. Sorry for the essay.
>
> ----------------------------------------------------------------
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Access to variables internal to Octave

Ole Jacob Hagen-3
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 | Threaded
Open this post in threaded view
|

Re: Access to variables internal to Octave

Shai Ayal-2
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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Access to variables internal to Octave

jswensen
In reply to this post by Ole Jacob Hagen-3
Quoting Ole Jacob Hagen <[hidden email]>:

> 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

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