handle graphics

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

handle graphics

John W. Eaton-6
[I'm copying this to the graphics list, but since that is mostly
dormant now, I'd prefer to discuss this on the maintainers list, so
please reply there.  --jwe]

Is anyone actively working on implementing handle graphics for Octave?

I've been thinking about this recently.  My first thought was to
create a structure array to describe the figure windows.  For example,
something like

  figures, a 1-d structure array.  Each element of the structure
           array would contain all the information for a given figure
           window and would contain the following fields:

    title

    ...

    subplots, a 2-d structure array.  Each element of the structure
              array would contain all the information for a given
              subplot.

      axis, a 1-d structure array.  Each element of the structure
            array would contain all the information about the given
            axis (element 1 is the x axis, element 2 is the y axis,
            etc.) and would contain the following fields:

        label
        tics
        ...

      line, a 1-d struct array.  Each element of the structure array
            would contain all the information about the given line in
            the subplot and would contain the following fields:

        style
        width
        label
        data
        ...

This data structure would be stored in a global variable and would be
manipulated by the various plotting functions.  For example, if the
first plotting command were

  plot (x, sin(x))
           
then the global structure would be initialized to default values and
filled in with the data for a single figure window with a single
subplot area (filling the window).  The data for the sin(x) curve
would be stored in the structure along with the plot description.  If
the next command were

  legend ("sin(x)");

then the data structure would be modified to store "sin(x)" as the
label for the first line of the current plot and the current figure
would be redrawn given the data in the structure.

Using this, we could implement various graphics backends, but all
would share the same common set of functions to manipulate the global
data structure that describes the state of the figures on the screen.
Experimenting with various backends would be fairly easy (you would
really only need to implement the function that takes the global data
structure and displays it on the screen).  I imagine that it might
even be possible to implement a backend using gnuplot.

Next, I started looking at the properties for Matlab handle graphics
so that I could see whether this could be done entirely in M-files or
whether we would need a custom data structure and functions written in
C++.  I was hoping to be able to do it all in M-files because it might
be simpler to implement and debug.  Unfortunately, it doesn't seem
that it would be easy to do.  For example, a call like

  set (h, 'property', value)

changes the value of the 'property' field in the data structure
pointed to by the handle h.  So we can't pass the actual data
structure around (because of the call-by-value semantics of
Matlab/Octave).  It seems that Matlab graphics handles are some kind
of pointer value encoded in a double object.  Using only the scripting
language, how can we use something like that to lookup the location in
a complex structure array?  One possibility would be that each
graphics handle object type would have a ID field, and we could
traverse the global data structure looking for the ID that matches.
But that is likely to be slow.  Any ideas?

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Brian Blais
John W. Eaton wrote:
> Is anyone actively working on implementing handle graphics for Octave?
>
> I've been thinking about this recently.  My first thought was to
> create a structure array to describe the figure windows.  

Although I haven't worked on it for graphics, I did make a quick
handle-based GUI implementation, using FLTK as a backend.  You can see
it at http://web.bryant.edu/~bblais/octave/

I used a structure array, and the handle passed is the index into that
structure array.  All of the handle manipulation is in the m-files.

>  It seems that Matlab graphics handles are some kind
> of pointer value encoded in a double object.  Using only the scripting
> language, how can we use something like that to lookup the location in
> a complex structure array?

I think that the matlab handle is something like:

        figure_number+object_number/100000

so you can get both the figure number and object number from some simple
math.  if you count all objects (including figures) as equal, then you
don't need a double value.

                       
                        Brian Blais



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

             [hidden email]
             http://web.bryant.edu/~bblais

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Shai Ayal-2
In reply to this post by John W. Eaton-6
John,

Octplot is active (well, at least not dormant) and so is oplot I
think. They both implement handle graphics. There is also CMO, which
is a bit more abstract.

The way I implement handle graphics in octplot is to make distinction
between objects (figure,axes,line ....) and properties (color,
position, width ....), just like matlab.

So each object has a unique handle and through it you can access all
it's properties. To support the hierarchy of objects, each objects
also has a "parent" property and might have "children" properties,
holding the handles of parent/children.

My code is a stand-alone application accepting commands through a
socket connection with octave, since at the time I didn't have time to
delve into the mysteries of octave c++ implementation. In retrospect
it was probably a mistake.

