Additional Cursors

[imaginationcoin]

Please can you add definitions and support for the default cursors:

resize diagonal top left
resize diagonal bottom right
resize diagonal top right
resize diagonal bottom left
alt select
unavailable
hand grab
help select
hand grab
handwriting

[elmindreda]

Those ones weren't added because they're not available on all platforms and at that point you're better of making your own.

[imaginationcoin]

horizontal and vertical resize are standard, so the two diagonal resize, i think a couple of them are missing along with just a few other standard cursors. I would like the ability to offer the standard system cursors as well as custom ones.

[elmindreda]

Here are the standard cursors available on each platform:

• OS X
• Windows
• X11

[ocornut]

I came here asking for the same question and found this. The lack of cursor on OS X is pretty unfortunate :( Perhaps is that it wouldn't hurt if glfw supported the definition for some of those extra cursors, with the documented fact that they won't be used on some platform. (the comment can be next to the definition).

(As for X11, It looks pretty clear that X11 cursors predate the jurassic era so perhaps they shouldn't be treated as the bottleneck.)

[elmindreda]

I may squeeze in a few extra standard cursors by following the example set by SDL2. Since OS X has the most limited set but also doesn't (obviously) support cursor themes, I'll also consider adding custom images matching the existing standard cursors.

[andrewrk]

Alternate approach: an API where you can set standard cursors including the ones in the top post here, but get an error code if the platform does not support the selected standard cursor. Then the application code could notice the error and set a custom cursor. That way GLFW does not have to include any art.

[elmindreda]

@andrewrk That is the solution I want to avoid, as it is the least user friendly.

[andrewrk]

I understand. Be careful though - trading power for user-friendliness in a C API is a dangerous road.

[PlutoniumHeart]

I wouldn't throw an error, just ignore it in OS X and don't do anything, people use GLFW on OS X probably already know better than asking for things that don't exist any way.

[wjakob]

+1, I just ran into this. It's puzzling to have GLFW_HRESIZE_CURSOR and GLFW_VRESIZE_CURSOR but not the diagonal version.

[ocornut]

FYI was looking into this today, and found references (untested) of the fact that OS X apparently have those cursors but they are not documented:

https://stackoverflow.com/questions/10733228/native-osx-lion-resize-cursor-for-custom-nswindow-or-nsview
https://stackoverflow.com/questions/27242353/cocoa-predefined-resize-mouse-cursor

If OS X was the bottleneck here that may be a solution to easily add some extra cursors.

[codecat]

Still disappointed this hasn't been implemented yet.. what would it take for this to get an accepted PR? What would be the desired API? I'm willing to make a PR myself if an API can be agreed upon.

I particularly like the "return error code" if creation of a standard cursor is not available on some platform. Perhaps just return null so that the cursor will just be the standard cursor if the code follows something like this:

GLFWcursor* cursor;

void Initialize()
{
  cursor = glfwCreateStandardCursor(GLFW_BOTHRESIZE_CURSOR);
}

void Update()
{
  // For cursor == nullptr, it'll just set it to the default cursor
  glfwSetCursor(cursor);
}

[ocornut]

Still disappointed this hasn't been implemented yet.. what would it take for this to get an accepted PR? What would be the desired API? I'm willing to make a PR myself if an API can be agreed upon.

As many projects the number of issues can be hard to follow up so I don't think it is particularly constructive to state disappointment (we all have issues that are important to us).

IHMO even a PR that implemented what you suggest and not even support all the cursors on OSX would be a way forward. As GLFW depends on work for multiple platform it can be paralyzing for a single developer, and difficult to coordinate multiple people.

I imagine if a PR existed which proved that it was possible on OSX (and maybe discussed the potential issues associated to using undocumented API, or provided references as to who may be doing the same) and implemented the bulk of the cross-platform work if it would be much easier to take a decision on the API and merging details.

[codecat]

As for the cross-platform work, I do have and regularly use Windows, Mac, and Ubuntu machines. I can definitely see what is available on those.

As many projects the number of issues can be hard to follow up so I don't think it is particularly constructive to state disappointment (we all have issues that are important to us).

You're right, I apologize for that wording. Didn't mean to make it sound personal or anything like that.

[elmindreda]

Started working on this in the more-standard-cursors branch.

Does the naming of the new cursor constants make sense?

How strict should the new cursors be about matching visually? On platforms where the usual generic move cursor is a closed hand instead of a four-way arrow cross, should GLFW_RESIZE_ALL_CURSOR map to that or should there be a separate GLFW_CLOSED_HAND_CURSOR?

[ocornut]

Hello,

Thank you Camilla for looking into this. I think the names you added are alright seeing they tend to match what most platform uses (e.g. NOT_ALLOWED is the closest to what most platforms uses, apart from win32 "NO" which is misleading anyway).

To answer this one specific example:

Looking at https://github.com/glfw/glfw/compare/more-standard-cursors it appears only Mac doesn't have a resize-all cursor. I noticed that the original post didn't mention such cursor explicitly. I'm also noticing that even though I added one in dear imgui, I never had a use for it. The only usage context I can think of in using Alt-control in Windows to move a window. That's not answering the more general question, but knowing of other typical usages of a resize-all cursor would help making that decision?

I was thinking maybe this particular cursor should be called MOVE and not RESIZE-ALL ? But resize-all appears to be the standard name everywhere, and SDL use SDL_SYSTEM_CURSOR_SIZEALL which also maps to closedHandCursor on Mac so it seems like a reasonable choice.

Personally I am most looking forward for:

• RESIZE_NWSE
• RESIZE_NESW
• NOT_ALLOWED
• HELP

I can imagine exposing this if it was available:

• WAIT (HOURGLASS)

Maybe other users (e.g. @imaginationcoin) would have more feedback on this.

[ocornut]

Taking the liberty to ping @imaginationcoin @andrewrk @PlutoniumHeart @wjakob @codecat who posted in this issue to see if they have any feedback regarding the branch which Camilla proposed?

[elmindreda]

The following cursors have been added with 7dbdd2e

• GLFW_RESIZE_NWSE_CURSOR
• GLFW_RESIZE_NESW_CURSOR
• GLFW_RESIZE_ALL_CURSOR
• GLFW_NOT_ALLOWED_CURSOR

The macOS context help cursor behaved strangely on 10.10 Yosemite and was left out for now.

[ocornut]

Wonderful, thank you Camilla, much appreciated!

[aloucks]

@elmindreda Is there any chance these new cursors could be backported to 3.3?

[elmindreda]

@aloucks Do you mean can it be added to the 3.3-stable branch or can it be adapted so it fits cleanly on top of 3.3?

[aloucks]

@elmindreda It would be nice if they could be added to 3.3-stable and released as 3.3.4 if 3.4.0 is a long way out. The progress on glfw.org shows 6%.

I thought the cursor addition was a bugfix and they would show up in one of the recent patch updates, but it didn't happen. I wasn't sure if that was intentional or the work to backport just hadn't happened.

[johnnovak]

Just noting that I'd also like to get my hands on this feature in the near future. I'm not familiar with the GLFW release processes, is there something we can do to make sure this is included in the next patch release?

[elmindreda]

@aloucks @johnnovak Do you need the additional cursors in any stable branch, or that and pre-built binaries, or that and an official release?

[aloucks]

@elmindreda An official release would be ideal. I'd like to put in a PR to update the Rust glfw native bindings. This is generally updated from the most recent GLFW release tag. I don't think it would be a good idea to have the native bindings reflect changes that aren't present in an actual release.

I understand if you want to hold off on a new release, but I figured it wouldn't hurt to ask :)

[johnnovak]

@elmindreda For my own purposes I'm fine with just patch that I can apply to the 3.3 official sources (my app is written in Nim and I'm linking statically to glfw).

Also, I'm the maintainer of the Nim glfw bindings so whenever this gets released officially I'll update that, But strictly speaking, for my own app this is not a requirement.

EDIT: Also, I only care about Windows and OS X, if that counts.

[elmindreda]

I created the branch but apparently forgot to tell anyone about it... 🤦‍♀️

@johnnovak A branch with this feature plus 3.3-stable is being maintained as new-cursors-on-3.3-stable in this repo.

@aloucks Noted. The current release scheme is admittedly a flaming disaster but for the same reasons all I can say at the moment is "I'm working on it." Sorry, I'm working on it.

[johnnovak]

@elmindreda Thanks, much appreciated. I will try it sometime!

[johnnovak]

@elmindreda I've just tried this branch on my Windows 10 machine and when I'm switching to any of the newly introduced cursor shapes, the default arrow cursor gets displayed.

@ocornut @aloucks Could you guys get this work on Windows?

[elmindreda]

@johnnovak I cannot reproduce that here. Does glfwCreateStandardCursor emit any errors for those cursors?

[johnnovak]

@elmindreda @ocornut @aloucks Sorry guys, I must have messed up something before. It's working as expected!

Thanks again for creating this branch @elmindreda !

[Journeyman1337]

If you keep adding more cursor shapes that may or may not be supported, a function for determining if a particular cursor shape is supported would also be a nice addition. I made a separate issue thread for this suggestion.
#1935

[elmindreda]

This issue seems to have been addressed, as far as the intersection between system cursor sets allow. #1935 seems like a good place to explore potentially going further.

Closing this. Thank you everyone for your help!