point mirroring results in odd mouse behaviour

[axd1967]

Expected Behaviour

When enabling both horizontal and vertical mirroring, mouse movements should remain intuitive

Actual Behaviour

Mouse movements are inverted too

Steps to reproduce

System

• Stellarium version: Stellarium 24.4+
  Version 24.4.8-0de39da [master]
  Based on Qt 5.12.8

• Operating system:
  Operating System: Kubuntu 20.04
  KDE Plasma Version: 5.18.8
  KDE Frameworks Version: 5.68.0
  Qt Version: 5.12.8
  Kernel Version: 5.4.0-171-generic
  OS Type: 64-bit
  Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz
  Memory: 15.3 GiB of RAM

• Graphics Card: <Manufacturer (likely Intel, NVidia, AMD?), Model (HD, Geforce, Radeon..., with model number), driver version?>

• Screen type (if applicable): Resolution, HighDPI, scaling

Logfile

If possible, attach the logfile log.txt from your user data directory. Look into the Guide for its location.

[gzotti]

Cannot reproduce with Qt6-based build, and we should have seen this by around 2015 with Qt5. What OS is that?

[alex-w]

Cannot reproduce with Qt6-based and Qt5-based builds in linux (Ubuntu 22.04.4 LTS)

[axd1967]

Cannot reproduce with Qt6-based build, and we should have seen this by around 2015 with Qt5. What OS is that?

(issue edited, info added)

[gzotti]

I find numerous reports of weird mouse behaviour on KDE Plasma, wayland vs. X11, etc. Probably not our bug.

[axd1967]

Note: to avoid zenith lock, make sure the test starts without zenith in the centre. (See below about this.)

This also happens in normal mode (without any mirroring).

Dragging the bottom half vertically works normally, dragging any point in the upper half (striped line) inverts the movement .

Dragging left/right also has issues: eg. dragging something a bit below 9 o'clock towards the left actually drags the view down.

Rotational inputs (as opposed to radial movements) seem to work fine everywhere.

To me this feels like a coordinate transformation issue; anyhow, it is not natural.

The requirement should be "I want to drag the selected point where I want"; in other words, the selected grip point should always remain under the mouse cursor.

For example: I want to center on a constellation that is currently physically in my back.

1. switch to "almost" zenital view
2. select a constellation in the top half of the screen (which has objects behind the observer)
3. you should be able to drag it from top to bottom to a point in the bottom half without "losing" it.

Note that this works fine when rotating (i.e. (anti)clockwise dragging) the view around the zenith: but you may not change the radial distance (to Z) while doing so.

About the zenith lock: observe that it is not possible to drag beyond zenith. This also feels like an unnecessary software limitation, most probably meant to avoid ending up "upside down" (which would be the case; in other words, having a view elevation of more than 90 degrees).

Can someone on Windows confirm/invalidate this?

[axd1967]

Further analysis: what happens in fact is

When dragging purely radially away from Z, the view pans down. (and towards Z = up.)

(in eq mount mode, read NCP instead of Z in the above)

[10110111]

Dragging the bottom half vertically works normally, dragging any point in the upper half (striped line) inverts the movement .

I can confirm that this has existed for many years. Ideally, the point held by the mouse at the start of motion should simply follow the cursor (with some clamping of amplitude of motion when this would imply roll in addition to pitch&yaw). But current implementation indeed works the way you describe.

About the zenith lock: observe that it is not possible to drag beyond zenith

This is just as sensible a limit as the lack of roll control. And if roll is added, there would be no need to extend the limits, since all the possible camera orientations would become available.

[gzotti]

This is the way the program has worked since 2008 and probably earlier, and millions of users have learned to deal with it. Yes, you cannot drag the sky around picking a single star and keeping the mouse cursor attached to that star. So what? There are at least no unexpected kinks while dragging the sky around. Whoever is rewriting StelMovementMgr may attempt solving this, but I indeed like to have an UP vector orientation and zenith limit based on current coordinate frame (add ecliptical, galactic and other frames!), and no upside-down or sideways-rolled screens.