Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it

[Vincent Lefevre]

Control: retitle -1 with GNUTERM=wxt, "gnuplot -persist" hangs if gnuplot cannot draw before stdin is closed, e.g. with FVWM's ManualPlacement

On 2024-02-29 03:47:41 +0100, Vincent Lefevre wrote:
> On 2024-02-29 03:43:33 +0100, Vincent Lefevre wrote:
> > This can be reproduced with the following script:
> > 
> > #!/bin/sh
> > 
> > gnuplot -persist <<EOF
> > plot '-' using 1:2 t '' with line
> > 0 0
> > 10 10
> > e
> > EOF
> > 
> > No issues with GNUTERM=qt, but with GNUTERM=wxt, it doesn't work.
> 
> Or just:
> 
> $ echo 'plot x' | gnuplot -persist

This may be related to my window manager FVWM (and its configuration),
where I choose the window position before it appears:

  ManualPlacement (aka active placement).  The user is required to
  place every new window manually.  The window  only  shows  as  a
  rubber  band  until a place is selected manually.  The window is
  placed when a mouse button or any key except Escape is  pressed.
  Escape  aborts  manual  placement which places the window in the
  top left corner of the screen.  If mouse  button  2  is  pressed
  during the initial placement of a window (respectively Shift and
  mouse  button  1 in case Mwm emulation has been enabled with the
  Emulate command), the user is asked to resize the window too.

For instance, if I run

  { echo 'plot x' ; sleep 3 ; } | gnuplot -persist

there are no issues if I place the window before the 3 seconds,
but the problem appears if I wait for more than 3 seconds.

The problem seems to be due to the fact that the standard input gets
closed before gnuplot can actually draw. Indeed,

  { echo 'plot x' ; exec >&- ; sleep 3 ; } | gnuplot -persist

triggers the problem even if I place the window before the 3 seconds.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)