8000 support for alternative svg renderers · Issue #83 · hyprwm/hyprcursor · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

support for alternative svg renderers #83

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

Open
pg83 opened this issue Mar 9, 2025 · 4 comments
Open

support for alternative svg renderers #83

pg83 opened this issue Mar 9, 2025 · 4 comments

Comments

@pg83
Copy link
pg83 commented Mar 9, 2025

librsvg depends on Rust, and it is not very desirable sometimes...

There are plenty of alternatives:

https://github.com/sammycage/lunasvg
https://github.com/cppfw/svgren
https://github.com/google/skia (best in class, but really heavy)
https://github.com/memononen/nanosvg

@vaxerski
Copy link
Member
vaxerski commented Mar 9, 2025

rsvg is widely packaged. Why not use your own renderer then?

@pg83
Copy link
Author
pg83 commented Mar 9, 2025

rsvg is widely packaged

I have a functional system without Rust dependencies, and I like to use hyprland in it. Rust is painful in source-based distros, if you want to build everything from sources.

@vaxerski
Copy link
Member

I see. Well, MRs welcome. Probably CMake should automatically pick a renderer

@barracuda156
Copy link
barracuda156 commented Apr 2, 2025

It would be great to avoid depending on rust indeed.

@pg83 Thanks for references, this may be useful elsewhere.
Also, you might be able to use an earlier librsvg, though there is an issue to address (see the link), which the upstream won’t, but we could.

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

3 participants
0