In your proposal there is no clear distinction between object and
properties, in a sense everything is a property of the "root". This is
a nice idea, but incompatible with matlab where an object has an
handle and properties don't have one. This kind of structure can be
coerced on your proposed structure by denoting some properties as
special and giving direct access to them using a handle (i.e. all
figures will have handles, but the titles won't). As usual matlab
compatibility makes us use less than optimal coding.

Stated your way the whole graphics back-end becomes a rendering issue,
like the document/view style of programming where the structure is the
document and and the back-end is a viewer. I like it.

Shai Ayal

On 7/12/05, John W. Eaton <[hidden email]> wrote:

> [I'm copying this to the graphics list, but since that is mostly
> dormant now, I'd prefer to discuss this on the maintainers list, so
> please reply there.  --jwe]
>
> Is anyone actively working on implementing handle graphics for Octave?
>
> I've been thinking about this recently.  My first thought was to
> create a structure array to describe the figure windows.  For example,
> something like
>
>   figures, a 1-d structure array.  Each element of the structure
>            array would contain all the information for a given figure
>            window and would contain the following fields:
>
>     title
>
>     ...
>
>     subplots, a 2-d structure array.  Each element of the structure
>               array would contain all the information for a given
>               subplot.
>
>       axis, a 1-d structure array.  Each element of the structure
>             array would contain all the information about the given
>             axis (element 1 is the x axis, element 2 is the y axis,
>             etc.) and would contain the following fields:
>
>         label
>         tics
>         ...
>
>       line, a 1-d struct array.  Each element of the structure array
>             would contain all the information about the given line in
>             the subplot and would contain the following fields:
>
>         style
>         width
>         label
>         data
>         ...
>
> This data structure would be stored in a global variable and would be
> manipulated by the various plotting functions.  For example, if the
> first plotting command were
>
>   plot (x, sin(x))
>
> then the global structure would be initialized to default values and
> filled in with the data for a single figure window with a single
> subplot area (filling the window).  The data for the sin(x) curve
> would be stored in the structure along with the plot description.  If
> the next command were
>
>   legend ("sin(x)");
>
> then the data structure would be modified to store "sin(x)" as the
> label for the first line of the current plot and the current figure
> would be redrawn given the data in the structure.
>
> Using this, we could implement various graphics backends, but all
> would share the same common set of functions to manipulate the global
> data structure that describes the state of the figures on the screen.
> Experimenting with various backends would be fairly easy (you would
> really only need to implement the function that takes the global data
> structure and displays it on the screen).  I imagine that it might
> even be possible to implement a backend using gnuplot.
>
> Next, I started looking at the properties for Matlab handle graphics
> so that I could see whether this could be done entirely in M-files or
> whether we would need a custom data structure and functions written in
> C++.  I was hoping to be able to do it all in M-files because it might
> be simpler to implement and debug.  Unfortunately, it doesn't seem
> that it would be easy to do.  For example, a call like
>
>   set (h, 'property', value)
>
> changes the value of the 'property' field in the data structure
> pointed to by the handle h.  So we can't pass the actual data
> structure around (because of the call-by-value semantics of
> Matlab/Octave).  It seems that Matlab graphics handles are some kind
> of pointer value encoded in a double object.  Using only the scripting
> language, how can we use something like that to lookup the location in
> a complex structure array?  One possibility would be that each
> graphics handle object type would have a ID field, and we could
> traverse the global data structure looking for the ID that matches.
> But that is likely to be slow.  Any ideas?
>
> Thanks,
>
> jwe
>
>

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

John W. Eaton-6
On 12-Jul-2005, Shai Ayal wrote:

| In your proposal there is no clear distinction between object and
| properties, in a sense everything is a property of the "root".

Maybe my description wasn't clear.  The structure I presented was a
form of a tree, and at each level of the tree, you would have some
properties and some other graphics objects.  I think we could further
simplify this so that each graphic object is a structure with four
elements:

  id            a serial number, so we can look up this object given a handle
  parent-id     so we can go up the structure if necessary
  properties    a structure array of (name, value) pairs
  children      an array of other graphics objects

jwe

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Ole Jacob Hagen-3
Hi,

Oplot is active, as Shai Ayal mentioned.

Me and a professor is writing on a paper about Oplot and Octave.

Oplot is "callback"-based with changes and updates in Props.
Props is our implementation of handle graphics.
Props returns matrices, strings, struct arrays and so on.
Root, Figure, Axes, Line, Text and Image is implemented in some degree.
Line, and Text works.
Image needs some work.
Surface needs a refactory.


Will describe Oplot and Props implementation later.

Cheers,

Ole J.

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Driss Ghaddab-2
In reply to this post by Shai Ayal-2
Quoting Shai Ayal <[hidden email]>:

> John,
>
> Octplot is active (well, at least not dormant) and so is oplot I
> think. They both implement handle graphics. There is also CMO, which
> is a bit more abstract.
>

Hi,

CMO is on hold, as I am moving and just changed my job.
John, please see http://driss.ghaddab.free.fr/cmo/ to get a feeling of
what CMO
is.  Its aim is to provide also an class hierarchy. But the objects are
managed
by an external module that is run in a parallel thread.

When the user accesses an object property or method, the object transfer the
request to the module thread and the module responds to the request
(but it can
also be programmed to access or execute the method in the Octave thread). It
also implements callbacks, event queue etc. The event queue mimics Matlabs
behaviour. Objects have unique identifiers and they are a new Octave
data type.
The 'set' command accepts both a CMO object or the unique identifier (an
integer, as currently implemented).  Apart of the "set(obj, 'Property',
value)"
syntax, CMO also allows the "obj.Property = value" and "obj.method ()"
syntaxes.

