Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

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

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

> Again only guessing, but I wonder if some window managers send SIGINT
> to the controlling process (or did back in the day) when a window is
> forcibly closed. 
>
>> 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?
>
> You make a lot of plots but presumably they are all made from the
> same environment.  My concern would be that it breaks some other 
> window manager or desktop or OS or X-server etc...

I have the same concern too, but I can't effectively test other people's
setups. If nobody has the cycles to think about fixing bugs in the x11
terminal, maybe we should just leave this alone.


> ... Hang on a minute, when you say "keep SIGINT only" do you mean keep the
> SIGINT handling as it is (masked) or do you mean keep (as in "not block")
> SIGINT?

I meant a small patch that only changes the handing of SIGINT: SIGINT
would have the default behavior (killing gnuplot_x11), but SIGTSTP would
be ignored. To keep the patch as small as possible, since the SIGTSTP
behavior isn't all that important.


>> 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.
>
> I think we had this discussion about 10 years ago :-)
>    https://sourceforge.net/p/gnuplot/mailman/message/30718556/

We did! I completely forgot about that!


> At the time there was at least one plot type (3D images)
> for which x11 was faster, but I do not think that is true today.
>
> It's been a while since I did extensive benchmarking, but here's a
> quick timing run on my home desktop:
>
> [~/temp] setenv GNUTERM x11 ; time gnuplot all.dem < /bin/yes >& /dev/null
> 14.931u 3.520s 0:52.84 34.9%    0+0k 8+0io 0pf+0w
> [~/temp] setenv GNUTERM qt ; time gnuplot all.dem < /bin/yes > & /dev/null
> 13.143u 2.276s 0:21.02 73.3%    0+0k 0+0io 0pf+0w
> [~/temp] setenv GNUTERM wxt ; time gnuplot all.dem < /bin/yes > & /dev/null
> 40.824u 4.306s 0:48.56 92.9%    0+0k 4328+0io 1008pf+0w
>
> Both wxt and qt are faster than x11 (clock time).
> qt is impressively faster - the test run completes in less
> than half the time used by x11.
>
> Note that the 'u' and 's' times for wxt are for a single process
> while those for x11 and qt are for the inboard (gnuplot) process only.
> But qt is faster than x11 by that measure also.

I guess I wasn't convinced by the thread 10 years ago, but I'll look
again. Thanks for the measurements. In your view, which is the one to
use for interactive plotting on GNU/Linux boxes? qt or wxt? I just
quickly tried both of them, and there are a few bugs/quirks in both of
them I'd want to fix before moving all my usage to one of those. That's
for a later email.


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

Is it? If I was building a GTK application (not wx; plain GTK), could I
use the gnuplot wxt terminal as a widget in that application? The docs
don't make that clear, and definitely don't tell you how to do that.

Similarly, what if I was building a Qt application? "help qt" mentions a
"widget" option, which maybe provides this function, but that option
isn't documented, so I don't know what it does.

And I want to use FLTK for my applications, so these don't help me. I
guess a new "fltk" terminal would be the "right" way to do that, but
that's not a good use of anybody's time. x11 is a good base to build on,
since all the widget toolkits depend on it (for now at least), and I bet
you could build UI widgets for most toolkits based on "set terminal x11
window whatever".

So yeah. I think there's value in maintaining it, and fixing bugs in it.
I don't have a ton of cycles to put towards that, but I will send some
patches when they're ready.

dima