Improving cursor rendering on Wayland (opens in new tab)

Use XDG ini.

Or if that’s not the reason, the behaviors of a lot of projects RH birthed or heavily influence make a whole lot more sense if you assume it is and are fairly lacking in explanation otherwise. If it’s not the case, they’ve managed to accidentally do something that’s in their interest, I guess.

GNOME is also the one holdout that doesn't support server-side rendering of window decorations (like the title bar with buttons to close and minimize).

GNOME has pushed back on several wayland protocol extensions that all the other compositors supported.

Gnome are consistently the hold-out, and are the source of much drama and chagrin in Wayland.

macOS cursors are provided by an NSCursor class which can either be one of the standard cursor image or provided through an NSImage object, which supports a number of data types (among the usual pixel-based formats like PNG or JPEG also PDF), it looks like applications can also register their own data formats via a class called NSImageRep.

https://patents.google.com/patent/US5471570A/en

EDIT: The linked patent seems to only cover 1 bit inversion, not full color inversion. I can't find the patent for the full color, but recall reading that a patent stopped the adoption of a nice color inverting cursor for Linux that Windows has had for so long. If Windows has had it for as long as you say, then perhaps any relevant patents have expired?

Screensharing is handled by pipewire [0], changing keyboard layouts aren't defined [1] by wayland, and generally anything Wayland devs think would 'corrupt' their protocol.

They leave most things to the compositor to implement, which leads to significant fragmentation as every compositor implements it differently.

Long gone are the days of xset and xdotool working across nearly every distro due to a common base, now the best you'll get is running a daemon as root to directly access `/dev/uinput` [2] or implementing each compositors accessibility settings (if they have them) as a workaround.

[0] https://superuser.com/questions/1221333/screensharing-under-...

[1] https://unix.stackexchange.com/questions/292868/how-to-custo...

[2] https://github.com/ReimuNotMoe/ydotool

I found one issue (https://github.com/hyprwm/Hyprland/issues/2945) mentioning something similar, but no resolutions as of yet, so not sure what's going on.

Gnome3 doesn't manifest the same issue, so worth checking out if it happens to you if you're curious about moving from Gnome to Hyprland.

I’m not sure we want a turing-complete language as a cursor format. ;)

But I agree that a simpler vector format than the kitchen sink that is SVG would be good.

https://github.com/hyprwm/hyprcursor/blob/main/docs/MAKING_T...

Looking at the full description of the format, it includes the ability to use nested config sections with `{ ... }`, which has some obvious benefits for some use-cases. But for the complexity needed for defining cursors, I don't see the benefit of `.hl` over fdo `.desktop` configs. In fact, it looks like you could parse the hyprcursor `.hl` config files with a `.desktop` parser? Which might be more palatable for cross-desktop support?

This allows the application to customize the cursor, which happens more frequently than you might expect, e.g. dragging and dropping a file changes the "cursor" to include the little preview of the file. So the client already needs to learn how to render cursor images to composite the cursor image on top of the DnD preview.

One of Wayland's original core philosophies is to share behavior by shared library, rather than by protocol, because social agreement is already required, and is way better for a community long-term. So there is also a libwayland-cursor library that allows you to load Xcursors, which allows the client to do all the compositing and customization it needs, while still supporting a standard.

zwp_cursor_shape makes sense for a basic client without too many needs, but it's not a great idea for a full toolkit, otherwise DnD dragging (or any other case that requires compositing cursor images) will show a different cursor.

Also, SVG for cursors is not really a great idea.

Of course, because this is Wayland, one good idea suffers due to coexisting with other independently good ideas. The minds behind Wayland didn't want the protocol to ossify like X11 did, so they made extensions essential. If a given functionality doesn't need to be core, it's an extension.

Both great ideas in isolation, yet now, as a result, Wayland has trapped its ecosystem in a half-assed state of completeness. The one saving grace is that, unlike X11, things will actually improve over time as the gaps get filled in and older applications age out of the ecosystem.

  s/SVG/a vector format/

For one, "network first" for a GUI is not a sane model, and that is only more and more true as more "compute" is pushed onto the GPU.

Basically, in the "old Wayland way", the Wayland compositor gave the client a surface and said "hey, draw something into this and I'll make it your cursor" and then the compositor well, composited it, using either true hardware cursor or an overlay layer of some kind. If the app froze, the cursor would still move, it just might not be updated. This seems clean architecturally but turns out to suck because now every client needs some kind of cursor drawing library in it, hopefully the same one everyone else is using so that cursor theming works and you don't get a different default mouse cursor in every app.

So then Wayland introduced wp_cursor_shape, which is where the client instead says "hey, draw a 'standard pointer' cursor over me please." But, the "old" client-drawn way is still supported and used, for example in GTK apps.

This proposal seems to just be a really complicated recommendation to change the file format used behind wp_cursor_shape, and a plea for "old" apps to either adopt this format/library or stop using client rendering. I think that switching to wp_cursor_shape pretty much Makes Sense for most apps, but the article didn't really sell me on this file format.