CMO is indeed more abstract, as it is primarly intended as a framework to
develop concurrent modules running in parallel threads. (cygwin supported,
too).  As soon as things settle a bit here, I'll start the Octave's Graphics
Module, OGM.

OGM will first be abstract, too.  And at first it will only implement GUI
capabilities leaving plotting capabilities to gnuplot or other plotting
engines.  I planned it this way because I am the only developer, and I prefer
to advance step by step.

Cheers,


Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Shai Ayal-2
In reply to this post by John W. Eaton-6
I kind of liked the idea of no distinction between objects and
properties, but never mind.

As you can see from the other responses to your email, at least 3
projects are actively pursuing this goal. All 3 have implemented this
tree structure, each in a different way. If indeed emulating matlab
handle graphics will become an "official" goal of octave, this could
be manifested by have an "official" object/property tree in octave as
you propose.

Shai

On 7/12/05, John W. Eaton <[hidden email]> wrote:

> On 12-Jul-2005, Shai Ayal wrote:
>
> | In your proposal there is no clear distinction between object and
> | properties, in a sense everything is a property of the "root".
>
> Maybe my description wasn't clear.  The structure I presented was a
> form of a tree, and at each level of the tree, you would have some
> properties and some other graphics objects.  I think we could further
> simplify this so that each graphic object is a structure with four
> elements:
>
>   id            a serial number, so we can look up this object given a handle
>   parent-id     so we can go up the structure if necessary
>   properties    a structure array of (name, value) pairs
>   children      an array of other graphics objects
>
> jwe
>

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

N Smethurst
In reply to this post by John W. Eaton-6
So after ignoring us for years, John finally decides to take an interest
in what must be considered the biggest downfall of an otherwise
excellent numeric software system.

I must admit that I lost most of my interest in developing KVisualiser
after having failed to attract even the smallest amount of help from the
core Octave developers - i.e. those who really understand the (difficult
to understand) inner workings of the C++ code. My project has been on
hold for a while now, and I am reluntant to restart it unless I see some
positive action to create a plugin based handle graphics hierarchy in
Octave.

Ole and I discussed this issue to death in 2002/2003. All we need is
that someone with an intimate understanding of the C++ code in Octave
creates a plugin based framework consisting of an octave_value based
class hierarchy based on the handle graphics hierarchy. We (everyone
interested in creating visualisation applications that work with Octave)
would then be responsible for doing everything else.

What we cannot easily do is understand the poorly documented internals
of the Octave code base. We need someone like John to do that.

Nicholas


John W. Eaton a écrit :

>[I'm copying this to the graphics list, but since that is mostly
>dormant now, I'd prefer to discuss this on the maintainers list, so
>please reply there.  --jwe]
>
>Is anyone actively working on implementing handle graphics for Octave?
>  
>

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

John W. Eaton-6
In reply to this post by Shai Ayal-2
On 12-Jul-2005, Shai Ayal wrote:

| I kind of liked the idea of no distinction between objects and
| properties, but never mind.

If we put all the properties for a given object together in a
structure array, then listing all the possible property names for a
given object is trivial:

  fieldnames (object.properties)

so I think there is some advantage.

| As you can see from the other responses to your email, at least 3
| projects are actively pursuing this goal. All 3 have implemented this
| tree structure, each in a different way. If indeed emulating matlab
| handle graphics will become an "official" goal of octave, this could
| be manifested by have an "official" object/property tree in octave as
| you propose.

