[Top][All Lists]

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

Re: handle grapics with Document/View design

From: jswensen
Subject: Re: handle grapics with Document/View design
Date: Thu, 18 Aug 2005 08:57:34 -0600
User-agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.10

Quoting "John W. Eaton" <address@hidden>:

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.


I guess the two big advantages of maintaining the "Document" as an in-memory XML
representation is 2-fold.
1) The Schema can be used to easily enforce input limitations (only on/off)
2) There are things like XPath that allow the coder to easily find things in the
XML tree (e.g.  nodes = xpath_exec( "/root/children/*/[type='uicontrol']" )
would return all children of type uicontrol or node = xpath_exec( "/*/[id=24]"
) to get the node representing the handle with id 24 )  Note: I may have the
syntax wrong for the XPath statements, but you get the picture.

I guess as I think about it a little more, the design I currently have could
almost be considered a Document/View design.  There are a bunch of 'handles'
derived from a handle class.  Each of these handles contains a bunch of
properties derived from a Property class.  Whenever a property is set, I pass
the property onto the UI subsystem.  Whenever a UI callback occurs, the
property is modified.

As to finding the proper handle, the functions I have implemented so far (get
and set) allow the user to pass in either a 'handle' or an integer.  If an
integer, it looks the associated handle up from the handle tree.  If a handle,
it just uses it.  In order to make the handle show up in octave properly, the
'print' member of octave_value was overloaded to display the handle id.

So I guess I am a little confused now.  I really want to do what the core
maintainers of Octave want done. I have quite a bit of work done in my current
implementation and it doesn't really seem that far from being a Document/View
design as-is.

So I guess my question is whether a design based around the following concepts:
(1) a set of classes representing the 20-25 handle types
(2) each handle containing a set of various properties
(3) the sole interface between the DOC (handles+properties) and the VIEW
(whatever UI toolkit that may be) is the passing of the modified property,
whether the be a set operation from DOC to VIEW or a callback from VIEW to DOC

If it is acceptable, then my current code is really close.  If not, then it
needs a rehash.  I guess I would prefer to use just C++ and the octave
libraries for the DOC portion, since all adding XML would do is add another
library dependency.

Also, I think the link to my code that I gave yesterday was messed up. Here is
it again for anyone that is interested.  Use the name: anonymous  and an empty



reply via email to

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