bugGNU Octave - Bugs: bug #34120, using mouse-scrolling after plotyy...


bug #34120: using mouse-scrolling after plotyy losed y1 plot

Submitter:  None
Submitted:  Wed 24 Aug 2011 05:48:13 PM UTC
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  3 - Low Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  octavia Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 13 Dec 2017 08:58:05 PM UTC, comment #12: 

Changing priority to Low.  I don't think anyone is working on this.

Rik <rik5>
Group administrator
Wed 16 Nov 2016 07:18:18 PM UTC, comment #11: 

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?

Mike Miller <mtmiller>
Group administrator
Sun 02 Oct 2011 10:38:21 PM UTC, comment #10: 

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.

[hax, h1, h2] = plotyy (x, sin(x), x, cos(x))
get (hax, 'color')

ans =

    [1x3 double]

axes (hax(1))

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.

Ben Abbott <bpabbott>
Group Member
Wed 21 Sep 2011 10:58:14 AM UTC, comment #9: 

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.

Tue 20 Sep 2011 10:11:16 PM UTC, comment #8: 

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.

Ben Abbott <bpabbott>
Group Member
Tue 20 Sep 2011 09:04:21 PM UTC, comment #7: 

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.

Tue 20 Sep 2011 08:44:03 PM UTC, comment #6: 

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.

Tue 20 Sep 2011 08:23:51 PM UTC, comment #5: 

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.


Tue 20 Sep 2011 12:16:21 PM UTC, comment #4: 

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.

Ben Abbott <bpabbott>
Group Member
Tue 20 Sep 2011 11:09:24 AM UTC, comment #3: 

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.


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.

Tue 20 Sep 2011 12:32:21 AM UTC, comment #2: 

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?

Ben Abbott <bpabbott>
Group Member
Wed 24 Aug 2011 05:51:23 PM UTC, comment #1: 

PS , the p hotkey reverts the scroll as in gnuplot but does not recover the lost plot.

Wed 24 Aug 2011 05:48:13 PM UTC, original submission:  

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.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-12-13 rik5 StatusNeed Info Confirmed
    2017-12-13 rik5 Priority5 - Normal 3 - Low
    2016-11-16 mtmiller Release3.4.0 dev
    2011-09-20 bpabbott Item GroupIncorrect Result Feature Request
        Assigned tobpabbott None
    2011-09-20 bpabbott StatusNone Need Info
        Assigned toNone bpabbott

    Back to the top

    Powered by Savane 3.12