Re: Handle Graphics implementation in Octave.

[Ole Jacob Hagen]

Hi. 

On Tue, 11 Nov 2003 10:05:41 -0500
Paul Kienzle <address@hidden> wrote:

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

Of course, the visualisation application shouldn't do any numeric stuff. This 
is a job for Octave.
But there is recommended to have a  duplex communication from Octave and 
visualisation application.
To get reply-codes, so visualisation application says that it was set(gca, 
'XGrid', 'on') performed successfully. 
This example was not good, since you will see an immidiate response on this 
command. A grid is turned on. 
But if a well defined communication protocol between Octave and visualisation 
application is developed, 
there should be no problems in making wrappers from Python, R, SciLab to this 
visualisation application. 
And they can still use Matlab-way-of-thinking. 

There are 3 guys working on  handle graphics to Octave today, and these guys 
are:

1. Nick Smethurst; kvisualiser
2. Hans Oluf Hagen; Oplot++
3. Ole Jacob Hagen (me); Oplot++

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

Oplot++ and kvisualiser should both be thread-safe. 
There's no problems in forking Oplot from Octave. 
I had some troubles that Oplot became a zombie-process, 
but this is solved today. 

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

I guess a user wouldn't notice this changes, if they were executed 
sequentially, or?
It's not much data to sent.  
Of course we could always send absolutely all handle graphics data, 
and not send the modified one. 
This is not a very good solution, since transmission errors might occur, 
and what a waste of bandwidth? 
This will require some kernel memory usage, 
to send all handle graphics objects every time. 

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

Latex-style support.

I don't know if VTK supports latex-style fonts, but I  guess this could be 
fixed.
I know that Coin3d doesn't support latex-styles.  

> Output is important.  Try to include the page model
> in the design up front.
??? What's on your mind? A design of visualisation frontend? With some features 
it should have?  

Thinking some years from now on....

This question is raised number of times:
When is a  GUI-frontend to Octave available? 
Will it ever be made one, which is included into either sourceforge, or core?
This will require some rethinking of code, and a choice of gui-API has to be 
made. 
Is there anyone, who are developing on this? 
A visualiser should be integrated in gui-frontend, 
but this will narrow down a possibilities of an user. 

I am developing Oplot++ based on Coin3D and Qt, while Nick is developing 
KVisualiser based on VTK and KDE.
What if I and Nick agree on a making a gui-frontend to Octave, using e.g Qt for 
portability.
Free version of Qt runs on both Mac OS X, Windows and Linux. 
Octave is still running in Windows using Cygwin?  

And this GUI-frontend supports both Oplot++, KVisualiser and Gnuplot for 
starters?
Me and Nick is pretty much doing the same thing here. 
This is completely waste of time, if you ask me. 
Why: handle graphics offers also run-time creation of widgets, so called 
uicontrol and uimenu. 
This will require a good base of GUI-frontend, using Qt, we can create run-time 
widgets, and pushbuttons and so  on.
And use Oplot and Kvisualiser as plugins to the GUI-frontend, may be?
 
Nick and Hans O; We have a job to do :-)
 
Cheers,

Ole J.