Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving cursor rendering on Wayland

blog.vaxry.net

Post reply on HN
Print view View original

91–100 of 134 posts

Re: Improving cursor rendering on Wayland

#91

Post by aquova »

thayne wrote: post #45

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 o…

It should be noted that the author is the creator of hyprland/hyprlang, so perhaps not too surprising that they made it a dependency, although I do agree with you.

Re: Improving cursor rendering on Wayland

#92

Post by Someone »

redder23 wrote: post #90

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 a…

> Makes total sense to make cursors SVG

  s/SVG/a vector format/
I would think hard before supporting full SVG, as it opens a can of worms. https://www.w3.org/TR/SVG11/script.html#ScriptElement: “A ‘script’ element is equivalent to the ‘script’ element in HTML and thus is the place for scripts (e.g., ECMAScript)”

Re: Improving cursor rendering on Wayland

#93

Post by jorvi »

DaSHacka wrote: post #81
open592 wrote: post #73

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.

Wayland provides little by design, so this is quite typical. For example: 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…

I believe the Wayland spec writers / devs themselves have admitted that due to how strenuous working on X ended up being for them, they erred too much on the cautious side and underscoped Wayland.

Re: Improving cursor rendering on Wayland

#95

Post by johnny22 »

matheusmoreira wrote: post #60
vundercind wrote: post #22

Earlier quoted context omitted.

Gnome and Wayland (among other things) are the way they are, in part, to make running anything other than a standard-package-selection Red Hat unappealing to folks who might pay for Linux (enterprise). It’s good for them if their stuff’s a bit broken if you use other distros, or configs/software they don’t want to support, and if they cause integration pain and extra work for other distros. Or if that’s not the reaso…

So why don't people just stop caring what gnome thinks? Can't they just standardize the stuff regardless of gnome "holding out" on them or whatever it is they're doing? Do they need their permission or something? Just leave gnome behind. Doesn't really matter whether they catch up or not.

gnome folks are on the committees just like everybody else is. They don't have veto power in that way over the accepted standards, only in what they implement.

Re: Improving cursor rendering on Wayland

#96

Post by lpribis »

blueflow wrote: post #84
nine_k wrote: post #71

Earlier quoted context omitted.

The format they use. Find and view a *.desktop file, for instance.

*.desktop files are at most ini-like, they have a different specification that does not mention "INI" at all. What did formerly_proven refer to when saying "XDG ini"?

"INI" is not a specification. All INI parsers are slightly different, such that people refer to any file with

    [Section]
    Key = Value
Format as "INI" or INI-like, including the xdg format.

Re: Improving cursor rendering on Wayland

#97

Post by animatethrow »

Eduard wrote: post #94

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

For many years the XOR sprite cursor was patented, but the patent seems to have expired in 2013. One of us should make the request to the GNOME/KDE/Wayland/DE people and link the expired patent:

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?

Re: Improving cursor rendering on Wayland

#98

Post by iforgotpassword »

jorvi wrote: post #93
DaSHacka wrote: post #81

Earlier quoted context omitted.

Wayland provides little by design, so this is quite typical. For example: 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…

I believe the Wayland spec writers / devs themselves have admitted that due to how strenuous working on X ended up being for them, they erred too much on the cautious side and underscoped Wayland.

A form of second system syndrome, swing the pendulum too much in the opposite direction. Someone called the Wayland devs "shell shocked X devs".

Re: Improving cursor rendering on Wayland

#99

Post by iforgotpassword »

layer8 wrote: post #80
sp1rit wrote: post #72

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 li…

> PostScript 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.

Makes me think of the haiku icon format.

Re: Improving cursor rendering on Wayland

#100

Post by thayne »

vetinari wrote: post #77
thayne wrote: post #44

Earlier quoted context omitted.

That isn't really surprising to anyone who has been following how GNOME approaches wayland. 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.

They did that for a reason. Rendering decorations server-side is a really bad idea. Just because X11 did it is not a reason to repeat the mistake. If other compositors want to do it, they have their optional extension for that. Eventually, they will find out why they shouldn't do it. With mandatory extension, there would be no way back, with optional, there is.

I'm not opposed to having mechanism to opt in to client side decoration, but making it mandatory is problematic for several reasons:

1. Different apps will draw decorations differently, leading to a lot inconsistency. 2. It means apps designed for other environments that don't draw their own decorations won't have any decorations. 3. If your client doesn't use one of the big all encomposing gui toolkits (not every app needs that), then it has to implement the decorations itself, which is non-trivial to do correctly (I know because I have worked on it for such an app). 4. You can't reliably configure the appearance and behavior of the decorations in a central place for all applications.

Fuethermore, if clients always draw their own decorations, then if you use a tiling wm and don't want decorations at all, you are stuck with them.

Post reply on HN