[Top][All Lists]

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

Re: Access to variables internal to Octave

From: jswensen
Subject: Re: Access to variables internal to Octave
Date: Tue, 16 Aug 2005 11:09:04 -0600
User-agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.10

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?


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,

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

    |                   |                    |                    |
StringProperty NumericProperty CallbackProperty StringOptionsProperty

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


P.S. Sorry for the essay.


reply via email to

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