Re: Access to variables internal to Octave

[jswensen]

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

> On 16-Aug-2005, address@hidden 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.

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