"Place Paintings" Mouse Pointer Moving Offset

[3813127458]

Issue: the painting symbol is moving away from the mouse pointer.

Place_Paintings_Mouse_Pointer_Offset.webm

ideal_probe.zip

Branch 24.1.-a6698e08

Operating System: openSUSE Tumbleweed 20240208 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.7.2-1-default (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i7-4600U CPU @ 2.10GHz Memory: 15,3 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4400 Manufacturer: CompuLab Ltd. Product Name: Intense-PC2 (IPC2) System Version: 1.x

[ra3xdh]

I cannot reproduce this using Qt5 build. The Windows version is not affected too. I suspect this may depend on display resolution.

[3813127458]

two screens, 2560 x 1440, each

[ra3xdh]

I have access only to fullHD hardware and cannot test this using HiDPI hardware. Wait for someone who can provide a fix.

[iwbnwif]

@3813127458

How old is your build? I think that this may have been partially fixed, however there is still a problem if you move the origin so that it is no longer in the top left corner.

For example, using the middle mouse button pan the page so that the 0,0 marker is in the middle of the screen and try to add some text. It is a similar issue to #492.

It can be fixed for text in GraphicText::MouseMoving by changing the lines x1 = x y1 = y

to: x1 = gx y1 = gy

The other painting objects should be similar. However, I am not sure if this is the best way to go about it.

[3813127458]

It was a recent build: 24.1.-a6698e08 probably just a few days old.

The issue exists on all other desktop/platforms: X11, Wayland, Gnome, KDE, Debian, Manjaro, openSUSE and Windows. Also the last official Windows version 2.1.0 is affected. Screen resolution for all mentioned test cases and platforms: 2560 x 1440

Components placement work well, but all painting objects have same issue:

Mouse_pointer_Issue.webm

[tomhajjar]

I have a recent Windows build and see it. In my case the "Ghost" "A" is above my cursor which is actually at "a"

[3813127458]

@tomhajjar: could you please add your method how to create a Windows build step-by-step here: https://github.com/ra3xdh/qucs_s/discussions/414

[tomhajjar]

Vadim supplies me with advanced builds when he can. My build is generally weeks old...

[ra3xdh]

I still cannot reproduce this problem using the latest build on my machine. Everything works as expected. Here is an animated GIF. I cannot fix what I cannot reproduce.

[tomhajjar]

It doesn't do it on a blank schematic for me. It does it on the specific schematic attached above.

It only does it for "Paintings". Doesn't matter which one. Text, circle...etc

[ra3xdh]

Yes, I can reproduce it now. The bug appears only if schematic is loaded. There is something related to the recent refactoring in schematic.cpp

[zergud]

In general, I suggest totally remove such tricky "cursors" and replace with custom QCursor implementation For now I'll try to fix it

[ra3xdh]

I suggest totally remove such tricky "cursors"

Yes, it would be the best solution.

[wawuwo]

@ra3xdh

The bug appears only if schematic is loaded. There is something related to the recent refactoring in schematic.cpp

I see the issue in 2.1.0 too, it happens if the 0,0 cross is not in the top-left corner of view, even with empty schematics. When schematic is loaded there is some automatic scrolling to fit it in the view, that's why the bug happens after loading a schematic.

So steps to reproduce are:

1. Create new schematic
2. Scroll the view left or right or upwards or downwards
3. Select "painting" tool and move mouse cursor over the schematic

~Cursor "companion" is drawn out of place because ViewPainter adjusts coordinates by adding to them canvas-relative coordinates of the 0,0 cross.~

~Let's take arrow as an example:~ ~1. The "companion" is drawn via Schematic::PostPaintEvent (here).~ ~2. Schematic processes PostedPaintEvents and calls Viewpainter::drawLine.~ ~3. drawLine adds DX and DY to the passed arguments~

~When "the cross" is in the top left corner of the view, its canvas-relative coordinates are (0,0), DX and DY are equal to zero too. But when the view is scrolled, canvas grows out, and "the cross" changes its coordinates to non-zero.~

~PostedPaintEvent has PaintOnViewport property which I believe should be used to tell the ViewPainter not to adjust coordinates. So maybe there is a way to fix the problem by modifying ViewPainter and PostedPaintEvent in Schematic.~

UPD: wrong guess

(To be honest this PostPaintEvent subsystem looks very fragile and flaky and is quite hard to comprehend)

[iwbnwif]

@wawuwo This fix works for me on Ubuntu / Wayland 3840 x 2160.

It is worth noting that the video in the original post shows the 'A' moving further from the cursor as the user moves it to the right, which I think is a different problem?

I agree with @zergud it would be best to get rid of these drawn cursors because they leave artefacts when the mouse goes outside of the schematic area.

[zergud]

Let's do it after 24.1 release ;)

[wawuwo]

@iwbnwif

This fix works for me the 'A' moving further from the cursor as the user moves it to the right, which I think is a different problem

Could you please elaborate on this? If " 'A' moving further from the cursor" is a different problem, then what was fixed? :(

[iwbnwif]

@wawuwo Unfortunately, it seems that the video in the first post is no longer available.

When the cursor was at the left side of the screen, the 'A' was quite close to the cursor, but as the user moved the cursor to the right of the screen, the distance between the 'A' and the cursor increased.

I.e, it wasn't a constant offset between the cursor and the 'A', but instead some fraction/multiple of the 'x' position. This was even more evident with the schematic zoomed out a long way.

I think the fix corrected the constant offset caused by the 0,0 point of the schematic being other than in the top left corner. I believe the scaled offset was fixed as well recently because I was only able to reproduce a constant offset in the build immediately before this fix.

Either way, it is working well now!

[3813127458]

I can confirm, that it works nicely now as it should. Great fix. Thx. For sure, it was not a blocking issue, but a "cosmetic" issue.