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: John W. Eaton
Subject: Re: Integrating Quint into the Octave sources
Date: Mon, 18 Apr 2011 11:28:37 -0400

On 18-Apr-2011, Jacob Dawid wrote:

| I am working with Ubuntu and it is safe to install the QtCreator. It should
| pull all dependencies needed to build Qt apps.

OK.

| qmake invokes other tools, like the uic or moc to generate special code that
| enables features of Qt that otherwise would not be available in a standard C++
| only library. Imitating this behaviour may be possible, but not easy. In order
| to save us a lot of headaches it's a good solution to keep the build processes
| independent from each other and build each project for itself.

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.

| I already spoke with Jordi about this.

Can you share that conversation?

| The coding style proposed by GNU is disastrous,

In what way is it disastrous?

| 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


reply via email to

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