You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
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 needCursorTheme::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 aPathBuf
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?The text was updated successfully, but these errors were encountered: