octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: request of Mac OSX users


From: Ben Abbott
Subject: Re: request of Mac OSX users
Date: Mon, 29 Dec 2008 11:13:48 -0500


On Dec 28, 2008, at 2:56 PM, Thomas Treichl wrote:

Ben Abbott schrieb:
On Dec 28, 2008, at 2:27 PM, Thomas Treichl wrote:
Ben Abbott schrieb:
On Dec 27, 2008, at 12:34 AM, Ben Abbott wrote:
The gnuplot maintainers have recently committed a change that allows the x11 terminal to have its size and position specified.

I've modified a local version of gnuplot_drawnow to take advantage of these features. The first time a plot is drawn it works correctly. When I place a loop around a plot command, the plot grows progressively taller. It appears the each plot produces a window which is taller by an amount approximately equal to 10 pixels.

Thus, figure(1) below is about 100 pixels taller than figure(2)

  figure(1)
  clf
  for n=1:11
      plot(1:10)
      drawnow
  endfor

  figure(2)
  clf
  plot(1:10)

I'd like to be able to examine the entire gnuplot stream. Unfortunately, if I replace "drawnow" with

  drawnow ("x11", "/dev/null", true, sprintf("debug-%d.gp", n))

The plots render as would be expected.

In the unlikely event that someone has a recent build of gnuplot 4.3.0+ and a recent developers build for octave, I've attached a path for gnuplot_drawnow that adds a single line to gnuplot_drawnow and willl produce the effect I've described.

So my question is, can anyone describe what is changes for the gnuplot stream in these two examples?

Ben
I've spent some time isolating the problem regarding the recently committed a change to gnuplot that allows the x11 terminal to have its size and position specified. The problem is not related to Octave, but it is a problem if supporting the figure handle property "position" is desired (which I've been working on). Thus far, my exchanges with the gnuplot developers indicates that the problem may be isolated to my system. I'm running Mac OSX 10.5.6 and XQuartz 2.3.1 (xorg-server 1.4.2-apple17). I'm hoping someone here is also running OSX and gnuplot 4.3.0+ (Revision > 1.2224.2.330). If so the following commands place iteratively in a file produce a plot whose height iteratively grows taller.
  set terminal x11 size 560,480 position 440,106
  set multiplot;
  plot x
  unset multiplot;
I've attached a file with the iterations. I'd be interested in what other Mac OSX users get when the following is typed from the Terminal window. gnuplot -persist simple_example.gp Please let me know if the plot grows taller and include your Mac OSX version, and the x- server information.

Hi Ben,

I compiled a current development snapshot Gnuplot 4.3.0. I run your test 'simple_example.gp' and saw a figure window that grew in y-direction. If I understand your script which always says "size 560,480" then I also would expect that this size is fixed, right?! But it actually isn't.

I'm sorry that I'm not that plotting and not that Gnuplot specialist either to give some more help, but I hope I can help with this information, here also is the system that I'm running: OS X 10.4.11, i386, and current the X11 server is

bash ~$ X -version
XFree86 Version 4.4.0 / X Window System
(protocol Version 11, revision 0, vendor release 6600)

Best regards,

Thomas
Thanks Thomas,
I won't worry that the problem is isolated to my particular system. By the way Ethan Merritt (gnuplot developer) has been very helpful in isolating the problem. The window appears to be growing by the amount reserved for displaying the cursor coordinates at the bottom of the figure. By adding a "unset mouse" command after "unset multiplot", the window no longer grows (at least for me). Once done, the mouse actions are still active (I'm not sure this is intentional). If you don't mind, can you verify this solution works for you as well? File attached.

Yes sure, I can help, no problem. That's exactly what I can see now, yes. No growing window anymore with your new script 'simple_example.gp'.

 Thomas

Thomas / (other Mac OSX user)

Ethan Merritt (gnuplot developer) is willing to fix this problem but does not have a Mac available to track down the problem.

Unfortunately, I lack the skills needed to debug c/c++ code. If you are inclined to assist, see the thread at the link below

http://www.nabble.com/problem-with-%22set-x11-%7Bsize-WW%2CHH%7D-%7Bposition-XX%2CYY%7D%22-to21190071.html

The branch including Ethan's reply dated "Dec 29, 2008; 12:15am" is the one to read.

Ben




reply via email to

[Prev in Thread] Current Thread [Next in Thread]