bugGNU Octave - Bugs: bug #44302, Qt single click zoom in processed...


bug #44302: Qt single click zoom in processed before double click autoresize recognized

Submitted by:  Rik <rik5>
Submitted on:  Thu 19 Feb 2015 04:54:28 AM UTC  
Category:  Plotting with OpenGL Severity:  2 - Minor
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  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)

Tue 05 Mar 2019 11:40:45 PM UTC, comment #15: 

I just checked as well and I don't seem to have a problem with autoresize anymore.

Rik <rik5>
Project Administrator
Tue 05 Mar 2019 08:57:11 PM UTC, comment #14: 

I can't reproduce this behavior in Octave 5.1. When I activate zoom mode, I can single click and it zooms in. When I double click, I only see a zoom out to the original zoom level, I don't see a zoom in first.

Mike Miller <mtmiller>
Project Administrator
Fri 23 Dec 2016 06:47:37 PM UTC, comment #13: 

The (minor) mis-behavior of a qt plot, to first zoom in on a double click, before eventuelly re-zooming to autoscale, is still present in Octave 4.2.0.

Hartmut <hardy>
Fri 10 Apr 2015 03:47:53 PM UTC, comment #12: 

I've done some experimenting and distinguishing between single and double clicks is actually reasonably difficult.  The recommended approach is to set a timer in the SingleClickEvent callback and if it times out before the reception of a DoubleClickEvent then it should proceed.  This seems overly complex, and even those who suggested this course of action weren't exactly keen about it.

Rik <rik5>
Project Administrator
Mon 02 Mar 2015 08:41:09 PM UTC, comment #11: 

Re-titling to reflect the remaining issue with single vs. double clicks.  This is an annoyance, but not really gating on the 4.0 release.

Rik <rik5>
Project Administrator
Mon 02 Mar 2015 05:15:16 PM UTC, comment #10: 

It should be Qt who decides on single/double click.  But Octave is not connecting to the single click event.  In Canvas.cc, the code connects to

void Canvas::canvasMousePressEvent (QMouseEvent* event)
void Canvas::canvasMouseReleaseEvent (QMouseEvent* event)
void Canvas::canvasMouseDoubleClickEvent (QMouseEvent* event)

The code in canvasMousePressEvent detects the first button down of a double click and implements the "Zoom In" function.  Only later does Qt deliver a DoubleClickEvent which then autoscales the axis.  So there is a strange Zoom In, followed by a jump back to the autoscaled size.

Rik <rik5>
Project Administrator
Fri 27 Feb 2015 07:31:51 PM UTC, comment #9: 

Isn't that up to Qt to decide whether there is a single or double click, and then pass that event to us?

John W. Eaton <jwe>
Project Administrator
Fri 27 Feb 2015 07:21:42 PM UTC, comment #8: 

The mouse zooms in the correct direction for me now too.

I also see the problem with zoom needed to be followed by drawnow.

In Qt, the single-click/double-click behavior is still a little weird.  On the first click the plot is zoomed in, and then on the second click it is zoomed back (maybe to an Autoscale setting).  It seems like should be waiting until we determine whether this is a single or double-click sequence before executing anything.

Rik <rik5>
Project Administrator
Fri 27 Feb 2015 02:04:10 AM UTC, comment #7: 

Yes zooming with the wheel looks good to me now.

The zoom/drawnow problem affects both Qt and FLTK for me.

Mike Miller <mtmiller>
Project Administrator
Fri 27 Feb 2015 01:00:44 AM UTC, comment #6: 

About mouse wheel "directions" keep in
mind that Apple has switched the scrolling direction.
So, it will be appropriate to allow both directions
to satisfy both camps.

Michael Godfrey <godfrey>
Project Member
Fri 27 Feb 2015 12:27:18 AM UTC, comment #5: 

I checked in the following changeset:


Is this a move in the right direction?

I also noticed that with the Qt plot widget, calling the zoom function doesn't seem to do anything, but then a call to drawnow results in a change in the displayed plot.  I suspect that's a timing or synchronization issue of some sort, but I don't know how to fix it.

John W. Eaton <jwe>
Project Administrator
Thu 19 Feb 2015 07:22:05 AM UTC, comment #4: 

Qt zoom with the mouse wheel still looks to be in the opposite (wrong) direction for me.

Interestingly, calling "zoom (2)" also zooms in the wrong direction. So the mouse handler is probably doing the right thing, but maybe the zoom function at a lower level for the Qt canvas is backwards?

Making the zoom factor apply to both the mouse wheel and clicking makes sense to me.

Mike Miller <mtmiller>
Project Administrator
Thu 19 Feb 2015 06:49:44 AM UTC, comment #3: 

Maybe the property should be called "zoomfactor" or similar and should also apply to the amount we zoom by for clicking as well as using the wheel?

John W. Eaton <jwe>
Project Administrator
Thu 19 Feb 2015 06:40:00 AM UTC, comment #2: 

I checked in the following changeset to allow the zoom factor to be set using the mousewheelzoom axes property. To set a default for all axes, set defaultaxesmousewheelzoom in the root figure properties.


Maybe we should have a way to constrain the values of properties?

The zoom direction for the mouse wheel should now be consistent.

John W. Eaton <jwe>
Project Administrator
Thu 19 Feb 2015 05:17:33 AM UTC, comment #1: 

Thanks for opening a bug to track this. I mentioned it on the list but is probably long lost by now.

According to


the zoom factor in Matlab is 2 in both directions.

Mike Miller <mtmiller>
Project Administrator
Thu 19 Feb 2015 04:54:28 AM UTC, original submission:  

The mouse wheel zoom direction seems backwards to most other programs.  All of the following use mouse wheel up to zoom IN.

gnuplot: Shift + Mousewheel Up
FLTK: Mousewheel Up
GIMP: Shift + Mousewheel Up
Inkscape: Shift + Mousewheel Up

Currently with the Qt graphics toolkit and the mode set to zoom, Mousewheel Up causes a zoom OUT.

Also, the zoom percentage, at 50%, is way to large.  The 5% that FLTK currently uses is about right.  Is this number configurable in some way?

Rik <rik5>
Project Administrator


(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 hardy (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

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

    Only project members can vote.




    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-05 mtmiller StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2019-03-05 mtmiller Carbon-CopyRemoved 80942 => -
    2015-04-23 rik5 Priority5 - Normal => 3 - Low
    2015-03-02 rik5 Severity3 - Normal => 2 - Minor
        Item GroupFeature Request => Incorrect Result
        SummaryQt mouse wheel zoom direction should be reversed => Qt single click zoom in processed before double click autoresize recognized
    2015-02-19 mtmiller StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.5