Re: Minimal requirements from a handle graphics package

[Shai Ayal]

Hi Ole,

> image
> uicontrol
> uimenu
> uicontextmenu
> light
> rectangle
> Command: delete must be included.

I'm OK with that

>
> And which M*lab version should our handle graphics package be compatible
> with?
> R11, R12, R13, R14? Mathworks has redesigned their handle graphics
> package, from R13 to R14.
>
> Should we strive for R11 or R13 compatibility ?

lets go for the version w/o the "group" objects.

> You can also find similar low-level functions  in oplot as well. You can
> browse online here:
> http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/src/octave/
>
> You'll find that both octplot and oplot has the same low-level
> functions. They both are dispatching, creating aliases for their functions.
> The low level function set/get are used in a similar way in both octplot
> and oplot
>
> Oplot version of set/get calls oplotcom(....), while octplot versions
> calls the octplot_command(....)

good. This is precisely my point -- lets now share the high level functions

> See examples at the end of this mail. So octplot and oplot is more
> alike, than you would like to prefer, I guess. Octplot uses also a
> similar toogle mechanism as enabling/disabling usage of graceplot.
> These m-files can be retrieved from octave-forge. It handles the order
> of the search directories in the loadpath used in Octave.

nice, but I don't see toggle as place to enforce a standard. lets
leave it to individual packages on how to invoke them.

> Oplot uses props for handle graphics storage, while octplot is a
> Props-less implementation...This it not entirely true, or is it Shai?
> You are calling MAKE_REF(...) to make properties available to both read
> and write.
>
> I can see that you've created your own Props-similar implementation? I
> am refering to the prop-prefixed cpp-source files in octplot.

Every handle graphics objects should have properties, and as such I
have a "Props" implementation by definition. I am not sure it is
similar to yours -- props has a better design in that it is separate
from the "drawing engine. In octplot they are intertwined -- I am not
a very good software designer.


> Therefore I would say and claim that octplot and oplot is very alike.
> Same principles, but different software design in some areas.
>
> Besides, we have exchanged files from each other.
>
> The handle graphics functionality restricts developers in designing and
> implementing visualisation application to octave supporting handle
> graphics.
>
> The same minimum amount of low-level functions have to be shipped: line,
> surface, image, patch, text, figure, axes, set, get and delete.  These
> must be shipped to ensure minimal visualisation functionality.
>
> This require that the following graphic objects are supported: root,
> figure, axes, line, surface, patch, image and text.

You agree with me than ?

> If octave shall provide a library for the graphical objects at all, the
> Props library or a similar library would be preferable. Props can be
> used internally by Octave, or by the visualisation application. It
> should be noticable that Props used internally inside Octave doesn't do
> any visualisations. For a graphic less props browse
> http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/props/octave/
>
> This could be nice to use, if you want to handle/experiment with handle
> graphics without visualisation, and to experiment on how props really
> works.
>
> Props was designed and developed during a bachelor thesis written by my
> brother, Hans O.

This is another issue which I was trying to avoid in this thread --
How the handle graphics system is implemented. JWE wants it top be all
m-files, Ole wants it to be props and Shai doesn't really care since
octplot does this internally. So lets bypass this area of disagreement
on the "wiring" of handle graphics and concentrate on what we can
collaborate on -- the low-level functions.

Shai