[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave-maintainers Digest, Vol 38, Issue 56
From: |
Ben Abbott |
Subject: |
Re: Octave-maintainers Digest, Vol 38, Issue 56 |
Date: |
Sun, 31 May 2009 15:07:17 -0400 |
On May 31, 2009, at 2:58 PM, Daniel J Sebald wrote:
Rik wrote:
------------------------------------------------------------------------
Subject:
Re: plot and image demos (growing window)
From:
Ben Abbott <address@hidden>
Date:
Sat, 30 May 2009 03:13:39 -0400
To:
Rik <address@hidden>
To:
Rik <address@hidden>
CC:
address@hidden
Thanks Rik. The only difference I see in the two files are in the
beginning.
From 9097
set terminal x11 enhanced title "Figure 1" ; set output "/dev/
null";
reset; set autoscale fix;
From the current tip
set terminal x11 enhanced title "Figure 1" set output '/dev/null';
reset; set autoscale keepfix;
The "output" is not relevant as it is not present when rendered to
the screen.
However, when add both the remaining differences to the current
sources the window still grows.
Rik, can you confirm that your build for 9097 did *not* produce a
growing window when running a gnuplot 4.2.5 or 4.3.0?
The problem definitely seems to be gnuplot related. For gnuplot
version
4.2.2, revision 9097 works. For gnuplot version 4.2.5, revision 9097
fails. 4.3 won't compile on my Hardy Heron box. I suppose we
could try
to work-around their bug if we could figure out how we are
triggering it
or we will simply have to let it pass as being outside of Octave.
I'm not saying there isn't a bug in gnuplot, but I'm still trying to
understand what the method is for controlling the size of the x11
window and/or mouse. (Unfortunately, savanah server isn't working
so that I can view the latest code.)
There is too much in between Octave and gnuplot to conclude this is
a gnuplot bug based on your observation. For example, I see in the
gnuplot record the following changes:
Revision 1.160.2.11 - (view) (download) (annotate) - [select for
diffs]
Thu Dec 25 05:50:59 2008 UTC (5 months ago) by sfeam
Branch: branch-4-2-stable
Changes since 1.160.2.10: +80 -2 lines
Diff to previous 1.160.2.10 , to branch point 1.160
set term x11 {size XX,YY} {position XX,YY}
Revision 1.179 - (view) (download) (annotate) - [select for diffs]
Thu Dec 25 03:02:05 2008 UTC (5 months ago) by sfeam
Branch: MAIN
Changes since 1.178: +80 -2 lines
Diff to previous 1.178
set term x11 {size XX,YY} {position XX,YY}
So, if this is when the new feature was added, it could simply be
that this is when the bug started appearing. That is, before the
above dates, gnuplot didn't have the feature that Octave is
attempting to use so there is no way the hypothetical bug could have
been illustrated whether the source of the problem is in Octave or
gnuplot. Restating, perhaps the bug in Octave didn't appear until
gnuplot has the option {size XX,YY} and {position XX,YY}.
Presently this size/position information is only sent to x11 *once*
for each window, when it is first created.
Ben, are you sure that Octave doesn't currently have the feedback
path of getting the X11 window size from X11 resources? I see in
gnuplot_drawnow.m the method
screensize = get (0, "screensize")(3:4);
used in computing the size. Furthermore, I see in some of the C++
code that John added something that gets screensize from the X11
window system:
2009-01-22 John W. Eaton <address@hidden>
* toplev.cc (octave_config_info): Check OCTAVEUSE_OS_X_API instead
of __APPLE__ && __MACH__.
* display.cc (display_info::init): Get info for Windows and OS X
systems.
The screensize is not the same thing as the figure size. For me, my
computer's sceen size is 1440x878 pixels.
So I'm wondering if there is in fact a feedback loop where
1) Octave tells gnuplot to set size of the window.
2) gnuplot does so, but then also tags an extra 13 pixels for the
coordinates line
3) Octave inquires the screen size from X11 resources, so the actual
size is 13 larger than what Octave last requested.
4) repeat beginning at line 1.
No. This is not in the code.
*If* that is the case, the solution is to unset the mouse before
inquiring about the X11 screensize, or subtract off 13 points if the
mouse is known to be active, or lobby Ethan at the gnuplot
discussion list to not increase the size of the plot for the
coordinate line at the bottom of the figure, but instead subtract
from the available plotting space (or have an option to configure
how that line behaves).
The one thing I'm uncomfortable with in the first two solutions
above is that the coordinate line in the plot window doesn't appear
immediately after a "set mouse" until the mouse is moved over the
screen. (But hopefully gnuplot developers would fix that easily
enough if asked.)
Dan
PS: Does this bit of code in gnuplot_drawnow do anything if we end
up using {size XX,YY} option?
if (any (strncmpi (term, {"x11", "wxt"}, 3)) && new_stream
&& __gnuplot_has_feature__ ("x11_figure_position"))
## The "close" is added to allow the figure position property
## to remain active.
term_str = sprintf ("%s close", term_str);
endif
This code is responsible for sending the terminal command to gnuplot.
Notice it is only sent if the plot stream is a "new_stream". Thus, it
only gets sent one time for each window.
Ben
- Re: Octave-maintainers Digest, Vol 38, Issue 56, Rik, 2009/05/31
- Re: Octave-maintainers Digest, Vol 38, Issue 56, Ben Abbott, 2009/05/31
- Re: Octave-maintainers Digest, Vol 38, Issue 56, Daniel J Sebald, 2009/05/31
- Re: Octave-maintainers Digest, Vol 38, Issue 56,
Ben Abbott <=