From octave-graphics-request at bevo dot che dot wisc dot edu  Tue Mar  9 17:25:42 1999
Subject: Re: Comments on GUI and plotting library
From: matthew joseph valenta <mvalenta at u dot washington dot edu>
To: Rafael Laboissiere <rafael at icp dot inpg dot fr>
cc: octave-graphics at bevo dot che dot wisc dot edu
Date: Tue, 9 Mar 1999 15:25:36 -0800 (PST)



On 9 Mar 1999, Rafael Laboissiere wrote:

> 1) Definition of a user level interface, probably in the form of a C++
>    class, for both the plotting calls and the GUI objects.  
> 
> 2) Definition of the interface at the Octave language level.  
> 
>    Question: are we going towards Handle Graphics (TM) or will we try to
>    keep compatibility with the gnuplot syntax?  I did a lot of graphical

I'm sorry.  I've been up 24 hours and I don't understand the difference
b/w 1 & 2.  Please explain.  Sorry for my drowsiness. :-)

Personally, Matlab compatibility is a must because I want to leverage
Octave as a replacement for Matlab in our lab.  If everyone has to rewrite
their m-files, they just won't switch.  Furthermore, the same is true of
current Octave users and GNUPlot.  So I think that we will need to write
backwards compatibility for both.  However, that doesn't mean we shouldn't
design a new API!  I think we should design an API as we see fit and
then write wrappers to make it backwards compatible.  i.e. Slowly migrate
people to Linux from Windows via W.I.N.E.

I too agree that Handle Graphics is satanic.  Oh, maybe you didn't say
that..(and no offense to satanists...)

>    add a new driver.  I started coding a driver for Gtk/Gdk last year, but
>    had to stop before December by lack of time.  The idea was to have a Gtk
>    widget that would contain the graphical rendering and would respond to
>    mouse events.  This widget could be easily integrated in a GUI. This
>    project is though too Gtk-centric, and is maybe not what we are looking
>    for.

Actually that sounds really useful to me.  Particularly if we could make
the mouse events work.  In any case, I would buy embedding the plotter
inside another toolkit (ala "xanim" within "aktion!") because that would
keep the code seperate.  How hard would this be?

>    months and development is very slow.  Fortunately, PLplot is GPL'ed, so
>    there would be no problem in forking/continuing the project, if we
>    really want it.

I'm not above legal theft.  

> 4) Implementation with specific toolkits.

I am also fairly ambivalent.  Why don't we vote on a toolkit to focus on
at the START?  I vote for wxGTK.

>    Matthew Valenta and JWE mentioned interprocess communication via sockets
>    and CORBA.  Is this a real proposal?  Do you have anything more concrete
>    on that?

I don't.  The sort of CORBA interfaces that I had in mind (GNOME's Baboon
and KDE's KOM/OP) are not in place yet.  I'm not even sure if they're
usable yet.

Matt Valenta