Re: handle grapics with Document/View design

[jswensen]

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.
>
> jwe
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
password.
http://swenmac.homeip.net:8080/svn/handle_graphics/

John



----------------------------------------------------------------