educelab / volume-cartographer

Volumetric processing toolkit and C++ libraries for the recovery and restoration of damaged cultural materials
GNU General Public License v3.0
63 stars 21 forks source link

'Zoom in' not working as keybind #28

Closed hariseldon137 closed 1 year ago

csparker247 commented 1 year ago

Are you on a Mac or a keyboard where you have to hold shift to get the +?

From the PR:

Depending on your keyboard layout, you may have to somewhat modify the above commands. For example, my keyboard has the + key as a super to the = key, changing the Zoom In shortcut to Ctrl + Shift + =. Modifying the shortcuts for all keyboard layouts is not convenient or easy, so consider this a limitation.

hariseldon137 commented 1 year ago

I'm on a PC running linux, and yes I have to hold shift to get the +. (is there a keyboard that isn't like that??)

hariseldon137 commented 1 year ago

Ah ok yes ctrl- to zoom out and ctrl+shift= to zoom in. Thanks.

csparker247 commented 1 year ago

Yes, there are many different keyboard layouts and it can be in different places. As it currently is coded, it should work if you hold Shift as well or use the + on a numpad (which I know is dumb).

Anyway, this is an issue with how Qt has chosen to implement the standard keyboard action for the ZoomIn concept. I personally think there's a bug, but they don't seem to agree or at least don't think it's a priority.

The obvious solution for VC is hard code it to Ctrl + =, but that's no necessarily portable across keyboard layouts, so I chose to do it the official Qt way for the time being in lieu of implementing #23. Holding Shift for a little while didn't seem like that big of a deal, but let me if that doesn't work or if it's a major inconvenience.

hariseldon137 commented 1 year ago

Well whatever position the various commands are in, a segmenter's hand sits in that position for the better of 8 hours a day. So anything awkward is quickly compounded. Imagine a gamer who's WASD is mapped to CTRL-SHIFT-=, and ALT, and so on. Additionally since we move the dots with the mouse, it makes the most sense to have all the commands over on the left side of the keyboard, otherwise the keyboard is hanging off the edge of your desk. I see you are going to make it user-mappable, so I'll wait for that (or reprogram my keyboard with QMK).

The only requirements are that the hand needs to be able to rest in a neutral position on the left side of the keyboard for the zoom, movement (what the alt key does), and impact range. (zoom is least important)

Another helpful command would be to have another bind to move up or down 100 slices, in addition to the current 1x and 10x. Would really help people find good pages to segment.

One last low priority thing would be to make the enter key work as 'start' in the Ending Slice box, the way enter works in the choose slice box.