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