From octave-graphics-request at bevo dot che dot wisc dot edu  Thu Mar 11 02:31:15 1999
Subject: Comments on GUI and plotting library
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Rafael Laboissiere <rafael at icp dot inpg dot fr>
Cc: octave-graphics at bevo dot che dot wisc dot edu
Date: Thu, 11 Mar 1999 02:28:40 -0600 (CST)

On  9-Mar-1999, Rafael Laboissiere <rafael at icp dot inpg dot fr> wrote:

| Apparently, there are some quite separate problems that we are 
| facing now, although they are interrelated:
| 
| 1) Definition of a user level interface, probably in the form of a C++
|    class, for both the plotting calls and the GUI objects.  
| 
|    Comment: I agree with  JWE that this should be as toolkit-independent as
|    possible. 
| 
|    Question: is somebody doing this?  If there is a written (even rough)
|    design around, I would gladly take a look.

I don't know if anyone is working on this.  I haven't done it myself.

Several people have pointed out wxWindows.  I've looked at the web
page for it and it seems like the most likely candidate to me at this
point.  It is distributed under terms that are compatible with the
GPL and it provides the possibility for working under Windows NT/95
with a Windows look-and-feel.  I don't personally care very much about
that, but some people might and it seems like a good idea to leave
that possibility open.  Since it already works with several different
toolkits, perhaps we don't need to worry about defining our own
generic interface on top of wxWindows?  Maybe we can just trust that
it is already generic enough?  (It would be useful if someone who has
more experience with GUI toolkits could comment on this.)

| 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
|    Matlab programming in the past and I really think that Handle Graphics
|    is not a good thing.  If strict compatibility with Matlab matters, there
|    will be then no choice.

As I've said before, if there is a better way of doing things, I think
we should use the better way with the idea of being able to provide a
compatibility layer.  For example, would

  gui_object.background_color = "blue";
  gui_object.geometry = "...";
  redisplay (gui_object);

or something similar make more sense than set and get?  It would seem
to be easy to write get and set in terms of this kind of data
structure, but I don't know for sure, since I've never really used the
Matlab GUI stuff and I don't have much experience programming with GUI
toolkits.  Again, someone with more experience should speak up if
there are problems with this.

| 3) Finding a adequate plotting engine.  
|   
|    Comment: I say "finding ", because I am sure we are going to reinvent
|    the wheel.
| 
|    Question: what are we looking for exactly?  A plotting library (a la
|    plplot or pgplot) callable from C++ or a pipe-communicating program
|    (a la gnuplot)?  I think that a plotting library would be more
|    appropriate for our goals, but I may be wrong.

I think it would be nice if we had a widget that could be used as part
of the GUI toolkit we choose.  Then the graphics widget could be used
as part of the GUI too.  Perhaps some existing graphics library (the
GNU one, or plplot, or gnuplot) could be adapted?

jwe