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

[Daniel J Sebald]

On 09/22/2012 09:55 AM, Mike Miller wrote:
> On Sat, Sep 22, 2012 at 10:18 AM, Ben Abbott<address@hidden>  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.
>
> I'm pretty open to any behavior as well. My main concern is when I see
> code that unconditionally sets an environment variable without
> considering that it may be wiping out a user's preferences.

I understand that.


> > > 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).
>
> Dan, is your intent here that only Qt GUI users get the Qt gnuplot
> while console users get the X11 gnuplot?

No, that wasn't my intention.  Someone using the console should be able 
to select Qt gnuplot if they like.  I was thinking X11 should remain the 
default (i.e., the current defaults).  I think there is some library 
that needs to be present to use Qt.  If the GUI is running, we all the 
Qt support is present.  If running from the console, that is not assured.


>  If the Qt gnuplot is
> preferred, and it sounds like it may be based on this list of
> features,

I must say, I think the alpha scaling of Qt is going to win out 
eventually if that is made accessible to users somehow.


>  should it not be the default for everyone on every system
> (if available) regardless of whether Octave is running in terminal or
> Qt mode?

Not sure.  I'm wondering if we should just leave octave-cli figures as 
they are, at least for the next major rev.  It might be too 
discombobulating for the user running the console to see a new type of 
window, then run GUIDE+O and see the similar look and feel.  S/he might 
wonder if that were a mistake.  It will be a contrast of the previous 
Octave (i.e., non-GUI octave) and the new interface.

Of course, after a short while users will posting messages "Can't we 
have that Qt window for the console version?"  So, maybe in a later version.

The other thing is that I'm not real familiar with the Apple figure 
window.  Maybe there are some who prefer that over Qt.


> > 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, good point, I made the following change locally and this brings
> up either the X11 or Qt gnuplot, depending on which variant I have
> installed. Is this reasonable to test for and prefer Qt on all systems
> over the current system-dependent defaults?

Feel free to investigate a suitable behavior.  Probably get insight that 
way.

Dan