Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <sf...@us...> - 2014-09-22 19:01:19
|
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?
If so, is it worth holding up release of 5.0 until this change has been
implemented and tested?
Ethan
|
|
From: Tatsuro M. <tma...@ya...> - 2014-09-23 08:54:55
|
----- 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. For windows, there is not "fork" function so that persist mode works differently from other platforms. In persist mode (case [1]), gnuplot session does not terminated so that we can use mouse for windows and wxt terminal. For qt terminal, perhaps gnuplot session is terminated but gnuplot_qt process exists. We cannot use mouse for zoom for qt terminal. Tatsuro |
|
From: Ethan A M. <sf...@us...> - 2014-09-23 18:24:10
|
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 > > For windows, there is not "fork" function so that persist mode works differently from other platforms. > In persist mode (case [1]), > gnuplot session does not terminated so that we can use mouse for windows and wxt > terminal. > > For qt terminal, perhaps gnuplot session is terminated but gnuplot_qt process exists. > We cannot use mouse for zoom for qt terminal. Yes. That is the documented behavior. But it seems to surprise some people. > > Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2014-09-24 01:34:45
|
----- 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. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2014-09-24 04:35:33
|
----- 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).
|
|
From: Tatsuro M. <tma...@ya...> - 2014-09-24 04:53:14
|
----- 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
|
|
From: Tatsuro M. <tma...@ya...> - 2014-09-24 06:54:20
|
Sorry I have mistaken.
line around 455 => 1455
Tatsuro
>
> In command.c
>
>
> line around 455 => 1455
> #=====================================================================
>
> #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
>
|
|
From: sfeam <sf...@us...> - 2014-12-08 06:04:08
Attachments:
qt_pause_on_windows.patch
|
On Wednesday, 24 September 2014 03:54:10 PM Tatsuro MATSUOKA wrote:
> >
> > In command.c
> >
> >
> > line around 455 => 1455
> > #=====================================================================
> >
> > #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 lost track of this question.
I think you are right that qt needs the same treatment.
Please try this patch (in-line and also attached):
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/command.c 2014-09-14 11:21:12.000000000 -0700
+++ gnuplot-cvs/src/command.c 2014-12-07 21:58:07.958118580 -0800
@@ -1453,8 +1453,8 @@ pause_command()
if (sleep_time < 0) {
#if defined(_Windows)
-# ifdef WXWIDGETS
- if (!strcmp(term->name, "wxt")) {
+# if defined(WXWIDGETS) || defined(QTTERM)
+ if (!strcmp(term->name, "wxt") || !strcmp(term->name, "qt")) {
/* copy of the code below: !(_Windows || OS2) */
if (term && term->waitforinput && paused_for_mouse){
fprintf(stderr, "%s\n", buf);
@@ -1470,7 +1470,7 @@ pause_command()
# endif
}
} else
-# endif /* _Windows && WXWIDGETS */
+# endif /* _Windows && WXWIDGETS or QTTERM */
{
# ifdef USE_MOUSE
if (paused_for_mouse && !GraphHasWindow(graphwin)) {
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Ethan
|
|
From: Bastian M. <bma...@we...> - 2014-12-08 06:08:07
|
Am 08.12.2014 um 07:03 schrieb sfeam:
> On Wednesday, 24 September 2014 03:54:10 PM Tatsuro MATSUOKA wrote:
>>>
>>> In command.c
>>>
>>>
>>> line around 455 => 1455
>>> #=====================================================================
>>>
>>> #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 lost track of this question.
> I think you are right that qt needs the same treatment.
> Please try this patch (in-line and also attached):
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot/src/command.c 2014-09-14 11:21:12.000000000 -0700
> +++ gnuplot-cvs/src/command.c 2014-12-07 21:58:07.958118580 -0800
> @@ -1453,8 +1453,8 @@ pause_command()
>
> if (sleep_time < 0) {
> #if defined(_Windows)
> -# ifdef WXWIDGETS
> - if (!strcmp(term->name, "wxt")) {
> +# if defined(WXWIDGETS) || defined(QTTERM)
> + if (!strcmp(term->name, "wxt") || !strcmp(term->name, "qt")) {
> /* copy of the code below: !(_Windows || OS2) */
> if (term && term->waitforinput && paused_for_mouse){
> fprintf(stderr, "%s\n", buf);
> @@ -1470,7 +1470,7 @@ pause_command()
> # endif
> }
> } else
> -# endif /* _Windows && WXWIDGETS */
> +# endif /* _Windows && WXWIDGETS or QTTERM */
> {
> # ifdef USE_MOUSE
> if (paused_for_mouse && !GraphHasWindow(graphwin)) {
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>
> Ethan
>
>
Please also set the tracker item
https://sourceforge.net/p/gnuplot/bugs/1502/
which includes a patch.
Bastian
|
|
From: Jun T. <tak...@kb...> - 2014-09-26 10:00:49
|
First of all, I personally feel the current behavior of --persist is just fine. If an equivalent of [2] is implemented within gnuplot, what a user can do if she/he wants to get the current behavior of [1]? Anyway, I tested the following three commands with term=aqua/wxt/qt on my Mac so that you can get an idea about the situation on Mac. term=xxx # aqua/wxt/qt [0] gnuplot -e "set term $term; splot x*y*y" [1] gnuplot -e "set term $term; splot x*y*y" --persist [2] gnuplot -e "set term $term; splot x*y*y; pause mouse close" & (OS X 10.8.5/gnuplot-cvs/wxWidgets-svn/Qt5.3.2) =====[[ aqua ]]===== Aquaterm.app is an application independent of gnuplot and does not support mouse feedback. [0][1] The gnuplot quits immediately but the plot window survives. The plot can't be changed by mouse (this is always the case with aqua) but I can print or save the plot from the Aquaterm menu. [2] The gnuplot process goes into the background, and suspended (stopped) by 'tty input'. It does not quit even when the plot window is closed. (If I bring the gnuplot to the foreground then it quits.) Since aqua does not support mouse, 'pause mouse close' is equivalent to 'pause -1' and gnuplot is waiting for a carriage return to be hit. =====[[ wxt ]]=====` On Mac OS X gnuplot handles wxt by itself (does not fork). [0][1] A plot window opens but closes immediately, and the gnuplot quits. [2] The plot window survives and I can rotate the plot by mouse. But If I change the focus to the terminal window from which I started the gnuplot and enter a next shell command (or just hit return), then the gnuplot process (in the background) is stopped by "tty input"; I can't change the focus back to the plot window (it does not respond). If I bring the gnuplot to the foreground then it quits and the plot window is closed. I haven't yet understood why this happens. =====[[ qt ]]===== [0] gnuplot quits and the plot window is closed immediately. [1] gnuplot quits but the plot window (gnuplot_qt) survives; the plot can't be rotated by mouse (of course). [2] The plot window survives and the plot can be rotated by mouse. If the plot window is closed then the gnuplot (in the backgrond) also quits. Changing the focus from/to the plot window causes no problem. To summarize, on Mac OS X, [2] works fine with qt but not with aqua/wxt (at least currently). But implementing [2] within gnulot may not be equivalent to putting gnuplot into background by shell, and the 'tty input' problem would not happen (or could be avoided). NOTE: I noticed the following two are equivalent: gnuplot -e 'cmd1; cmd2' gnuplot -e 'cmd1; cmd2; exit' In plot.c (line 622) noinputfiles is set to FALSE if '-e cmds' is given; the '-e cmds' is considered as a kind of "input file". The man page of gnuplot is somewhat ambiguous about the behavior when '-e cmds' is specified but no input file is given. Jun |
