Re: gnuplot terminal size & position

[Ben Abbott]

On Feb 16, 2011, at 4:34 AM, Benjamin Lindner wrote:

>> I had tried to resize the windows for x11, wxt, and aqua.
>> Unfortunately, changing the position/size means the existing (x11, wxt,
>> aqua) window will be closed and a new one opened. This results in (1) a
>> "flickering" when animations are run, (2) the window repositioning itself
>> after being moved by the mouse. The consensus at that time was
>> flickering/repositioning was less desirable than not being able to change he
>> window position/size.
> 
> I tend to disagree here. At least the size of the window should be
> specifiable from octave.
> I agree that it's not easily done, however, give the current state of things.
> 
> (1) is a problem of the respective gnuplot terminal, this does not
> happen for the windows terminal. It simply moves/resizes the window
> (i.e. gnuplot uses the MoveWindow() function from windows API)
> 
> (2) is partly a problem of the gnuplot terminal and partly a problem
> of octave itself.
> Octave does not know when you move the gnuplot window, so to octave,
> the position hasn't changed. That problem could theoretically be
> solved (for the windows terminal, can't tell about x11, aqua and wxt)
> by making gnuplot report the current window's position & size and
> reading it into octave and updating the figures properties.
> However, the bug on octave's side is, that I currently cannot change
> only the window's position or only its size (yes, I know the
> competition does it the same way, it's nevertheless a bug...)
> 
> By separating the size and position (their handling in
> gnuplot_set_term at least), and only setting the property that hasn't
> changed one can avoid the repositioning problem, if only the size of
> the window has changed.
> 
> So for example:
>  figure(1);
>  plot( 0:0.1:10, sin(0:0.1:10), "@-;sin;");
>  sp = get(gcf,'position');
>  newpos = sp;
>  newsize = sp;
>  newpos(1:2) += [100, 100];
>  newsize(3:4) += [100, 100];
> 
> now using the mouse move the figure around. Then
>  set(gcf,'position', newsize);
> only updates the figure's position, leaving its size as is.
> 
> If you change the figure's size using the mouse and issue
>  set(gcf,'position', newpos)
> only it's position is updated, the size is left unchanged.
> 
> The catch with this is, again (2) - if you move the window, then
> octave currently doesn't know about it. So trying to reposition back
> will not work, because octave thinks the window hasn't moved anyway,
> and doesn't issue a position command to gnuplot (and vice versa for
> re-sizing).
> The solution to this would be either: read the position/size from
> gnuplot, or make octave somehow aware of the fact that I only want to
> change the window's position or only the window's size - and then
> issue the corresponding commands to gnuplot.
> 
> The situation currently is unsatisfactory, I know. I personally would
> prefer if octave had a way of allowing the size and position of the
> window specified spearately. This would solve all problems, expect not
> being able to read back the current position (but which I wouldn't
> need to know then anyway, because I can only change the window's size
> respecively position).
> What would be the odds against such a feature?
> 
>> Can a patch be made that only effects the windows terminal?
> 
> Yes, I think this would be possible.
> 
>> ... also have
>> you looked at any of the animations to see if the window flickers? (comet,
>> or comet3?)
> 
> I tried comet and comet3, and it's not perfectly smooth, but I
> wouldn't call it flickering.
> But these animations don't change either the size or position, so I
> wouldn't expect flickering anyway (according to (1)?)

The flickering for x11/wxt occurred because gnuplot deleted the old window and 
created a new one. I'd expect the same behavior for windows, but don't know if 
that is the case.

>> If the window size is modified by the mouse, does it self
>> correct when updated?
> 
> That depends on what you'd define "updated".

Anything that causes the plot to be redrawn. What happens for ...

plot (0:1)
hold all
# reposition / resize window with the mouse
plot (-1:0)

... My experience is that the size and position of the figure window will 
revert to that specified by the figure's "position" property.

> Speaking of gnuplot alone now.
> If you exeute
>   set term windows size 400,300 position 200,200
>   plot sin(x)
> and then move the window, issuing
>   set term windows position 200,200
> will re-position it back (without changing its size).
> Similarily, if you resize it and issue
>   set term windows size 400,300
> the window will be re-sized back without changing its current position.

Its been a while since I worked on this. I don't recall if I tried to handled 
the size and position separately. 

> Now currently there is no way to use this functionality from octave,
> because octave cannot determine if I only want to change the size or
> only want to change the position.
> 
> I currently do a check-against-the-last-known-position/size approach
> (used in the example code above), but, again, octave is ignorant of
> manual moves, so this is not really satisfactory.

Detecting whether the window has been manually repositioned or resized is the 
only problem I see. If the window were deleted and redrawn in those cases, I 
don't think anyone would mind. However, how do we make sure the "position" 
property reflects the windows current position and size? The recent gnuplot 
does give us access to the x11 ID for the windows. Can that be used to trigger 
an update to the "position" property when the window's position/size is 
changed? ... can the same be done for the window's terminal? (it cannot for 
aqua).

Ben