Yes, think it would be bad to have N separate implementations of this.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Shai Ayal-2
To me is seems that CMO, being the most abstract, will probably be a
good start. However I know almost nothing about it, so Driss will have
to fill us in on this.

>From the little he did write, it is almost struct like in the sense
that object.property syntax is already implemented and it does have
facilities to communicate with external modules.

Shai

On 7/13/05, John W. Eaton <[hidden email]> wrote:

> On 12-Jul-2005, Shai Ayal wrote:
>
> | I kind of liked the idea of no distinction between objects and
> | properties, but never mind.
>
> If we put all the properties for a given object together in a
> structure array, then listing all the possible property names for a
> given object is trivial:
>
>   fieldnames (object.properties)
>
> so I think there is some advantage.
>
> | As you can see from the other responses to your email, at least 3
> | projects are actively pursuing this goal. All 3 have implemented this
> | tree structure, each in a different way. If indeed emulating matlab
> | handle graphics will become an "official" goal of octave, this could
> | be manifested by have an "official" object/property tree in octave as
> | you propose.
>
> Yes, think it would be bad to have N separate implementations of this.
>
> jwe
>

Reply | Threaded
Open this post in threaded view
|

Oplot, Props and Octave supports handle graphics.

Ole Jacob Hagen-3
In reply to this post by N Smethurst
Oplot, Props and Octave works pretty good with eachother...I think.... :-)

Oplot consists of a transport-channel, visualisation, and octave-module.
This octave-module forks Oplot, and sends data to Oplot by using the
transport-module. On Linux unix domain sockets is used.

This octave-module can be easily modified to also implement tcp/ip or
pipes.
The Oplot-application is able to send back data to Octave, by using the
same transport-module as the octave-module.

Usage of Props-code only exists in Oplot, and not in Octave.
The octave-module can transmit and receive datatypes such as: struct,
matrix, mxnx3 matrices, numbers, strings.
Support of new datatypes can be easily added in oplotcom.cc i
$(OPLOT)/src/octave. Remember duplex support. :-)

Props is an independent library in Oplot, where callback and
initiatiation are handled.
Oplot is only using Props-library, and is setting callbacks to
determined classes.

Callbackinterface-class in Props is a parent-class, and is inherited by
RootCallbackInterface and FigureCallbackInterface.

RootCallbackInterface is used and inherited by OpFigureManager-class in
Oplot.
RootCallbackInterface is initialised by the following line in
OpFigureManager's ctor:

    Root::instance().setRootCallbackInterface(*this*);


FigureCallbackInterface is used and inherited by OpFigureWindow-class in
Oplot.
FigureCallbackInterface is initialised by a the following line in
OpFigureManager::new_figure(Props::Figure* fig):

int
OpFigureManager::new_figure( Figure* fig) {

    OpFigureWindow* fw = *new* OpFigureWindow(fig, *this*);
    QPoint pos(420,500);
    QSize sz = *this*->parentWidget(*true*)->size();
    fig->setCallbackInterface(fw);
    fw->setPosition(pos,sz);
    *this*->addFigureWindow(fw, (int) fig->getHandle());
    *return* 0;
}


Axes-Callbacks, Line-Callbacks, Image-Callbacks, Text-Callbacks are
initialised in a similar fashion:

Axes-Callbacks:

int
OpFigureWindow::new_axes( Axes* ax) {
    OpAxesObject *opax = *new* OpAxesObject(ax, *this*,m_axNum);
    ax->setCallbackInterface(opax);
    m_axNum++;
    *return* 0;
}


Initialisation of callbacks and creation of new child of Axes-object
such as Text, Line, Image is created like this:
Guess how Surface, Patch and Rectangle-object should be initialised?

int
OpAxesObject::new_child( Object* p,  Object* c) {
    const std::string* child = c->get_string("Type");
    *if*(*child == "Text") {
        Text *text = *static_cast*<Text *>(c);
        OpTextObject *textObject = *new* OpTextObject(text, *this*);
        text->setCallbackInterface(textObject);
        m_textComponents.push_back(textObject);
    } *else* *if*(*child == "Line") {
        Line* line = *static_cast*<Line*>(c);
        OpLineObject *lineobject = *new* OpLineObject(line, *this*);
        line->setCallbackInterface(lineobject);
        }
        m_visComponents.push_back(lineobject);
    } *else* *if*( *child == "Image") {
        Image *image = *static_cast*<Image *>(c);
        OpImageObject *imageObject = *new* OpImageObject(image, *this*);
        image->setCallbackInterface(imageObject);
        m_visComponents.push_back(imageObject);
    }
    *return* 0;
}


