Re: Feature question: waiting on a plot window

[sfeam <sf...@us...>]

On Sunday, 19 August 2018 23:52:05 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > On Sunday, 19 August 2018 20:25:24 Dima Kogan wrote:
> >> Dima Kogan <gn...@di...> writes:
> >>
> >> > Ethan A Merritt <sf...@us...> writes:
> >> >
> >> >> On Friday, August 17, 2018 1:15:24 PM PDT Dima Kogan wrote:
> >> >>>
> >> >>> I'm looking for a feature that (I think) doesn't exist currently. Want
> >> >>> to ask first, in case something DOES exist that I'm not seeing.
> >> >>
> >> >> The command you are looking for is
> >> >> 	pause mouse close
> >>
> >> This works in its most basic form, which is awesome. Thanks! But I'm now
> >> going to be a pain in the butt. For a gnuplot-using application to work
> >> reasonably, this needs to only wait for a window-close event when one is
> >> coming: i.e. when a window is open. Scenarios that could happen:
> >>
> >> 1. User already closed the window before I send my "pause mouse close"
> >
> > That sounds like a case of "well then don't do that".
> > If the parent program sends the plot command and the pause command
> > in immediate succession the time window in which that race could happen
> > would be very small.  If the commands do not come in immediate
> > succession then maybe the program logic needs re-thinking.
> > Can you give a more complete example of the flow of events?
> >
> >> 2. We're using a non-interactive terminal (dumb, pdf, etc etc)
> >> Ideas on handling that?
> >
> > So far as I know, in that case the next <\n> in the input stream
> > will terminal the "pause" command.  Does that not work for you?
> 
> I played with it a bit more just now, and it's good-enough. It would be
> NICE if "pause mouse close" could know if there's anything to
> potentially wait for, but I guess I don't strictly need it.

If you have identified a sequence of reasonable events that causes gnuplot
to lock up entirely, I would consider that a bug.  In the case of 
"pause mouse" I agree that if you issue this command in the state that
the current terminal is mouseable but the most recent plot window has
been closed then you have a potential lock-up.  

I say "potential" because from a normal terminal session you can break the
lock by typing Ctrl-C.  This resets error and pause conditions and returns
you to the gnuplot command line.   

However, if gnuplot is being run from some non-terminal controlling process
I am not entirely clear on who would have to send SIGINT (Ctrl-C) to whom.
I don't understand you usage scenario well enough to guess.
Does the user who is operating the mouse also have a terminal window open?
If Ctrl-C is typed in that window, what process receives the signal?

	Ethan
  

> Thanks much. This will fix a long-standing annoyance with gnuplotlib