Some suggestions for improving adoption of this:

1. Don't have a dependency on hyprlang. Other projects will probably be averse to that. Use a more common configuration language, using a common library.

2. Have a shim layer so that hyprcursor cursors can be used by applications that use the XCursor API (maybe have a drop in replacement library for libxcursor that delegates to hyprcursor).

3. Have a specification so other implementations can use the cursor format as well, in case other compositors/clients don't like your implementation for some reason.

really not a fan of using the hyprland format for configuration. If this is supposed to be widely adapted, untying it from hyprland is necessary.

The article essentially says--whether this is a good idea or not--that GTK is the one hold-out, which I wasn't really expecting as a punchline; why is GTK not implementing this?

How are cursors stored and drawn on let's say macOS? Honest question, comparing with X is easy but not exactly state of the art.

Is displaying a few hundred KB of data on the screen really enough of a "problem" that it warrants putting image libs and potentially other dependencies in the middle of something as basic as cursor rendering?

Instead of SVG, I wonder if not the ideal format would be Haiku's Vector Icon Format (HVIF) [1][2]. It has binary files that are much smaller and it too supports multiple levels of detail for different sizes.

I heard somewhere that Haiku would use it for its own cursors, but my google searches for getting that verified have not been fruitful.

[1]: https://www.haiku-os.org/news/2006-11-06_icon_facts/

[2]: https://www.haiku-os.org/articles/2006-11-13_why_haiku_vecto...

I want a color-inverting cursor for Wayland. MS windows has it for 30 years.

Surprised that Wayland would go the route of entirely deferring to the client for cursor rendering instead of providing a default implementation and exposing an api which client can use to assume control.

"Well lol just draw a png haha

Well, no, it's not that simple.

Rasters are annoying. Raster means an image is stored with pixels, for example a png, or an mp4. The problem with rasters is that when you resize them, the computer has to take a wild guess at what it should look like."

The problem with any display this software is going to run on is that it is also made with pixels. GTK foundation tried this approach for years, putting all their eggs into this basket, and recently having a reckoning and admitting this approach has not been working. Pixels are here to stay.

I've been experimenting with using Hyprland (a Wayland WM) on my laptop, and ironically Qt apps have been the ones that misbehave the most. Everything seems happy to use my preferred icon theme, but when hovering over a Qt app, the sizing greatly changes. I've mostly just gotten used to it (plus I never really got their overall theming correct) but I might have to try this out and see if it fixes my issues.

Since the Xcursor format is extensible, why not just define new chunk types for PNG and SVG? Such an approach could provide two-way compatibility.

The thing I like about the Xcursor image format is that it so extremely simple[0]. Every semi-competent developer should be able to implement a parser/writer for the format in under an hour.

But encoding the images with PNG does make sense, given the wide availability of libpng and the potential file size savings. I don't know how the feel about SVG support. One the one hand using vector graphics for cursors seems like a great idea but SVG is a very complex format, with the only real parser available being librsvg, which massively increases toolchain complexity. Too bad PostScript doesn't support transparency.

[0]:https://www.x.org/releases/X11R7.7/doc/man/man3/Xcursor.3.xh...

What is this config.hl file format?

At first, I thought it’s hlc [0], but I couldn’t find confirmation in the git repo either.

[0]: https://www.linode.com/docs/guides/introduction-to-hcl/

> In the beginning of wayland, and in the core design spec, it's the client's job to draw the cursor. I mean, it kind of makes sense, as some apps might want to draw a custom cursor (e.g. games)

Wait what. That's even more insane than client-side decorations.

Makes total sense to make cursors SVG, kind of crazy that nobody has done this b4 and that it's that outdated. Then yet again, handling SVG takes a lot more than some uncompressed images. So my question is how many resources, ram ... does it actually take to make some 200kb SVG as a cursor compared to some old uncompressed picture that might be bigger, but it's simply put on the screen 1:1. I guess it COULD be just about the unit process but if it's full SVG support than cursors can now be animated and be calculating all kinds of shit inside the SVG.

Xcursor doesn't predate PNG. Heck, it came alongside a tool, xcursorgen, that could be used to process pngs and generate the binary cursor files. Xcursor appeared somewhere around 2002-2003 as an extension of Xrender. Before that X had monochrome cursors.

There are some legacy X specifics in the theme format that would necessitate something more modern. IIRC, Xrender used a hash of hard-coded X pixmaps to find the cursor files to match. That's why some of the filenames are a long string of hex digits. The rest are predefined X cursor names.

Why are all these problems? Wasn't this solved already years ago in another software, I mean, Xorg? Why do we need to revisit the problem again?

> A max 96x96 Bibata cursor, a single cursor, is about 2MB.

Umm this does not pass smell test.. 96x96x4=36864 bytes of raw pixel data. How does that become 2MB?!

> instead of being a caveman and making symlinks all over the place

And what's wrong with that?

Uh, if gtk apps draw the cursor client side, what happens if such an app freezes?

xorg and it's problems is so funny

1968: Mother of all demos presents mouse

1980: Personal Computers with mouse become popular, apple Lisa, Microsoft Windows 1

2000: Touch devices with stylus are popular

2007: Apple releases Iphone with finger touch

2015: Conversational interfaces like Alexa, Siri start becoming available.

2022: ChatGPT presents a huge tech improvement in conversational interfaces.

2024: "Actually let's rebuild this technology from the 80s from the bottom up. That's what we need"

I do not regret moving away from open source/free software.