Handle Graphics implementation in Octave.

[Ole Jacob Hagen]

Hi. 

This message can also be found in
octave-graphics-list, but since maintainers-list is
read more often, I will post it here as well. 

Why are people always reading maintainer list, and not
checking postings at graphics list?
I would suggest people to check out the graphics
sections as well. <check it out now, funk soul
brother, right about now...>

To Nick: Oplot++ is coming around. 
Have to write code to visualise plottings from
scratch, since this have not been implemented in Coin
yet, that's why my progress is slow. 
But fortunately my progress in number of codelines are
pretty good. ;-)

How far have you (Nick) come with your implementation
of handle graphics in kvisualiser? 

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.  
We should also strive for a handle graphics solution
where an user can easily change both transport method,
and visualisation application. 
This will require forking of a child process....the
child process is the visualisation application.
So, how can a generic handle graphics, wich supports
different communications schemes with forking work? 
Well, this is a challenging question, which require a
good solution. Nothing is impossible. 

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. 
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. 

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. 

Reason why one property are sent, is to save memory
and better control of data transferred. 
And the protocol is simple, so you don't need to be a
PHD  to figure it out.

The interface unit should be very generic, so people
who want's to make their own visualisation-application
can develop further on it. How can we solve this?

Solution 1: 
Maybe it should read some environmental variables,
like OCTAVE_VISUALIZER_BIN=oplot,
OCTAVE_COMMUNICATION=pipes, local, tcpip? 
These environmental values, can be detected and read
by getenv-function. This means that we have almost
solved this in a terrific/terrible way.

Solution 2: 
Maybe OCTAVE_VISUALIZER_BIN and OCTAVE_COMMUNICATION
should appear in .octaverc instead of being
environmental variables?

The latter way is always best, I guess. 
Default values appears in .octaverc, and should be: 
OCTAVE_VISUALISER_BIN=gnuplot
OCTAVE_COMMUNICATION=pipe 
This will mean that it's possible to change this value
from Octave, without quiting an octave session. And
thereby change visualisation application. This would
be great wouldn't it?

Handle graphics would not be disabled if gnuplot is
chosen, since newer gnuplot version can use some
handle graphics features. set-function has been
replaced by gset. Set-function are from now on
reserved for handle graphics implementation?

It would be recommended that some configuration of
Octave in deciding which application to fork. 
Since Octave needs to fork a child process, since a
GUI has not been developed yet....(That's not entirely
correct, since goctave and koctave have been
developed). The existing gui-frontends are developed
in gtk and kde, which will narrow down number of OS's
this will work in. 
Therefore a Qt-solution, or a WxWindows-solution
should be used. KDE runs on Windows using Cygwin
today, pleas e take a look at
http://kde-cygwin.sourceforge.net/ if you don't
believe me. Even Qt for X11, is ported to Cygwin. 

The visualisation-application will then collect datas
sent by pipes or sockets, and updating figures. 
Visualisation-application should also be able to
change values of handle graphics objects.  
This will have some drawbacks, since handle graphics
objects are stored in two applications, both in Octave
and visualisation-application. 
The most critical handle graphics objects are XData,
YData and ZData. But visualisation library which
visualisation application should handle this
sufficiently. 

I've visualised pretty large datasets in Oplot++. And
still there is two copies of XData, YData and ZData,
both in Oplot and Octave. 

The main advantage of my suggestion, is that an user
can choose freely his own visualisation application,
wether it's Oplot++, GnuPlot, QMatPlot, KNewPlot,
KVisualiser, QWT-based visualisation-application and
so on.

I hope that functionality and flexibility are always 
primary goals in our implementation, if not you should
start working at Micro$oft.

Some comments, besides the Micro$oft-thing?


Cheers, 

Ole J. 


______________________________________________________
Få den nye Yahoo! Messenger på http://no.messenger.yahoo.com/
Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så morsom