#2460 Extremely small "back" cursor on HiDPI screen under Windows with GTK backend

[Jiri Techet]

On Windows with GTK3 backend, when using HiDPI settings (300% scale factor in my case), the "back" cursor that appears when hovering over the left margin with line numbers is extremely small - see the attached "screenshots" (made by a phone because I couldn't capture the cursor with the screenshot tool). The cursor is at line 37. To my naked eye, the cursor is smaller by those 300%.

Possibly related, on macOS with retina display (using GTK3 backend), the cursor is sized correctly but is pixelated as if it were rendered at half of the native resolution and then scaled up.

I don't have a linux HiDPI setup so I couldn't test but it's also possible that similar problem is there as well.

[Jiri Techet]

Screenshot with a normal "forward" cursor.

[Jiri Techet]

Forgot to mention, tested with the latest Scintilla 5.5.4.

[Neil Hodgson]

GTK is likely using standard Windows cursors for the common arrow and other cursors but not the reverse arrow since this is not provided by Windows. The Windows-supplied cursors are HiDPI enabled.

The Win32 platform layer has code to draw the reverse arrow cursor from a geometric figure. See LoadReverseArrowCursor and CursorHelper. This was added with [415388] for [#2321].

This drawing could be implemented on GTK if someone wants to do the work. The size and colour of the cursor theme are retrieved from the registry and are unlikely to have GTK wrappers. Drawing the cursor like this may also help with [#2439] for distributions that no longer bundle GDK_RIGHT_PTR.

[Jiri Techet]

I had a look at what happens with cursors with GTK and macOS and Windows backends. For macOS, the code it here:

https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/quartz/gdkcursor-quartz.c?ref_type=heads#L191

For cursors which are native to the platform, GTK tries to use that cursor - this doesn't include the back arrow cursor which (I guess) is then created from some image provided by GTK.

On Windows, cursors from https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/win32/gdkcursor-win32.c?ref_type=heads#L39 (as far as I can say, the back arrow is missing there) are loaded to a hash table which is then used by gdk_win32_display_get_cursor_for_type(). Again, there seems to be some fallback for non-native cursors.

Would it be acceptable if normal cursor is used instead of the back cursor on macOS and Windows when using the GTK backend? To me the back arrow is possibly a nice bonus (I don't care much to be honest) but seeing the cursor 3x smaller on Windows is just weird, distracting, and hard to locate for people with impaired vision.

I can prepare a patch and test it if this is OK.

[Neil Hodgson]

To me, showing the reversed arrow is a fairly important indication of an otherwise-invisible mode that guides the user when interacting with the margins.

For macOS, dropping the reverse arrow just because it's pixelated is prioritising appearance over functionality. The Cocoa platform layer provides 1x and 2x versions of the reverse arrow as PNGs scintilla/cocoa/res/mac_cursor_flipped@2x.png and these look more native than the Win32 code. Since GTK doesn't integrate with the macOS bundle (or Win32 resource) approach to image inclusion, the PNGs could be converted to XPMs and included in the source code.

For Windows it is quite difficult to match all details of the standard arrow cursor with the Win32 API so it would be even more difficult from GTK. Unsure if the standard arrow is better than using something more distinct like GDK_CENTER_PTR (which is defined as 'alternate select' at About Cursors) or GDK_HAND2.

[Jiri Techet]

OK, to me the back arrow is something quite special to Scintilla as other editors like vscode, XCode and others use just a normal cursor and the margin provides functionality similar to Scintilla and nobody seems to be confused because of that.

In any case, if "some different" cursor should be used, it's probably fine to leave the pixelated cursor on macOS (it's probably just me who notices such things anyway).

Under Windows, though, it's a real problem. I find GDK_CENTER_PTR a little strange (but I'm a macOS user where I think this type of cursor isn't used so maybe it's something Windows users might expect, I don't know). Wouldn't GDK_HAND1 (i.e. IDC_HAND) be better? Android Studio seems to use it (see the attached screenshot - it's from macOS but I expect they use the same cursor under Windows too). To me it looks more natural and I think there won't be any confusion with other uses of the hand cursor.

[Neil Hodgson]

Wouldn't GDK_HAND1 (i.e. IDC_HAND) be better?

GDK_HAND1 will be fine.

I thought GDK_HAND2(which is an outline in the X cursor font) would be IDC_HAND since it is more similar than GDK_HAND1 which looks like a more solid finger pointing on X.
https://docs.gtk.org/gdk3/enum.CursorType.html

it's probably fine to leave the pixelated cursor on macOS (it's probably just me who notices such things anyway)

Various Windows and Mac users have put quite a bit of effort into mirroring the standard cursor for the Win32 and Cocoa platforms.

For GTK, most of the users are on Linux where there hasn't yet been much interest in pretty cursors. With scaling becoming more common on Linux, there'll probably be more activity with scalable cursors like SVG as are now used on Windows.

the back arrow is something quite special to Scintilla as other editors like vscode, XCode and others use just a normal cursor

Some Microsoft products like Word, Visual Studio, and ISE use the reverse arrow in the margin.

[Jiri Techet]

GDK_HAND1 will be fine.

OK, I'll prepare a patch.

I thought GDK_HAND2(which is an outline in the X cursor font) would be IDC_HAND

Unless I overlook something, it doesn't seem to be mapped this way. So we'd get back to the re-rendered GTK cursor which would probably be 3x smaller.

Various Windows and Mac users have put quite a bit of effort into mirroring the standard cursor for the Win32 and Cocoa platforms.

Unfortunately this is a catch up game with macOS and Windows because when these OS's change the visual aspect of cursors in some way, the back cursor will be off. For instance, I've just tried this with SciTE from the app store and the back cursor is bigger than the normal cursor (on my M1 macBook Pro 14 at least - it may even be caused by different pixel densities of different models and settings used for these models).

And aren't Windows cursors even themable? In that case the back cursor will be different visually anyway.

Anyway, these are just discussion points, GDK_HAND1 will solve the most obvious problem.

[Neil Hodgson]

And aren't Windows cursors even themable? In that case the back cursor will be different visually anyway.

Yes. That is why the previous Win32 code for the reverse arrow cursor copied the pixel data from the current IDC_ARROW cursor then flipped it. However, with the scaled colour-choice cursors that were implemented in Windows 10, that data was not available scaled, so shape drawing was implemented. It was a question of which user expectations to prioritize: size and colour options or theme when theme use is rare.

[Jiri Techet]

OK, I'll prepare a patch.

Here it is, see the attachment.

I've created a PR in Geany at https://github.com/geany/geany/pull/4204 so if you want to test by yourself, you can try the build artifact at the bottom of the page here

https://github.com/geany/geany/actions/runs/12776624357

You can also compare it to the previous "small cursor" problem by trying e.g. the build here

https://github.com/geany/geany/actions/runs/12677847562/

[Jiri Techet]

Here's a screenshot of the result.

[Neil Hodgson]

Committed as [dc2860].