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?

[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.