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


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

Submitted by:  None
Submitted on:  Wed 24 Aug 2011 05:48:13 PM UTC  
Category: Plotting with gnuplotSeverity: 3 - Normal
Priority: 3 - LowItem Group: Feature Request
Status: ConfirmedAssigned to: None
Originator Name: octaviaOriginator Email: -unavailable-
Open/Closed: OpenRelease: dev
Operating System: GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission 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>
Project 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>
Project 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.

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>
Project 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>
Project 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>
Project 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>
Project 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 File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 13 Dec 2017 08:58:20 PM UTCrik5StatusNeed Info=>Confirmed
    Wed 13 Dec 2017 08:58:05 PM UTCrik5Priority5 - Normal=>3 - Low
    Wed 16 Nov 2016 07:18:18 PM UTCmtmillerRelease3.4.0=>dev
    Tue 20 Sep 2011 10:11:16 PM UTCbpabbottItem GroupIncorrect Result=>Feature Request
      Assigned tobpabbott=>None
    Tue 20 Sep 2011 12:32:21 AM UTCbpabbottStatusNone=>Need Info
      Assigned toNone=>bpabbott

    Back to the top

    Powered by Savane 3.1-cleanup1