dicom view zooming should use zoom mousemode assignment

[Elaine Meng]

as discussed in the meeting today, it may be a good idea to make the dicom-view plane zooming use whatever button(s) is(are) currently assigned to the zoom mousemode. I guess similar for translation, if not already the case. Thanks!

[Elaine Meng]

On second thought, I'm less sure about translation.  Since the slice views don't rotate, it may be more natural to translate them with left button.
Elaine

[Zach Pearson]

Continuing from #9303 which also requests the translation mouse mode.

[Zach Pearson]

The default zoom mousemode assignment is on the wheel; we already respect that and it probably doesn't make sense to let it change. By default translate is on the middle and right mouse buttons. We make the right mouse zoom by default, but that can be changed, and I can put some effort into writing logic that detects what mouse modes those buttons are assigned to and dispatches a mouse event from there.

[Elaine Meng]

This sounds backwards from what I was suggesting, to use whatever button(s) the user has set to zoom for zooming, and whatever button(s) the user has set to translation for translation  (regardless of whether they are the defaults or not).  But maybe I'm just misunderstanding your comment.   In most cases they will indeed be set to wheel for zoom and middle-mouse for translate, since the user won't have bothered to change them.  Sometimes right-mouse might be assigned to something else since the Right Mouse toolbar makes it easy to do so.

[Zach Pearson]

Sorry, I think I can clarify. The main hitch with full MouseModes support in viewports other than the main 3D viewport is that they all assume they're operating over the 3D window, and that assumption is kinda deeply relied on. It's worth noting that because of this constraint the side view doesn't implement full mouse mode support either.

What I could do is write something like session.ui.mouse_modes.button_for_mode() and query it using 'zoom' or 'translate' and see what they're assigned to, and do the appropriate action based on that (but only if it's not assigned to left, which has to be for segmenting)

alternatively, we could

• query session.ui.mouse_modes.mode(button) whenever button is either 'middle' or 'right'
• only if the returned mouse mode is translate or zoom, do something

and the last alternative that comes to mind would be to agree on some default behavior. Right now the wheel zooms, middle translates, right zooms.

[Elaine Meng]

Well, to the user those four panes are all in the main graphics window.  They won't think of them as separate tool windows, and it didn't even occur to me that that might be the case until your comment just now.  When somebody shows orthoplanes or planes along any axis in the main window with the "volume" command or Volume Viewer, it doesn't make their mouse mode assignments stop working, so they wouldn't expect this 4-panel slice + 3D view make them stop working either.

Still a couple of questions then before deciding what the behavior should be:

(1) In this ticket, are we talking about the three slice views from "dicom view" and/or Segmentations only? (Are you saying that the user mousemode assignments do already and will always apply to the fourth pane, the 3D rendering?)  

(2) Since you said "agree on some defaults," are you saying that if these dicom-slice mousemodes are totally separate and not linked to the overall mousemode assignments, it would be possible for the user to change them?

[Elaine Meng]

For an analogous tool that "hijacks" left mouse when it is open, see Color Key.  But it only uses that one button for drawing, translating, and resizing.   

I feel like maybe we should consult with the team as to what do do about tools that need several of their own special mousemodes.  Especially for these slice views that occupy the main graphics window and look just like the slice views from Volume Viewer, I think it is confusing for their mouse modes to diverge from the main mouse modes.

[Elaine Meng]

Whoops, I misspoke because  I got confused between Chimera and ChimeraX.  In ChimeraX, Color Key does NOT hijack left mouse.  At my behest, it plays nicely and is treated as one of the main mouse modes.  By default, opening the tool assigns it to right mouse, and this mode does have an icon on the Right Mouse toolbar.

[Elaine Meng]

Sorry, continuing on:  and the Color Key dialog has an option on it for what button is assigned.  But the Segmentations (dicom view) situation is more complicated and I'm not saying it has to (or even could be) the same as Color Key.  I just mean that it is better to make specific tools not conflict with the rest of ChimeraX, if possible.

[Zach Pearson]

Well, to the user those four panes are all in the main graphics window [ . . . ] didn't even occur to me that that might be the case until your comment just now.

Yeah, that makes sense. I can see how it would cause confusion.

To 1) Yes, this is just about the 3 slice views and segmentations. The 3D graphics window will always respect mouse modes -- it's the same widget as it ever was, just repositioned to make room for the others.

To 2) Yes, if desired the user could change them.

I feel like maybe we should consult with the team as to what do do about tools that need several of their own special mousemodes.

We can query them in the office tomorrow or cc chimerax-programmers, up to you depending on urgency.

[ . . . ] it is better to make specific tools not conflict with the rest of ChimeraX, if possible

I agree!

[Elaine Meng]

I don't think it is that urgent since what you have hardwired now is pretty good and similar to the default main mousemode assignments. Unless you yourself feel that it is urgent to get it settled soon. Even though I suggested it, I'm not sure if consulting others will yield clarity or just add to the confusion -- it was just a passing thought.  But depending on what you prefer, could bring it up during your next demo or  in casual conversation with one or more of the other developers at the time of your choosing.

Both of your ideas are reasonable, (A) querying main ChimeraX mouse mode assignments for zoom and translation and using them as long as they are not set to left mouse or Shift-scroll, and (B) sticking with agreed-upon settings independent of the main mouse modes.  Is (A) an excessive amount of work?  I suggested honoring the main mouse mode assignments without any sense of difficulty of implementation.  In the case of (B), my first impression is that what you have now seems reasonable although I reserve the right to change my mind  :-)

[Elaine Meng]

Now I realize why I complained about the translation and zooming in the slice views.  It is because the trackpad equivalents of the mouse buttons are not working at all (at least in Monday's daily build) and I couldn't figure out how to do them.  If we say that middle mouse does blah then it should also work with option+trackpad (aka alt-trackpad) on Mac, and similarly for right mouse and command-trackpad on Mac, and there are also corresponding trackpad equivalents on Windows/Linux that might be similar or different than on Mac.

[Elaine Meng]

Another quibble is that the direction of zooming with the wheel is the opposite from that in the 3D window.  I'd vote for reversing it so that scrolling downward in the slice views enlarges, the same as in the 3D window.

[Zach Pearson]

Oh, true. I tried to account for natural scrolling but got it backwards -- thanks for letting me know!

[Zach Pearson]

Also, I don't think A would be too excessive. I'll get on it!