From octave-graphics-request at bevo dot che dot wisc dot edu  Fri Mar 12 09:32:16 1999
Subject: Re: Comments on GUI and plotting library
From: Jonathan King <kingjw at missouri dot edu>
To: octave-graphics at bevo dot che dot wisc dot edu
Date: Fri, 12 Mar 1999 09:31:56 -0600 (CST)


On Thu, 11 Mar 1999, Matthew J Valenta wrote:

> Jonathan King wrote:
> >

[big snip]

> > The charms are many:  First, we aren't really asking Octave to do 
> > anything it can't already do right now, and people who don't need 
> > or like GUIs won't pay any cost to those of us who do.  Second, we 
> > don't weld Octave to a toolkit we might come to regret, or have to 
> > worry how to make a matlab-like language handle graphics commands.  

[snip]

> There is an even bigger advantage to using this approach.  By keeping the 
> GUI code separate, we make it easier for someone else to take our GUI 
> code and connect it to their program.

I'm not sure I quite see what you mean.  The GUI code this would involve
is at two levels.  One of these is on the perl/tk side (or, as I think
could eventually be preferred, just C++ wrapper around ptk the library).
That's the stuff that would actually talk to the toolkit.  On the m-file
or Octave side of things, we'd basically be handling the code that
users write to set up and run the GUI, basically translating whatever
style of interface definition we give the user into calls we can make on
the toolkit directly.  Delicate issues include how to handle callbacks to
Octave.
 
> > Do you think it's worth a try?
> 
> Yes. What do other people think?

Let me emphasize that what I mean by "try" at this point is just a
quick prototype that actually works to some degree so that we can then
decide what kinds of GUI elements we really need to provide with what
interface.  I wouldn't want to prevent anybody from using the prototype
stuff, but I sure as heck wouldn't want to support it.

(I'm answering JWE's specific comments on this separately.)
 
> I've been digging deeper into this idea and there are a number of 
> possibly useful Perl modules that might save us work.  

Again, for a protype this is true.  Most of the Perl modules you see
out there are glue around some library that we might eventually want
to use directly (like Mesa/Open GL).

> Most interesting though is PDL, which appears to include some 2-D 
> and 3-D plotting abilities.  

OK. Be careful here.  I'm sure that the PDL would disagree somewhat with
what I'm going to say here, but I think that PDL exists primarily because
people didn't really know about Octave and/or really disliked Matlab.
When I was playing with it last, it still had some really weird and
idiosyncratic features.  There is some interesting stuff here, but mostly
in the way of libraries that they have wrapped, and maybe some of the code
to handle multidimensional arrays.

jking