Interactive Zoom Mouse Drag Direction

Support
1

Currently, when you interactively zoom with the mouse, dragging the mouse up zooms out, and dragging down zooms in. I’m using my slicer module as an extension to a main app that zooms in the opposite direction. This confuses the users making them zoom in the wrong direction when in the slicer module UI.

Is there a way to make mouse drag up zoom in and mouse drag down zoom out?

Thanks

2

Reviewing the current state of your SlicerQReads custom app, it appears you are using a modified Slicer version that has already swapped some zoom/pan functionality for mouse clicks by way of this commit. For inverting zoom in/out based on those mouse interactions I would suggest to look in those same files as that commit to then invert some more logic.

4

Hi @jamesobutler,

Here’s how I attempted to reverse the zoom mouse drag direction…

  1. Changed the following code in vtkMRMLSliceIntersectionWidget.cxx (MouseWheelForward = Zoom In / MouseWheelBackward = Zoom out) …
    this->SetEventTranslation(WidgetStateIdle, vtkCommand::MouseWheelForwardEvent, vtkEvent::ControlModifier, WidgetEventZoomInSlice); // DVP swapped Zoom In and Zoom Out
    this->SetEventTranslation(WidgetStateIdle, vtkCommand::MouseWheelBackwardEvent, vtkEvent::ControlModifier, WidgetEventZoomOutSlice); // DVP swapped Zoom In and Zoom Out

… And these lines in the PyObject *PyvtkMRMLSliceIntersectionWidget_ClassNew() method in vtkMRMLSliceIntersectionWidgetPython.cxx

    { "WidgetEventZoomInSlice", vtkMRMLSliceIntersectionWidget::WidgetEventZoomOutSlice },
    { "WidgetEventZoomOutSlice", vtkMRMLSliceIntersectionWidget::WidgetEventZoomInSlice },
  1. Does this look correct?
  2. Will this require a full rebuild?

Thanks

5

@jamesobutler,

image

I made the above changes. I simply swapped the zoom in/out Signals slots so that in calls out and out calls in. For instance…

The WidgetEventZoomInSlice (Zoom In) signal calls the opposite (Zoom Out) function, vtkMRMLSliceIntersectionWidget::WidgetEventZoomOutSlice, and visa versa.

This is obviously the wrong way to do it, right?

:expressionless:

6

Changing the mapping like this is fine, but it would be a bit more future-proof if you did not change the Slicer core source code but instead you would run some Python code at startup to change the mapping. See example here.

7

@lassoan, I disagree that it’s fine. I’d like your way much better if I can now figure out the correct parameters to use for the Zoom mouse drag and mouse wheel direction.

I’ll search for it. Thanks

8

@lassoan @jamesobutler @jcfr

Hello @lassoan, I stayed up till past 2 in the morning trying to figure out the secret formula for changing the zoom in/out mouse drag direction using Python. Then I began to wonder why @jcfr did not use Python here

Also, @jamesobutler commented here.

So why did my code here not work? Shouldn’t the mouse wheel at least be working in the opposite direction. Maybe I’m building incorrectly.

Should I continue to try to implement this in Python?

Thanks

9

Good morning @jamesobutler @lassoan @pieper @jcfr,

Could someone please tell me why making these changes (swapping slots) would have no effect on mouse actions Zoom events after rebuilding?

I’m totally lost…

Thanks

10

It should not be necessary to look into the generated Python wrapper. It is the exact translation of the corresponding header file to a Python object. It contains no additional information compared to the header file.

Changing the translation from GUI event to widget event in the constructor should work well. Changing it in Python is more flexible, but you need to do it for each view (and if you switch layout then you need to do it for the newly created view, too). Also make sure to remove the old mapping before trying to add a new one.