Priority: P2: Important
Resolution: Won't Do
Affects Version/s: 5.15.0 RC2
Fix Version/s: None
Component/s: Widgets: Widgets and Dialogs
Environment:Various Rolling Linux Distros + Xorg (or Wayland) + Plasma
This issue by Nick: https://bugreports.qt.io/browse/QTBUG-94778
I believe incorrectly identifies the issue; that is why I am choosing to correctly report the bug. This is still an upstream issue with QT, not Plasma. (acording to Nate Graham) I wouldn't consider this a duplicate report as much as I would consider it a correction. I will also be more thorough.
We are talking about QT affecting KDE Plasma 5. The problem occurs with right clicking a desktop icon on a dualhead system (assuming you are right clicking it on the right monitor). What Nick assumed is that it will calculate it correctly according to screen dimensions, but that it would display on the wrong screen.
The actual issue as elaborated by Eric Putney is that it will calculate it correctly according to dimensions, and it will also display on the correct screen, but it will have a horizontal offset of exactly (Right Monitor Width)px in the direction of the left monitor. Given that Nick Nack likely had two same size monitors, he didn't assume this was the problem, he thought that it was placing it incorrectly to begin with.
Steps to Reproduce:
~Have two monitors
~For my specific circumstance, just place a monitor to the right of your laptop device.
~Your laptop screen (left) should be primary; your connected secondary monitor (right) is going to be used for our test.
~Make a New Folder/Icon on your desktop and right click it on the laptop monitor.
~~It will be correct as always
~Move said Folder/Icon to secondary screen and right click it
~~You will see the offset issue I described above
~Repeat the test with your connected monitor as primary and on the left. The laptop screen will be right and not primary.
~~Right clicking on your laptop monitor will display the same issue
~~Connected monitor should work as expected
The issue is the same for both tests; we just "switched" the monitors. Assuming a dualhead system, the monitor on the right (Not physical right, but settings) will have this issue regardless of primary status.
The video demonstrations will show what the issue is. The videos have what is marked as primary and what is marked as secondary as well as direction for reference.