Re: Access to variables internal to Octave

[Shai Ayal]

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, address@hidden <address@hidden> wrote:
> 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.
> 
> ----------------------------------------------------------------
> 
> 
> 
>