Quantcast

gnuplot terminal size & position

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gnuplot terminal size & position

benjamin lindner-3
Hello,

I am trying to implement the "size" and "position" options for the
windows terminal, which gnuplot 4.4.2 supports.
I discovered, that setting the figures size&position with
  set(gcf,"position", [200,200,400,300])
does not result in the plotting window changing its size & position,
which is due to the fact, that the respective size_str is not applied
for already open plotting windows.
It requires the following change to work

@@ -272,7 +278,7 @@
       term_str = sprintf ("%s %s", term_str, title_str);
     endif
     if (isempty (strfind (term, "corel")))
-      if (! isempty (size_str) && new_stream)
+      if (! isempty (size_str) )
         ## size_str comes after other options to permit specification of
         ## the canvas size for terminals cdr/corel.
         term_str = sprintf ("%s %s", term_str, size_str);

and I wanted to ask, what was the reason for only using the size
string for new plotting windows, and not for already open ones?

benjamin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gnuplot terminal size & position

bpabbott
Administrator
On Feb 15, 2011, at 12:26 PM, Benjamin Lindner <[hidden email]> wrote:

Hello,

I am trying to implement the "size" and "position" options for the
windows terminal, which gnuplot 4.4.2 supports.
I discovered, that setting the figures size&position with
set(gcf,"position", [200,200,400,300])
does not result in the plotting window changing its size & position,
which is due to the fact, that the respective size_str is not applied
for already open plotting windows.
It requires the following change to work

@@ -272,7 +278,7 @@
term_str = sprintf ("%s %s", term_str, title_str);
endif
if (isempty (strfind (term, "corel")))
- if (! isempty (size_str) && new_stream)
+ if (! isempty (size_str) )
## size_str comes after other options to permit specification of
## the canvas size for terminals cdr/corel.
term_str = sprintf ("%s %s", term_str, size_str);

and I wanted to ask, what was the reason for only using the size
string for new plotting windows, and not for already open ones?

benjamin
 
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.

Can a patch be made that only effects the windows terminal? ... also have you looked at any of the animations to see if the window flickers? (comet, or comet3?) If the window size is modified by the mouse, does it self correct when updated?

Ben

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gnuplot terminal size & position

benjamin lindner-3
> 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)?)

> If the window size is modified by the mouse, does it self
> correct when updated?

That depends on what you'd define "updated".

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.

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.

benjamin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gnuplot terminal size & position

bpabbott
Administrator
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gnuplot terminal size & position

benjamin lindner-3
> 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.

It doesn't seem to do this for windows.

>> 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.
Ah, I get it. No it doesn't change either size or position.
But that's because I added the aforementioned
check-against-the-last-known-position code, and for octave, the window
has neither moved nor changed its size, so it does not re-issue a
"size" or "position" option to gnuplot. It only does if you call
set(h, 'position', foo) and either the position has changed or the
size has changed from the last call of set(h, 'position', foo).
I attached what I changed so far if you're curious.

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

For the windows terminal, the patch is pending on gnuplot's mailing
list. If you'd want to check it, you'd have to build from recent CVS
yourself.

>> 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).

Does this mean that separate "size" and "position" figure options are
not a problem? (I feared that this would raise loud opposition).
That'd be half the problem's solution, actually that would /be/ the
problem's solution.

Detecting manual movements currently is not possible, I agree. (I
think it should be possible to do so if you either ask gnuplot - but
the it would have to be implemented there - or ask the OS if you know
the window handle. I could do a quick hack to check it this is
possible for windows...)
But detecting manual movements is only required if you want to read
out the current position, but you don't need the current position to
specify a new position /if/ there is a way to signal that a new
position is requested (vice versa for the size) and there you're back
at the separate "size" and "position" options (or whatever other way
to implement it).

So, yes, it would be cool if I could read out the current window's
position. But then again, this would mirror only the position on the
screen, not the actual size of the window - the window on screen is
larger than what you specify with "set term windows size x,y". here
x,y is the canvas size (like in all printout terminals), and the
actual window on screen is larger (it includes e.g. a status bar, a
caption bar, possibly a toolbar, and borders).
Which size would you then reflect in octave? The size the OS will tell
you is the window size, not the canvas size. So setting the size as
e.g. [400,300] and then reading the window's (screen) size will yield
a larger window size.

benjamin

gnuplot_windows_sizeposition.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gnuplot terminal size & position

bpabbott
Administrator
On Feb 16, 2011, at 10:08 AM, Benjamin Lindner <[hidden email]> wrote:

> 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.

It doesn't seem to do this for windows.

>> 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.

Ah, I get it. No it doesn't change either size or position.
But that's because I added the aforementioned
check-against-the-last-known-position code, and for octave, the window
has neither moved nor changed its size, so it does not re-issue a
"size" or "position" option to gnuplot. It only does if you call
set(h, 'position', foo) and either the position has changed or the
size has changed from the last call of set(h, 'position', foo).
I attached what I changed so far if you're curious.

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

For the windows terminal, the patch is pending on gnuplot's mailing
list. If you'd want to check it, you'd have to build from recent CVS
yourself.

>> 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).

Does this mean that separate "size" and "position" figure options are
not a problem? (I feared that this would raise loud opposition).
That'd be half the problem's solution, actually that would /be/ the
problem's solution.

Detecting manual movements currently is not possible, I agree. (I
think it should be possible to do so if you either ask gnuplot - but
the it would have to be implemented there - or ask the OS if you know
the window handle. I could do a quick hack to check it this is
possible for windows...)
But detecting manual movements is only required if you want to read
out the current position, but you don't need the current position to
specify a new position /if/ there is a way to signal that a new
position is requested (vice versa for the size) and there you're back
at the separate "size" and "position" options (or whatever other way
to implement it).

So, yes, it would be cool if I could read out the current window's
position. But then again, this would mirror only the position on the
screen, not the actual size of the window - the window on screen is
larger than what you specify with "set term windows size x,y". here
x,y is the canvas size (like in all printout terminals), and the
actual window on screen is larger (it includes e.g. a status bar, a
caption bar, possibly a toolbar, and borders).
Which size would you then reflect in octave? The size the OS will tell
you is the window size, not the canvas size. So setting the size as
e.g. [400,300] and then reading the window's (screen) size will yield
a larger window size.

benjamin
 
Regarding separate size and position options, this should be handled by the gnuplot specific code. The figures properties should not change.

Regarding the rest, can you propose a changeset?

Ben

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gnuplot terminal size & position

benjamin lindner-3
In reply to this post by benjamin lindner-3
> I could do a quick hack to check it this is
> possible for windows...)

This works on windows platform, if you know the window's handle
(that's what it's called here).
So if gnuplot told you the handle of the graph's window, one can query
the window's position and size from octave.
Loading...