help-octave
[Top][All Lists]
Advanced

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

Re: QTOctave and Octave 3.4


From: Jordi Gutiérrez Hermoso
Subject: Re: QTOctave and Octave 3.4
Date: Tue, 18 Oct 2011 18:48:06 -0500

2011/10/18 Uwe Brauer <address@hidden>:

> However there was a GUI (or 2 if your count GUI Octave) so
> breaking it, without having a substitute seems to me a bad
> design decision.

We are not deliberately breaking anything. We simply are not working
with the people who are implementing ugly hacks to make a GUI for
Octave. Hacks that break when we do something different in Octave
because we are not working with people making external GUIs. This is
why we want a native GUI maintained along with the Octave core, so
that we can make sure it *works*. It's not pure ideology why we don't
want external GUIs. It's that this has been a proven failed attempt
for the last 20 years.

Consider the analogous situation we had with external plotting
engines: octplot, octaviz, yaog... All of them died. Consider now the
native OpenGL plotting backend in Octave which is about 98% ready to
replace gnuplot as the default. It's faster, prettier, much better 3d
support, produces beautiful plots, and isn't tied down to chasing
whatver gnuplot features are or aren't implemented:

    http://octave.sourceforge.net/compare_plots/

We're trying to fix it. It's a problem that needs to be fixed
correctly and put an end to 20+ years of dozens of abandoned GUI
attempts.

> There is no change to roll back and make the old GUI work
> again? At least till there is a new (of course much better)
> GUI?

I have no idea what it is, because I don't know what those other GUI
attempts did that break with the new one. Maybe jwe knows. Most of
them do the wrong thing and oversimplify interaction with Octave. They
use pipes. They would have to chase after whatever Octave is doing
nowadays in order to work.

- Jordi G. H.


reply via email to

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