[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?
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.
----------------------------------------------------------------