octave-maintainers
[Top][All Lists]
Advanced

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

handle grapics with Document/View design


From: John W. Eaton
Subject: handle grapics with Document/View design
Date: Thu, 18 Aug 2005 10:00:01 -0400

On 18-Aug-2005, address@hidden wrote:

| I went back and re-read jwe's email (and responses) concerning a
| Document/View design and realize that it is a much better solution.
| I don't think the work I have done so far has been in vain, though,
| since it got me more familiar with octave internals, etc.
| 
| I want to shoot some ideas by everyone before I start work on this
| one, to see if I understand your concept of a Doc/View design, as
| well as how those who are really maintainers view integration with
| octave.
| 
| ----------------------           -------------------------
| |  handle graphics   |           |  handle graphics view |
| |        DOC         |<--------->|        VIEW           |
| |                    |           | (gtkmm in my case)    |
| ----------------------           -------------------------
|           ^
|           |                      ----------------
|           |                      |              |
|           |--------------------->|    Octave    |
|                                  |              |
|                                  ----------------
| 
| I spent a little time last night toying around with an XML schema
| and believe that the DOC can be an XML file (with an associated
| schema).  Thus, the DOC will *be* an XML file and the communication
| between the DOC and VIEW will be a validatable subset of the whole
| document.  The interface between Octave and the DOC will be the
| standard get, set, gcf, etc.

I don't know much about XML, but I would guess that you could
represent the data in an XML format.  I was not thinking about XML,
but rather that Octave would maintain a data structure (probably in an
Octave struct array) that would describe the current state of the handle
graphics.  This struct would be available to the code that displays
the graphics (in whatever form).  Probably the display code would only
be invoked by the drawnow function.  There may be some details to work
out (like how to keep it from blocking Octave input while handling a
lot of data, etc.) but I think that can be handled with threads or
separate processes for viewing the data and some kind of signals for
communication.  Callbacks will also need some thought.  But the basic
idea is that Octave should manage the data and the viewer should only
be responsible for displaying it.  This way, I think you could write
the part of the code that manages the handle graphics data for Octave
(in the absence of callbacks anyway) so that it would work without a
display at all (i.e., drawnow does nothing, or just shows you the
current data structure for debugging).

If it is most convenient for your viewer to have an XML document to
work with, then I think you could convert the internal Octave struct
array to the XML format before passing it to your viewer.  But I don't
see why Octave would need to manipulate an XML document directly.  But
as I said, I don't know much about XML, so maybe I'm missing
something.  What would be the advantage of having Octave work directly
with an XML representation, and how would that be different than just
having an internal struct array to represent the data?

One question I have about this approach is whether it is possible to
implement the "handle" object (apparently a specially encoded number)
that Matlab uses in the scripting language.  How do you take this
number and find the appropriate part of the data structure that
represents the handle graphics state?  I think you need to do this so
you can modify the global data structure given just the handle of a
small part of it.  It seems to me that this operation would be easy to
do in C++ because the number could be converted to a pointer into the
data structure.  But Octave does not have pointers, so it needs to be
done in some other way, perhaps by searching the structure for some ID
tags.  But that might be slow (or perhaps not -- I think we would have
to do some experiments).  If simple lookups based on ID tags are too
slow, then maybe we need some additional feature in the language to
allow quick lookups of data in a structure given a "pointer".

| At some point (once the DOC portion is fairly well developed), I
| think it will make sense to have Octave push the values of certain
| items (e.g. diary state and filename, echo state, etc <mostly root
| handle properties>) into the document when they are set in the
| Octave environment.

Sure, that could be a useful place to store these kinds of things.
Perhaps also things like "page_screen_output" that are currently
built-in variables could also go in the list of root properties.  That
could provide a nice way to organize them as well.

jwe



reply via email to

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