The latest v0.3.1 release doesn't allow for custom cursor sizing.

[JonathanSteininger]

The built version with hyprcursor support does not allow hyprcursor to use the themes.

Hyprcusor falls back to the x11 version of the theme.

This does not happen in the v0.30.0 release.

[JonathanSteininger]

I believe the new implementation from 4ed2c6a76613825ea59e3edff50818353354a396 was a poorer implementation to begin with.

actual Issue

The new implementation generates the xcursors for each theme. And then extracts the the xcursor theme. Then uses those extracted files to generate the hyprcursors.

I believe it does the extraction incorrectly as in many manifest files there are anomalies.

why the change needs to be reverted

In my opinion the change needs to be reverted and another solution to be found that 4ed2c6a76613825ea59e3edff50818353354a396 tried to fix.

The hyprcursor-util tool is made to make xcursor themes into hyprcursor themes and distribute the final result. Not include that step in the build process. You can use the tool to create the creation files the first time. fix them up. And then include them permanently in the build process like the previous implementation did 28cb6d2a81e7046400eb177f7131b15507468c57.

The current latest implementation 4ed2c6a76613825ea59e3edff50818353354a396 undid the previous implementation 28cb6d2a81e7046400eb177f7131b15507468c57 and used the hyprcursor-util tool to extract the creation files from the generated xcursors for each theme. And uses those to generate the hyprcursors. The change also made all the hyprcursor config files in src/config/ go unused for a worse implementation.

I'm pretty certain the hyprcursor-util is generating creation files with anomalies leading to a theme that hyprcursor refuses to use as it was designed. Relying on this seems impossible. I belive for the new implementation to require more work to fix and patch. Than to use the previously working and efficient method.

ps.

I'm not certain. But I belive generating the themes from svgs also increases the accuracy of the cursors. Having the hyprcursor theme be generated from xcursors which are pngs seems like a silly step for what hyprcursor tries to achieve.

[sgoudham]

Hey :wave:, thanks for raising this issue.

Happy to accept a PR on a better implementation, I have to rely on external contributions for hyprland specific stuff as I don't use it myself. @kerichdev can you remember the reasoning for your implementation? I know we discussed it a little on discord and I think you had to do some things a certain way because of the bugs you were encountering.

In terms of generating from svg/png, I think @kerichdev and I determined that there was no noticeable difference but we could very well be wrong.

[kerichdev]

Yes - we had to generate hyprcursors specifically from the generated xcursors, as whatever implementation was there before ended up making the cursors look blurry, and fail to set first try without changing the size first.

I've been running the current version of the cursors on hyprland with all the latest (non-git) packages, and everything seems to work fine. Unless I'm missing something?

As for SVG/PNG, there might be a difference on 4k res, where much bigger cursor sizes are required - however I am unable to test that.

[kerichdev]

Setting the GTK xcursor to a different theme, I can confirm that hyprcursor has no issue picking up the one from the theme. I'm not sure if hyprcursor can fallback directly to an alternative xcursor theme on its own?

Whenever hyprctl fails to set a cursor, it alarms you of so with a failed to set cursor message, so i'm not getting this either. Setting an absurd size of 72 still has the cursor looking beautifully crisp, if we speak of the SVG/PNG stuff.

[JonathanSteininger]

Hyprcursor is meant to give the functionality for better scaling and allow you to basically have any size of cursor.

With the new implementation I am fixed to the same size steps of the xcursor variant. It does set it to the cursor but fails to set the size to the exact size specified.

For testing purposes if you want a cursor size of 100. You could with the previous implementation but not the current one.

I'm not sure if thats a limitation from the fact that it uses png`s when extracting from the xcursor theme. Compared to the svgs it used in the previous implementation where size is disregarded when creating the hl theme with hyprcursor-util.

[JonathanSteininger]

Also @kerichdev . I am not able to see any of the blurring you are referring to with the previous implementation.

However, I think the previouse implementation fails to override the cursor names for each cursor. When comparing the previous to the current. I can see some cursors not being used in the previouse implementation. Like when resizing windows or moving them around.

[JonathanSteininger]