I present to you Oplot with Props and Octave.
e.g root = get(0); root.Clipping <enter> gives "on" as output.

Setting properties such as set(handle_value, 'property_name',
property_value) is of course possible.
Getting properties with get(handle_value, 'property_name') returns the
property_value that is contained in property_name in handle_value...


Available properties and handle graphics objects supported by Props, and
Oplot are presented at the bottom of this email.


Cheers,


Ole J.



>
>
>
>
> root: root = get(0) gives
> root =
> {
>   BusyAction = queue
>   ButtonDownFcn =
>   Children = [](0x0)
>   Clipping = on
>   CreateFcn =
>   CurrentFigure = [](0x0)
>   DeleteFcn =
>   ErrorMessage =
>   HandleVisibility = on
>   HitTest = on
>   Interruptible = yes
>   Parent = [](0x0)
>   ScreenDepth = 16
>   ScreenSize =
>
>     0  0  0  0
>
>   Selected = off
>   SelectionHighlight = no
>   Tag =
>   Type = Root
>   Units = centimeters
>   UpdateScene = on
>   UserData =
>   Visible = on
> }
>
> fig = get(gcf) gives:
>
> fig =
> {
>   Alphamap = [](0x1)
>   BackingStore = on
>   BusyAction = queue
>   ButtonDownFcn =
>   Children = 146.41
>   Clipping = on
>   Color =
>
>     0.80000  0.80000  0.80000
>
>   Colormap = [](0x3)
>   CreateFcn =
>   CurrentAxes = 146.41
>   DeleteFcn =
>   Dithermap = [](0x3)
>   Dithermapmode = manual
>   DoubleBuffer = off
>   FixedColors = [](0x3)
>   HandleVisibility = on
>   HitTest = on
>   Interruptible = yes
>   MenuBar = figure
>   MinColormap = 0
>   Name =
>   NextPlot = add
>   NumberTitle = on
>   Parent = 0
>   Pointer = arrow
>   PointerShapeCData =
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>     0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>
>   PointerShapeHotSpot =
>
>     0
>     0
>
>   Position =
>
>     420  500  600  500
>
>   Renderer = patiners
>   RendererMode = auto
>   Resize = on
>   Selected = off
>   SelectionHighlight = no
>   ShareColors = yes
>   Tag =
>   Type = Figure
>   Units = pixels
>   UserData =
>   Visible = on
>   WindowStyle = normal
> }
>
> ax = get(gca) gives:
>
>
> ax =
> {
>   Box = off
>   BusyAction = queue
>   ButtonDownFcn =
>   CameraPosition =
>
>     0  0  7
>
>   CameraPositionMode = auto
>   CameraTarget =
>
>     0  0  0
>
>   CameraUpVector =
>
>     0  1  0
>
>   Children =
>
>     194.71  116.84  193.48  134.74  125.46  196.92
>
>   Clipping = on
>   ColorOrder =
>
>     0  0  1
>     0  1  0
>     1  0  0
>     0  1  1
>     1  0  1
>     1  1  0
>
>   CreateFcn =
>   DataAspectRatio =
>   1  1  1
>
>   DataAspectRatioMode = auto
>   DeleteFcn =
>   HandleVisibility = on
>   HitTest = on
>   Interruptible = yes
>   NextPlot = add
>   Parent = 1
>   PlotBoxAspectRatio =
>
>     1  1  1
>
>   PlotBoxAspectRatioMode = auto
>   Position =
>
>     0.13000  0.11000  0.77500  0.81500
>
>   Projection = orthographic
>   Selected = off
>   SelectionHighlight = no
>   Tag =
>   Title = 176.29
>   Type = Axes
>   Units = normalized
>   UserData =
>   View =
>
>      0  90
>
>   Visible = on
>   XGrid = off
>   XLabel = 189.24
>   XLim =
>
>     0  1
>
>   XLimMode = auto
>   XTick =
>
>    Columns 1 through 7:
>
>     0.00000  0.10000  0.20000  0.30000  0.40000  0.50000  0.60000
>
>    Columns 8 through 11:
>
>     0.70000  0.80000  0.90000  1.00000
>
>   YGrid = off
>   YLabel = 194.79
>   YLim =
>
>     0  1
>
>     0  0  1
>     0  1  0
>     1  0  0
>     0  1  1
>     1  0  1
>     1  1  0
>
>   CreateFcn =
>   DataAspectRatio =
>
>     1  1  1
>
>   DataAspectRatioMode = auto
>   DeleteFcn =
>   HandleVisibility = on
>   HitTest = on
>   Interruptible = yes
>   NextPlot = add
>   Parent = 1
>   PlotBoxAspectRatio =
>
>     1  1  1
>
>   PlotBoxAspectRatioMode = auto
>   Position =
>
>     0.13000  0.11000  0.77500  0.81500
>
>   Projection = orthographic
>   Selected = off
>   SelectionHighlight = no
>   Tag =
>   Title = 176.29
>   Type = Axes
>   Units = normalized
>   UserData =
>   View =
>
>      0  90
>
>   Visible = on
>  XGrid = off
>   XLabel = 189.24
>   XLim =
>
>     0  1
>
>   XLimMode = auto
>   XTick =
>
>    Columns 1 through 7:
>
>     0.00000  0.10000  0.20000  0.30000  0.40000  0.50000  0.60000
>
>    Columns 8 through 11:
>
>     0.70000  0.80000  0.90000  1.00000
>
>   YGrid = off
>   YLabel = 194.79
>   YLim =
>
>     0  1
>
>   YLimMode = auto
>   YTick =
>
>    Columns 1 through 7:
>
>     0.00000  0.10000  0.20000  0.30000  0.40000  0.50000  0.60000
>
>    Columns 8 through 11:
>
>     0.70000  0.80000  0.90000  1.00000
>
>   ZGrid = off
>   ZLabel = 188.17
>   ZLim =
>
>     0  1
>
>   ZLimMode = auto
>   ZTick =
>
>    Columns 1 through 7:
>
>     0.00000  0.10000  0.20000  0.30000  0.40000  0.50000  0.60000
>
>    Columns 8 through 11:
>
>     0.70000  0.80000  0.90000  1.00000
>
> }
>
> li = get(line) gives
>
> li =
> {
>   BusyAction = queue
>   ButtonDownFcn =
>   Children = [](0x0)
>   Clipping = on
>   Color =
>
>     0  1  0
>
>   CreateFcn =
>   DeleteFcn =
>   EraseMode = normal
>   HandleVisibility = on
>   HitTest = on
>   Interruptible = yes
>   LineStyle = -
>   LineWidth = 0
>   Marker = none
>   MarkerSize = 0
>   Parent = 146.41
>   Selected = off
>   SelectionHighlight = no
>   Tag =
>   Type = Line
>   UserData =
>   Visible = on
>   XData =
>
>     0  1
>
>   YData =
>
>     0  1
>
>   ZData = [](1x0)
> }
>
> himage = get(image) gives:
>
> himage =
> {
>   AlphaData = [](0x0)
>   AlphaDataMapping = none
>   BusyAction = queue
>   ButtonDownFcn =
>   CData = [](0x0x0)
>   CDataMapping = direct
>   Children = [](0x0)
>   Clipping = on
>   CreateFcn =
>   DeleteFcn =
>   HandleVisibility = on
>   HitTest = on
>   Interruptible = yes
>   Parent = 146.41
>   Selected = off
>   SelectionHighlight = no
>   Tag =
>   Type = Image
>   UserData =
>   Visible = on
>   XData =
>
>     0  2
>
>   YData =
>
>     0  3
>
> }
>
> htxt = get(text) gives:
>
> htxt =
> {
>   BusyAction = queue
>   ButtonDownFcn =
>   Children = [](0x0)
>   Clipping = on
>   Color =
>
>     0  0  0
>
>   CreateFcn =
>   DeleteFcn =
>   FontAngle = normal
>   FontName =
>   FontSize = 10
>   FontUnits = data
>   HandleVisibility = on
>   HitTest = on
>   HorizontalAlignment = left
>   Interruptible = yes
>   Parent = 146.41
>   Position =
>
>     0  0  0
>
>   Rotation = 0
>   Selected = off
>   SelectionHighlight = no
>   String =
>   Tag =
>   Type = Text
>   Units = data
>   UserData =
>   VerticalAlignment = middle
>   Visible = on
> }
>
>



Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Rafael Laboissiere
In reply to this post by John W. Eaton-6
* John W. Eaton <[hidden email]> [2005-07-13 06:28]:

> On 12-Jul-2005, Shai Ayal wrote:
>
> | As you can see from the other responses to your email, at least 3
> | projects are actively pursuing this goal. All 3 have implemented this
> | tree structure, each in a different way. If indeed emulating matlab
> | handle graphics will become an "official" goal of octave, this could
> | be manifested by have an "official" object/property tree in octave as
> | you propose.
>
> Yes, think it would be bad to have N separate implementations of this.

Another important issue is the specification of a clear interface for the
backend plotting engines.  This could be implemented as a C++ class
allowing for additions in the future.  The current plotting
implementation requires changing loads of __pl*__.m files, which were
originally written for gnuplot.  This is what the PLplot and graceplot
interfaces do right now. This ought to be changed in the future.

As soon as the interface is clearly defined and becomes "the" standard, I
think that people working with the different plotting engines will be
more motivated to implement the backends.

--
Rafael

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

John W. Eaton-6
On 13-Jul-2005, Rafael Laboissiere wrote:

| Another important issue is the specification of a clear interface for the
| backend plotting engines.  This could be implemented as a C++ class
| allowing for additions in the future.

What I have in mind is to do as much as possible in the Octave
scripting language.  For example, I think Octave could just call a
"update_graphics" call periodically, and expect that the graphics
backend(s) would then do the right thing for each currently displayed
object.  For efficiency, this may mean that the graphics backend(s)
would have to queue requests to avoid and process a batch of them to
avoid "flashing" effects on the screen.  We could also have an
"update_graphics_and_redisplay_now_for_sure_i_really_mean_it_this_time"
function to force the graphics backend to flush its queue of updates
(otherwise, implementing something like a movie might not work quite
right).

