Re: Persistent confusion about gnuplot -persist

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: tmacchant3 Merritt Ethan ; gnuplot-beta
> Cc: 
> Date: 2014/9/24, Wed 13:35
> Subject: Re: Persistent confusion about gnuplot -persist
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA 
>>  To: Merritt Ethan ; gnuplot-beta
>>  Cc: 
>>  Date: 2014/9/24, Wed 10:34
>>  Subject: Re: Persistent confusion about gnuplot -persist
>> 
>>  ----- Original Message -----
>> 
>>>   From: Ethan A Merritt 
>>>   To: gnuplot-beta; Tatsuro MATSUOKA 
>>>   Cc: 
>>>   Date: 2014/9/24, Wed 03:23
>>>   Subject: Re: Persistent confusion about gnuplot -persist
>>> 
>>>   On Tuesday, 23 September, 2014 17:54:44 Tatsuro MATSUOKA wrote:
>>>> 
>>>>    ----- Original Message -----
>>>>    > From: Ethan A Merritt
>>>>    > To: gnuplot-beta
>>>>    > Cc: 
>>>>    > Date: 2014/9/23, Tue 03:43
>>>>    > Subject: Persistent confusion about gnuplot -persist
>>>>    > 
>>>>    > 
>>>>    > There have recently been several queries, bug reports, 
> support 
>>>   requests,
>>>>    > and so on that involve misunderstanding about what to expect 
> from 
>> 
>>>>    > gnuplot -persist    or    set term <foo> persist.
>>>>    > 
>>>>    > People seem to assume that if the window is still showing on 
> the 
>>>   screen,
>>>>    > they should be able to pan/zoom/unzoom and so on using the 
> mouse
>>>>    > buttons or the widgets at the top of the terminal GUI.  
>>>>    > 
>>>>    > The documentation is quite explicit that this isn't true 
> in 
>>>   general because
>>>>    > such operations require the main program to recalculate and 
>>  redraw the
>>>>    > plot, which cannot happen in -persist mode because the main 
>>  program
>>>>    > has already exited.     As it happens, the wxt terminal back 
> in 
>>>   version 4.4
>>>>    > was an exception to this general case.  I guess people 
> remember 
>>  that 
>>>>    > exception and want to generalize it to all current 
> terminals.
>>>>    > 
>>>>    > That is, people expect this
>>>>    > 
>>>>    >     [1] gnuplot -persist -e "plot sinh(x); exit"
>>>>    > 
>>>>    > to act like this
>>>>    > 
>>>>    >     [2] gnuplot -e "plot sinh(x); pause mouse close; 
>>  exit" 
>>>   &
>>>>    > 
>>>>    > The question is, should we continue pointing to the 
> documented 
>>>   limitations
>>>>    > of "persist", or should we change what persist 
> does to 
>>  match 
>>> 
>>>>    > people's
>>>>    > expectation?  
>>>>    > 
>>>>    > So far as I know [2] works properly for the x11, wxt, and qt 
> 
>>  terminals
>>>>    > under linux.  I don't know about MSWin (win) or OSX 
> (aqua).
>>>>    > 
>>>>    > Assuming that [2] can be made to work correctly on all three 
> of 
>>  these
>>>>    > platforms, should we reimplement "set term ... 
> persist" 
>>  and 
>>>>    > "gnuplot -persist"
>>>>    > to act like this instead of retaining the current 
> implementation?
>>>>    >
>>>> 
>>>> 
>>>>    I have tested on windows (cvs changelog date is 2014-09-20)
>>>> 
>>>>    gnuplot -e "plot sinh(x); pause mouse close; exit"
>>>> 
>>>> 
>>>>    works as expected for wxt and windows terminal.
>>> 
>>>>    But for qt terminal, gnuplot exit immediately and we cannot use 
> mouse.
>>> 
>>>   Does "pause mouse close" work correctly from an interactive 
>>  session 
>>>   using qt?    
>>> 
>>>       Ethan
>> 
>> 
>>  On windows using qt  
>>  "pause mouse close" does not work correctly.
>> 
>> 
>>  The plot does not respond any mouse and keyboard operation.
>>  By closing plot by close button top right position, "gnuplot>" 
> 
>>  prompt does not appear.
>> 
>>  BTW, on windows using wxt and windows  
>>  "pause mouse close" works correctly.
>> 
> Using qt on windows, "pause mouse xxx" ("xxx" is a keyword) 
> does not work correctly
> on version 5.1.0 (ChangeLog 2014-09-24). 


In command.c


line around 455
#=====================================================================

#if defined(_Windows)
# ifdef WXWIDGETS
if (!strcmp(term->name, "wxt")) {
    /* copy of the code below:  !(_Windows || OS2) */
    if (term && term->waitforinput && paused_for_mouse){
fprintf(stderr, "%s\n", buf);
term->waitforinput(0);
    } else {
#  if defined(WGP_CONSOLE)
fprintf(stderr, "%s\n", buf);
if (term && term->waitforinput)
    while (term->waitforinput(0) != (int)'\r') {}; /* waiting for Enter*/
#  else /* !WGP_CONSOLE */
if (!Pause(buf))
    bail_to_command_line();
#  endif
    }
} else
# endif /* _Windows && WXWIDGETS */

#=====================================================================


For qt, are similar treatments required?

Sorry I do not enough time to check the matter more in detail.

Tatsuro