From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Nov 11 09:05:53 2003
Subject: Re: Handle Graphics implementation in Octave.
From: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
To: Ole Jacob Hagen <waterthrill at yahoo dot no>
Cc: octave-maintainers at bevo dot che dot wisc dot edu
Date: Tue, 11 Nov 2003 10:05:41 -0500

On Tue, Nov 11, 2003 at 09:47:45AM +0100, Ole Jacob Hagen wrote:
> Remember that we might be required to make a new
> octave_value type, which works pretty much as struct
> arrays, since set/get mechanisms in Matlab's  handle
> graphics can be manipulated like this:
> h = plot(x,y);
> handle =get(h);
> handle.XData will list x-coordinates of curve. This
> feature should be implemented. 
> 
> What about the other way? Should it be possible to set
> handle graphics objects in a similar way?
> example:
> h = plot(x,y);
> gca_handle= get(gca);
> gca_handle.XLabel = 'x-Axes';
> 
> This would be nice, wouldn't it? I wonder if Matlab
> (R14) offers this functionality.  

Yes it does, but you have to call
	set(gca,gca_handle)
once you have gathered all of your properties.  You
probably don't want to mess with this since there may
be reasons why properties are collected and changed
but not immediately applied.

An alternative which might work is for the handle
itself to allow direct manipulation of its properties.
Since Matlab treats handles as opaque objects this
won't conflict with existing code.  This would be
much the same situation as with files, which in
octave are of class file and in Matlab are of class
double.  There will still be corner cases where there
may be conflicts, such as functions which do too good
a job type checking their arguments, but I suspect
those will be rare.  I have yet to see an issue with
file handles when running programs written for matlab
under octave.

> We can divide handle graphics solution  with
> communication to external application such as Oplot++
> or kvisualiser into 3 units: 
> 
> 1. Handle graphics layer, where handle graphics are  
>    implemented. 
> 2. Interface layer to external applications. 
> 3. Transport layer, which decides wether sockets 
>    (tcp/ip, udp, local), pipes can be used. 
> 
> The core handle graphics routines, and objects should
> be handled by Octave, maybe be within core of Octave
> as NDArray is. 

That's not so clear.  The more functionality implemented
in the visualiser, the more useful it will be to other
apps such as R, SciLab, Scientfic python, etc.  By that
argument, put in the visualiser just what it needs and 
no more.  Leave the numeric stuff on the octave side, and 
have all the GUI stuff in the visualiser.

> Then we need some kind of interface level, which will
> interface hande graphics to the correct communication
> protocol, wether it's pipes, unix domain socket. As I
> see it now, shared memory is very hard to solve with
> two separate application, 
> where visualisation-application is forked, or it might
> be a process in /etc/init.d, but this is not an option
> at this stage. 

Ideally the bulk of the visualiser would be available
as a thread-safe library so it could be bound in the
same process or even the same thread as the driving app.

> 
> The Interface layer require that datas are sent in one
> way, and one way only => A common communication
> protocol has to be developed. 
> This protocol has to be based on properties of handle
> graphics in Matlab. 
> Example: set(gca, 'PropertyName', 'PropertyValue') are
> sent directly, which means that only one PropertyValue
> are sent at time. 
> But a user might want to send many parameters such as
> set(gca, 'PropertyName1', 'PropertyValue1',...
> 'PropertyName2', 'PropertyValue2',...
> 'PropertyName3', 'PropertyValue3');
>  which is allowed in Matlab. This is not a problem
> really, since we sent these as four messages. 
> 1.  send that gca are to be configured. 
> 2.  setValue('PropertyName1', 'PropertyValue1');
> 3.  setValue('PropertyName2', 'PropertyValue2')
> 4.  setValue('PropertyName3', 'PropertyValue3')
> 
> This will require four transmissions. 
> This will be a base for transport unit. 

You probably want a way of batching the ops so that
the screen updates happen altogether rather than
piecemeal.

Different visualisers have different capabilities.  You
need some way of testing whether a certain class of
features is supported.  The details get messy here.
For example, what if one app supports latex style
math, another supports mathml and a third supports
none of the above?  Do we standardize on one model
(e.g. latex since it is human readable) and require
the app to translate it as best they can?

Output is important.  Try to include the page model
in the design up front.

Paul Kienzle
pkienzle at users dot sf dot net