Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Scalable Cursors #25

Open
bbb651 opened this issue Feb 27, 2025 · 2 comments
Open

Support Scalable Cursors #25

bbb651 opened this issue Feb 27, 2025 · 2 comments

Comments

@bbb651
Copy link

bbb651 commented Feb 27, 2025

KDE introduced an extension to xcursor themes to support svg cursors which has landed in 6.2, see this blog and this issue for more detail.

The main downside is that it is not an official xdg spec, in fact there's hyprcursor which is a different standard. However it seems to me that it's much more likely that this is the format we'll end up with consider KDE's prevalence and the fact it's based on json and not hyprlang, there's already interest in upstreaming it.

I'm not sure how the API should look, I think parsing metadata.json should be left up to users, so I think we just need CursorTheme::load_scalable. If a scalable cursor is not found, I think the expected behavior is use the xcursor if it exists rather than fallback to the next theme, so it would have to return a PathBuf along with whether it's an svg. Is an svg only mode, or some other api that gives more control to users of the crate needed?

@bbb651
Copy link
Author

bbb651 commented Feb 27, 2025

I drafted #26 and thought about it a bit and not giving more control over looking up cursors seems insufficient.
Even with xcursors, if the one with the highest priority is malformed, you have no way to fallback to other themes - it feels like this crate is trying to both be low level and high level at the same time, fundamentally since it doesn't handle loading the cursors it needs to give you access to all possible cursors. I think moving the logic from CursorThemeIml::load_icon_with_depth to an iterator you can pull will work.

@esposm03
Copy link
Owner

Hi, first of all thank you for the heads up, I wasn't aware of the ongoing effort around SVG cursors. I think this crate definitely needs to support them, however I'm a bit unsure about implementing something that is, at least currently, only supported by one desktop. Maybe we should wait a bit longer, either until the spec is merged, or until multiple DEs support it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants