Re: [long] Handle Graphics and visualisation applications in Octave.

Hi Ole,

> DO NOT USE COPY AND PASTE TO CREATE NEW M-FILES,
>  SINCE THEY ARE COPYRIGHTED AND THEREBY A PROPERTY OF THE MATHWORKS, INC.
> These files are: subplot.m, plot.m, title.m and all the high level + all the low level function such as get.m and set.m..
> set.m and get.m exists only for help functionality, anyway. 

So it looks like: "As long as it is legal to use web documentation describing a 
behaviour to mimic it, it is ok". That's fine.
I'm rather from the "reinvent the wheel" kind than the one from "copy'n'paste".

> >Currently it behaves like matlab: events are polled in the input wait loop (and 
> > in future in some specific gui-functions), and it can call user functions or it can 
> > evaluate strings on button click etc... For the moment it construct the GUI from 
> > an XML file (using glade, but wxWindows and QT offer the same 
> > functionality). I am currently in need for the graphic-handle and I am investigating the existing solutions.
> 
> I guess you are refering to OctaViz? Or VatKo? If you are refering to VatKo, please give us a link and source, so we can see what you have done so far. 

OctaViz is a wrapper around VTK which makes it very powerful for a VTK user.

My VaTKo should have been a separate visualization program that serves clients through some communication channel (binary tokens). It was not planned to 
provide matlab compatibility.. It should have been driven with some commands and would have returned events to the clients (mouse motion if they are tracked, clicks, buttons activation etc). I implemented the communication channel (tcp/ip, tls, with XDR support, unix sockets) and preliminaray figure/
subfigure/axes/plot classes. axes and plot classes were not finished. I did a Gtk-
VTK widget, too . At that point I saw that other projects advanced quicker than me and, more importantly, planned to provide matlab compatibility... 

Most of VaTKo code is in fact in the communication and  the server-client layers. I just put online my old internal doc and a doxygen API documentation/code. http://freefluid.dyndns.org/home/ VaTKo links (introduction contains two dvi, and user_manual contain Doxygen API + code).

In the current state, a server can accept connections and display a splash screen 
(in fact an interactive vtk sombrero)  and a gui. A client can only connect. So 
nothing impressive, hence I am not providing a tarball, unless really wanted...

> Have you been in touch with Mr. Nick Smethurst?  

No. It seems to me that KV depends on a desktop environment. I do not use nor 
Gnome nor KDE. Those are too large and slow on my system. I hope desktop 
dependency won't be necessary in KV in the future (I seem to recall that it was 
removed, but I don't see it notified on the web site).

>  0: Starting Octave creates just the root-object of handle graphics. This is also done by Matlab, as per today refering to documentation on http://www.mathworks.com
>  1. creating x and y vectors.
>  2. Create p_h with plot, p_h is in fact h-g object named Line, which also require an Axes-object and a Figure object.
>  There is only one copy of x and y in Octave's memory, while the visualisation application has it's own x and y vector.
>  3. l_h, which is a struct-array contains XData, YData, ZData and the rest of properties of Line object.
>      This command collects the p_h-object directly from visualisation application, and l_h objects are only created at this time.  
> 
>  Matlab is now having to versions of x and y vectors. The original is x and y, while XData and YData are copies of x and y.
> 
> As long as we agree on a native implementation of h-g objects in Octave, and how Octave should use them, then a user can choose between n-number of visualisation application. 

Yes, to octave, everything should remain an abstraction. Only the middle layer 
between octave and the visualisation/gui layer will translate the commands and 
transmit back events. Maybe a way to push developers to add gui/viz modules 
is to start at octave level with the g-h infrastrucute. Then publish some API which 
the modules interfacing octave and the vizgui program have to use. 

In the current state of my prototype (called O'Gui), small .oct files provide 
connection to a shared library. First ogui_init is called. It initializes the 
communication channels (a std::list<> for events, a single command slot 
and a socketpair for asynchronous communication), install an event_hook in 
octave input loop, and start a thread.

The thread initializes GUI and listens to the socket. 

Commands from octave are passed through the command slot. Commands 
from octave to the gui are blocking until gui responds, hence the single 
command slot. Gui is signalled using the socket and gets the command from the 
slot (no overhead or delay because it is a shared memory read). It handles the 
command and returns the result in the command slot, and then it signals octave 
using the socket.  Octave, which was in a blocking socket read, is then 
unblocked to get the result from the cmd slot and to translate it back to the 
interpreter. 

Callbacks are registered using another .oct module. Octave  sends to the gui the 
object_ID/event_ID/callback_ID triplet and the gui connects the event to a 
specific signal handler. This signal handler is called with the associated triplet 
when the event occurs.  Then it adds the event_ID/object_ID/callback_ID triplet 
to the mutex protected std::list<event>. The latter is polled by octave in the 
input loop and in some other commands (figure, etc., according to matlab's 
doc).  If octave is not already in a callback (that has called the event polling 
function), the even is executed (eval for a string callback, and function call for a 
user-function callback).  If octave was already in some current callback, then if 
the callback is interruptible, it executes the new event-callback (I have to check 
if this works). If the current callback is not interruptible, the event is or discarded 
or just ignored for a later handling.

Another .oct file allows the loading of a .glade file to create the GUI.  Widgets retain their Glade name, so the user can associate to them a signal and a callback string to evaluate or a callback function to execute (by using the function-handler).  

By this multithreaded design, as many have already used, GUI does not block 
when octave works.  As the link between octave and the other module is 
narrowed down to a single command slot (+possible a large shared memory to 
pass large data set) and to a quite small shared memory to pass back events, it 
would be easy to provide another IPC option (separate process, TCP/IP...). Thus, I will abstract this layer a bit more.

That's the current state -I need to check if a callback can be executed within an other callback, though...

Now, to offer matlab compatibility at the interpreter level, there is only the g-h 
to design, so I can think about how to glue it to the UI layer. If the visualization module can take long time to finish, I thing the GUI part can be achieved quite quickly once the g-h is implemented.

It is clearly possible to work on the gui without taking into account the 
visualization module, as long as they share the same scheme to pass back 
events, send commands and receive results, hence my plan to abstract this part.

g-h seems to be only an object hierarchy. g-h being just a pointer to the inner 
object. The challenge is in designing its interaction with the GUI/Visualisation 
layer, isn't it? Maybe we can design a special API to which the GUI/Viz (hum 
VizGui sounds like Whiskey) modules have to comply?

-- 
Cheers