Also, Octave will need to periodically call a function to get events
back from the graphics engine and perform the actions requested.

I think the key thing is that we separate the management of the data
structure that describes the graphics objects and properties from the
display of that information.  Otherwise, it will be very hard to
switch from one graphics or GUI toolkit to another later on.

But I'm not an expert in graphics and gui tools, so if this is bad
design, someone should say so, and please explain why it is bad and
(in simple terms) what would be better.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Quentin Spencer
John W. Eaton wrote:

>We could also have an
>"update_graphics_and_redisplay_now_for_sure_i_really_mean_it_this_time"
>function to force the graphics backend to flush its queue of updates
>  
>
Matlab has a "drawnow" command that does what I think you're describing,
but your name for it is so much more descriptive :).

-Quentin

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Daniel Sebald
In reply to this post by N Smethurst
N Smethurst wrote:
> So after ignoring us for years, John finally decides to take an interest
> in what must be considered the biggest downfall of an otherwise
> excellent numeric software system.

I'm not a fan of handle graphics.  Opinion of course, but first finding a characteristic's position in some hierarchy tree before changing it always seems a bother to me.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Daniel Sebald
Daniel J Sebald wrote:

> N Smethurst wrote:
>
>> So after ignoring us for years, John finally decides to take an
>> interest in what must be considered the biggest downfall of an
>> otherwise excellent numeric software system.
>
>
> I'm not a fan of handle graphics.  Opinion of course, but first finding
> a characteristic's position in some hierarchy tree before changing it
> always seems a bother to me.

That and the fact one is then limited to the plot properties that are part of the handle graphics tree, whereas the plotting engine may have some nice features to utilize.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Jonathan Stickel
In reply to this post by Daniel Sebald
Daniel J Sebald wrote:

> N Smethurst wrote:
>
>> So after ignoring us for years, John finally decides to take an
>> interest in what must be considered the biggest downfall of an
>> otherwise excellent numeric software system.
>
>
> I'm not a fan of handle graphics.  Opinion of course, but first finding
> a characteristic's position in some hierarchy tree before changing it
> always seems a bother to me.
>

Indeed.  Although Nicholas's comments seem harsh, I tend to agree.  I
also don't see a tremendous need to replicate handle graphics either.  I
think the most important thing is to have a usable, and beautiful,
graphics and visualization system available sooner rather than later.
It could take years, if ever, to replicate Matlab's advanced 3D surface
and volume functionality starting from scratch.

After much searching, fumbling, and frustration with 3D visualization
support for octave, I was elated when Octaviz was introduced last year.
  If nothing else, with a little knowledge about VTK (which is well
documented), Octaviz provides a means to create any visualization you
could want.  It is all there already.  For easy usability, all that
remains is to write m-file functions that mimic Matlab's.  Many standard
ones like "mesh" and "surf" are already there.  And Octaviz already has
object oriented access to figure properties, although not exactly handle
graphics.

