Re: q for quit in plot windows

[<tim...@en...>]

> The ctrl-c copy was easy enough.  Just replace "c" with "ctrl-c"...
>
> Anyway, I see when typing 'h' for a plot to get the key bindings there are
> these
> two at the very top (i.e., follow the button description):
>
>
>   Space          raise gnuplot console window
>   q            * close this X11 plot window
>
> [snip]
>
>                * indicates this key is active from all plot windows
>
> I'm assuming that by the use of term->(function) the mouse/keyboard
> interface is
> meant to be very general and not restricted to X11.


I will try not to repeat what was said by Ethan and Petr, but here are my
thoughts on this:

"raise console" and "quit plot window" do not go through the event system
(because they predate it), they are handled directly by the terminal.
That's why ' ' and 'q' are keys that you cannot bind to something else,
with the exception of the 'ctrl-q' option in x11 and wxt.

There's no term->close right now, nor is there a term->raiseconsole (and
that's fortunate, since raising _gnuplot console_ is not the _plot window_
business).


> Is that right, i.e., maybe
> it can be used on a different window environment and all the bindings
> behave the
> same.
>
> So, I'm wondering
>
> 1) Why use the word X11 in the documentation?  (Would the user care?)

True, that should be fixed.

>
> 2) Why the footnote that this key is active for all plot windows?  (Aren't
> all
> keys active for all the plot windows?  Or does this mean for all
> window-based
> terminals?)
>

Most keys, like the one for 'replot' only work in the active (i.e. current
terminal) window.

> 3) Why not simply put the 'q' in the regular list of bindings?

You need a term->close to do that. That's not difficult to write, most of
the code is already in place (for 'set term ... close' in particular).

_However_, that way 'q' would not work anymore if wxt (or x11, or any
screen terminal that is concerned by this) is not the current active
terminal.

For example, see the following:
set term wxt
plot x
'q' -> the window is closed
plot x -> the window appears again
set term png
'q' -> nothing happens, because events from wxt are no longer processed

Read further for ideas to workaround this situation.


> If the user applies the -ctrlq option
> the 'q' binding no longer makes sense, but that is still the case the way
> it
> currently is in the documentation. Also, gnuplot shouldn't allow the user
> to
> bind 'q' and 'space'.  If I type
>
>   bind "q" 'print "great"'
>
> the list of bindings shows
>
>   q            * close this X11 plot window
> [snip]
>   q              `print "great"'

Those problems are a result of 'q' not being really handled by the event
system in the first place.

Please note that we already have some of the code to change that situation
right now:

First, there's patch #1474309 to make ' ' be a normal hotkey (writing a
similar patch for 'q' would be even smaller). The only issue before
committing is precisely the one illustrated above: the key doesn't work
anymore if the screen terminal is no longer the active one in the gnuplot
session, because events are only processed from the active terminal.

We understood the issue, and Ethan even wrote a patch for it : it's
#1500654... (read the patch summary, it's exactly the discussion here!)
and he closed the patch himself too...

I have thought about this for quite a long time, here is my conclusion:
We cannot call several term->waitforinput() at the same time, or even
sequentially, because they are all blocking calls, so the approach taken
by Ethan would not work if we want to use _both_ X11 and wxt in the same
session for example. Making term->waitforinput non-blocking means using a
poll with a timeout, and I think it's quite bad to do so (i.e. it means
regular wakeups, which implies among other things high battery usage on a
laptop, see www.linuxpowertop.org).

I see two alternatives to this:
1) Choose one (and only one) so-called 'screen terminal' that would be
privileged and see its events being processed even if it is not the
current one. If wxt is the 'screen terminal', x11 could still be chosen,
but it wouldn't get any interactive behaviour (well, actually it would
partially, since gnuplot_x11 is able to give mouse coordinated without the
core having to say anything)

2) Have a more general event loop system where a terminal could "install"
event sources... for example it is easy to watch for *several*
file-descriptors on unix-like systems _at the same time_, without polling
regularly. In a wxWidgets-on-GTK event loop, these file descriptors would
be:
-stdin, for gnuplot command-line,
-the file descriptor that wxt is using for its connection to the X server,
-the file descriptor for the pipe that the x11 terminal uses to talk to
gnuplot_x11

That way, the event loop could handle the events from both wxt and x11,
and we could make 'q' and ' ' always working, even for an inactive plot
window.

The only drawback of this approach is that it's slightly
platform-specific. On Windows, the loop would most likely wait for
so-called 'messages' instead of file descriptors... and note that this is
already how it works on Windows ! There's no term->waitforinput() there,
only a getc wrapper that actually processes the "messages" and we could
write a patch right now that does #2.

On Unix, we would have to do something like what is done in
x11->waitforinput, where select() is used to wait for stdin _and_ the pipe
at the same time...

Wow, what a long message... Don't hesitate to comment.

Timothée