Re: [OctDev] RE: GUI for Octave programs.

[Paul K. <pki...@ki...>]

On Tue, May 15, 2001 at 07:11:42PM -0400, Julian A. de Marchi, Ph.D wrote:
> Hey, what a crazy name you have (pronunciation please?)!
> 
> So...
> 
> re: the CVS, yes, it's a hairball and I brought that up with Paul K;
> partly it's a matter of where the matcompat (biggest/only upload so far)
> got situated.  My own feeling is that each "PROJECT" should have its own
> parent folder in the CVS.  So
> 
> 	/matcompat/...
> 	/tk_octave/...
> 
> for starters.  This should clear up any mess, at least from a high-level
> perspective it will keep any hairballs localised.  Let me see what the
> other devs thinks.

As you say, the only thing on the site is matcompat, it just happens to
be in /octave/... instead.  That suits me fine since many of the routines
are useful to the wider octave community, not just those who want to
run existing matlab code.

The confusion in the present tree has two sources.  One is the CVS
download instructions.  They should tell you how to grab the entire
tree rather than just a single "module".   The following seems to work:

  cvs -z3 -d:ext:dev...@cv...:/cvsroot/octave co .

The other source of confusion is that CVS does not control directory
structure, and does not allow you to remove empty directories.
Rearrangements to accomodate the first problem left vestiges of the old
organization and the confusing structure we have today.  

The whole project needs to be purged and a new CVS tree put in place
having the structure we want, and clear instructions on where to put
new files and directories.  This may need to be done periodically,
especially if routines are sucked off into the main Octave distribution
with any regularity.

Before putting the new tree is in place, feel free to rearrange the
/octave/... subdirectory.  I used the structure that was already in place
since changing it would have made the tree even more confusing.  I would
particularly like the numeric/nonnumeric distinction to go away, and have
the scripts tree be one level flatter.  I would also prefer all the parts
to a package together (scripts, dld, documentation, tests, demos, sample
data) rather than in separate trees, but the current organization is
closer to Octave's organization, so there are grounds for keeping things
as they are. 

> 
> re: JWE, yes, he's reluctant about anything GUI-related (he doesn't even
> use X-Windows, strictly a command-line dude as far as I know).  But as
> I said before, I think once the code carries its own weight any lead will
> naturally turn into gold.  There's still no FORMAL arrangement about
> pulling SF work into the main dist, but again I think that if the code
> proves itself it will happen one way or another.  JWE runs a tight ship.
> SF provides a popular means within the Octave community for parallel
> efforts, and is thereby popularly de-facto legit.  TCL/TK is the best
> proposition I've ever gleaned from the octave discussion archives on the
> GUI issue.

There is a strong argument for not moving code into Octave proper.
As long as OctaveSF contains useful routines people will continue to
use it and any new contributions will immediately have a wide audience.
If on the other hand you regular pick off the great and the good, then the
only people who will bother with it are the hard core developers of which
there are very few.  Also, once the code is in Octave proper it is harder
to maintain since all changes then have to be done through bug reports.
Whether or not those bug reports receive action depends on John's level
of interest.  

> 
> Let me know when you get your SF handles registered.  Be sure to check the
> SF HOW-TOs on CVS before you start uploading.
> 
> =jo...@us...
> 
> -----Original Message-----
> From: Przemek Klosowski [mailto:pr...@ja...]
> Sent: Tuesday, May 15, 2001 1:15 PM

<snip>

> John wasn't enthusiastic about Tcl as a vehicle for GUI building when I
> talked to him
> last, but I think it's an attractive proposition and I am looking forward to
> having
> people try it.

It strikes me as wasteful to invoke another interpreter for a different
language when we already have an interpreter available to us.  For one
thing, that requires your users to learn another language before being
able to develop their own GUI.  Is it feasible to control TK directly
from Octave and avoid any TCL?  Either way, your TK controls will need
to be able to trigger Octave callbacks, so it would be nice to cut out
the middle man.

Paul Kienzle
pki...@ki...