Cursor (shape/image) handling

[DJMcNab]

Our current API for cursor shape is: https://github.com/linebender/glazier/blob/b4c505a3ec8216940244b2b7e77207c648d4be64/src/window.rs#L390-L397

This is probably fine, but it is a little bit unclear - it should be better documented. Reading CursorDesc and Cursor helps slightly: https://github.com/linebender/glazier/blob/b4c505a3ec8216940244b2b7e77207c648d4be64/src/mouse.rs#L21-L50

So, make_cursor creates a long-lived handle to a buffer stored in Cursor::Custom, and set_cursor sets the cursor to that buffer, or one of the specified presets.

The first problem is that this doesn't actually allow accepting a custom image. This was lost when we migrated from druid-shell. I don't think we want to bring in a full dependency on something like image for this, so I'd be tempted to just support 32-bit ARGB buffers in a Vec<u8> in idk, right then down order? Whatever order makes sense, anyway. Maybe adding a dependency for this is fine?

The second issue is that the set of default cursors is very small. There is (now?) a web spec we can follow, so we should probably just use that set.

[waywardmonkeys]

I was going to bring up https://github.com/rust-windowing/cursor-icon ... so this seems like a good time to do that.

[jneem]

Hm, they don't seem to support custom cursors? Also, they have a lot more variants than we do, but I remember that our variants were specifically chosen to be the ones that are available on all our platforms. Has the cursor availability changed on windows or macos recently?

[DJMcNab]

The interoperability crate not having custom cursors is fine - we can have an intermediate type StandardOrCustom (or whatever). Then set_cursor can be generic over impl Into<StandardOrCustom>

In terms of being available on all platforms, that is a reasonable concern - however, I think it's still correct to use this set. This is the least surprising set we could use, and conversion code from this set to the best option on each platform's exist elsewhere. E.g. https://github.com/rust-windowing/winit/blob/master/src/platform_impl/windows/util.rs#L167

Seems like an office hours discussion!

[xStrom]

146 revealed that Cursor doesn't have Send due to HCURSOR. Future improvements to the cursor code could strive for Cursor to have Send.

Alternatively there should be more robust testing that Cursor consistently doesn't have Send on all platforms, like we have for Window.

[DJMcNab]

I reached a potential solution yesterday - instead of requiring something like the image crate, we can "just" give a list of supported image/byte layouts (like wgpu does for textures), and require clients to provide the texture of that kind

[xStrom]

Seems doable and it would still allow for us to have additional helper methods that get enabled when an optional image feature or similar is enabled.