octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integrating Quint into the Octave sources


From: Jacob Dawid
Subject: Re: Integrating Quint into the Octave sources
Date: Mon, 18 Apr 2011 17:43:52 +0200

John,

I don't see a GUI for Octave as a separate thing.  I see it as part of
Octave, which is why I would like to integrate the sources with Octave
rather than keep them separate.  But we are not likely to change the
overall way that Octave is built.  We can compromise and have the Qt
parts built with qmake, but the overall configuration and make step
should be through the current configure script and top-level
Makefile.  That is essential for having the method of building Octave
consistent with other GNU software.  Additionally, I think we should
be building one main program called "octave" with a command-line
option to allow users to disable starting the GUI when they want to
run Octave in a terminal.


Okay, but I think we should wait a bit. The GUI is still very young and naturally it can't provide what people expect. We should at least clearly state that it's in early stage and ny any means not ready for daily use. We also encountered the first strange bugs, like crashes when you type .5 instead of 0.5.
 
| I already spoke with Jordi about this.

Can you share that conversation?| The point is I copied the files itself and modified them heavily to fit our
| needs just to have a working project. Also I am planning to remove them on the
| long-term and replace them by better code. The whole terminal emulation is
| really far more than we really need, it's overcomplicated. By that I mean, it
| draws the terminal as a picture receiving keypresses and mouseclicks as any
| other widget. The clean solution would be of replace it by a QTextEdit and
| throw away tons of unmaintanable code.

| The coding style proposed by GNU is disastrous,

In what way is it disastrous?


It's against to what I think is good style. Just that. :) Cut.
 
| The point is I copied the files itself and modified them heavily to fit our
| needs just to have a working project. Also I am planning to remove them on the
| long-term and replace them by better code. The whole terminal emulation is
| really far more than we really need, it's overcomplicated. By that I mean, it
| draws the terminal as a picture receiving keypresses and mouseclicks as any
| other widget. The clean solution would be of replace it by a QTextEdit and
| throw away tons of unmaintanable code.

In that case, I think there is an even greater incentive to keep the
code you imported separate from the code you wrote yourself.  Having
it in a separate subdirectory should help to make the separation
clear.

jwe

Yes, you are right here. This was not necessary before since I was almost working on my own, but it's definately clever to separate that.

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .


reply via email to

[Prev in Thread] Current Thread [Next in Thread]