Microscopic Mouse Cursor on HiRes Display

[GSStnb]

Expected behavior

LC retains system mouse curor size or cursor size is configuarble within LC.

Observed behavior

The mouse cursor in LC is a fraction of the system mouse cursor.

Steps to reproduce or sample file

Set system mouse cursor to maximum size
Move mouse from desktop panel to LC application window.
Mouse cursor changes size becoming much, much smaller (and hard to find in the drawing window).

Operating System and LibreCAD version info

Version: 2.2.1_alpha-424-g806e61d0
Compiler: GNU GCC 11.4.0
Compiled on: Apr 25 2024
Qt Version: 5.15.3
Boost Version: 1.74.0
System: Debian GNU/Linux trixie/sid
Other:
Cinnamon desktop
Display is 3840x2160

[dxli]

Could someone help me confirm this issue?

I am using standard 1920x1080 screens here.

[GSStnb]

Here area couple of screen capture showing the difference (zoomed 200%):


The system setting for the mouse cursor is just Small to Large. The panel height is 40 pixels, so the system mouse cursor is +/- 24. In LC it is maybe 16 pixels.

[GSStnb]

I did some poking around the source and I found the following in /LibreCAD-master/librecad/src/ui/qg_graphicview.cpp:

#if (defined (Q_OS_WIN32) || defined (Q_OS_WIN64))
    #define CURSOR_SIZE 16
#else
    #define CURSOR_SIZE 15
#endif

Am I correct in my thinking that in Windows the system cursor size is used, but in Linux and MacOS it would be fixed at 15 pixels? The Qt documentation lists, among a whole bunch of additionsl OSes, "Q_OS_LINUX" and "Q_OS_MACOS"

[dongxuli-concord-design]

Cursors are controlled by Qt. We can set the pixel sizes, but for cursors (and other GUI items, except drawing in coordinated), the pixels are in device independent units for Qt, meaning Qt will scale them by a factor, if high dpi device is detected.
So, the size 16 may mean 32 actual pixels on high dpi.

It helps to play with this value still

[GSStnb]

I changed line 69 in /LibreCAD-master/librecad/src/ui/qg_graphicview.cpp from
#if (defined (Q_OS_WIN32) || defined (Q_OS_WIN64))
to
#if (defined (Q_OS_WIN32) || defined (Q_OS_WIN64) || defined (Q_OS_LINUX) || defined (Q_OS_MACOS))

...and it seemed to do the trick (in a Debian VM at various resolutions from 1920x1080 to 3840x2160) and it remained at an appropriate size (if not larger in LC than the system cursor). I compared the native LC I compiled to the most recent appImage.

(Can you try it on your Windows PC?)

[dongxuli-concord-design]

It means for all systems we are targeting

[GSStnb]

The three installation packages (Win64, appImage, dmg) would be addressed with
#if (defined (Q_OS_WIN64) || defined (Q_OS_LINUX) || defined (Q_OS_MACOS))
while remaining OSes would default to the defined CURSOR_SIZE.

I haven't seen any comments about macOS and I don't have access to Mac, so Im guessing it woiuld be the same problem on a Mac with a hi-res screen with the way it is currently defined...

[dxli]

I will test on Mac.

Could you create a PR?

[GSStnb]

I don't have a full develoipment environment set up so I cannot create a PR right now. It is a minor edit:

Change line 69 in /LibreCAD-master/librecad/src/ui/qg_graphicview.cpp from
#if (defined (Q_OS_WIN32) || defined (Q_OS_WIN64))
to
#if (defined (Q_OS_WIN64) || defined (Q_OS_LINUX) || defined (Q_OS_MACOS))

Does LC still need a Win32 variant?

[dxli]

Could you test this fix?

32bit windows is gone in the new development branch. However, we should be careful when removing win32 definitions in source code, because win32 is also used for 64bit windows

[GSStnb]

Here are a few comparisons (g_cursorSize=32):
previous version of appimage @3840x2160

Actual cursor ~20 pixels

compiled with latest commit at @3840x2160

Actual cursor ~54 pixels

previous version of appimage @2560x1080

Actual cursor ~40 pixels

"w/commit at @2560x1080

Actual cursor ~54 pixels

And just because I was curious (g_cursorSize=16):

Actual cursor ~58 pixels

(These screen captures are cropped and enlarged. At native resolution the cursors are much smaller.)

It seems the g_cursorSize is a default but overridden by system(?) Or a max / min? What ever the case, much better!

[GSStnb]

The latest appImage (LibreCAD-latest-1-g3112c123.AppImage) fails with ... error while loading shared libraries: libQt6Svg.so.6: cannot open shared object file: No such file or directory

[dxli]

The specified 32 is treated as device independent pixels, so ended up roughly the same size on different physical pixel pitches

[dxli]

I just tested the latest master branch AppImage: 581dc21

The AppImage works for me, and there's only minor changes from 3112c12

[GSStnb]

Good news and bad news. I downloaded the latest appImage and yes, it launches. The bad news is that the cursor is still tiny - but only when launching from the appImage. I also download the latest source and compiled it from scratch and it works correctly - with a larger cursor.

[GSStnb]

...having said that - I may have introduced something I shouldn't have - I compiled LC with QT6 libraries. I extracted the AppImage and looked at the contents - it uses QT5 libraries.

[dxli]

No, we are using qt6 with qt6 compatibility modules. It's clear, if you check the workflow file : it's built with qmake6

[GSStnb]

Are these not QT5 libraries?

[dxli]

I think you are looking at a wrong file.

You can run AppImage with the option "--appimage-mount" to mount at investigate.

[GSStnb]

I ran the AppImage with the option "--appimage-extract", "--appimage-mount" shows the same thing:

[dxli]

Let's keep tracking at issue #1787