OK, so I will make it into a draft PR to have a place to work. Then I can add few obviously missing items (like RotTrackball set in other places) in another commit.
For the actual formulas used, I opted for low disruption to users used to the old scheme - inside a trackball ring, it stays the same - but there are other ways and certainly some users will argue for them. Here is a nice playground to test some methods. But I would build with any method (like my current one) to have something, changing the formula (or having a choice of some) is a nicely isolated change to eventually do later.
@ghutchis After build, we could now test the trackball mode in Navigation Mode only when Alt-drag is used (should rotate Z axis when dragged far away from screen center).
Build done, the logic mostly works as intended, it just rotates Z in countersense and about 3.5 times slower than it should Likely some scaling constants and sense inversion, I’ll fix it.
Hopefully fixed, ready for a build (I expect correct trackball behavior for Alt-drag, in Navigation Tool only for now).
In the meantime, for anybody testing this: On Linux: If Alt-drag moves the whole window instead, do something like this:
menu Applications / Settings / Window Manager Tweaks / Accessibility / Key used to grab and move windows: Alt → None On Mac: You may need to do a security fix in terminal (I need it for the official builds as well): sudo xattr -cr /Applications/Avogadro2.app codesign --force --deep --sign - /Applications/Avogadro2.app
These are the symptoms that you need it (for googlers) :
“Avogadro2” is damaged and can’t be opened, You should move it to the trash.
Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Codes: UNKNOWN_0x32 at 0x0000000100d88000
Exception Codes: 0x0000000000000032, 0x0000000100d88000
There’s an official cert for the continuous builds and releases.
Is it expected to work with weekly builds? (I think it does not for me - I tried either these or stable build, have to retry to be sure - but at least one of them fails for me.)
I have to periodically update the cert - if there’s a problem with the current continuous build, let me know.
I just tested both Current Release and Nightly Build for Apple Silicon (from the Avogadro site) and both work. I must have downloaded on some less lucky no-cert day for Mac and never tried again (using it on Linux only),
So how shall we proceed @ghutchis ? One possible course would be just work towards merge of PR2962 with the current functionality. It is pretty non-obtrusive, providing a bit more functionality to those who press Alt (happens to already work in half the tools) and not doing any harm to others. Then later on we could:
Decide on which buttons zoom/pan belong and add these
Let more tools propagate Alt-drag to trackball
Maybe work on better virtual trackball variants, using this one as a clear basis
I would now rename the PR to just “Camera Controls with Virtual Trackball” leaving out “Global”, you would eventually do code review and we would be one incremental step further.
What do you think?
One last change I am considering in this step is normalizing XY rotations speed in such a way that crossing the virtual trackball circle edge to edge results always in the same amount of molecule rotation (e.g. 360 degrees, as this seems to be in pymol). This would make the sensitivity different with Alt (likely higher) but would make it independent on resolutions and window size. With global navigation available, the Navigation Tool may likely become specialized for very precise navigation so this would already differentiate that way. Limiting the XY area to a circle only, the XY rotation span feels a bit insufficient now.
Funny. What I wished for most at the start of this thread:
sits in the Avogadro source code for some 3 years already, it is just missing in the docs. Just discovered this while thinking “OK, now to my original goal, I’ll make another PR for camera RPC” So for the records and all googlers coming here, Avogadro camera can be remote controlled by RPC, as demonstrated in my test script. So I’ll use these for my physical 3D billiard ball control device.
Regarding other RPC capabilities hidden in Avogadro, source code inspection suggests at least these exist:
addBondOrders alignAtom alignView centerAtom createBonds exportFile fillTranslationalCell fillUnitCell kill loadMolecule openFile removeBonds rotateScene saveGraphic setProjection setRenderTypes setVibrationalAmplitude setVibrationalMode showVibrations standardCrystalOrientation startVibrationAnimation stopVibrationAnimation translateScene wrapUnitCell zoomScene
(For the PR2962 side effect of my effort, I am of course willing to finish and/or improve it.)
AI is really clueless about camera RPC in Avogadro, I had to force it to look precisely at the right source code file to finally acknowledge that the functionality exists…
You can do that more easily with the avogadro PyPI package, which includes avogadro.connect for JSON-RPC: avogadro/connect.py
I’ve posted a few times asking for suggestions on RPC features for automation, e.g. Tasks for Automation
Suggestions are definitely welcome on new capabilities.
As far as AI, I’d welcome ways to make that more obvious, e.g. a list of commands. I know the new MCP mechanism is basically JSON-RPC, but haven’t had time to look into ways to expose the existing local RPC mechanism to scripting or automation.
If that’s something that interests you, let’s open a new thread.
I created Issue #237 regarding the missing docs, I personally will not be able to touch it for two months now (but can return to it later if still needed).
avogadro/connect.py
Sure, seen it. I now marked my script as just an AI-made dirty way to verify that Avogadro has rotate RPC and linked to connect.py as a way to do it properly.
Likely some scaling constants and sense inversion, I’ll fix it.