Re: plot and image demos (growing window)

[Ben Abbott]

On May 29, 2009, at 2:05 AM, Daniel J Sebald wrote:

> Ben Abbott wrote:
> > On May 29, 2009, at 1:35 AM, Daniel J Sebald wrote:
> > > Ben Abbott wrote:
> > >
> > > > On May 29, 2009, at 12:58 AM, Jaroslav Hajek wrote:
> > > >
> > > > > On Fri, May 29, 2009 at 2:09 AM, Ben Abbott <address@hidden>   
> > > > > wrote:
> > > > >
> > > > > > On May 28, 2009, at 5:25 PM, John W. Eaton wrote:
> > > > > >
> > > > > > > On 28-May-2009, Ben Abbott wrote:
> > > > > > >
> > > > > > > | This looks like a feature of gnuplot. When a subsequent  
> > > > > > > "set  term
> > > > > > > | x11 ..." command is encountered before the prior plot- 
> > > > > > > stream   completes
> > > > > > > | there appears to be some unintended interaction between   
> > > > > > > gnuplot  and
> > > > > > > | x11 which causes the window to grow.
> > > > > > > |
> > > > > > > | For example, try ...
> > > > > > > |
> > > > > > > |       for n=1:100; plot(1:1000); drawnow; end
> > > > > > > |
> > > > > > > | Adding the command "unset mouse" the the beginning of the   
> > > > > > > plot- stream
> > > > > > > | eliminates the problem. Shall a "unset mouse" be added to  
> > > > > > > be   beginning
> > > > > > > | of each plot-stream? (changeset attached) ... If desired a   
> > > > > > > "set  mouse"
> > > > > > > | may added at the end of the plot-stream. Unfortunately, I   
> > > > > > > don't  know
> > > > > > > | of a good way to detect the state of "set/unset mouse". We  
> > > > > > > could
> > > > > > > | obtain the x11 window ID and ask x11 for the window size while
> > > > > > > | toggling the mouse state, but is it worth the hassle?
> > > > > > >
> > > > > > > No, I don't think it is worth it.
> > > > > > >
> > > > > > > Even unset mouse/set mouse might not be worth it.  Is there  
> > > > > > > an  easy
> > > > > > > way to demonstrate this bug with a simple gnuplot script?  If   
> > > > > > > so,  then
> > > > > > > I'd say report it as a bug in gnuplot and we should not  
> > > > > > > bother  to  work
> > > > > > > around it in Octave.
> > > > > > >
> > > > > > > jwe
> > > > > >
> > > > > >
> > > > > > John / anyone-else,
> > > > > >
> > > > > > can you confirm that the simple example I gave causes your   
> > > > > > window  to grow?
> > > > > >
> > > > > > Ben
> > > > >
> > > > >
> > > > > Confirmed; it really grows.
> > > >
> > > > ok, I'll try to create an example using only gnuplot that does  
> > > > the   same (thus far, I've failed).
> > >
> > >
> > > Ben,
> > >
> > > I've an old version of Octave (3.0.0+) on this machine and just   
> > > compiled the latest gnuplot.  The above command does not cause  
> > > the  plot window to grow.
> > >
> > > A month or two ago there was a discussion about querying window  
> > > size/ placement so that a moved/resized window will stay in the  
> > > same  place.  Might there be a problem with that code?  For  
> > > example, I can  imagine a scenario where Matlab's concept of  
> > > window size and  gnuplot's concept of window size differ by one  
> > > point and every time  Matlab queries and sets the window there is  
> > > a difference of one pixel.
> > >
> > > Dan
> > I suspect the growth behavior only occurs when the window position  
> > and  size are specified for gnuplot. The 3.0.x series does not  
> > include this  capability. Also, it should anly be present for  
> > gnuplot 4.2.5 and above.
> > In any event, your recollection is correct. The solution for the   
> > moment is to explicitly set the window size and position only when  
> > it  is first created.
> > Your intuition is also good. Gnuplot allows an additional line to  
> > be  added to the bottom of each plot window where mouse coordinates  
> > are  displayed. This extends the height of the window by 13 pixels.  
> > It is  by this amount that the window incrementally grows.
>
> Ah, OK that at least gives some insight.
>
>
> > I'm still trying to demonstrate the effect using only gnuplot ...   
> > unfortunately, I'm still failing :-(
>
> Well, if the window is growing, Octave must be acquiring the window  
> size/position when the mouse is active, then mouse is turned off and  
> the window size is set, then mouse is turned back on... that's my  
> guess.  My guess is that the mouse coordinate line at the bottom is  
> added as an extra (or extension) and not really accounted for in  
> gnuplot's core.

Octave doesn't acquire the window position. I'd hoped to do so, but  
haven't developed a proper solution.

> For example, try the following in gnuplot (no Octave):
>
> plot x
> unset mouse
> set mouse
>
> What I notice is that "unset mouse" causes the extra line for the  
> coordinates to immediately disappear.  But the coordinate line does  
> not automatically reappear until I place the cursor into the X11  
> plot window.
>
> Anyway, it seems to me that the coordinate window is tagged on as  
> extra.
>
> Is there some way in the Octave code to turn the mousing off (i.e.,  
> unset mouse) before querying for the X11 position/size?

The only way would be to ...

(1) get the window size
(2) set mouse
(3) get the window size
(4) unset mouse
(5) get the window size
(6) Determine if the mouse was originally set or unset
(7) Return the mouse to its original state

Such an implementation is kludgy :-(

However the greater difficulty is how to obtain the x11 window  
position and size reliably for Unix and Windows.

Ben