What's holding back folks, especially "octave maintainers", from
interest in Octaviz?  Who knows.  They have stayed quiet far too long.

Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

John W. Eaton-6
On 13-Jul-2005, Jonathan Stickel wrote:

| I also don't see a tremendous need to replicate handle graphics
| either.  I think the most important thing is to have a usable, and
| beautiful, graphics and visualization system available sooner rather
| than later.

You are focusing too much on the rendering part of things here.  The
point is that I am now finding code written for Matlab that would be
able to run "out of the box" in Octave if only the handle graphics
functions were implemented in some way.  The implementation does not
have to be perfect or even complete.  But the core functions should be
present so that more freely available code that was originally written
for Matlab can also run within Octave, without having to first remove
all the graphics functionality (which is often not an easy thing to
do, because there is a lot of code out there that mixes computation
and graphics in ways that are not easy to seperate).

| It could take years, if ever, to replicate Matlab's
| advanced 3D surface and volume functionality starting from scratch.

I don't think that anyone is suggesting that we implement the
rendering parts from scratch.  We could use the Python matplotlib,
Vtk, or whatever someone else wants to write, in whatever combination
of those things is appropriate for the actual displaly of the graphics
information at hand.  But to hook these things up to Octave in a
Matlab compatible way, we have to implement the interface for Octave
to manage the graphics objects and properties.  I think that part can
and should be independent from the rendering code, and that it should
only have to be implemented once.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Daniel Sebald
In reply to this post by Jonathan Stickel
Jonathan Stickel wrote:

> Daniel J Sebald wrote:
>
>> N Smethurst wrote:
>>
>>> So after ignoring us for years, John finally decides to take an
>>> interest in what must be considered the biggest downfall of an
>>> otherwise excellent numeric software system.
>>
>>
>>
>> I'm not a fan of handle graphics.  Opinion of course, but first
>> finding a characteristic's position in some hierarchy tree before
>> changing it always seems a bother to me.
>>
>
> Indeed.  Although Nicholas's comments seem harsh, I tend to agree.  I
> also don't see a tremendous need to replicate handle graphics either.  I
> think the most important thing is to have a usable, and beautiful,
> graphics and visualization system available sooner rather than later. It
> could take years, if ever, to replicate Matlab's advanced 3D surface and
> volume functionality starting from scratch.

Gnuplot is catching up too.  I know it has been some slow going, but a lot of the features are in the recent release.  Perhaps more coming soon...  although, pie charts is still dodgy.  (Octave's fix with the repeated lines reminds of "Speedy" neon signs from McDonald's way back when.)  Pie charts are a philosophical divide.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: handle graphics

Jonathan Stickel
In reply to this post by John W. Eaton-6
Ah, I understand much better now.  Thanks for making this clear, and I
think your vision for this is good.  For those of us who have a vested
interest the various plotting/visualization plugins are probably a
little apprehensive about how things will turn out :-)

I don't have enough experience to contribute to the planning phase, but
I am interested to help with details of implementation when you are ready.

Regards,
Jonathan


John W. Eaton wrote:

> On 13-Jul-2005, Jonathan Stickel wrote:
>
> | I also don't see a tremendous need to replicate handle graphics
> | either.  I think the most important thing is to have a usable, and
> | beautiful, graphics and visualization system available sooner rather
> | than later.
>
> You are focusing too much on the rendering part of things here.  The
> point is that I am now finding code written for Matlab that would be
> able to run "out of the box" in Octave if only the handle graphics
> functions were implemented in some way.  The implementation does not
> have to be perfect or even complete.  But the core functions should be
> present so that more freely available code that was originally written
> for Matlab can also run within Octave, without having to first remove
> all the graphics functionality (which is often not an easy thing to
> do, because there is a lot of code out there that mixes computation
> and graphics in ways that are not easy to seperate).
>
> | It could take years, if ever, to replicate Matlab's
> | advanced 3D surface and volume functionality starting from scratch.
>
> I don't think that anyone is suggesting that we implement the
> rendering parts from scratch.  We could use the Python matplotlib,
> Vtk, or whatever someone else wants to write, in whatever combination
> of those things is appropriate for the actual displaly of the graphics
> information at hand.  But to hook these things up to Octave in a
> Matlab compatible way, we have to implement the interface for Octave
> to manage the graphics objects and properties.  I think that part can
> and should be independent from the rendering code, and that it should
> only have to be implemented once.
>
> jwe
>
>

12