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

[Daniel J Sebald]

On 09/22/2012 09:18 AM, Ben Abbott wrote:
> 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

That is an option.  However, I'm wondering if we want to add scripts to 
the GUI source code when simply setting some environment variable is 
pretty innocuous.

On the other hand, if there were a custom Qt figure window, that's a 
different story.

Dan