add new wayland cursors

[m4rch3n1ng]

added the new dnd-ask and all-resize as specified in wayland/wayland-protocols!294. one concern is, that the names might not be final (especially for dnd-ask), and changing them later would be a breaking change. i think that could potentially be mitigated by adding a new enum variant and deprecating the current, but i also think that it will probably take some time (if it will even happen) for wayland to change the naming, so it should probably be fine for a while.

mutter falls back to dnd-copy and dnd-move while kwin falls back to copy and move. since this repo consistently uses the dnd-less versions, i decided to fall back to copy and move respectively.

i don't know what description to add to those: breeze doesn't have them and the only ones i could find for the new dnd-ask icon were in the adwaita docs and from bibata who are drawing them very differently. (though bibata does some other strange decisions like having a different cursor for dnd-copy and copy). if you want me to i could add a description like /// Often drawn as an arrow with either a small question mark or three dots next to it, but i just left it for now.

[kchibisov]

I'm not sure how to be with this one. The repo follows the w3c css cursor spec, thus such cursors are not present in it and would confuse the impl.

Maybe we should separate them into the platform specific enum, so we say that they are generally may not be present, etc?

[m4rch3n1ng]

there's an open issue for this at w3c/csswg-drafts#10115, but it doesn't seem like there's happening a lot there. i think even without this being added to the css standard adding these is useful: cursor-icon is used by winit, smithay and the smithay-client-toolkit and i think it would be annoying to not be able to set your winit cursor to all of the available ones.

maybe a native and a css cursor enum might make sense? but i don't know if that would complicate things.

[madsmtm]

There is precedent in keyboard-types for non-standard variants. As long as it's clearly documented, I'm on board with it here as well.

Though I would somewhat prefer to wait with adding these 'till they're actually finalized in the Wayland protocol (unless there's a good reason not to?).

Moreso, I'd be interested in seeing how Chrome and/or Firefox decide to expose these to the Web, if they do?

[m4rch3n1ng]

not sure what you mean by "finalized in the wayland protocol", but the new cursors were released in wayland-protocols 1.42, released on march 27th.

[kchibisov]

he means w3c spec, not wayland spec, since this crate more or less represent w3c spec.

[madsmtm]

No I meant the Wayland spec, I wasn't sure it was actually released

[Enokilis]

I wouldn't bet on 'move' ever having its common use case reinterpreted when all three major platforms treat it as 'all-resize' is described. It would be really nice if the CSS spec were less ambiguous and had some meaningful reference cursors.

[madsmtm]

I am fine with this with the comments below resolved. Again, while this library does follow the W3C spec, I do not believe we need to limit ourselves to that (as long as it's clearly stated so in docs).

[madsmtm]

Either the docs for this function should be updated, we should panic here, or we should return a standard Web name like copy/move.

[m4rch3n1ng]

updated the docs of the function. i would personally be against a panic! as that makes it more annoying for a wayland compositor to load cursor icons to render, like i do with my own compositor here.

[madsmtm]

Thanks.

Noting down my thoughts for why this is the better solution (rather than returning copy/move), and why it's fine as a non-breaking change:
On Wayland, a 1-to-1 mapping will be useful when importing cursors.
On Web, Winit and similar "consumer" libraries will set the cursor CSS property for e.g. CursorIcon::AllResize to all-resize. This isn't supported by any (current) browser, and so the browser will fall back to the default icon - just like it will on e.g. the macOS backend, which also doesn't handle this case.

[kchibisov]

We should clearly indicate in the docs that those 2 new icons are not part of the w3c spec we refer to and that they may generally not be present as is.