Re: Handle Graphics and visualisation applications in Octave.

Hi,

> Hi. 
> 
> There is a lot of development going on in replacing Gnuplot as
> visualisation application. 
> There are following graphics systems available to Octave: 
> 1. Gnuplot
> 2. epsTk a postscript toolkit for octave and matlab. 
> 3. Kmatplot, renamed to Qmatplot. 
> 4. Knewplot  
> 5. Plplot 
> 6. Grace
> 
> 
> And these are coming; 
> 1. KV (Kvisualizer, Nick Smethurst)
> 2. Octaviz (Dragan Tubic et. al)
> 3. Oplot++ (Ole J. Hagen, Hans O. Hagen)
> 
> Since KV, Octaviz and Oplot++ will support MATLAB's Handle Graphics, we
> should collaberate in how to solve this matter. 
> There is no point in re-inventing the wheel, and try to limit  Octave
> to just one visualisation application. 

On the other if we never did reinvent the wheel we would
still use wooden discs with our cars...

I totally agree. Moreover, those use different approaches and have different dependencies. Unless octave provides its middle-weight native plotting and gui alternatives, those different projects make real sense to me. 

> I am working out a little paper, with a suggestion how to solve this
> problem. 
> It is pretty much based on that: 
> 1. Octave treats handle graphic objects as cell/struct arrays         
>    internally. 
> 2. Octave  gets h-g objects from visualisation application, since this 
>    is most naturally. I believe that even Matlab is doing the same.  
> 3. Octave has a native  implementation of h-g objects.
> 4. Each visualisation application makes their unique high-level and  
>    low-level drivers. 
> 
> Explanation of 4: 
> What I mean that Octave could have a built-in variable called
> use_plot_engine='......', 
>  which can be changed runtime and can take the following values: 
>  grace, oplot, knewplot,qmatplot, octaviz, and it's default value are
> gnuplot. 
> In my Octave-distribution I've got m-files for plotting in: 
> /usr/share/octave/$VERSION/m/plot. 

Makes sense to me. In my case I am working on a GUI (buttons menus created by the user -uicontrol, uimenu etc).

I have a working prototype (in fact a hack to check for feasibility) in prealpha 
stage that uses gtk as its widget set. It is designed to allow for easier 
extensions to other widget sets (QT, wxWindows, Java??). I also thought about 
providing the user for the choice of the widget set at run time. 

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.

What are the legal issues on using graphics-handle or using the same GUI approach than Matlab?