I’d love to have some camera controls which work the same regardless of the current mode, even some awkward ones - this would make it possible to control the camera from outside at least by simulated keystrokes and/or mouse events. (Better yet, have some proper way to remote control this, as hinted by @ghutchis here.) I made my own 3D trackball I use for camera control in pymol and connecting it to Avogadro is very complicated due to the modal nature of the GUI.
Even outside of my 3D billiard ball niche, I guess some mode independent camera control would be welcome.
There are already some keyboard controls… There was also some support for 3Dconnexion’s devices (they added it). If you have specific suggestions, they’re always welcome.
If the 3Dconnexion’s devices currently work (anybody can confirm?) and can control the camera, I should likely emulate one - 3DConnection claims it works with Avogadro 2 and there is an opensource spacenav project which should support it on Linux. Way worth exploring, thanks for the hint @ghutchis. (Support was added to Avogadro in PR396).
(For specific suggestions regarding the camera control keys and mouse actions, it is a tough topic being explored by more experienced users than I am, so my only wish it that at least one way to control camera XYZ&zoom should work in all modes - AFAIK none does now.)
If you see the keyboard shortcuts I linked above, the arrow keys do this now (using modifiers)
- up, down, left, right = rotate
- Ctrl + keys = pan
- Shift + up / down = zoom
Does this not work for you?
If atom in a molecule is selected, arrows in Manipulation Tool move that atom, not camera view. So no, these are not universal camera view keys for me (using the latest weekly build).
Okay, but what would you want the manipulation tools to do? In other words - the intuition I’d have for the manipulate tool is that arrow keys should in fact manipulate the selected atoms.
I get what you want: consistent shortcuts for changing the camera. What I want to know - what keystrokes would work and wouldn’t block intuitive use with particular tools? It’s a bit easier in Pymol because it doesn’t have “edit modes.”
I feel camera control is completely orthogonal to anything else the program does (a bit like window management is orthogonal to what applications do) and deserves always accessible controls. I even made a new input device just for this and I am extremely happy with the resulting experience (a bit like one gets addicted to Mac trackpad). What I really want is to make it work also with Avogadro, by whatever means (remote procedure call like I use in pymol, or python scripting hooking to event loop as I did in FreeCAD, or scripted keys+mouse as I tried in Avogadro). But of cause this can be just me, I am not that sure I will make others equally happy.
Still, I feel that separation of camera control can be useful even as just a mental model with corresponding use of keyboard+mouse - perhaps with Ctrl pressed, mouse could always behave like in the Navigation Tool mode? Perhaps “asdf” could in all modes behave like “hjkl” in the Navigation Tool mode? (I’d need to think this over while looking at a complete key bindings list…)
perhaps with Ctrl pressed
I think I tried control-arrow shortcuts in the past and they didn’t get captured somehow. I should look into that, because obviously Ctrl + arrow with modifiers could be fairly universal.
Until you want to type as for arsenic in the edit or template tool…
I have to go teach, but I’ll try to figure out why the Ctrl + arrow wasn’t working. This was certainly one of the requests from the community survey.
Yeah, the trick is that Ctrl+arrow current means something in Manipulate, but that’s probably not widely used. (Remap it to Ctrl+Shift+arrow in manipulate to rotate around the Z axis.)
Also, Alt already means something on the keyboard — it’s the “bigger step” multiplier in both Navigator (scale = 6.0f) and Manipulator (10° vs 5°).
So here would be my “consistent camera” proposal - though I welcome other ideas:
| Camera (always, any tool) | |
|---|---|
| Alt/Option + drag | rotate / zoom / pan per button |
| Middle drag, Right drag | zoom-tilt, pan (already true in Navigator) |
| Ctrl + arrows | pan |
So for Alt + Mouse:
- Alt+Left Mouse Button = rotate
- Alt+Middle = zoom
- Alt+Right = pan
I think these would all be currently unused.
Thoughts? Concerns? Better ideas? @vhanzl - would this fit your needs?
Thanks @ghutchis, yes, that would work for me (if the third rotation axis is also somewhere - with zoom or pan as the other mouse direction?).
One little nuisance is that Alt-drag is often used as an alternative way to reposition windows on Linux (with cursor anywhere in the window) but the space of options is crowded and those who care can remap the window movement to WinKey-drag. (And I personally do not care as I use my four fingers drag on touchpad to reposition windows.)
Why not Ctrl-mouse?
At least on Mac, that’s generally reserved for “bring up a contextual menu” - I’m pretty sure that’s common on Windows too.
OK, then be it Alt. I am investigating what other software uses and Alt seems to be common. Compared to your proposal @ghutchis, switched Pan and Zoom seems to be more common:
- Alt+Left Mouse Button = rotate
- Alt+Middle = pan
- Alt+Right = zoom
And for what exactly “rotate” means, I take back my lazy desire for all 3 axis rotations being directly accessible, users would be better served by “accumulative virtual trackball engine”, as e.g. pymol uses (with just drag) using just one binding - which is probably what you had in mind. (And I can script this version as well.)
Okay, but I’ve used a lot of mice in which the middle is the scroll wheel - so I’ve always considered that on the Zoom side because it felt natural.
Okay, but I’ve used a lot of mice in which the middle is the scroll wheel - so I’ve always considered that on the Zoom side because it felt natural.
Fair enough - I personally have no preference here as I do not use any mouse for a decade or so and I am just guessing - maybe those with mouse on their table could tell us what they think…
For the “accumulative virtual trackball engine”, this part of coding is a bit involved - now Avogadro rather directly maps mouse coordinate changes to 3 space axis changes. Controlling all 3 axis by just 2D path of the mouse drag needs more math - I guess it is no rocket science either but can be done in different ways, some much better than others. The pymol way is my favorite among these. I am already very grateful that you pay so much attention to this @ghutchis so if there is any need for help tackling these pesky transformations, I’d be happy to add my 2 cents.
If you have some sample code or pseudo-code (or can point me at the relevant parts of Pymol source code) it would be really helpful.
We ported the code from Avogadro 1.0 / 1.2 directly and in the survey evidently it’s worse in 2.0 than in 1.2? (Not sure how the same code can be worse, but 
)
Another survey user mentioned Blender - which I haven’t used much either.
Pymol implements it in layer1/SceneMouse.cpp where virtual_trackball == 1 (here and here) and the user view is described here but I guess I need to dig in a bit more and process this information to be really useful… Working on it.
Maybe it is actually quite simple. For every small part of drag with Alt:
- When cursor is within a virtual trackball radius from screen center, behave like Navigation Tool.
- When not that close, compute angular change with pivot in screen center and apply it the same way as Navigation Tool applies horizontal movement with Shift.
Trackball radius is 0.45*min(w, h) where w, h is screen size (screen meaning the part of screen with molecule). “Small part” may likely mean sum of distances currently available in all events on mouse input before it would block. (Maybe the Manipulation Tool now saves the origin of the whole drag - for trackball, we need to apply each small part individually.)
(Looking how this fits to the related part of the Avogadro source code…)
Here is my draft of the above idea in C++ (just a sketch of the trackball math, not a full PR).
(Really just a discussion input, I did not setup the build environment and did not even check this by compiler for syntax errors.)
Probably the way to test this out is to get a draft PR together. Even if you submit a PR, the build actions will let you know if there’s something wrong. I’ll start drafting the other changes, e.g what I mentioned here.
If there’s a PR, you can also add a comment @coderabbitai review to get feedback from the CodeRabbit bot.
I think this is probably something in which we need a build and then asking for some testers to try it out. Since I have a Mac laptop with a 2D trackpad, I have pretty much the worst case for this. (Plus I’m used to the old scheme.)