From: Ben A. <bpa...@ma...> - 2008-12-28 04:38:31
Attachments:
changeset-gnuplot_size-position.patch
|
Recently a change was committed that allows the x11 terminal to have its size and position specified. I've attempted to use this new feature from Octave. I've modified a local version of Octave's gnuplot_drawnow.m 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) Iteratively typing plot(1:10) at octave's command does not produce the problem. I've attached a simple changeset which can be applied to Octave's developer's sources to duplicate this problem. I'm eager to find a solution so if there is anything I can try to isolate the problem, let me know. Ben |
From: Ben A. <bpa...@ma...> - 2008-12-28 04:59:55
|
I've concatenated several plot streams produced by Octave to demonstrate what I am seeing. The file is attached. Just type the command below. The resulting plot should grow in height each time it is plotted. $ gnuplot -persist growing_plot.gp http://www.nabble.com/file/p21190150/growing_plot.gp growing_plot.gp -- View this message in context: http://www.nabble.com/problem-with-%22set-x11-%7Bsize-WW%2CHH%7D-%7Bposition-XX%2CYY%7D%22-tp21190071p21190150.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-28 07:00:03
|
On Saturday 27 December 2008, Ben Abbott wrote: > > I've concatenated several plot streams produced by Octave to demonstrate what > I am seeing. The file is attached. > > Just type the command below. The resulting plot should grow in height each > time it is plotted. I see no change in the plot window size; each plot is redrawn exactly on top of the previous one. My machine is running x11-server-xorg-1.4.0.90 kdebase-kdm-3.5.9 I think that to debug this we will need to know your operating system environment, and in particular the window manager and the X-server being used. > $ gnuplot -persist growing_plot.gp > > http://www.nabble.com/file/p21190150/growing_plot.gp growing_plot.gp > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Ben A. <bpa...@ma...> - 2008-12-28 16:03:33
Attachments:
simple_example.gp
|
On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: > On Saturday 27 December 2008, Ben Abbott wrote: >> >> I've concatenated several plot streams produced by Octave to >> demonstrate what >> I am seeing. The file is attached. >>> Just type the command below. The resulting plot should grow in >>> height each >> time it is plotted. > > I see no change in the plot window size; each plot is redrawn > exactly on top > of the previous one. My machine is running > x11-server-xorg-1.4.0.90 > kdebase-kdm-3.5.9 > > I think that to debug this we will need to know your operating system > environment, and in particular the window manager and the X-server > being used. > I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If by "operating system environment" you're looking for more than I gave, let me know what it is you'd like to see. For more info on XQuartx see the link below. http://xquartz.macosforge.org/trac/wiki I've spent some time reducing the number of gnuplot commands needed to produce the problem. If the 4 lines below are placed iteratively in a file, the resulting window progressively grows taller (with the title bar being static). set terminal x11 size 560,480 position 440,106 set multiplot; plot x unset multiplot; I've attached another file for this simplified example. In any event, the problem appears to only exist (for me) in multiplot mode. I also noticed that the final window height is not always the same. Ben |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-28 18:53:31
|
On Sunday 28 December 2008, Ben Abbott wrote: > > On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: > > > On Saturday 27 December 2008, Ben Abbott wrote: > >> > >> I've concatenated several plot streams produced by Octave to > >> demonstrate what > >> I am seeing. The file is attached. > >>> Just type the command below. The resulting plot should grow in > >>> height each > >> time it is plotted. > > > > I see no change in the plot window size; each plot is redrawn > > exactly on top > > of the previous one. My machine is running > > x11-server-xorg-1.4.0.90 > > kdebase-kdm-3.5.9 > > > > I think that to debug this we will need to know your operating system > > environment, and in particular the window manager and the X-server > > being used. > > > > I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If by > "operating system environment" you're looking for more than I gave, > let me know what it is you'd like to see. For more info on XQuartx see > the link below. > > http://xquartz.macosforge.org/trac/wiki > > I've spent some time reducing the number of gnuplot commands needed to > produce the problem. If the 4 lines below are placed iteratively in a > file, the resulting window progressively grows taller (with the title > bar being static). > > set terminal x11 size 560,480 position 440,106 > set multiplot; > plot x > unset multiplot; > > I've attached another file for this simplified example. > > In any event, the problem appears to only exist (for me) in multiplot > mode. I also noticed that the final window height is not always the > same. Could you please try adding the command "unset mouse" to the beginning of your test script, and check whether that makes any difference? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Ben A. <bpa...@ma...> - 2008-12-28 19:27:03
|
On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote: > On Sunday 28 December 2008, Ben Abbott wrote: >> >> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: >> >>> On Saturday 27 December 2008, Ben Abbott wrote: >>>> >>>> I've concatenated several plot streams produced by Octave to >>>> demonstrate what >>>> I am seeing. The file is attached. >>>>> Just type the command below. The resulting plot should grow in >>>>> height each >>>> time it is plotted. >>> >>> I see no change in the plot window size; each plot is redrawn >>> exactly on top >>> of the previous one. My machine is running >>> x11-server-xorg-1.4.0.90 >>> kdebase-kdm-3.5.9 >>> >>> I think that to debug this we will need to know your operating >>> system >>> environment, and in particular the window manager and the X-server >>> being used. >>> >> >> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If by >> "operating system environment" you're looking for more than I gave, >> let me know what it is you'd like to see. For more info on XQuartx >> see >> the link below. >> >> http://xquartz.macosforge.org/trac/wiki >> >> I've spent some time reducing the number of gnuplot commands needed >> to >> produce the problem. If the 4 lines below are placed iteratively in a >> file, the resulting window progressively grows taller (with the title >> bar being static). >> >> set terminal x11 size 560,480 position 440,106 >> set multiplot; >> plot x >> unset multiplot; >> >> I've attached another file for this simplified example. >> >> In any event, the problem appears to only exist (for me) in multiplot >> mode. I also noticed that the final window height is not always the >> same. > > Could you please try adding the command "unset mouse" to the beginning > of your test script, and check whether that makes any difference? bingo! When "unset mouse" precedes the first "set terminal x11 ..." command the resulting plot is unaware of the mouse. However, when I tried ... set terminal x11 size 560,480 position 440,106 set multiplot; plot x unset multiplot; unset mouse The tracing of the cursor still works. Is this behavior expected/intended? ... meaning; Are the mouse actions enabled when the mouse is set and the 1st "set terminal [...]" command is encountered? ... and that subsequent "unset mouse" commands will not turn the mouse actions off? Ben p.s. when the mouse actions are active my x11 window extends down a bit. My impression is that the degree to which it extends is the same as the amount the window grows, I assume this was what your were thinking? Ben |
From: Ben A. <bpa...@ma...> - 2008-12-28 20:03:21
|
On Dec 28, 2008, at 2:26 PM, Ben Abbott wrote: > > On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote: > >> On Sunday 28 December 2008, Ben Abbott wrote: >>> >>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: >>> >>>> On Saturday 27 December 2008, Ben Abbott wrote: >>>>> >>>>> I've concatenated several plot streams produced by Octave to >>>>> demonstrate what >>>>> I am seeing. The file is attached. >>>>>> Just type the command below. The resulting plot should grow in >>>>>> height each >>>>> time it is plotted. >>>> >>>> I see no change in the plot window size; each plot is redrawn >>>> exactly on top >>>> of the previous one. My machine is running >>>> x11-server-xorg-1.4.0.90 >>>> kdebase-kdm-3.5.9 >>>> >>>> I think that to debug this we will need to know your operating >>>> system >>>> environment, and in particular the window manager and the X-server >>>> being used. >>>> >>> >>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. If >>> by >>> "operating system environment" you're looking for more than I gave, >>> let me know what it is you'd like to see. For more info on XQuartx >>> see >>> the link below. >>> >>> http://xquartz.macosforge.org/trac/wiki >>> >>> I've spent some time reducing the number of gnuplot commands >>> needed to >>> produce the problem. If the 4 lines below are placed iteratively >>> in a >>> file, the resulting window progressively grows taller (with the >>> title >>> bar being static). >>> >>> set terminal x11 size 560,480 position 440,106 >>> set multiplot; >>> plot x >>> unset multiplot; >>> >>> I've attached another file for this simplified example. >>> >>> In any event, the problem appears to only exist (for me) in >>> multiplot >>> mode. I also noticed that the final window height is not always the >>> same. >> >> Could you please try adding the command "unset mouse" to the >> beginning >> of your test script, and check whether that makes any difference? > > bingo! > > When "unset mouse" precedes the first "set terminal x11 ..." command > the resulting plot is unaware of the mouse. > > However, when I tried ... > > set terminal x11 size 560,480 position 440,106 > set multiplot; > plot x > unset multiplot; > unset mouse > > The tracing of the cursor still works. > > Is this behavior expected/intended? ... meaning; Are the mouse > actions enabled when the mouse is set and the 1st "set terminal > [...]" command is encountered? ... and that subsequent "unset mouse" > commands will not turn the mouse actions off? > > Ben Another quick comment. I checked with another Mac OSX user. He is 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) So he has a different version of OSX and is running a different X- server. The growing window problem also existed for him and disappeared when "unset mouse" was added below "unset multiplot". Ben |
From: Ben A. <bpa...@ma...> - 2008-12-28 23:40:23
|
On Dec 28, 2008, at 4:30 PM, peter wrote: > Ben Abbott wrote: > >>>>> I've spent some time reducing the number of gnuplot commands >>>>> needed to >>>>> produce the problem. If the 4 lines below are placed iteratively >>>>> in a >>>>> file, the resulting window progressively grows taller (with the >>>>> title >>>>> bar being static). >>>>> >>>>> set terminal x11 size 560,480 position 440,106 >>>>> set multiplot; >>>>> plot x >>>>> unset multiplot; >>>>> >>>>> I've attached another file for this simplified example. >>>>> >>>>> In any event, the problem appears to only exist (for me) in >>>>> multiplot >>>>> mode. I also noticed that the final window height is not always >>>>> the >>>>> same. >>>> Could you please try adding the command "unset mouse" to the >>>> beginning >>>> of your test script, and check whether that makes any difference? >>> bingo! >>> >>> When "unset mouse" precedes the first "set terminal x11 ..." command >>> the resulting plot is unaware of the mouse. >>> >>> However, when I tried ... >>> >>> set terminal x11 size 560,480 position 440,106 >>> set multiplot; >>> plot x >>> unset multiplot; >>> unset mouse >>> >>> The tracing of the cursor still works. >>> >>> Is this behavior expected/intended? ... meaning; Are the mouse >>> actions enabled when the mouse is set and the 1st "set terminal >>> [...]" command is encountered? ... and that subsequent "unset mouse" >>> commands will not turn the mouse actions off? >>> >>> Ben >> > > So this seems to confirm my suggestion that it is related to the > window > being stretched to add the cursor output zone. There is probably some > difference in the way events are triggered and processed on OSX that > leads to it getting several mouse events, each one pumping the window > height. > > Can you arrange it so that your mouse is away from where the x window > appears so that there is no mouse events? On linux that will give a > plot > with no extra space for mouse position output. > > On linux a static mouse in the window's area whenit comes up does not > cause any output or window increase until it is moved. I think that is > where the difference lies. Mouse oriented focus doens't make any difference. However, your question did ring a bell. The X11 on Mac OSX has preferences for (1) Focus Follows Mouse and/or (2) Focus On New Windows. I had (1) unchecked and (2) checked. With (1) checked and (2) unchecked the problem with the growing window is gone. Nice deduction! Ben |
From: <pl...@pi...> - 2008-12-29 01:06:25
|
Ben Abbott wrote: >>>> Ben >> So this seems to confirm my suggestion that it is related to the >> window >> being stretched to add the cursor output zone. There is probably some >> difference in the way events are triggered and processed on OSX that >> leads to it getting several mouse events, each one pumping the window >> height. >> >> Can you arrange it so that your mouse is away from where the x window >> appears so that there is no mouse events? On linux that will give a >> plot >> with no extra space for mouse position output. >> >> On linux a static mouse in the window's area whenit comes up does not >> cause any output or window increase until it is moved. I think that is >> where the difference lies. > > Mouse oriented focus doens't make any difference. However, your > question did ring a bell. > > The X11 on Mac OSX has preferences for (1) Focus Follows Mouse and/or > (2) Focus On New Windows. I had (1) unchecked and (2) checked. > > With (1) checked and (2) unchecked the problem with the growing window > is gone. Nice deduction! > > Ben > > I tried those focus settings on linux and it still works correctly. one can see the extra bit of window flash in and out and finally remaining off until there is some mouse action. It seems the event that would reduce the extra area is either not firing or getting purged without having effect. This is probably going to need someone on a Mac to do some debugging. |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-28 21:12:43
|
On Sunday 28 December 2008, you wrote: > > On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote: > > > On Sunday 28 December 2008, you wrote: > >> > >> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote: > >> > >>> On Sunday 28 December 2008, Ben Abbott wrote: > >>>> > >>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: > >>>> > >>>>> On Saturday 27 December 2008, Ben Abbott wrote: > >>>>>> > >>>>>> I've concatenated several plot streams produced by Octave to > >>>>>> demonstrate what > >>>>>> I am seeing. The file is attached. > >>>>>>> Just type the command below. The resulting plot should grow in > >>>>>>> height each > >>>>>> time it is plotted. > >>>>> > >>>>> I see no change in the plot window size; each plot is redrawn > >>>>> exactly on top > >>>>> of the previous one. My machine is running > >>>>> x11-server-xorg-1.4.0.90 > >>>>> kdebase-kdm-3.5.9 > >>>>> > >>>>> I think that to debug this we will need to know your operating > >>>>> system > >>>>> environment, and in particular the window manager and the X-server > >>>>> being used. > >>>>> > >>>> > >>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. > >>>> If by > >>>> "operating system environment" you're looking for more than I gave, > >>>> let me know what it is you'd like to see. For more info on XQuartx > >>>> see > >>>> the link below. > >>>> > >>>> http://xquartz.macosforge.org/trac/wiki > >>>> > >>>> I've spent some time reducing the number of gnuplot commands needed > >>>> to > >>>> produce the problem. If the 4 lines below are placed iteratively > >>>> in a > >>>> file, the resulting window progressively grows taller (with the > >>>> title > >>>> bar being static). > >>>> > >>>> set terminal x11 size 560,480 position 440,106 > >>>> set multiplot; > >>>> plot x > >>>> unset multiplot; > >>>> > >>>> I've attached another file for this simplified example. > >>>> > >>>> In any event, the problem appears to only exist (for me) in > >>>> multiplot > >>>> mode. I also noticed that the final window height is not always the > >>>> same. > >>> > >>> Could you please try adding the command "unset mouse" to the > >>> beginning > >>> of your test script, and check whether that makes any difference? > >> > >> bingo! > >> > >> When "unset mouse" precedes the first "set terminal x11 ..." command > >> the resulting plot is unaware of the mouse. > >> > >> However, when I tried ... > >> > >> set terminal x11 size 560,480 position 440,106 > >> set multiplot; > >> plot x > >> unset multiplot; > >> unset mouse > >> > >> The tracing of the cursor still works. > >> > >> Is this behavior expected/intended? ... meaning; Are the mouse > >> actions > >> enabled when the mouse is set and the 1st "set terminal [...]" > >> command > >> is encountered? ... and that subsequent "unset mouse" commands will > >> not turn the mouse actions off? > >> > >> Ben > >> > >> p.s. when the mouse actions are active my x11 window extends down a > >> bit. My impression is that the degree to which it extends is the same > >> as the amount the window grows, I assume this was what your were > >> thinking? > > > > Yeah. Not that it really explains anything. > > > > I'll make a wild guess that the problem is related to the code > > introduced by the comment at line 4284 of gplt_x11.c > > > > 4284: > > /* it seems to be impossible to distinguish between a > > * resize caused by our call to XResizeWindow(), and > > * resize started by the user/windowmanager; but we can > > * make a good guess which can only fail if the user > > * resizes the window while we're also resizing it > > * ourselves: */ > > > > It claims to be working around various window-manager quirks. > > You could try commenting out various sections of that code, or > > adding debug statement to keep track of which code path is being > > triggered. It may be that an additional test, or conditional code > > for Mac OSX, could bypass the problematic code path. > > I'm unskilled unskilled in c/c++. So for my purposes I'll settle with > including "unset mouse" after "unset multiplot". > > Given the qualification above, it appears to me that this will produce > consistent results across different architectures, correct? I think we can do better than that. Turning off mouse interaction altogether is more drastic than simply turning off the extra space at the bottom of the window that echoes the current coordinates. What I really wanted to test was the equivalent of toggling the tracking window via the 'm' hotkey. But we don't currently have a way of doing that from the command line. Petr Mikulik was proposing (maybe even had a patch?) to provide command line equivalents for all the hotkey operations. Perhaps he has a suggestion. > Ben > > p.s. we dropped of the list, I assume that was intentional? Not really. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Ben A. <bpa...@ma...> - 2008-12-28 21:22:27
|
On Dec 28, 2008, at 4:12 PM, Ethan A Merritt wrote: > On Sunday 28 December 2008, you wrote: >> >> On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote: >> >>> On Sunday 28 December 2008, you wrote: >>>> >>>> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote: >>>> >>>>> On Sunday 28 December 2008, Ben Abbott wrote: >>>>>> >>>>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: >>>>>> >>>>>>> On Saturday 27 December 2008, Ben Abbott wrote: >>>>>>>> >>>>>>>> I've concatenated several plot streams produced by Octave to >>>>>>>> demonstrate what >>>>>>>> I am seeing. The file is attached. >>>>>>>>> Just type the command below. The resulting plot should grow in >>>>>>>>> height each >>>>>>>> time it is plotted. >>>>>>> >>>>>>> I see no change in the plot window size; each plot is redrawn >>>>>>> exactly on top >>>>>>> of the previous one. My machine is running >>>>>>> x11-server-xorg-1.4.0.90 >>>>>>> kdebase-kdm-3.5.9 >>>>>>> >>>>>>> I think that to debug this we will need to know your operating >>>>>>> system >>>>>>> environment, and in particular the window manager and the X- >>>>>>> server >>>>>>> being used. >>>>>>> >>>>>> >>>>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. >>>>>> If by >>>>>> "operating system environment" you're looking for more than I >>>>>> gave, >>>>>> let me know what it is you'd like to see. For more info on >>>>>> XQuartx >>>>>> see >>>>>> the link below. >>>>>> >>>>>> http://xquartz.macosforge.org/trac/wiki >>>>>> >>>>>> I've spent some time reducing the number of gnuplot commands >>>>>> needed >>>>>> to >>>>>> produce the problem. If the 4 lines below are placed iteratively >>>>>> in a >>>>>> file, the resulting window progressively grows taller (with the >>>>>> title >>>>>> bar being static). >>>>>> >>>>>> set terminal x11 size 560,480 position 440,106 >>>>>> set multiplot; >>>>>> plot x >>>>>> unset multiplot; >>>>>> >>>>>> I've attached another file for this simplified example. >>>>>> >>>>>> In any event, the problem appears to only exist (for me) in >>>>>> multiplot >>>>>> mode. I also noticed that the final window height is not always >>>>>> the >>>>>> same. >>>>> >>>>> Could you please try adding the command "unset mouse" to the >>>>> beginning >>>>> of your test script, and check whether that makes any difference? >>>> >>>> bingo! >>>> >>>> When "unset mouse" precedes the first "set terminal x11 ..." >>>> command >>>> the resulting plot is unaware of the mouse. >>>> >>>> However, when I tried ... >>>> >>>> set terminal x11 size 560,480 position 440,106 >>>> set multiplot; >>>> plot x >>>> unset multiplot; >>>> unset mouse >>>> >>>> The tracing of the cursor still works. >>>> >>>> Is this behavior expected/intended? ... meaning; Are the mouse >>>> actions >>>> enabled when the mouse is set and the 1st "set terminal [...]" >>>> command >>>> is encountered? ... and that subsequent "unset mouse" commands will >>>> not turn the mouse actions off? >>>> >>>> Ben >>>> >>>> p.s. when the mouse actions are active my x11 window extends down a >>>> bit. My impression is that the degree to which it extends is the >>>> same >>>> as the amount the window grows, I assume this was what your were >>>> thinking? >>> >>> Yeah. Not that it really explains anything. >>> >>> I'll make a wild guess that the problem is related to the code >>> introduced by the comment at line 4284 of gplt_x11.c >>> >>> 4284: >>> /* it seems to be impossible to distinguish between a >>> * resize caused by our call to XResizeWindow(), and >>> * resize started by the user/windowmanager; but we can >>> * make a good guess which can only fail if the user >>> * resizes the window while we're also resizing it >>> * ourselves: */ >>> >>> It claims to be working around various window-manager quirks. >>> You could try commenting out various sections of that code, or >>> adding debug statement to keep track of which code path is being >>> triggered. It may be that an additional test, or conditional code >>> for Mac OSX, could bypass the problematic code path. >> >> I'm unskilled unskilled in c/c++. So for my purposes I'll settle with >> including "unset mouse" after "unset multiplot". >> >> Given the qualification above, it appears to me that this will >> produce >> consistent results across different architectures, correct? > > I think we can do better than that. Turning off mouse interaction > altogether is more drastic than simply turning off the extra space at > the bottom of the window that echoes the current coordinates. > What I really wanted to test was the equivalent of toggling the > tracking window via the 'm' hotkey. But we don't currently have a way > of doing that from the command line. > > Petr Mikulik was proposing (maybe even had a patch?) to provide > command line equivalents for all the hotkey operations. Perhaps he > has a suggestion. > I agree. I have no desire to turn off the mouse interaction. What surprised me is that the mouse interaction still works for me if "unset mouse" occurs after "unset multiplot". Ben |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-28 22:32:42
|
On Sunday 28 December 2008, Ben Abbott wrote: > > On Dec 28, 2008, at 4:12 PM, Ethan A Merritt wrote: > > > On Sunday 28 December 2008, you wrote: > >> > >> On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote: > >> > >>> On Sunday 28 December 2008, you wrote: > >>>> > >>>> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote: > >>>> > >>>>> On Sunday 28 December 2008, Ben Abbott wrote: > >>>>>> > >>>>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: > >>>>>> > >>>>>>> On Saturday 27 December 2008, Ben Abbott wrote: > >>>>>>>> > >>>>>>>> I've concatenated several plot streams produced by Octave to > >>>>>>>> demonstrate what > >>>>>>>> I am seeing. The file is attached. > >>>>>>>>> Just type the command below. The resulting plot should grow in > >>>>>>>>> height each > >>>>>>>> time it is plotted. > >>>>>>> > >>>>>>> I see no change in the plot window size; each plot is redrawn > >>>>>>> exactly on top > >>>>>>> of the previous one. My machine is running > >>>>>>> x11-server-xorg-1.4.0.90 > >>>>>>> kdebase-kdm-3.5.9 > >>>>>>> > >>>>>>> I think that to debug this we will need to know your operating > >>>>>>> system > >>>>>>> environment, and in particular the window manager and the X- > >>>>>>> server > >>>>>>> being used. > >>>>>>> > >>>>>> > >>>>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. > >>>>>> If by > >>>>>> "operating system environment" you're looking for more than I > >>>>>> gave, > >>>>>> let me know what it is you'd like to see. For more info on > >>>>>> XQuartx > >>>>>> see > >>>>>> the link below. > >>>>>> > >>>>>> http://xquartz.macosforge.org/trac/wiki > >>>>>> > >>>>>> I've spent some time reducing the number of gnuplot commands > >>>>>> needed > >>>>>> to > >>>>>> produce the problem. If the 4 lines below are placed iteratively > >>>>>> in a > >>>>>> file, the resulting window progressively grows taller (with the > >>>>>> title > >>>>>> bar being static). > >>>>>> > >>>>>> set terminal x11 size 560,480 position 440,106 > >>>>>> set multiplot; > >>>>>> plot x > >>>>>> unset multiplot; > >>>>>> > >>>>>> I've attached another file for this simplified example. > >>>>>> > >>>>>> In any event, the problem appears to only exist (for me) in > >>>>>> multiplot > >>>>>> mode. I also noticed that the final window height is not always > >>>>>> the > >>>>>> same. > >>>>> > >>>>> Could you please try adding the command "unset mouse" to the > >>>>> beginning > >>>>> of your test script, and check whether that makes any difference? > >>>> > >>>> bingo! > >>>> > >>>> When "unset mouse" precedes the first "set terminal x11 ..." > >>>> command > >>>> the resulting plot is unaware of the mouse. > >>>> > >>>> However, when I tried ... > >>>> > >>>> set terminal x11 size 560,480 position 440,106 > >>>> set multiplot; > >>>> plot x > >>>> unset multiplot; > >>>> unset mouse > >>>> > >>>> The tracing of the cursor still works. > >>>> > >>>> Is this behavior expected/intended? ... meaning; Are the mouse > >>>> actions > >>>> enabled when the mouse is set and the 1st "set terminal [...]" > >>>> command > >>>> is encountered? ... and that subsequent "unset mouse" commands will > >>>> not turn the mouse actions off? > >>>> > >>>> Ben > >>>> > >>>> p.s. when the mouse actions are active my x11 window extends down a > >>>> bit. My impression is that the degree to which it extends is the > >>>> same > >>>> as the amount the window grows, I assume this was what your were > >>>> thinking? > >>> > >>> Yeah. Not that it really explains anything. > >>> > >>> I'll make a wild guess that the problem is related to the code > >>> introduced by the comment at line 4284 of gplt_x11.c > >>> > >>> 4284: > >>> /* it seems to be impossible to distinguish between a > >>> * resize caused by our call to XResizeWindow(), and > >>> * resize started by the user/windowmanager; but we can > >>> * make a good guess which can only fail if the user > >>> * resizes the window while we're also resizing it > >>> * ourselves: */ > >>> > >>> It claims to be working around various window-manager quirks. > >>> You could try commenting out various sections of that code, or > >>> adding debug statement to keep track of which code path is being > >>> triggered. It may be that an additional test, or conditional code > >>> for Mac OSX, could bypass the problematic code path. > >> > >> I'm unskilled unskilled in c/c++. So for my purposes I'll settle with > >> including "unset mouse" after "unset multiplot". > >> > >> Given the qualification above, it appears to me that this will > >> produce > >> consistent results across different architectures, correct? > > > > I think we can do better than that. Turning off mouse interaction > > altogether is more drastic than simply turning off the extra space at > > the bottom of the window that echoes the current coordinates. > > What I really wanted to test was the equivalent of toggling the > > tracking window via the 'm' hotkey. But we don't currently have a way > > of doing that from the command line. > > > > Petr Mikulik was proposing (maybe even had a patch?) to provide > > command line equivalents for all the hotkey operations. Perhaps he > > has a suggestion. > > > > I agree. I have no desire to turn off the mouse interaction. > > What surprised me is that the mouse interaction still works for me if > "unset mouse" occurs after "unset multiplot". So now I have another question. You are re-opening the same x11 display window for every plot. I don't understand why you want to do that, since you could just leave the previous window in place if the size is not supposed to change. Be that as it may, you could try explicitly closing the previous window before re-opening it: set term x11 1 size FOO,BAZ ...plot stuff set term x11 1 close set term x11 1 size FOO,BAZ ...plot different stuff -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Ben A. <bpa...@ma...> - 2008-12-28 23:56:39
|
On Dec 28, 2008, at 4:32 PM, Ethan A Merritt wrote: > On Sunday 28 December 2008, Ben Abbott wrote: >> >> On Dec 28, 2008, at 4:12 PM, Ethan A Merritt wrote: >> >>> On Sunday 28 December 2008, you wrote: >>>> >>>> On Dec 28, 2008, at 3:31 PM, Ethan A Merritt wrote: >>>> >>>>> On Sunday 28 December 2008, you wrote: >>>>>> >>>>>> On Dec 28, 2008, at 1:53 PM, Ethan A Merritt wrote: >>>>>> >>>>>>> On Sunday 28 December 2008, Ben Abbott wrote: >>>>>>>> >>>>>>>> On Dec 28, 2008, at 1:59 AM, Ethan A Merritt wrote: >>>>>>>> >>>>>>>>> On Saturday 27 December 2008, Ben Abbott wrote: >>>>>>>>>> >>>>>>>>>> I've concatenated several plot streams produced by Octave to >>>>>>>>>> demonstrate what >>>>>>>>>> I am seeing. The file is attached. >>>>>>>>>>> Just type the command below. The resulting plot should >>>>>>>>>>> grow in >>>>>>>>>>> height each >>>>>>>>>> time it is plotted. >>>>>>>>> >>>>>>>>> I see no change in the plot window size; each plot is redrawn >>>>>>>>> exactly on top >>>>>>>>> of the previous one. My machine is running >>>>>>>>> x11-server-xorg-1.4.0.90 >>>>>>>>> kdebase-kdm-3.5.9 >>>>>>>>> >>>>>>>>> I think that to debug this we will need to know your operating >>>>>>>>> system >>>>>>>>> environment, and in particular the window manager and the X- >>>>>>>>> server >>>>>>>>> being used. >>>>>>>>> >>>>>>>> >>>>>>>> I'm running Mac OSX 10.5.6 and with the X-server XQuartz 2.3.1. >>>>>>>> If by >>>>>>>> "operating system environment" you're looking for more than I >>>>>>>> gave, >>>>>>>> let me know what it is you'd like to see. For more info on >>>>>>>> XQuartx >>>>>>>> see >>>>>>>> the link below. >>>>>>>> >>>>>>>> http://xquartz.macosforge.org/trac/wiki >>>>>>>> >>>>>>>> I've spent some time reducing the number of gnuplot commands >>>>>>>> needed >>>>>>>> to >>>>>>>> produce the problem. If the 4 lines below are placed >>>>>>>> iteratively >>>>>>>> in a >>>>>>>> file, the resulting window progressively grows taller (with the >>>>>>>> title >>>>>>>> bar being static). >>>>>>>> >>>>>>>> set terminal x11 size 560,480 position 440,106 >>>>>>>> set multiplot; >>>>>>>> plot x >>>>>>>> unset multiplot; >>>>>>>> >>>>>>>> I've attached another file for this simplified example. >>>>>>>> >>>>>>>> In any event, the problem appears to only exist (for me) in >>>>>>>> multiplot >>>>>>>> mode. I also noticed that the final window height is not always >>>>>>>> the >>>>>>>> same. >>>>>>> >>>>>>> Could you please try adding the command "unset mouse" to the >>>>>>> beginning >>>>>>> of your test script, and check whether that makes any >>>>>>> difference? >>>>>> >>>>>> bingo! >>>>>> >>>>>> When "unset mouse" precedes the first "set terminal x11 ..." >>>>>> command >>>>>> the resulting plot is unaware of the mouse. >>>>>> >>>>>> However, when I tried ... >>>>>> >>>>>> set terminal x11 size 560,480 position 440,106 >>>>>> set multiplot; >>>>>> plot x >>>>>> unset multiplot; >>>>>> unset mouse >>>>>> >>>>>> The tracing of the cursor still works. >>>>>> >>>>>> Is this behavior expected/intended? ... meaning; Are the mouse >>>>>> actions >>>>>> enabled when the mouse is set and the 1st "set terminal [...]" >>>>>> command >>>>>> is encountered? ... and that subsequent "unset mouse" commands >>>>>> will >>>>>> not turn the mouse actions off? >>>>>> >>>>>> Ben >>>>>> >>>>>> p.s. when the mouse actions are active my x11 window extends >>>>>> down a >>>>>> bit. My impression is that the degree to which it extends is the >>>>>> same >>>>>> as the amount the window grows, I assume this was what your were >>>>>> thinking? >>>>> >>>>> Yeah. Not that it really explains anything. >>>>> >>>>> I'll make a wild guess that the problem is related to the code >>>>> introduced by the comment at line 4284 of gplt_x11.c >>>>> >>>>> 4284: >>>>> /* it seems to be impossible to distinguish between a >>>>> * resize caused by our call to XResizeWindow(), and >>>>> * resize started by the user/windowmanager; but we can >>>>> * make a good guess which can only fail if the user >>>>> * resizes the window while we're also resizing it >>>>> * ourselves: */ >>>>> >>>>> It claims to be working around various window-manager quirks. >>>>> You could try commenting out various sections of that code, or >>>>> adding debug statement to keep track of which code path is being >>>>> triggered. It may be that an additional test, or conditional code >>>>> for Mac OSX, could bypass the problematic code path. >>>> >>>> I'm unskilled unskilled in c/c++. So for my purposes I'll settle >>>> with >>>> including "unset mouse" after "unset multiplot". >>>> >>>> Given the qualification above, it appears to me that this will >>>> produce >>>> consistent results across different architectures, correct? >>> >>> I think we can do better than that. Turning off mouse interaction >>> altogether is more drastic than simply turning off the extra space >>> at >>> the bottom of the window that echoes the current coordinates. >>> What I really wanted to test was the equivalent of toggling the >>> tracking window via the 'm' hotkey. But we don't currently have a >>> way >>> of doing that from the command line. >>> >>> Petr Mikulik was proposing (maybe even had a patch?) to provide >>> command line equivalents for all the hotkey operations. Perhaps he >>> has a suggestion. >>> >> >> I agree. I have no desire to turn off the mouse interaction. >> >> What surprised me is that the mouse interaction still works for me if >> "unset mouse" occurs after "unset multiplot". > > > So now I have another question. > You are re-opening the same x11 display window for every plot. > I don't understand why you want to do that, since you could just leave > the previous window in place if the size is not supposed to change. > > Be that as it may, you could try explicitly closing the previous > window > before re-opening it: > > set term x11 1 size FOO,BAZ > ...plot stuff > > set term x11 1 close > set term x11 1 size FOO,BAZ > ...plot different stuff I'm a bit uncertain about the terminology. What I understand is done in Octave is that a plot stream is opened for a figure and it is not closed until the figure is deleted/closed. Are you suggesting that Octave's plot stream contain only one "set terminal ..."? ... if so by what means is it possible to clear the canvas and start from scratch? It is not permissible for Octave to close the window and open a new stream/window, as this would be a significant deviation from how Matlab works and compatibility with Matlab is a rather important feature. Meaning a specific plot window should not change size/ position unless the user specifically tells it to (which might be the result of actions by the mouse). By the way, it would really be cool if there was a method by which the size and position of a plot window could be determined. That way if a user moves or resizes a window Octave could do some checking and have some awareness of such (I'd be stunned if such were possible, but thought I'd ask). Ben |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-29 02:10:52
|
On Sunday 28 December 2008, Ben Abbott wrote: > > So now I have another question. > > You are re-opening the same x11 display window for every plot. > > I don't understand why you want to do that, since you could just leave > > the previous window in place if the size is not supposed to change. > > > > Be that as it may, you could try explicitly closing the previous > > window > > before re-opening it: > > > > set term x11 1 size FOO,BAZ > > ...plot stuff > > > > set term x11 1 close > > set term x11 1 size FOO,BAZ > > ...plot different stuff > > I'm a bit uncertain about the terminology. > > What I understand is done in Octave is that a plot stream is opened > for a figure and it is not closed until the figure is deleted/closed. Maybe. But you are talking about the stream from Octave to gnuplot, I think? Rather than the stream from gnuplot to gnuplot_x11? > Are you suggesting that Octave's plot stream contain only one "set > terminal ..."? ... if so by what means is it possible to clear the > canvas and start from scratch? That happens every time you issue a "plot" command. You don't have to do anything special. Although there is a "clear" command if for some reason you want to blank the window but not draw anything. > It is not permissible for Octave to close the window and open a new > stream/window, as this would be a significant deviation from how > Matlab works and compatibility with Matlab is a rather important > feature. ?? But that seems to be what your test script is doing already. > Meaning a specific plot window should not change size/ > position unless the user specifically tells it to (which might be the > result of actions by the mouse). Again, that's what has always been the case for gnuplot also, and the ability to specify the initial size does not change it. > By the way, it would really be cool if there was a method by which the > size and position of a plot window could be determined. That way if a > user moves or resizes a window Octave could do some checking and have > some awareness of such (I'd be stunned if such were possible, but > thought I'd ask). You can do that with a call into xlib; you don't need any special code in gnuplot for that. You should be able to get all the info you'd get from the command line using "xwininfo". -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Ben A. <bpa...@ma...> - 2008-12-29 03:17:48
|
On Dec 28, 2008, at 9:10 PM, Ethan A Merritt wrote: > On Sunday 28 December 2008, Ben Abbott wrote: > >>> So now I have another question. >>> You are re-opening the same x11 display window for every plot. >>> I don't understand why you want to do that, since you could just >>> leave >>> the previous window in place if the size is not supposed to change. >>> >>> Be that as it may, you could try explicitly closing the previous >>> window >>> before re-opening it: >>> >>> set term x11 1 size FOO,BAZ >>> ...plot stuff >>> >>> set term x11 1 close >>> set term x11 1 size FOO,BAZ >>> ...plot different stuff >> >> I'm a bit uncertain about the terminology. >> >> What I understand is done in Octave is that a plot stream is opened >> for a figure and it is not closed until the figure is deleted/closed. > > Maybe. But you are talking about the stream from Octave to gnuplot, > I think? Rather than the stream from gnuplot to gnuplot_x11? Correct, I speaking of the plot stream from Octave to gnuplot (my knowledge of how gnuplot works is nil) >> Are you suggesting that Octave's plot stream contain only one "set >> terminal ..."? ... if so by what means is it possible to clear the >> canvas and start from scratch? > > That happens every time you issue a "plot" command. You don't have > to do anything special. Although there is a "clear" command if for > some reason you want to blank the window but not draw anything. I'm not sure I understand the context correctly, but ... what of multiplot? ... there can be multiple plot commands that do not delete anything correct? ... this is the way Octave draws everything. My impression is that Octave relies upon "set terminal ..." to clear the canvas, but if "clear" does that, I'd rather go that route. >> It is not permissible for Octave to close the window and open a new >> stream/window, as this would be a significant deviation from how >> Matlab works and compatibility with Matlab is a rather important >> feature. > > ?? But that seems to be what your test script is doing already. Yes. However, but I hope to overcome that problem, or at the least allow the user to specify size and position via Octave's figure properties. >> By the way, it would really be cool if there was a method by which >> the >> size and position of a plot window could be determined. That way if a >> user moves or resizes a window Octave could do some checking and have >> some awareness of such (I'd be stunned if such were possible, but >> thought I'd ask). > > You can do that with a call into xlib; you don't need any special > code in gnuplot for that. You should be able to get all the info > you'd get from the command line using "xwininfo" hmmm ... that may be quite useful. xwininfo: Window id: 0xc00008 "Figure 1" Absolute upper-left X: 440 Absolute upper-left Y: 128 Relative upper-left X: 0 Relative upper-left Y: 22 Width: 560 Height: 493 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x21 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +440+128 -440+128 -440-279 +440-279 -geometry 560x493+440+106 Unfortunately, the height includes the portion needed to display the cursor's coordinates ... sigh :-( In any event, I've got plenty of new information to assimilate. I should spend some time applying what (I think) I have learned and then come back. Regarding my original problem, if there is a desire to change gnuplot, I'm happy to help out (if I can) or solicit some help for a MacOSX user with better programming skills than myself. Thanks Ben |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-29 05:15:31
|
On Sunday 28 December 2008, Ben Abbott wrote: > > On Dec 28, 2008, at 9:10 PM, Ethan A Merritt wrote: > > > On Sunday 28 December 2008, Ben Abbott wrote: > > > >>> So now I have another question. > >>> You are re-opening the same x11 display window for every plot. > >>> I don't understand why you want to do that, since you could just > >>> leave > >>> the previous window in place if the size is not supposed to change. > >>> > >>> Be that as it may, you could try explicitly closing the previous > >>> window > >>> before re-opening it: > >>> > >>> set term x11 1 size FOO,BAZ > >>> ...plot stuff > >>> > >>> set term x11 1 close > >>> set term x11 1 size FOO,BAZ > >>> ...plot different stuff > >> > >> I'm a bit uncertain about the terminology. > >> > >> What I understand is done in Octave is that a plot stream is opened > >> for a figure and it is not closed until the figure is deleted/closed. > > > > Maybe. But you are talking about the stream from Octave to gnuplot, > > I think? Rather than the stream from gnuplot to gnuplot_x11? > > Correct, I speaking of the plot stream from Octave to gnuplot (my > knowledge of how gnuplot works is nil) > > >> Are you suggesting that Octave's plot stream contain only one "set > >> terminal ..."? ... if so by what means is it possible to clear the > >> canvas and start from scratch? > > > > That happens every time you issue a "plot" command. You don't have > > to do anything special. Although there is a "clear" command if for > > some reason you want to blank the window but not draw anything. > > I'm not sure I understand the context correctly, but ... what of > multiplot? ... there can be multiple plot commands that do not delete > anything correct? ... this is the way Octave draws everything. It probably should not do that. Do you know why it does? > My impression is that Octave relies upon "set terminal ..." to clear > the canvas, but if "clear" does that, I'd rather go that route. Clear can be used inside of a stream of multiplot commands, whereas resetting the terminal obviously cannot. So it you really are using multiplot to draw new plots for some reason, "clear" is the way to go. > >> By the way, it would really be cool if there was a method by which > >> the > >> size and position of a plot window could be determined. That way if a > >> user moves or resizes a window Octave could do some checking and have > >> some awareness of such (I'd be stunned if such were possible, but > >> thought I'd ask). > > > > You can do that with a call into xlib; you don't need any special > > code in gnuplot for that. You should be able to get all the info > > you'd get from the command line using "xwininfo" > > hmmm ... that may be quite useful. > > xwininfo: Window id: 0xc00008 "Figure 1" > > Absolute upper-left X: 440 > Absolute upper-left Y: 128 > Relative upper-left X: 0 > Relative upper-left Y: 22 > Width: 560 > Height: 493 > Depth: 24 > Visual Class: TrueColor > Border width: 0 > Class: InputOutput > Colormap: 0x21 (installed) > Bit Gravity State: ForgetGravity > Window Gravity State: NorthWestGravity > Backing Store State: NotUseful > Save Under State: no > Map State: IsViewable > Override Redirect State: no > Corners: +440+128 -440+128 -440-279 +440-279 > -geometry 560x493+440+106 > > Unfortunately, the height includes the portion needed to display the > cursor's coordinates ... sigh :-( That extra height is equal to term->v_char. This quantity is not currently exported as a user variable, but it would be trivial to do so. Do you want it? Its name would be GPVAL_TERM_VCHAR. > In any event, I've got plenty of new information to assimilate. I > should spend some time applying what (I think) I have learned and then > come back. > > Regarding my original problem, if there is a desire to change gnuplot, > I'm happy to help out (if I can) or solicit some help for a MacOSX > user with better programming skills than myself. Well, if someone can figure out which bit of code in gplt_x11.c is getting called erroneously in your original trials, I'd be happy to help design a fix for it. But since I can't reproduce the problem here, I am entirely dependent on someone else to pin down the precise source of the error. -- Ethan A Merritt |
From: Ben A. <bpa...@ma...> - 2008-12-29 16:08:03
|
On Dec 29, 2008, at 12:15 AM, Ethan A Merritt wrote: > On Sunday 28 December 2008, Ben Abbott wrote: >> >> On Dec 28, 2008, at 9:10 PM, Ethan A Merritt wrote: >> >>> On Sunday 28 December 2008, Ben Abbott wrote: >>> >>>>> So now I have another question. >>>>> You are re-opening the same x11 display window for every plot. >>>>> I don't understand why you want to do that, since you could just >>>>> leave >>>>> the previous window in place if the size is not supposed to >>>>> change. >>>>> >>>>> Be that as it may, you could try explicitly closing the previous >>>>> window >>>>> before re-opening it: >>>>> >>>>> set term x11 1 size FOO,BAZ >>>>> ...plot stuff >>>>> >>>>> set term x11 1 close >>>>> set term x11 1 size FOO,BAZ >>>>> ...plot different stuff >>>> >>>> I'm a bit uncertain about the terminology. >>>> >>>> What I understand is done in Octave is that a plot stream is opened >>>> for a figure and it is not closed until the figure is deleted/ >>>> closed. >>> >>> Maybe. But you are talking about the stream from Octave to gnuplot, >>> I think? Rather than the stream from gnuplot to gnuplot_x11? >> >> Correct, I speaking of the plot stream from Octave to gnuplot (my >> knowledge of how gnuplot works is nil) >> >>>> Are you suggesting that Octave's plot stream contain only one "set >>>> terminal ..."? ... if so by what means is it possible to clear the >>>> canvas and start from scratch? >>> >>> That happens every time you issue a "plot" command. You don't have >>> to do anything special. Although there is a "clear" command if for >>> some reason you want to blank the window but not draw anything. >> >> I'm not sure I understand the context correctly, but ... what of >> multiplot? ... there can be multiple plot commands that do not delete >> anything correct? ... this is the way Octave draws everything. > > It probably should not do that. Do you know why it does? Octave & Matlab each place multiple plots in each figure window. By multiple plots, I mean multiple axes in one window. Some axes might be 2D of various types and others 3D. >> My impression is that Octave relies upon "set terminal ..." to clear >> the canvas, but if "clear" does that, I'd rather go that route. > > Clear can be used inside of a stream of multiplot commands, > whereas resetting the terminal obviously cannot. So it you really are > using multiplot to draw new plots for some reason, "clear" is > the way to go. Octave doesn't reset the terminal while multiplot is one. Rather it (1) sets the terminal, (2) turns on multiplot, (3) draws all axes / graphics objects, (4) turns off multiplot. When an object of the figure is changed, the sequence is repeated. At the moment, my modification to the plotstream has introduced some problems, so my understanding is suspect. >>>> By the way, it would really be cool if there was a method by which >>>> the >>>> size and position of a plot window could be determined. That way >>>> if a >>>> user moves or resizes a window Octave could do some checking and >>>> have >>>> some awareness of such (I'd be stunned if such were possible, but >>>> thought I'd ask). >>> >>> You can do that with a call into xlib; you don't need any special >>> code in gnuplot for that. You should be able to get all the info >>> you'd get from the command line using "xwininfo" >> >> hmmm ... that may be quite useful. >> >> xwininfo: Window id: 0xc00008 "Figure 1" >> >> Absolute upper-left X: 440 >> Absolute upper-left Y: 128 >> Relative upper-left X: 0 >> Relative upper-left Y: 22 >> Width: 560 >> Height: 493 >> Depth: 24 >> Visual Class: TrueColor >> Border width: 0 >> Class: InputOutput >> Colormap: 0x21 (installed) >> Bit Gravity State: ForgetGravity >> Window Gravity State: NorthWestGravity >> Backing Store State: NotUseful >> Save Under State: no >> Map State: IsViewable >> Override Redirect State: no >> Corners: +440+128 -440+128 -440-279 +440-279 >> -geometry 560x493+440+106 >> >> Unfortunately, the height includes the portion needed to display the >> cursor's coordinates ... sigh :-( > > That extra height is equal to term->v_char. This quantity is not > currently exported as a user variable, but it would be trivial to do > so. > Do you want it? Its name would be GPVAL_TERM_VCHAR. If it would work under Windows as well, then I certainly would like to have that. How might octave access the information? Would v_char = getenv ("GPVAL_TERM_VCHAR") do the trick (assuming you're speaking of the shell environment and both octave and gnuplot are sharing the same environment ... are they?) or is some other method needed? >> In any event, I've got plenty of new information to assimilate. I >> should spend some time applying what (I think) I have learned and >> then >> come back. >> >> Regarding my original problem, if there is a desire to change >> gnuplot, >> I'm happy to help out (if I can) or solicit some help for a MacOSX >> user with better programming skills than myself. > > Well, if someone can figure out which bit of code in gplt_x11.c is > getting called erroneously in your original trials, I'd be happy to > help design a fix for it. But since I can't reproduce the problem > here, > I am entirely dependent on someone else to pin down the precise source > of the error. ok. I have one of octave's contributers in mind who may be inclined to help out. Ben |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-29 17:25:16
|
On Monday 29 December 2008, Ben Abbott wrote: > >>>> Are you suggesting that Octave's plot stream contain only one "set > >>>> terminal ..."? ... if so by what means is it possible to clear the > >>>> canvas and start from scratch? > >>> > >>> That happens every time you issue a "plot" command. You don't have > >>> to do anything special. Although there is a "clear" command if for > >>> some reason you want to blank the window but not draw anything. > >> > >> I'm not sure I understand the context correctly, but ... what of > >> multiplot? ... there can be multiple plot commands that do not delete > >> anything correct? ... this is the way Octave draws everything. > > > > It probably should not do that. Do you know why it does? > > Octave & Matlab each place multiple plots in each figure window. By > multiple plots, I mean multiple axes in one window. Some axes might be > 2D of various types and others 3D. It seems to me that this would be better done by opening separate windows for each plot, perhaps tiled to be adjacent. That would let you edit and interact with each component plot separately, which is not possible for the separate components of a multiplot. Easy for me to say - I am neither programming nor using Octave. > >> My impression is that Octave relies upon "set terminal ..." to clear > >> the canvas, but if "clear" does that, I'd rather go that route. > > > > Clear can be used inside of a stream of multiplot commands, > > whereas resetting the terminal obviously cannot. So it you really are > > using multiplot to draw new plots for some reason, "clear" is > > the way to go. > > Octave doesn't reset the terminal while multiplot is one. Rather it > (1) sets the terminal, (2) turns on multiplot, (3) draws all axes / > graphics objects, (4) turns off multiplot. When an object of the > figure is changed, the sequence is repeated. As I said above, this approach seems very cumbersome compared to drawing and maintaining each component plot on its own. If nothing else, maintaining them in parallel would allow mouse interactions to continue in parallel, whereas mousing within a multiplot is very limited. Aside from that, you still have not explained why you (or Octave) would want to close and re-open the terminal plot window before starting a new plot. What do you gain by this? > At the moment, my modification to the plotstream has introduced some > problems, so my understanding is suspect. > > >>>> By the way, it would really be cool if there was a method by which > >>>> the > >>>> size and position of a plot window could be determined. That way > >>>> if a > >>>> user moves or resizes a window Octave could do some checking and > >>>> have > >>>> some awareness of such (I'd be stunned if such were possible, but > >>>> thought I'd ask). > >>> > >>> You can do that with a call into xlib; you don't need any special > >>> code in gnuplot for that. You should be able to get all the info > >>> you'd get from the command line using "xwininfo" > >> > >> hmmm ... that may be quite useful. > >> > >> xwininfo: Window id: 0xc00008 "Figure 1" > >> > >> Absolute upper-left X: 440 > >> Absolute upper-left Y: 128 > >> Relative upper-left X: 0 > >> Relative upper-left Y: 22 > >> Width: 560 > >> Height: 493 > >> Depth: 24 > >> Visual Class: TrueColor > >> Border width: 0 > >> Class: InputOutput > >> Colormap: 0x21 (installed) > >> Bit Gravity State: ForgetGravity > >> Window Gravity State: NorthWestGravity > >> Backing Store State: NotUseful > >> Save Under State: no > >> Map State: IsViewable > >> Override Redirect State: no > >> Corners: +440+128 -440+128 -440-279 +440-279 > >> -geometry 560x493+440+106 > >> > >> Unfortunately, the height includes the portion needed to display the > >> cursor's coordinates ... sigh :-( > > > > That extra height is equal to term->v_char. This quantity is not > > currently exported as a user variable, but it would be trivial to do > > so. > > Do you want it? Its name would be GPVAL_TERM_VCHAR. > > If it would work under Windows as well, then I certainly would like to > have that. How might octave access the information? Would v_char = > getenv ("GPVAL_TERM_VCHAR") do the trick (assuming you're speaking of > the shell environment and both octave and gnuplot are sharing the same > environment ... are they?) or is some other method needed? If you are sending commands to gnuplot, you can just refer to that variable by name. If you need to pass it back from gnuplot to the calling program, then it is probably best to set up full two-way communication via pipes. > >> In any event, I've got plenty of new information to assimilate. I > >> should spend some time applying what (I think) I have learned and > >> then > >> come back. > >> > >> Regarding my original problem, if there is a desire to change > >> gnuplot, > >> I'm happy to help out (if I can) or solicit some help for a MacOSX > >> user with better programming skills than myself. > > > > Well, if someone can figure out which bit of code in gplt_x11.c is > > getting called erroneously in your original trials, I'd be happy to > > help design a fix for it. But since I can't reproduce the problem > > here, > > I am entirely dependent on someone else to pin down the precise source > > of the error. > > ok. I have one of octave's contributers in mind who may be inclined to > help out. > > Ben > > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Ben A. <bpa...@ma...> - 2008-12-29 18:04:48
|
On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote: > On Monday 29 December 2008, Ben Abbott wrote: > >>>>>> Are you suggesting that Octave's plot stream contain only one >>>>>> "set >>>>>> terminal ..."? ... if so by what means is it possible to clear >>>>>> the >>>>>> canvas and start from scratch? >>>>> >>>>> That happens every time you issue a "plot" command. You don't >>>>> have >>>>> to do anything special. Although there is a "clear" command if >>>>> for >>>>> some reason you want to blank the window but not draw anything. >>>> >>>> I'm not sure I understand the context correctly, but ... what of >>>> multiplot? ... there can be multiple plot commands that do not >>>> delete >>>> anything correct? ... this is the way Octave draws everything. >>> >>> It probably should not do that. Do you know why it does? >> >> Octave & Matlab each place multiple plots in each figure window. By >> multiple plots, I mean multiple axes in one window. Some axes might >> be >> 2D of various types and others 3D. > > It seems to me that this would be better done by opening separate > windows > for each plot, perhaps tiled to be adjacent. That would let you edit > and interact with each component plot separately, which is not > possible > for the separate components of a multiplot. > > Easy for me to say - I am neither programming nor using Octave. I agree. However, that would break compatibility with Matlab ... which is actually what I'm attempting to improve. >>>> My impression is that Octave relies upon "set terminal ..." to >>>> clear >>>> the canvas, but if "clear" does that, I'd rather go that route. >>> >>> Clear can be used inside of a stream of multiplot commands, >>> whereas resetting the terminal obviously cannot. So it you really >>> are >>> using multiplot to draw new plots for some reason, "clear" is >>> the way to go. >> >> Octave doesn't reset the terminal while multiplot is one. Rather it >> (1) sets the terminal, (2) turns on multiplot, (3) draws all axes / >> graphics objects, (4) turns off multiplot. When an object of the >> figure is changed, the sequence is repeated. > > As I said above, this approach seems very cumbersome compared to > drawing and maintaining each component plot on its own. If nothing > else, > maintaining them in parallel would allow mouse interactions to > continue > in parallel, whereas mousing within a multiplot is very limited. Am I correct in inferring that rotation of plots does work but zooming does not (which is what I observe for Octave's gnuplot windows on Mac OSX). > Aside from that, you still have not explained why you (or Octave) > would > want to close and re-open the terminal plot window before starting a > new plot. What do you gain by this? Opps, I apparently wasn't clear in my description. Octave may have many plot windows open simultaneously. Each gnuplot window contains one Octave figure whose objects may be modified via a command line interface at the users discretion. The user may close a figure's window either via the mouse or via the command line. I've added support for the position and size options of the x11 terminal to my local code for octave. I notice that the x11 terminal only respects these properties for the first instance of "set termina x11 ..." in the plot stream. This is different than how the aqua and wxt terminals behave. Meaning that each time I change the terminals size, both the aqua and wxt windows change their size (at least wxt did before I began running 4.3+, not the wxt terminal does not work for me). Would it be possible for the x11 terminal to behave in the same manner? btw, if there are not know problem with the wxt terminal, let me know and I'll submit a bug report. >> At the moment, my modification to the plotstream has introduced some >> problems, so my understanding is suspect. >> >>>>>> By the way, it would really be cool if there was a method by >>>>>> which >>>>>> the >>>>>> size and position of a plot window could be determined. That way >>>>>> if a >>>>>> user moves or resizes a window Octave could do some checking and >>>>>> have >>>>>> some awareness of such (I'd be stunned if such were possible, but >>>>>> thought I'd ask). >>>>> >>>>> You can do that with a call into xlib; you don't need any special >>>>> code in gnuplot for that. You should be able to get all the info >>>>> you'd get from the command line using "xwininfo" >>>> >>>> hmmm ... that may be quite useful. >>>> >>>> xwininfo: Window id: 0xc00008 "Figure 1" >>>> >>>> Absolute upper-left X: 440 >>>> Absolute upper-left Y: 128 >>>> Relative upper-left X: 0 >>>> Relative upper-left Y: 22 >>>> Width: 560 >>>> Height: 493 >>>> Depth: 24 >>>> Visual Class: TrueColor >>>> Border width: 0 >>>> Class: InputOutput >>>> Colormap: 0x21 (installed) >>>> Bit Gravity State: ForgetGravity >>>> Window Gravity State: NorthWestGravity >>>> Backing Store State: NotUseful >>>> Save Under State: no >>>> Map State: IsViewable >>>> Override Redirect State: no >>>> Corners: +440+128 -440+128 -440-279 +440-279 >>>> -geometry 560x493+440+106 >>>> >>>> Unfortunately, the height includes the portion needed to display >>>> the >>>> cursor's coordinates ... sigh :-( >>> >>> That extra height is equal to term->v_char. This quantity is not >>> currently exported as a user variable, but it would be trivial to do >>> so. >>> Do you want it? Its name would be GPVAL_TERM_VCHAR. >> >> If it would work under Windows as well, then I certainly would like >> to >> have that. How might octave access the information? Would v_char = >> getenv ("GPVAL_TERM_VCHAR") do the trick (assuming you're speaking of >> the shell environment and both octave and gnuplot are sharing the >> same >> environment ... are they?) or is some other method needed? > > If you are sending commands to gnuplot, you can just refer to that > variable by name. If you need to pass it back from gnuplot to the > calling program, then it is probably best to set up full two-way > communication via pipes. ok. When I get that far, I'll likely be back on the help list. >>>> In any event, I've got plenty of new information to assimilate. I >>>> should spend some time applying what (I think) I have learned and >>>> then >>>> come back. >>>> >>>> Regarding my original problem, if there is a desire to change >>>> gnuplot, >>>> I'm happy to help out (if I can) or solicit some help for a MacOSX >>>> user with better programming skills than myself. >>> >>> Well, if someone can figure out which bit of code in gplt_x11.c is >>> getting called erroneously in your original trials, I'd be happy to >>> help design a fix for it. But since I can't reproduce the problem >>> here, >>> I am entirely dependent on someone else to pin down the precise >>> source >>> of the error. >> >> ok. I have one of octave's contributers in mind who may be inclined >> to >> help out. >> >> Ben > -- > Ethan A Merritt > Biomolecular Structure Center > University of Washington, Seattle 98195-7742 |
From: Ethan M. <merritt@u.washington.edu> - 2008-12-29 18:34:08
|
On Monday 29 December 2008 10:04:32 Ben Abbott wrote: > > On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote: > > > On Monday 29 December 2008, Ben Abbott wrote: > > > >>>>>> Are you suggesting that Octave's plot stream contain only one > >>>>>> "set > >>>>>> terminal ..."? ... if so by what means is it possible to clear > >>>>>> the > >>>>>> canvas and start from scratch? > >>>>> > >>>>> That happens every time you issue a "plot" command. You don't > >>>>> have > >>>>> to do anything special. Although there is a "clear" command if > >>>>> for > >>>>> some reason you want to blank the window but not draw anything. > >>>> > >>>> I'm not sure I understand the context correctly, but ... what of > >>>> multiplot? ... there can be multiple plot commands that do not > >>>> delete > >>>> anything correct? ... this is the way Octave draws everything. > >>> > >>> It probably should not do that. Do you know why it does? > >> > >> Octave & Matlab each place multiple plots in each figure window. By > >> multiple plots, I mean multiple axes in one window. Some axes might > >> be > >> 2D of various types and others 3D. > > > > It seems to me that this would be better done by opening separate > > windows > > for each plot, perhaps tiled to be adjacent. That would let you edit > > and interact with each component plot separately, which is not > > possible > > for the separate components of a multiplot. > > > > Easy for me to say - I am neither programming nor using Octave. > > I agree. However, that would break compatibility with Matlab ... which > is actually what I'm attempting to improve. Well, I'm totally lost. I don't understand why it would make any difference to the user, other than the gain in functionality. > Am I correct in inferring that rotation of plots does work but zooming > does not (which is what I observe for Octave's gnuplot windows on Mac > OSX). No, this is not correct. At least, not if you have correctly described how Octave uses multiplot. You cannot interact with the individual component plots of a multiplot. Not zooming, not rotation, not mouse tracking, no toggling ruler/grid/logscale, none of that. Doing things inside multiplot severely limits the features that gnuplot would normally give you automatically. > > you still have not explained why you (or Octave) would > > want to close and re-open the terminal plot window before starting > > a new plot. What do you gain by this? > > Opps, I apparently wasn't clear in my description. > > Octave may have many plot windows open simultaneously. Each gnuplot > window contains one Octave figure whose objects may be modified via a > command line interface at the users discretion. The user may close a > figure's window either via the mouse or via the command line. > > I've added support for the position and size options of the x11 > terminal to my local code for octave. I notice that the x11 terminal > only respects these properties for the first instance of "set termina > x11 ..." in the plot stream. This is different than how the aqua and > wxt terminals behave. Meaning that each time I change the terminals > size, both the aqua and wxt windows change their size I think you are either doing something wrong, or failing to explain the difference between what you are seeing and what you are expecting. The following sequence of commands will open three separate x11 plot windows with different sizes. Each window can be managed separately. This behaviour may not be truly identical to that for wxt, but so far as I know the differences are subtle rather than dramatic. Do you have a counter-example? set term x11 1 title "Plot window #1" plot foo set term x11 2 title "Plot window #2" splot baz set term x11 3 title "3rd plot window" plot blech # Close window 2, leave 1 and 3 unchanged: set term x11 2 close # Replace the contents of window 1, leaving window 3 unchanged set term x11 1 plot new-stuff > Would it be possible for the x11 terminal to behave in the same manner? Please describe "same manner" more explicitly. > (at least wxt > did before I began running 4.3+, not the wxt terminal does not work > for me). Are you saying that you have observed a recent regression in wxt? Please file a separate bug report. I am not aware of any outstanding problems other than the general incompatibility with Mac OSX. > btw, if there are not know problem with the wxt terminal, let me know > and I'll submit a bug report. Please do. -- Ethan A Merritt |
From: Ben A. <bpa...@ma...> - 2008-12-29 20:28:05
|
On Dec 29, 2008, at 1:34 PM, Ethan Merritt wrote: > On Monday 29 December 2008 10:04:32 Ben Abbott wrote: >> >> On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote: >> >>> On Monday 29 December 2008, Ben Abbott wrote: >>> >>>>>>>> Are you suggesting that Octave's plot stream contain only one >>>>>>>> "set >>>>>>>> terminal ..."? ... if so by what means is it possible to clear >>>>>>>> the >>>>>>>> canvas and start from scratch? >>>>>>> >>>>>>> That happens every time you issue a "plot" command. You don't >>>>>>> have >>>>>>> to do anything special. Although there is a "clear" command if >>>>>>> for >>>>>>> some reason you want to blank the window but not draw anything. >>>>>> >>>>>> I'm not sure I understand the context correctly, but ... what of >>>>>> multiplot? ... there can be multiple plot commands that do not >>>>>> delete >>>>>> anything correct? ... this is the way Octave draws everything. >>>>> >>>>> It probably should not do that. Do you know why it does? >>>> >>>> Octave & Matlab each place multiple plots in each figure window. By >>>> multiple plots, I mean multiple axes in one window. Some axes might >>>> be >>>> 2D of various types and others 3D. >>> >>> It seems to me that this would be better done by opening separate >>> windows >>> for each plot, perhaps tiled to be adjacent. That would let you >>> edit >>> and interact with each component plot separately, which is not >>> possible >>> for the separate components of a multiplot. >>> >>> Easy for me to say - I am neither programming nor using Octave. >> >> I agree. However, that would break compatibility with Matlab ... >> which >> is actually what I'm attempting to improve. > > Well, I'm totally lost. I don't understand why it would make any > difference to the user, other than the gain in functionality. > >> Am I correct in inferring that rotation of plots does work but >> zooming >> does not (which is what I observe for Octave's gnuplot windows on Mac >> OSX). > > No, this is not correct. At least, not if you have correctly > described > how Octave uses multiplot. You cannot interact with the individual > component plots of a multiplot. Not zooming, not rotation, > not mouse tracking, no toggling ruler/grid/logscale, none of that. > Doing things inside multiplot severely limits the features that > gnuplot would normally give you automatically. > >>> you still have not explained why you (or Octave) would >>> want to close and re-open the terminal plot window before starting >>> a new plot. What do you gain by this? >> >> Opps, I apparently wasn't clear in my description. >> >> Octave may have many plot windows open simultaneously. Each gnuplot >> window contains one Octave figure whose objects may be modified via a >> command line interface at the users discretion. The user may close a >> figure's window either via the mouse or via the command line. >> >> I've added support for the position and size options of the x11 >> terminal to my local code for octave. I notice that the x11 terminal >> only respects these properties for the first instance of "set termina >> x11 ..." in the plot stream. This is different than how the aqua and >> wxt terminals behave. Meaning that each time I change the terminals >> size, both the aqua and wxt windows change their size > > > I think you are either doing something wrong, or failing to explain > the difference between what you are seeing and what you are expecting. > The following sequence of commands will open three separate x11 plot > windows with different sizes. Each window can be managed separately. > This behaviour may not be truly identical to that for wxt, but so far > as I know the differences are subtle rather than dramatic. > Do you have a counter-example? > > set term x11 1 title "Plot window #1" > plot foo > set term x11 2 title "Plot window #2" > splot baz > set term x11 3 title "3rd plot window" > plot blech > > # Close window 2, leave 1 and 3 unchanged: > set term x11 2 close > > # Replace the contents of window 1, leaving window 3 unchanged > set term x11 1 > plot new-stuff > > >> Would it be possible for the x11 terminal to behave in the same >> manner? > > Please describe "same manner" more explicitly.' Ok, try this set term x11 1 size 500,400 position 100,100 plot sin(x) set term x11 1 size 500,200 position 300,100 close 1 plot sin(x) After the second plot command the window remains the same size and in the same position as the first. If I use the mouse to close the window prior to the second "plot sin(x)" then I get the effect I desire. Regarding my expectations, you are correct, I associated gnuplot's "close" option with deleting the window and all its options. I tried inserting a "set term x11 1 close" after the first "plot sin(x)" and prior to the second and I got the effect I desired. The aqua terminal behaves differently. The command below produce a change in the window size. set term aqua 1 size 500 400 plot sin(x) set term aqua 1 size 500 200 plot sin(x) Unfortunately, there is no "close" option for the aqua terminal. In any event, you've revealed another solution to me. I'll use "close" for the x11 terminal before updating the plot window. >> (at least wxt >> did before I began running 4.3+, not the wxt terminal does not work >> for me). > > Are you saying that you have observed a recent regression in wxt? > Please file a separate bug report. I am not aware of any outstanding > problems other than the general incompatibility with Mac OSX. I assume the wxt terminal is working. Thus, I'll invest some effort ensuring I have everything set up correctly. Just to be sure, what wx version is needed? I have wxmac 2.8.3 installed. Ben |
From: Ethan M. <merritt@u.washington.edu> - 2008-12-29 22:32:34
|
On Monday 29 December 2008 12:27:59 Ben Abbott wrote: > > > >> Would it be possible for the x11 terminal to behave in the same > >> manner? > > > > Please describe "same manner" more explicitly.' > > Ok, try this > > set term x11 1 size 500,400 position 100,100 > plot sin(x) > set term x11 1 size 500,200 position 300,100 > close 1 > plot sin(x) > > After the second plot command the window remains the same size and in > the same position as the first. Correct. The window is already open, and the second "set term" does not change its basic properties. This is pretty much necessary in order to allow sequences like: set term x11 ... ... plot lots of stuff, perhaps with mouse interaction, set term post; set output 'plot_v1.ps'; replot; set term x11 ... some more fiddling, perhaps zoom, change view, etc set term post; set output 'plot_v2.ps'; replot; set term x11 ... etc > Regarding my expectations, you are correct, I associated gnuplot's > "close" option with deleting the window and all its options. I tried > inserting a "set term x11 1 close" after the first "plot sin(x)" and > prior to the second and I got the effect I desired. > The aqua terminal behaves differently. The command below produce a > change in the window size. > > set term aqua 1 size 500 400 > plot sin(x) > set term aqua 1 size 500 200 > plot sin(x) > > Unfortunately, there is no "close" option for the aqua terminal. I don't know that much about the aqua terminal, and its project page on SourceForge appears moribund. The documentation for use with gnuplot, for instance, still refers to gnuplot version 3.8. I tried to stir up interest over there to at least release the existing 2-year-old aquaterm version 1.1 that includes support for transparency, but even that hasn't happened. "Close" sounds like it would be a trivial change, but it won't help anyone unless/until the aquaterm developers are willing to release and distribute a version that supports it. Perhaps you will be more successful than I was in prodding them to make a new release. I was told back in June that "the code is set for a 1.1 release, but needs testing on Intel Macs and 10.5.x". Maybe if you volunteer to be a tester, they will make a release candidate for you to test? The project website is here: https://sourceforge.net/projects/aquaterm/ And some people to prod are here: hba...@us... ama...@us... per...@ma... > In any event, you've revealed another solution to me. I'll use "close" > for the x11 terminal before updating the plot window. > > >> (at least wxt > >> did before I began running 4.3+, not the wxt terminal does not work > >> for me). > > > > Are you saying that you have observed a recent regression in wxt? > > Please file a separate bug report. I am not aware of any outstanding > > problems other than the general incompatibility with Mac OSX. > > I assume the wxt terminal is working. Thus, I'll invest some effort > ensuring I have everything set up correctly. Just to be sure, what wx > version is needed? I have wxmac 2.8.3 installed. So far as I know, the wxt terminal has never worked under OSX; I've been told that the control flow is inherently incompatible with the OSX graphics model. Timothée Lecomte has been working on a re-design that would allow it, but he doesn't have much time to devote to it. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Daniel J S. <dan...@ie...> - 2008-12-30 02:00:28
|
Ben Abbott wrote: > On Dec 29, 2008, at 1:34 PM, Ethan Merritt wrote: > > >>On Monday 29 December 2008 10:04:32 Ben Abbott wrote: >> >>>On Dec 29, 2008, at 12:25 PM, Ethan A Merritt wrote: >>> >>> >>>>On Monday 29 December 2008, Ben Abbott wrote: >>>> >>>> >>>>>>>>>Are you suggesting that Octave's plot stream contain only one >>>>>>>>>"set >>>>>>>>>terminal ..."? ... if so by what means is it possible to clear >>>>>>>>>the >>>>>>>>>canvas and start from scratch? >>>>>>>> >>>>>>>>That happens every time you issue a "plot" command. You don't >>>>>>>>have >>>>>>>>to do anything special. Although there is a "clear" command if >>>>>>>>for >>>>>>>>some reason you want to blank the window but not draw anything. >>>>>>> >>>>>>>I'm not sure I understand the context correctly, but ... what of >>>>>>>multiplot? ... there can be multiple plot commands that do not >>>>>>>delete >>>>>>>anything correct? ... this is the way Octave draws everything. >>>>>> >>>>>>It probably should not do that. Do you know why it does? >>>>> >>>>>Octave & Matlab each place multiple plots in each figure window. By >>>>>multiple plots, I mean multiple axes in one window. Some axes might >>>>>be >>>>>2D of various types and others 3D. >>>> >>>>It seems to me that this would be better done by opening separate >>>>windows >>>>for each plot, perhaps tiled to be adjacent. That would let you >>>>edit >>>>and interact with each component plot separately, which is not >>>>possible >>>>for the separate components of a multiplot. >>>> >>>>Easy for me to say - I am neither programming nor using Octave. >>> >>>I agree. However, that would break compatibility with Matlab ... >>>which >>>is actually what I'm attempting to improve. >> >>Well, I'm totally lost. I don't understand why it would make any >>difference to the user, other than the gain in functionality. >> >> >>>Am I correct in inferring that rotation of plots does work but >>>zooming >>>does not (which is what I observe for Octave's gnuplot windows on Mac >>>OSX). >> >>No, this is not correct. At least, not if you have correctly >>described >>how Octave uses multiplot. You cannot interact with the individual >>component plots of a multiplot. Not zooming, not rotation, >>not mouse tracking, no toggling ruler/grid/logscale, none of that. >>Doing things inside multiplot severely limits the features that >>gnuplot would normally give you automatically. >> >> >>>>you still have not explained why you (or Octave) would >>>>want to close and re-open the terminal plot window before starting >>>>a new plot. What do you gain by this? >>> >>>Opps, I apparently wasn't clear in my description. >>> >>>Octave may have many plot windows open simultaneously. Each gnuplot >>>window contains one Octave figure whose objects may be modified via a >>>command line interface at the users discretion. The user may close a >>>figure's window either via the mouse or via the command line. >>> >>>I've added support for the position and size options of the x11 >>>terminal to my local code for octave. I notice that the x11 terminal >>>only respects these properties for the first instance of "set termina >>>x11 ..." in the plot stream. This is different than how the aqua and >>>wxt terminals behave. Meaning that each time I change the terminals >>>size, both the aqua and wxt windows change their size >> >> >>I think you are either doing something wrong, or failing to explain >>the difference between what you are seeing and what you are expecting. >>The following sequence of commands will open three separate x11 plot >>windows with different sizes. Each window can be managed separately. >>This behaviour may not be truly identical to that for wxt, but so far >>as I know the differences are subtle rather than dramatic. >>Do you have a counter-example? >> >> set term x11 1 title "Plot window #1" >> plot foo >> set term x11 2 title "Plot window #2" >> splot baz >> set term x11 3 title "3rd plot window" >> plot blech >> >> # Close window 2, leave 1 and 3 unchanged: >> set term x11 2 close >> >> # Replace the contents of window 1, leaving window 3 unchanged >> set term x11 1 >> plot new-stuff >> >> >> >>>Would it be possible for the x11 terminal to behave in the same >>>manner? >> >>Please describe "same manner" more explicitly.' > > > Ok, try this > > set term x11 1 size 500,400 position 100,100 > plot sin(x) > set term x11 1 size 500,200 position 300,100 > close 1 > plot sin(x) > > After the second plot command the window remains the same size and in > the same position as the first. > > If I use the mouse to close the window prior to the second "plot > sin(x)" then I get the effect I desire. Ben, I haven't followed this thread closely, but keep in mind that Octave is currently programmed to create a new instance (process, version, whatever) of gnuplot for every plot it creates. John did things that way because gnuplot currently only has the mouse active in one window due to the fact that plot data is not retained but for the most recent plot. John figured gnuplot is small, so launch however many versions of it that are required. So, I think that when you typed "close 1", gnuplot was completely exited and a new plot command starts gnuplot from fresh. However, when you used the mouse to close the window, the X11 window was closed but gnuplot_x11 is still active so retains the information about the window size before it was externally closed (not by Octave, but by the mouse). Some work was done on retaining plotting data for all plots but I think it is only in experimental stage right now. Such a feature would enable Octave to not require opening a new version of gnuplot for every new Octave plot. Also, my guess is that gnuplot would be able to handle multiplot more robustly with data retention. There is a bit of work on both sides of the exchange to do that integration. Dan |
From: Ethan A M. <merritt@u.washington.edu> - 2008-12-30 02:52:35
|
On Monday 29 December 2008, Daniel J Sebald wrote: > Some work was done on retaining plotting data for all plots but I think it is only in experimental stage right now. Such a feature would enable Octave to not require opening a new version of gnuplot for every new Octave plot. Also, my guess is that gnuplot would be able to handle multiplot more robustly with data retention. There is a bit of work on both sides of the exchange to do that integration. I was under the impression that Octave started using that new feature the moment gnuplot started supporting it. Is that not the case? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Daniel J S. <dan...@ie...> - 2008-12-30 02:59:29
|
Ethan A Merritt wrote: > On Monday 29 December 2008, Daniel J Sebald wrote: > > >> Some work was done on retaining plotting data for all plots but I >> think it is only in experimental stage right now. Such a feature >> would enable Octave to not require opening a new version of gnuplot >> for every new Octave plot. Also, my guess is that gnuplot would >> be able to handle multiplot more robustly with data retention. >> There is a bit of work on both sides of the exchange to do that >> integration. > > > I was under the impression that Octave started using that new feature > the moment gnuplot started supporting it. Is that not the case? I'm guessing not because I hadn't heard discussion on the Octave list. (Then again, I missed about a year of Octave discussion.) Petr may have followed this more closely than I have. Dan |