[jchw]

Hmm, this leaves me with mixed feelings. It's obviously easier if everyone just adopts libhyprcursor instead of implementing a spec themselves and everyone having to iron out interoperability issues. Hyprlang doesn't look large, it's probably on the same order of magnitude as your average JSON decoder/encoder, but OTOH it's kind of a bespoke language versus other more "standard" options and I think this is likely to hinder adoption more than anything else. It's another "thing" whereas the desktop is already full of INIs, XMLs and JSON files.

Then again, I have no stake in the matter. I think if Vaxry wants this to be adopted though, dropping it onto the world like this is probably not the most likely case to get there. It probably would've been worth bugging maintainers for other compositors (kwin, sway?) to see if they had any input/thoughts on the matter. I can only imagine Hyprlang as a dependency would've come up immediately as a discussion topic (I could be very wrong though.)

[notresidenter]

This is a first-party package from the Hyprland organization. This is meant to be used by people that use Wayland+Hyprland and want a better cursor. I don't think the idea is to make the package itself attractive but to make the Wayland+Hyprland switch attractive by saying: look, here are all the things we do better, including cursors.

[jchw]

OK, but I am responding directly to the post itself when I say this. Specifically this:

> Will this ever be adopted?

> I don't know! All I know is that it's a clearly superior system that is easy to implement.

> The best path, in my opinion, would be to push for wp_cursor_shape adoption over at gtk. If gtk finally supports the protocol, almost all desktop apps that people might wanna use on Linux will be able to utilize hyprcursors via the compositor.

> Support from the toolkits themselves for hyprcursor itself is likely not going to happen, as hyprcursor is not made by a million-dollar non-profit entity via a 10-year-long bureaucratic process, unless somehow the developers over there decide it's more beneficial to use hyprcursors now rather than wait and develop their own, new standard. Who knows? :)

On one hand, I agree with toolkits simply adopting wp-cursor-shape. This makes a lot of sense, and unlike with the CSD argument, I don't really think it would place a particularly hard burden on Mutter to just implement this protocol.

On the other hand, though, if other compositors want a better solution than XCursor, they either have to adopt this or something else, or invent their own system. And Hyprland, by virtue of being a fairly popular and pragmatic Wayland compositor, will no doubt collect a fair number of themes in the Hyprcursor format.

And based on this particular wording:

> All I know is that it's a clearly superior system that is easy to implement. ... hyprcursor is not made by a million-dollar non-profit entity via a 10-year-long bureaucratic process, unless somehow the developers over there decide it's more beneficial to use hyprcursors now rather than wait and develop their own, new standard

This seems to suggest that Vaxry has:

- A belief that this really should be adopted, as a superior solution to cursor themes

- Some level of disdain for the idea that other developers might make their own standards instead of adopting this

Which honestly, is true... but that makes it all the more a shame that this probably won't happen for relatively unimportant reasons, meaning that likely, we'll end up with another cursor theme format later on that will be incompatible.

Not blaming them for not trying to do this as it seems Hyprland has mostly succeeded by simply blazing forward without gaining consensus, but there's a two way street to that approach IMO.

[thayne]

But if other compositor also used it, that would make it easier for hyprland users to use cursors that weren't designed specifically for hyprland. It would also be useful for apps that want to use custom cursor shapes (like, say, games).