Re: [patch #7847] Make gnuplot Qt terminal default for GUI/IDE via environment variable

[Daniel J Sebald]

I wanted to get a small survey of how people feel the GUI/IDE should 
behave with regard to the gnuplot terminal which includes Qt support in 
its latest version.  Mike submitted an addendum to a small patch that 
attempts to use gnuplot "qt" terminal by setting environment variable 
GNUTERM and falls back on the default if the version of gnuplot doesn't 
have "qt" support:

http://savannah.gnu.org/patch/?7847

If the latter happens then a message from gnuplot:

> Unknown or ambiguous terminal name 'qt'

appears on the screen.  Mike is proposing that if the user has GNUTERM 
variable already defined in their environment, then that should take 
precedent.

I'll give my feelings on this, but I'm open to any behavior.

Definitions:
console -- the system console that octave/GUIDE+O is launched from
terminal window -- the window in the GUIDE+O having the redirected 
octave output

First, I think the preference is going to be that GUIDE+O use Qt 
terminal.  It is a nice looking terminal using the Qt icons giving it a 
look and feel that match GUIDE+O.  It has a couple more features than 
X11 terminal and is more robust in terms of aliasing, alpha-scaling, 
print buttons, etc.  It will be ostensibly the same figure window on all 
three (four?) major platforms.  There is the option to customize a 
figure window and place just the plot within the figure window (i.e., 
forward looking).

Given that, I felt that having the gnuplot warning

> Unknown or ambiguous terminal name 'qt'

appear, which may be annoying but only happens at the start of launching 
GUIDE+O, is tolerable and in fact maybe a good thing because it might 
capture someone's attention and nudge them in the direction of realizing 
that there could be a Qt figure window.

So, should the environment variable GNUTERM defined before launching 
GUIDE+O take precedence over GUIDE+O defining GNUTERM to be qt (i.e., 
Mike's proposal)?  I'm fine with that, I guess.  Probably those users 
who even know the mechanism of GNUTERM will be savvy enough to know 
there is now Qt support in gnuplot.  But that does mean someone can't 
define GNUTERM for their octave-cli and get "qt" figures for 
octave/GUIDE+O unless they perhaps come up with a small shell script 
that pre-sets GNUTERM before launching octave/GUIDE+O.  (There's no 
sense in adding sophistication to Octave beyond the current setup.)

The other related item is that I've noted a couple times I feel that 
GUIDE+O should not be routing STDERR to terminal window but instead 
leave that directed to the console.  If that were the case, then 
gnuplot's error message would be very less annoying.

I'd prefer to leave the error message from gnuplot visible.

Dan