Earlier quoted context omitted.
XDG is the freedesktop group I believe. https://specifications.freedesktop.org/
Yes, i knew that. What is XDG ini?
The format they use. Find and view a *.desktop file, for instance.
Improving cursor rendering on Wayland
71–80 of 134 posts
Re: Improving cursor rendering on Wayland
#72The 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...
Re: Improving cursor rendering on Wayland
#73Surprised 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.
Re: Improving cursor rendering on Wayland
#74The 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?
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.
What else even uses Wayland? Sway?
Re: Improving cursor rendering on Wayland
#75Earlier 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.
What else even uses Wayland? Sway?
Sway, KDE, a handful of other compositors based on wlroots.
Re: Improving cursor rendering on Wayland
#76Surprised 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.
[deleted]
Re: Improving cursor rendering on Wayland
#77The 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?
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.
Re: Improving cursor rendering on Wayland
#78Since the Xcursor format is extensible, why not just define new chunk types for PNG and SVG? Such an approach could provide two-way compatibility.
Re: Improving cursor rendering on Wayland
#79Earlier 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've yet to see a good argument for why it's a bad idea. To me client-side decorations are mostly yet another way that the desktop is turning into a cluttered mess of different UI styles.
Re: Improving cursor rendering on Wayland
#80The 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.