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

 
 

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

Submitter:  Rik <rik5>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group Member
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>
Group Member
Fri 27 Feb 2015 12:27:18 AM UTC, comment #5: 

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/6ba3d0f7c6e8

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

http://hg.savannah.gnu.org/hgweb/octave/rev/ed1bafbb87ee

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

http://www.mathworks.com/help/matlab/ref/zoom.html

the zoom factor in Matlab is 2 in both directions.

Mike Miller <mtmiller>
Group Member
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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

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)
  •  

    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 group 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.13-f8d8.
    Corresponding source code