Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2012-02-09 16:03:35
|
Hi, quick one. coordinate readout in wxt multiplot is on "whole window" coord. system, centred at screen centre. This seems rather unhelpful since it does not relate to ANY of the plots' axes. Wouldn't this be a more useful feature if it translated mouse to 'local' axes of the hovered plot. similarly , if I create an on-screen annotation with a mouse button click , I get a 'global' coord that has no meaning on the graph where it is applied. This makes this rather nifty feature pretty much useless in the multiplot context. :( Peter. |
|
From: <pl...@pi...> - 2012-02-09 17:21:51
|
On 02/09/12 15:45, pl...@pi... wrote: > Hi, > > quick one. > > coordinate readout in wxt multiplot is on "whole window" coord. system, > centred at screen centre. > > This seems rather unhelpful since it does not relate to ANY of the > plots' axes. > > Wouldn't this be a more useful feature if it translated mouse to 'local' > axes of the hovered plot. > > similarly , if I create an on-screen annotation with a mouse button > click , I get a 'global' coord that has no meaning on the graph where it > is applied. > > This makes this rather nifty feature pretty much useless in the > multiplot context. :( > > Peter. PS. I don't want to give the impression I'm not happy with all this. It has a lot of really neat features which is why it would be good to get the wrinkles ironed out. It seems some of this has not had thorough , real use testing yet. I hope these reports will identify some rough edges and corner cases that have been missed. Apart from that it's bloody amazing at what I am able do with gnuplot . I'm producing some quite complex multiplot output of report quality that I can flick between a live wxt terminal and png file output at the flick of a variable (do_png=1). gnuplot is also calling bash scripts that get the data from source, process, filter and FFT it . The whole process in nearly down to one gnuplot load command now. I am impressed ! Peter. |
|
From: Ethan A M. <sf...@us...> - 2012-02-09 18:16:09
|
On Thursday, February 09, 2012 09:22:50 am pl...@pi... wrote: > On 02/09/12 15:45, pl...@pi... wrote: > > Hi, > > > > quick one. > > > > coordinate readout in wxt multiplot is on "whole window" coord. system, > > centred at screen centre. > > > > This seems rather unhelpful since it does not relate to ANY of the > > plots' axes. > > > > Wouldn't this be a more useful feature if it translated mouse to 'local' > > axes of the hovered plot. This is a very long-standing Feature Request. The nature of the problem is that the generic mousing code uses internal variables that are only correct for the "current" plot (actually the plot that was just completed). Since these variables are overwritten with each new plot in a multiplot, the information is not available except for the most recent subpanel. Relatively recently we added terminal-specific code to dump plot layout information so that mousing could be done by terminals like svg and canvas where the information was necessarily stored in the output file itself. As each plot is completed, the summary variables (essentially the ones reported in GPVAL_TERM_XXX) are written into a data structure. That provides a template for how we might do the same for the interactive terminals. I think it would have to be tackled one terminal at a time, but it sounds like a relatively straightforward programming task. If anyone is looking for a project .... :-) Ethan |
|
From: <pl...@pi...> - 2012-02-10 19:50:00
|
On 02/09/12 19:15, Ethan A Merritt wrote: > On Thursday, February 09, 2012 09:22:50 am pl...@pi... wrote: >> On 02/09/12 15:45, pl...@pi... wrote: >>> Hi, >>> >>> quick one. >>> >>> coordinate readout in wxt multiplot is on "whole window" coord. system, >>> centred at screen centre. >>> >>> This seems rather unhelpful since it does not relate to ANY of the >>> plots' axes. >>> >>> Wouldn't this be a more useful feature if it translated mouse to 'local' >>> axes of the hovered plot. > > This is a very long-standing Feature Request. > > The nature of the problem is that the generic mousing code uses internal > variables that are only correct for the "current" plot (actually the > plot that was just completed). Since these variables are overwritten with > each new plot in a multiplot, the information is not available except for > the most recent subpanel. > > Relatively recently we added terminal-specific code to dump plot layout > information so that mousing could be done by terminals like svg and canvas > where the information was necessarily stored in the output file itself. > As each plot is completed, the summary variables (essentially the ones > reported in GPVAL_TERM_XXX) are written into a data structure. > > That provides a template for how we might do the same for the interactive > terminals. I think it would have to be tackled one terminal at a time, > but it sounds like a relatively straightforward programming task. > If anyone is looking for a project .... :-) > > Ethan > There's perhaps more to this wxt+multiplot situation than the problems I indicated. Now using a CVS pull of today ( 10th Feb 2011). If I do a mouse scroll in any area of a multiplot, the multplot vanishes and is replaced by a full window version of the last plot. If it does anything restricted to one plot, it should perhaps scroll the last plot within the multiplot. Binning the multiplot altogether is a pretty nasty bug. Worse, if I close the wxt window and run the gnuplot script again using load command I get the multiplot format but with axes, xrange and yrange stolen from the earlier last plot in the series. The auto scaling feature that was working correctly before is now disabled and the scaling suitable for the last plot is applied to all. I am able to restore sanity by set yr [*:*] . Clearly this is a bug. If I click the autoscale button in the wxt toolbar, it also jumps to last plot full size display of the last plot element but does not mess up the autoscaling if I reload the gnuplot script. Peter. |
|
From: Ethan A M. <sf...@us...> - 2012-02-10 23:12:52
|
> There's perhaps more to this wxt+multiplot situation than the problems I > indicated. > > Now using a CVS pull of today ( 10th Feb 2011). > > > If I do a mouse scroll in any area of a multiplot, the multplot vanishes > and is replaced by a full window version of the last plot. If it does > anything restricted to one plot, it should perhaps scroll the last plot > within the multiplot. Binning the multiplot altogether is a pretty nasty > bug. All of this has been true for gnuplot terminals since approximately forever. "replot" can only reproduce the immediately prior plot command. It can't dive back into history and re-execute earlier plots in the session. So if you do a "replot" after a multiplot, it can only redraw the most recent subpanel. While I certainly understand the desire to re-create the entire set of panels that make up the multiplot, it takes more than a "replot" command to get there. > Worse, if I close the wxt window and run the gnuplot script again using > load command I get the multiplot format but with axes, xrange and yrange > stolen from the earlier last plot in the series. The auto scaling > feature that was working correctly before is now disabled and the > scaling suitable for the last plot is applied to all. Exiting multiplot does not reset or otherwise change the axis scaling. In that way it's just like any other plot. So unless you do a "reset" or "set auto" before re-executing the script, you won't be starting from a clean slate. > I am able to restore sanity by set yr [*:*] . Right. That's equivalent to "set auto" > Clearly this is a bug. Not really. Unless you do a "reset", all the current settings will influence the script you load. That's true regardless of multiplot. FWIW I don't see exactly the same behaviour that you describe for wxt. When I use mouse scrolling after a multiplot it blanks the screen and redraws only the most recent panel, in the same size it was before. It does not go to full-screen as you describe. I suppose this might depend on exactly what size/origin commands were used in the multiplot. Anyhow, I wonder if it's possible to skip the screen-blank step, leaving all the other panels untouched while the most recent one is updated? But it might be tricky to figure out automatically when that is or isn't the best thing to do. > If I click the autoscale button in the wxt toolbar, it also jumps to > last plot full size display of the last plot element but does not mess > up the autoscaling if I reload the gnuplot script. In truth I have never figured out how that button is intended to work :-) Ethan |
|
From: <pl...@pi...> - 2012-02-11 02:19:58
|
On 02/11/12 00:09, Ethan A Merritt wrote: >> There's perhaps more to this wxt+multiplot situation than the problems I >> indicated. >> >> Now using a CVS pull of today ( 10th Feb 2011). >> >> >> If I do a mouse scroll in any area of a multiplot, the multplot vanishes >> and is replaced by a full window version of the last plot. If it does >> anything restricted to one plot, it should perhaps scroll the last plot >> within the multiplot. Binning the multiplot altogether is a pretty nasty >> bug. > > All of this has been true for gnuplot terminals since approximately forever. > "replot" can only reproduce the immediately prior plot command. > It can't dive back into history and re-execute earlier plots in > the session. Would be nice if it could ;) The history is there ... Would rerunning everything in history since multiplot last became active make sense? "multireplot" if it needs to be functionally separte. Incidentally if this could work it would remove the "you can't change terminal when multiplot is active" restriction. Being able to do: set terminal png ; set output ... ; replot; like I do in single plot would be good. I currently have to have lots of if's and else's , flip a do_png variable and reload the script. > > So if you do a "replot" after a multiplot, it can only redraw > the most recent subpanel. > > While I certainly understand the desire to re-create the entire set > of panels that make up the multiplot, it takes more than a "replot" > command to get there. Sure, there could be all sorts of changed settings in between each plot command. The aim is to have something sane happen if I do something like a one increment on the mouse wheel instead of blowing out the whole multiplot and needing to rerun the script. Your explanations may help fix it up a bit. Thanks. > >> Worse, if I close the wxt window and run the gnuplot script again using >> load command I get the multiplot format but with axes, xrange and yrange >> stolen from the earlier last plot in the series. The auto scaling >> feature that was working correctly before is now disabled and the >> scaling suitable for the last plot is applied to all. > > Exiting multiplot does not reset or otherwise change the axis scaling. > In that way it's just like any other plot. So unless you do a "reset" or > "set auto" before re-executing the script, you won't be starting from a > clean slate. I think what I was missing is that I did not realise the mouse scroll would turn off auto-scaling. Since it has to set a specific yrange I suppose that makes sense. Thanks. > >> I am able to restore sanity by set yr [*:*] . > > Right. That's equivalent to "set auto" > >> Clearly this is a bug. > > Not really. Unless you do a "reset", all the current settings will > influence the script you load. That's true regardless of multiplot. Not quite true, a zoom will be lost. That's probably what led me to a false expectation that the scrolled window would be reset as well. I agree this is not a bug, just my mistaken expectation. > > FWIW I don't see exactly the same behaviour that you describe for wxt. > When I use mouse scrolling after a multiplot it blanks the screen and > redraws only the most recent panel, in the same size it was before. > It does not go to full-screen as you describe. I suppose this might > depend on exactly what size/origin commands were used in the multiplot. Ah, that maybe a clue. I just specified the layout and let automatic placement to the rest. It looks like explicitly setting origin etc. may preserve plot size and position. > Anyhow, I wonder if it's possible to skip the screen-blank step, > leaving all the other panels untouched while the most recent one is updated? > But it might be tricky to figure out automatically when that is or isn't > the best thing to do. > > >> If I click the autoscale button in the wxt toolbar, it also jumps to >> last plot full size display of the last plot element but does not mess >> up the autoscaling if I reload the gnuplot script. > > In truth I have never figured out how that button is intended to work :-) > > Ethan > Peter. |
|
From: Petr M. <mi...@ph...> - 2012-02-11 23:21:33
|
> > All of this has been true for gnuplot terminals since approximately forever. > > "replot" can only reproduce the immediately prior plot command. > > It can't dive back into history and re-execute earlier plots in > > the session. > > Would be nice if it could ;) The history is there ... > > Would rerunning everything in history since multiplot last became active > make sense? > > "multireplot" if it needs to be functionally separte. The only way how to achieve such a functionality is by doing "save" into a temporary file just after each plot. multireplot would have to load each file (and hope the original data are still available). There is no single structure keeping the complete gnuplot session, so a file is necessary. Actually, multireplot is not necessary as you can use "set term xxx n" instead and enjoy mousing in the nth window. BTW, the 2nd paragraph in "help mouse" says that mousing is not available in multiplot. Do you think a similar message should be added to "help multiplot"? --- PM |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-02-12 00:20:59
|
On Saturday, 11 February 2012, Petr Mikulik wrote: > BTW, the 2nd paragraph in "help mouse" says that mousing is not available in > multiplot. Do you think a similar message should be added to "help > multiplot"? No mouse _during_ multiplot is fine. The problem comes when you exit multiplot. Now the screen display still shows the multiplot panels, but mousing is re-enabled and if you try to use it then it destroys the current display. Maybe it would be better if we didn't re-enable mousing until the next plot command? Ethan |
