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

[Ben Abbott]

On Sep 22, 2012, at 3:30 AM, Daniel J Sebald wrote:

> 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.)

To avoid the gnuplot error, I suggest not defining GNUTERM=qt before checking 
that gnuplot supports the qt terminal.  The gnuplot toolkit includes a private 
function __gnuplot_has_terminal__.m which will detect if gnuplot includes 
support for the qt terminal.

        .../scripts/plot/private/__gnuplot_has_terminal__.m

To make use of this for the gui, we may need to make the function public.  In 
any event, if it is in your path, all you need to do is ...

        has_qt = __gnuplot_has_terminal__ ("qt");

Ben