Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

[Dima K. <gn...@di...>]

Hi Ethan.


Ethan A Merritt <me...@uw...> writes:

> On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
>>
>> I'm looking at patching gplt_x11.c to work better with existing X window
>> IDs. This is coming along. In the process I'm discovering other things.
>> One is that for some reason the gnuplot x11 backend is explicitly
>> ignoring the SIGINT and SIGTSTP signals:
>
> I do not recall, or never knew, those details. But I would imagine
> that it ignores SIGTSTP because backgrounding gnuplot_x11 would be a
> bad idea - it would stop responding to new commands from the main
> gnuplot process.

I suspected this predates you. It feels like an odd thing to do to
specifically mask out SIGTSTP, but I guess that's fine. Masking out
SIGINT creates zombies, though, so there's a clear downside. I can try
to keep SIGINT only, and dogfood that change in my everyday usage (I
make a LOT of plots). If I don't find anything obviously broken as a
result after a few weeks, can we merge it?


> It's been too many years since I was seriously using or looking at the 
> x11 terminal driver.  I think the world has moved on from direct use
> of Xlib to drive graphics output, in favor of higher level libraries.

One could say that the world has moved on from gnuplot too, yet here we
are. For my own interactive use I use the x11 terminal exclusively. I
find it to be dramatically faster than both qt and wxt. Doubly so if
x-forwarding (the world is in the process of moving on from X, but it's
not clear if it will ever get there). Yes, the x11 terminal doesn't do
anti-aliasing or transparency or fancy text like qt and wxt do, but I've
never felt like I missed those features in my usage.

In my mind, one big argument for gnuplot in general, as compared to
other plotting libraries, is its speed. Using a non-x11 terminal dulls
that argument.


> You said you were looking at this in order to create a gnuplot widget
> for FLTK? I've not previously heard of FLTK, and the fltk.org web site
> is not particularly informative. It looks like it's left over from
> twenty years ago. Can you describe the functionality you need?

FLTK is a widget set. Like Qt or wxt or GTK. It's simple and fast, but
for the purposes of this conversation this is a detail. We can be
talking about GTK instead.


> For example, do you need mousing support inside this widget? If not,
> can you use one of the png terminals rather than x11? The graphics
> would be better, particularly the text handling.
>
> Or maybe you could use svg + domterm? http://domterm.org/Features.html

OK, so on a very high-level a want a plotting library that is

- Fast

- Stable over time

- Available in all contexts in which I plot stuff. Currently this is
  from the terminal, from python, and (hopefully) from an FLTK widget.
  Other people could want to plot from Qt or GTK or R or whatever, and
  it'd be awesome if the same plotting backend was available in all of
  those.

Today, gnuplot is the closest to tick all those boxes for me. There's no
reason why the preferred Python plotting library (matplotlib) is
different from the R plotting library (ggplot2) is different from
whatever you're supposed to do in GTK (gtkdatabox?). And so on. I
generally use FLTK for GUI tools, so I'd like good plotting there, but
the FLTK part is a detail. It would be awesome if Gnuplot were available
as a widget for every GUI toolkit, which is obviously a lot of work. Or
we can use the x11 terminal talking to an external X window, and with a
small number of limitations, we'd be done.

Let's say the request was "I want a gnuplot-powered plotting widget in
my GTK application". What would you suggest in that case?