Using hyprcursor in KDE

[jinliu]

Hi. I'm working on adding SVG cursors to the KDE compositor kwin: https://invent.kde.org/plasma/breeze/-/merge_requests/433

and just saw your work. I'd prefer to use your format, and eventually make it a freedesktop.org standard.

There are a few concerns using it in KDE though:

1. The metadata file is in Hyprlang format, which is unfamiliar to KDE devs/users.

From https://github.com/hyprwm/hyprcursor/blob/main/docs/MAKING_THEMES.md it seems the actual format used is similar enough to a INI/desktop file, so can we use that instead?

Changes needed: a) Add section headers, e.g. "[General]" b) Same-named entries like

define_size = 64, image64.png
define_size = 32, image32.png

need to be merged:

define_size = 64, image64.png; 32, image32.png

2. I'd like to deploy the hyprcursor format of a cursor theme side-by-side with the xcursor format. So it would be good if manifest.hl is merged into xcursor's index.theme (which already has fields for name and description), so a cursor theme can have one index.theme file and both cursors and hyprcursors dir for traditional and cursor-shape-v1-enabled apps.

3. Instead of librsvg, in KDE we might want to use QtSVG to render SVG files. So can we have: a) An interface to only get the metadata part, i.e. the SVG/PNG filename, hotspot, etc., but not doing the actual rendering. b) A build option to only build that interface, not introducing librsvg and cairo dependencies.

[vaxerski]

1. What's wrong with hyprlang? If it's "similar enough", why change it to ini?

2. So, basically, if no manifest.hl, try to find metadata in index.theme? edit: fwiw, having both index.theme and manifest.hl is perfectly fine

3. a) SVG/PNG files are compressed and never saved into a file, so a memory buffer would make more sense IMHO. Especially with svg, it'd be trivial to just pack the svg into a string. b) makes perfect sense if a) is implemented

Also thanks for reaching out and the interest in getting this more widely adopted :)

[jinliu]

What's wrong with hyprlang? If it's "similar enough", why change it to ini?

There's nothing wrong. Just introducing one more config file format to KDE seems, er, less ideal. (OTOH I do realize that using INI would introduce one more config format to Hyprland.)

And I suspect this might become an obstacle when we try to make it a FDO standard.

So, basically, if no manifest.hl, try to find metadata in index.theme? edit: fwiw, having both index.theme and manifest.hl is perfectly fine

That would be fine. I'd like to keep changes minimal to how cursors are deployed (/usr/share/icons directory, index.theme, etc.), so existing code like cursor settings UI can still work with minimal changes.

a) SVG/PNG files are compressed and never saved into a file, so a memory buffer would make more sense IMHO. Especially with svg, it'd be trivial to just pack the svg into a string. b) makes perfect sense if a) is implemented

Yes, that would work.

[vaxerski]

mmm fdo, let's just say I dislike how the fdo operates.

anyways, I can do 2 and 3 tomorrow, 2 is pretty trivial and for 3 I can make a MR so that you can make sure the API will suit your needs.

For point 1, it's kinda worth noting that this would result in there being two formats accepted, .hl and .ini, which means both dependencies (hyprlang and... whatever ini parser..? idk any libraries there) would be pulled by distros regardless... Even if KDE would only utilize .ini, distros most likely will still compile hyprcursor with support for both (because why wouldnt they, all themes atm are .hl)

on that note: is there some standard expected ini parsing library or is it just "do whatever"?

[jinliu]

Considering it again, I think you don't need to do any change about 2. KDE will just read name and description from index.theme (which has proper l10n translations) as it currently does, not using these fields from manifest.hl.

For 1, how about we all use JSON instead? Unlike INI, it does have a standard. And it's more expressive than INI.

Disregarding FDO. Although Hyprlang makes sense for Hyprland config files, and INI makes sense for KDE config files. But if we see hyprcursor as a common cursor format, that would be adopted by many cursor themes, and used by multiple compositors, then IMHO it makes sense to use a popular config format like JSON.

[qweered]

What about yaml or toml instead of json?

[jinliu]

That's good too. I'd slightly prefer json because this is not end-user-facing, so we don't really need the user-friendness from those formats.

[JakeStanger]

YAML I wouldn't want to see, I think it's a mess and does nothing to help the "yet another config lang" situation here. TOML I think would be a good candidate as it's just standardised INI and works nicely for basic flat structures like here.

[vaxerski]

I've added support for toml via toml++. We use toml in hyprpm anyways and thus I've decided to use that.

It's similar (almost the same ?) to INI, and I am familiar with the deps. Plus, I dislike json. It's ugly :P

[vaxerski]

I've made a MR for the raw data API.

[vaxerski]

Is there anything left to do here from my side?

on a tangent, https://youtu.be/fpf_psv42aY?si=Kz952IuEtck4SMIi&t=305 at 5:05, yet another example of how KDE could benefit from hyprcursor :)

[jinliu]

Is there anything left to do here from my side?

No. Unfortunately things are a bit stagnant on my side. Sorry for that.

on a tangent, https://youtu.be/fpf_psv42aY?si=Kz952IuEtck4SMIi&t=305 at 5:05, yet another example of how KDE could benefit from hyprcursor :)

Yes. That is actually one of the motivating examples why I want to ship SVG cursors in KDE. The other one is so the user can choose arbitrary cursor size instead of a few pre-defined sizes.

[vaxerski]

No. Unfortunately things are a bit stagnant on my side. Sorry for that.

Don't worry, I was just asking so that if everything is done, I can close this as completed :)

Should there be anything wanted / needed by KDE in the future, feel free to open another issue. Thanks for considering hyprcursor :)