Re: Time to branch off 4.0 from 4.1?

[Petr M. <mi...@ph...>]

> > then "show variables" should have define all
> > usual mousing variables, obviously with zero values, and the MOUSE_KEY
> > should be set to -1:
>
> I do not like this idea at all. zero is a legal coordinate value, so
> setting coordinates to zero is not a safe way of indicating an abnormal
> return.

I didn't mean MOUSE_X, but MOUSE_KEY -- that's the indication what has
happened during "pause mouse".

From the programming point of view, what a driving program has to write to
gnuplot in either case -- an Octave example:

A. "close" sets MOUSE_X, .. to e.g. 0, and MOUSE_KEY to -1:

graw('\nprint MOUSE_X, MOUSE_Y, MOUSE_KEY;');
...read them from fifo...
if (mouse_key >= 0) ...

B. "close" does not define anything:

graw('\nif (defined(MOUSE_KEY)) print MOUSE_X, MOUSE_Y, MOUSE_KEY; else
print "0 0 -1"\n');
...read them from fifo...
if (mouse_key >= 0) ...

Note that "\n..." is necessary as one character gets eaten during close.


In summary: I would like more to have MOUSE_KEY defined always, and being
positive for mouse and key events, and being negative for a "fatal" case of
no such event.


> I suggest that the proper fix is to modify your scripts to test for the
> existence of the variable before trying to print it.

The above-mentioned script works, just "it does not look so nice" with the
additional "if ; else 0 0 -1".


BTW, one bug:

gnuplot> plot x
gnuplot> pause mouse key
 ..hit q
gnuplot> pause mouse key
 ..now must press Ctrl-C
gnuplot> pause mouse key
    warning: Mousing not active
                     ^
         expecting string

gnuplot> pause mouse
         warning: Mousing not active


It should report the "Mousing not active", or rather "Interactive terminal
window is closed", even in the 1st trail; that Ctrl-C is fatal for driving
apps.



> > Finally, what do you think about this: "q" hotkey is disabled when
> > "pause mouse key" comes to action;
>
> I have been unable to figure out how to do this.
> The "q" hotkey is handled directly by gnuplot_x11, which doesn't know
> anything about "pause mouse".

Thus, a special string must be sent to the interactive terminal at the
beginning, and another one at the end.

Actually, it will be the same thing as switching on/off mouse-related menu
items in the PM terminal, when mouse gets disabled in gnuplot. See
mouse.c: builtin_toggle_mouse()
...
# ifdef OS2
    update_menu_items_PM_terminal();
# endif
...


/* update menu items in PM terminal */
void
update_menu_items_PM_terminal(void)
{
    send_gpPMmenu(PM_pipe);
}


=> and send_gpPMmenu does:

    putc('#', PM_pipe);
    fwrite(&gpPMmenu, sizeof(gpPMmenu), 1, PM_pipe);

Great hack, but works as user expects.


> I think it would take a separate communication channel and a new set of
> driver calls to implement this, since gnuplot would have to inform
> gnuplot_x11 asynchronously that it is requested to change how it is
> handling X11 input events. Frankly, I think it would be a huge headache to
> get this working.

That's why my previous idea to change "set_cursor" api to "set_interactive"
to pass exactly such events, instead of those e.g.  SET_SPECIAL events sent
by some .trm.


> The only alternative I have been able to come up with is to
> move the "q" processing for the current plot window out of gnuplot_x11
> altogether, and make it equivalent to
>    bind 'q' '<some command related to set term x11 close>'
> If you have any better ideas, please speak up.

But "q" is traditional as it closes -persisten gnuplot_x11 too.

> > thus, command.c should call
> > "x11_hotkeys(0)" and afterwards "x11_hotkeys(1)" to enable them again.
> x11_hotkeys()?   Is this a new driver primitive that you have designed?
> I agree it would be possible to do this sort of thing by adding a new set
> of driver primitives.  But that's a big job and I don't have time to tackle it.

To be reused set_cursor. Ok, then it can wait for cvs branch splitting.

---
Petr