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

[Ben Abbott]

On Sep 23, 2012, at 7:16 PM, Ben Abbott wrote:

> 
> On Sep 23, 2012, at 2:20 PM, Daniel J Sebald wrote:
> 
>> On 09/23/2012 09:10 AM, Ben Abbott wrote:
>>> 
>>> On Sep 23, 2012, at 5:27 AM, Daniel J Sebald wrote:
>>> 
>>>> 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:
>>>>>> 
>> [snip]
>>>>>>> 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.
>>> 
>>> I hadn't noticed Mike's changeset would change the behavior of CLI Octave.  
>>> If I'm reading you correctly, Octave should set the terminal to "qt" if 
>>> (the GNUTERM environment variable is empty) and (gnuplot supports the "qt" 
>>> terminal) and (the GUI is running).  Correct?
>> 
>> Yes, I believe that makes sense.  If there is a way for the scripts to 
>> determine the GUIDE is running I think it is fair that somewhat non-generic 
>> code such as the private functions in the plotting engine use that condition.
>> 
>> Dan
> 
> I think Mike's patch (below) can be modified to check if the GNUTERM 
> environment variable has been set, and if empty then set it to "qt". That way 
> we don't need to know the GUI/IDE is running.  
> 
> On Sep 22, 2012, at 10:55 AM, Mike Miller wrote:
> 
>> 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, can you generate a changeset?
> 
> Ben

jeezz ... that doesn't make any sense.  I was too rushed for a coherent post, 
so I'm back with a bit more patience to improve it ;-)

I was intending that octave-gui.cc include something like below.  With that 
perhaps __gnuplot_drawnow__.m doesn't need to be changed?

        std::string gnuterm = getenv ("GNUTERM");
        if (gnuterm.empty ()) 
          setenv ("GNUTERM", "qt", 1);

Ben