Changing priority to Low. I don't think anyone is working on this.
|
This bug still appears to affect Octave 4.2 and the development version using gnuplot 5. Does anyone interested in gnuplot intend to work on this or close as won't fix?
|
The approach to syncing the pan/zoom of the gnuplot window can be implemented using a single gnuplot plot and assigning the objects plotted to either x1y1 or x1y2.
Taking this approach deviate from compatibility with Matlab. However, this deviation may be desirable. For example, the commands below result in the 2nd axes being hidden behind the first.
In addition to the unfortunate behavior of the axes "color", there would also be conflicts in the axes "xlabel" and "title" properties.
I'm not a fan of ML's implementation, so I recommend the Octave implementation by syncing the axes color, xlabel, and title properties. Before, implementing the x1y1/x1y2 changes, I'll put together a changeset for syncing the color, xlabel, and title props and propose the change to the developers.
|
OK , so most of the fundamentally flawed design seems to be inherited from MAtlab. I've never used it so I can't compare. I suppose you're stuck with that.
However, I find it rather surprising that you think NOT having plot lines and axes disappear when strolling or zooming is a "feature request".
I assume matlab does not loose plots and axes.
What does matlab do if you redefine x axis markers and ticks? Do you get a messy superimposition of the new and old axes?
Definitely looks like there are issues that need to be looked at here.
Whether anyone has time or motivation is another question.
|
plotyy is intended to be consistent/compatible with the Matlab variant, but I think this gnuplot feature can be put to use without violating the intended Matlab behavior.
I don't know when I (or someone else?) will have the time to fix this. As Octave's implementation is working as intended, I'm changing this to e feature request as well.
For the moment I'm changing the assignment to "none". When/if I get started I'll assign myself to it. If someone else decides to take this on, please either assign themselves or let us know via a comment.
|
see gnuplot>help axes
current octave plots could be done on x1y1 and x1y2 , removing the redundant x2 clone lying under x1 could have several advantages.
1/ a useful second x axis available as needed
2/ ability to redefine x1 ticks without having to repeat the operation on the useless x2 to avoid making a mess.
making xlabel , ylabel commands explicit rather than depending on some ephemeral state " last used axis" which is not directly visible (and often undocumented when it is changes) would make robust scripting easier.
|
As I suggested elsewhere , it seems that axes="x2y2" could be parsed by plot() within the existing code structure. This may make plotyy() redundant. (unless this is some matlab feature that you are attempting to clone.)
plot() would probably then need to return a list similar to plotyy() but that also could be done by a simple extension to existing behaviour whilst still preserving backwards compatibility.
|
set x2range [0:20]; set y2range [0:100]; f1(x)=x; f2(x)=x*x; set x2tics; set y2tics; plot [0:10] f1(x) axes x1y1 ,f2(x) axes x2y2
I have made several references to this feature in the other bugs I've posted recently. I glad to see this has now reached critical mass.
I hope that helps you see clearly how this can be done in gnuplot.
You will notice all four axes are completely independent and the scroll feature scrolls both in unison and without either line disappearing.
HTH
|
Thanks for the quick response.
You mentioned that "Using gnuplot directly on the same system does not lose lines when scrolling in either single or double axes plotting".
I did not realize that gnuplot was able to do that with double axes.
If you can provide a simple gnuplot example, it may be possible that Octave's plotyy can be implemented to produce the same effect.
|
When I said "gnuplot does not do this" I was referring to the buggy behaviour just described in the previous sentence.
To be explicit: octave calling gnuplot exhibits the described problem. Using gnuplot directly on the same system does not lose lines when scrolling in either single or double axes plotting.
x=[0:10];y=x;
plotyy(x,y,x,-y)
then scroll with arrow key or mouse wheel. First mouse/key scroll event and the first plot line vanishes, as described.
On looking more closely at this, I notice this is more of the "last axis used" paradigm bugginess.
It seems the scrolling and redraw is only communicated to the y2 axis and plot. Not only does the x1,y1 plot disappear, so do those axes!
"An" x axis remains but this is probably the undocumented and identical x2 axis, I'd bet money the x1 has gone as well.
This only emphasises my existing criticisms of plotyy and the last axis syndrome.
|
I'm confused.
You've indicated the problem is with gnuplot backend, but that gnuplot "does not do this"?
Perhaps you can provide a short list of commands and actions needed to demonstrate the problem?
|
PS , the p hotkey reverts the scroll as in gnuplot but does not recover the lost plot.
|
Using the mouse scrolling feature of gnuplot works correctly on an x-y plot but if using plotyy , on the first mouse scoll event only the y2 plot gets scrolled, the other disappears , never to retrun.
Gnuplot does not do this on the same installation.
|