[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Access to variables internal to Octave
From: |
Shai Ayal |
Subject: |
Re: Access to variables internal to Octave |
Date: |
Wed, 17 Aug 2005 12:20:05 +0300 |
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.
>
> ----------------------------------------------------------------
>
>
>
>