Re: Octave-maintainers Digest, Vol 38, Issue 56

[Daniel J Sebald]

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

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.

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.

*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