Actually. I can see that when setting cursor sizes below 30 The border of the cursor begins to be less defined and appears blurry.

[kerichdev]

Less than 30 does happen to be a common size. Plus, it's not about the size. It's the fact that the previous cursors would refuse to set if you didn't change the size to something else while setting them.

It's also why you wouldn't see the cursors at all when resizing, for example.

[JonathanSteininger]

Ok. I have done some testing and the issue I was facing would more likely fit into an issue with hyprcursor rather than this theme. When creating a hyprcursor theme with hyprcursor-util and the sources are pngs and the resize_algorithm is set to none then there will be no scaling between the set resolutions from the xcursor theme. you will be fixed to the usual 24, 32, 48, 64.

simply setting --resize bilinear when extracting the theme will let you set any size. But is the cause for the blurry cursor for sizes under 30.

Also. Are you able to reproduce the issue with not being able to change cursor unless its a different size? I cant reproduce it anymore on my machine with the old implementation?

[kerichdev]

With the old implementation? Are you sure you're looking at the correct cursors? Try changing them to a different accent, like blue, without changing the size - does it change?

Specifically, does it show up where hyprcursors are supposed to show up, and not the GTK ones?

[JonathanSteininger]

Yes. Switching between 2 cursor themes from the previous implementation is working for me. catppuccin-mocha-green and catppuccin-mocha-red.

I don't know why it changed.

[JonathanSteininger]

Could it have been fixed with the v0.41.0 release of hyprland with this issue fix being merged?

[kerichdev]

It could be the fix. However, that still leaves us with the blur-ness issues, as well as a question about how exactly a better implementation would look?

[JonathanSteininger]

The issue is that if you need a small cursor the non scaling method would give you a more defined and less blurry cursor. but you would be limited to the 24 pixel size.

But doing this your way in addition with the bilinear scaling method causes large cursors to be really blurry due to it using pngs instead of svgs.

I want to test using a combination of the svg and png's for each cursor and see what happens.

[JonathanSteininger]

I could have just read the documentation. You can not mix pngs and svgs in hyprcursor themes.

So would the only option be to have 2 different build processes? One for small cursors (using the pngs from xcursor) and one for big and uncommon scaling (using the raw svgs)?

I feel like this would be a bandaid fix. This seems like something that can be fixed or improved from hyprcursor rather than having this problem with every theme.

[JonathanSteininger]

Also. The previous implementation is missing all overrides. So many cursors fail to switch to the correct one.

I can fix this if we go for the bandaid both solution.

[JonathanSteininger]

Im gonna open an issue on hyprcursor about this problem.

[JonathanSteininger]

Ok. So I have been messing around with the input svgs and the blurring only occurs when there is a 1 pixel gap between the edge of the svg to the start of the cursor.

This gap is there for the shadow effect the cursors have.

When the svg has no gap to the left it is even sharper than the xorg version in my opinion.

Xcursor (24px):

Hyprcursor without gap (24px):

This is the one I changed to have no gap.

Hyprcursor with gap (24px):

This is the one with the blurriness issue at size 30 or below.

Extra tests that I have done.

I have experimented quite a bit to see the results I will get.

1. Just removing the shadow and keeping the gap kept the blurriness.
2. Changing the scale of the border made it blurry due to often being 1.5px wide
3. Keeping the shadow of the cursor but having the pointer have no gap to the left is not blurry. But you lose the ever so slight amount of shadow on really large cursors.

Results

So with my testing there could be several ways to fix this issue.

1. We could make a version of each svg that has this fix in place that gives a clear result of the final cursor on small scales.

   This would be a time consuming job, But I would be up for it.

2. We make the alt version of the cursor with no gap and shadows that can be used for smaller cursor sizes. This option would work well if in the future multiple svgs could be used for a hyprcursor with size thresholds.

   This would have the benifit of keeping the shadow for large cursor sizes while still having crips cursors on small sizes. I would still need to make alt cursors though.

[kerichdev]

This would be a time consuming job, But I would be up for it.

This raises the question - would anyone else be up for that? Otherwise the package risks being unmaintained at one point.