We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3285 - Can't get system "SIZE" cursors, but instead always getting the "HAND" cursor
Summary: Can't get system "SIZE" cursors, but instead always getting the "HAND" cursor
Status: REOPENED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-05 16:43 UTC by cra0zy@gmail.com
Modified: 2018-08-07 06:13 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cra0zy@gmail.com 2016-03-05 16:43:54 UTC
The following cursors:
SDL_SYSTEM_CURSOR_SIZENWSE
SDL_SYSTEM_CURSOR_SIZENESW
SDL_SYSTEM_CURSOR_SIZEWE
SDL_SYSTEM_CURSOR_SIZENS
SDL_SYSTEM_CURSOR_SIZEALL

are all getting replaced by:
SDL_SYSTEM_CURSOR_HAND

That is trying to use them always results into getting a hand cursor.
Comment 1 cra0zy@gmail.com 2016-03-05 16:58:49 UTC
Correction, they aren't getting replaced by SDL_SYSTEM_CURSOR_HAND
 but by "fully closed hand", That hand is gotten when the window is moving.
Comment 2 cra0zy@gmail.com 2016-03-05 17:10:19 UTC
And I may have jumped the gun, found the reason, it turns out that:
SDL_SYSTEM_CURSOR_SIZEWE
SDL_SYSTEM_CURSOR_SIZENS

work correctly, but these 2:
SDL_SYSTEM_CURSOR_SIZENWSE
SDL_SYSTEM_CURSOR_SIZENESW
are getting replaced by the hand.

Some Linux DEs have 4 cursors, one for each corner instead of Windows like where there are 2 cursors.
Comment 3 Philipp Wiesemann 2016-03-05 22:57:14 UTC
In "src/video/x11/SDL_x11mouse.c" the same cursor is set for SDL_SYSTEM_CURSOR_SIZENWSE, SDL_SYSTEM_CURSOR_SIZENESW and SDL_SYSTEM_CURSOR_SIZEALL.

This could be a bug. Or maybe the active cursor theme uses "closed hand" for both "sizing" and "moving" (which could be confusing :).
Comment 4 cra0zy@gmail.com 2016-03-06 21:07:27 UTC
> Or maybe the active cursor theme uses "closed hand" for both "sizing" and "moving" (which could be confusing :).

Linux Cursor themes I've seen ended up having 4 different cursors for it(1 for each window corner). The API should probably be updated to support each corner cursor separately.

Example with awdita theme(default with GNOME):
https://github.com/GNOME/adwaita-icon-theme/blob/master/src/cursors/pngs/96x96/top_left_corner.png
https://github.com/GNOME/adwaita-icon-theme/blob/master/src/cursors/pngs/96x96/top_right_corner.png
https://github.com/GNOME/adwaita-icon-theme/blob/master/src/cursors/pngs/96x96/bottom_left_corner.png
https://github.com/GNOME/adwaita-icon-theme/blob/master/src/cursors/pngs/96x96/bottom_right_corner.png
Comment 5 Ryan C. Gordon 2016-03-08 04:36:00 UTC
This is because SDL_SYSTEM_CURSOR_SIZENWSE and SDL_SYSTEM_CURSOR_SIZENESW both map to X11's XC_fleur cursor. Windows has a cursor that has two diagonal arrows that matches well here, but X11 doesn't.

These are the choices:

 https://tronche.com/gui/x/xlib/appendix/b/

There are clearly better choices if we had separate SDL cursors for NE, NW, SE and SW (and Windows could have reused cursors as appropriate), but that's not how it worked out.

(Having a hand cursor is technically a bug in the font used for this, but it's probably because XC_fleur is generally used when dragging things.)

Going to mark this bug as ASSIGNED, so we can change this API later.

--ryan.
Comment 6 Ryan C. Gordon 2018-08-06 21:20:25 UTC
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.
Comment 7 cra0zy@gmail.com 2018-08-07 06:13:15 UTC
Gonna reopen this as this is still an issue.