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

[Mike Miller]

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.

>> 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? If the Qt gnuplot is
preferred, and it sounds like it may be based on this list of
features, should it not be the default for everyone on every system
(if available) regardless of whether Octave is running in terminal or
Qt mode?

> 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?

diff --git a/libgui/src/octave-gui.cc b/libgui/src/octave-gui.cc
--- a/libgui/src/octave-gui.cc
+++ b/libgui/src/octave-gui.cc
@@ -82,8 +82,6 @@
 {
   dissociate_terminal ();

-  setenv ("GNUTERM", "qt", 1);
-
   QApplication application (argc, argv);

   while (true)
diff --git a/scripts/plot/__gnuplot_drawnow__.m
b/scripts/plot/__gnuplot_drawnow__.m
--- a/scripts/plot/__gnuplot_drawnow__.m
+++ b/scripts/plot/__gnuplot_drawnow__.m
@@ -333,7 +333,9 @@
   term = getenv ("GNUTERM");
   ## If not specified, guess the terminal type.
   if (isempty (term) || ! __gnuplot_has_terminal__ (term, plot_stream))
-    if (ismac ())
+    if (__gnuplot_has_terminal__ ("qt", plot_stream))
+      term = "qt";
+    elseif (ismac ())
       term = "aqua";
     elseif (! isunix ())
       term = "windows";


-- 
mike