On 10/04/2013 10:52 AM, Jordi Gutiérrez Hermoso wrote:
On Fri, 2013-10-04 at 19:35 +0400, Dmitry Roshchin wrote:
I want to split octave packages to "octave" (for terminal usage) and
"octave-
gui" (for users who want GUI). But in this case it's more logical to
have
"octave" binary instead of "octave-cli" for backward compatibility and
"octave-gui". Are there any reasons for current naming?
The reasons is that octave should by default be linked to a GUI, and
the Octave binary can also be GUI-less if you pass it the --no-gui
option.
The only reason octave-cli exists is so that you can have a binary
that isn't linking to Qt, if for some reason you really don't want to
have the Qt libraries in memory when running Octave.
Well, I'd say not the only reason. There was a conscious philosophy
back at the start of Unix in the days when computer memory and disk
space were limited to make computer programs modular and then
interconnect them in ways with redirection, pipes and so on. The other
philosophy is to be more application based, with big graphical
interfaces that do everything and possibly repeat some functionality
that other programs might be doing as well. Guess I'd attribute that
philosophy to Apple... but a point of note is that Apple ran into
trouble with this approach when in the mid 90s they were swamped by
PowerMac maintenance issues, and it was a unix-based OS that Steve
Jobs brought back to Apple that saved the company. GUI's have their
benefits, no doubt, but the point is organization and maintenance.
I'm still for the former approach, i.e., that a program should be
command-line based with a possible graphical shell around it. (Go to
weather.com to experience runaway bloat.) That's been the philosophy
with Octave and Octave GUI as well. That's why the claim that Octave
should be thought of as more of the GUI than the underlying program
doesn't sit well with a Unix dog.
There are perfectly good uses of non-gui Octave. For example, one
could login remotely and modify/run Octave batch jobs of some sort.
Dan