the ternary is in already, 1c503ab covers the three getters this PR adds (getDistance, getFov, getProjection). left getTranslation/getRotation in the long form since theyre pre-existing and not part of this change, can add if needed.

on the compatibility hit, i went and checked which drivers can actually construct the affected variants. it comes out to only the dbus driver.

every InputEventTranslate / InputEventRotate construction in the tree:

both ctors default relative = true (InputDriverEvent.h), and none of SpaceNav, Joystick, HidApi or QGamepad construct these events at all, they all go through InputEventMapper:

SpaceNavInputDriver      direct events=0
JoystickInputDriver      direct events=0
HidApiInputDriver        direct events=0
QGamepadInputDriver      direct events=0

so the only consumers that can reach the changed paths are dbus callers, which is the api this PR is deliberately changing. that doesnt tell us how many real dbus consumers exist, so @MichaelPFrey @Lenbok input is still worth having, but it does mean no other input driver is affected.

happy to go the deprecate-and-add-*2 route instead if they'd rather not break it.

on the zoomFactor question (MainWindow.cc:466), that line is master's which PR doesnt touch. we only split the old single else into else if (event->relative) with the original line verbatim, plus a new else for the absolute case.

for what its worth i couldnt find a justification for the asymmetry either. QGLView::translate (src/gui/QGLView.cc:522) builds one rotation matrix and applies it to all three components identically, so nothing downstream treats Y specially. that line predates the 2022 src/gui move. out of scope here.

This seems fine in terms of not impacting my existing use at all, which to date has only been setters rather than getters.

Built and tested PR 7035 at commit 1c503ab61dca4abd52d64f1f01111cd92a9cab74 using the separate MSYS2 build at srcdir/builddir-pr-7035/openscad.exe.

Viewport Getters

Live D-Bus introspection exposed all expected methods, including the new getters:

• getDistance()
• getFov()
• getProjection()

The initial viewport returned:

Translation: [0, 0, 0]
Rotation:    [55, 0, 25]
Distance:    140
FOV:         22.5
Projection:  PERSPECTIVE

The absolute setter/getter round trip succeeded exactly:

translateTo(10, 20, 30) -> getTranslation() = [10, 20, 30]
rotateTo(30, 0, 150)    -> getRotation()    = [30, 0, 150]

The viewport was then restored to translation [0, 0, 0] and rotation [55, 0, 25], and both restored values were confirmed through the getters.

A manually rotated and translated viewport was also compared directly with Window > Viewport Control:

The translation difference is only display rounding; all values agree at the precision shown in the UI. This verifies on Windows that the PR fixes the old absolute translation scaling problem, uses the user-facing viewport representation, and supplies the missing distance, FOV, and projection getters.

Process Registration

Two independent PR-build processes were then started. A second process left at the startup chooser was not a valid test: the source shows that the chooser completes before MainWindow is created, the D-Bus driver is registered, and InputDriverManager::init() runs.

The second process was therefore launched with a SCAD file so it initialized fully. The first process retained ownership of org.openscad.OpenSCAD, and calls through that name continued to return the first viewport. The second process connected as :1.29 but did not leave a callable object: a direct getter call returned org.freedesktop.DBus.Error.UnknownObject. This confirms that the PR unregisters the second application object after failing to acquire the well-known service name.

In the initialized second process, Edit > Preferences > Axes is expected to show:

DBusInputDriver not open

The console-captured error was:

ERROR: DBusInputDriver: could not register service:

Qt supplied no detail after the colon. The registration failure and object cleanup are verified on Windows; the missing error detail is a remaining diagnostic limitation.

No message appeared in the GUI Console or Error Log, which is consistent with the startup order. MainWindow uses a scoped output handler during construction and clears it before InputDriverManager::init() opens the D-Bus driver. With no GUI output handler active at registration time, LOG(...) writes the error to standard error instead of either dock.