Re: (un)set mouse, x11 persist and gplt_x11.c: MOUSE_ALL_WINDOWS

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 23 March 2004 08:04 am, Petr Mikulik wrote:
> According to the bug report "[ 921033 ] pipe+mouse+x11", the following
>
> set mouse
> set term x11 1 persist
> plot sin(x)
> set term x11 2 persist
> plot x
> set term x11 3 persist
> plot tan(x)
> quit
>
> let terminals 1 and 2 mouseable, while not 3. There seems to be a bug
> that does not notify terminal 3 to be active for post-quit mousing.

Fixed in CVS.  If the connection between gnuplot and gnuplot_x11 is
broken (e.g. by 'quit') then gnuplot_x11 will take over the mousing.

But there is a related case for which I am not sure of the 
correct behaviour:

set term x11 1 persist
plot sin(x)
set term dumb

At this point the connection between gnuplot and gnuplot_x11 is
still present but, since the current terminal is no longer x11, mouse
events are ignored.  Should we explicitly turn mousing over to
gnuplot_x11 in this case even though the connection is still active?
Should gnuplot itself continue to handle X-events even though the
current terminal is now something other than x11?


> set mouse
> set term x11 1 persist
> plot sin(x)
> set term x11 2 persist
> plot x
> set term x11 3 persist
> plot tan(x)
> unset mouse
>
> unsets mouse only in terminal 3, and not in all terminals. Also a bug.

Not fixable.  Or at least not fixable in the general case, although the
specific simple example you give could be changed.   But why is it a
bug?  If you ask for a persistent X11 window, don't you expect it to
operate on its own without further input from gnuplot?

In fact, now that I think about it - I consider it a bug that if you type
'set term x11 nopersist; exit' at this point then all the previous windows
are closed even though they were individually opened with "persist".
I think that persist/nopersist should be a per-window property, not a
global one.

> I think gplt_x11.c should react to "m" hotkey to switch the mousing bar on/off.

Good idea.  I will add it to CVS when SourceForge comes back online.

> Finally, there is some funny behaviour of mousing ruler, when "set x11
> <another>; replot" -- it would be nicer to position the ruler to its x,y
> coordinates.

Please explain in more detail.  Do you mean that the new window should
not inherit the state of the ruler from the previous window?  Or do you
mean that it *should* inherit the ruler, but the ruler should be re-positioned?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195