Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point. Why don't they simply accept that some programs will never be ported to native Wayland APIs since Wayland implementations don't offer required features for some types of programs (like universal support for rendering consistent window decorations). With XWayland, X11 is just another client-side window system API, why not simply support that forever and why should it matter for application developers what happens below the X11 API shim? Especially since it is more feature complete and much less hassle than writing code directly against Wayland APIs?

View on HN

You could speculate on the wording, but there is currently no such plan to drop Xwayland in the upstream Xorg project. In fact, one of the maintainers seems to be enthusiastic about continuing to maintain it for a very long time, now that the workload won't be eaten up by xserver (https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...)

> Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point.

Astronaut 2: Always did.

Keeping the jank of X11 around was never long-term viable. One day you will have to either switch to Wayland-capable apps or sandbox whatever last version of Xwayland is out there to keep whatever old app you have going.

> Keeping the jank of X11 around was never long-term viable

Ha, it’s like saying “keeping the jank of win32, directx, GDI was never long-term viable” as your one and only argument for the inevitable success of Windows RT.

Fools, the lot of you GUI hipsters.

But unlike Windows we can go ahead and do this if we want as we control our own systems instead of delegating control to a corporation.

IE. I'll ditch X11 compatibility as soon as is feasible for me and it doesn't really matter if someone else keeps it around. That's on them.

Well, someone would still have to maintain a huge chunk of X indefinitely for that to work. :P

It can't be much more than a thin "translation layer" on top of Wayland similar to how xcb or xlib are two different flavours of the same thing right? The most important feature of XWayland is that it knows how to render the window chrome so that it looks consistent with other apps.

It's basically all of Xorg except the low-level graphics card driver bits. Xorg tracks a lot of state, there is no "thin wrapper" for that chonky protocol.

Ok then I have another grand idea: a system-level libwayland dynamic link library which eases the pain of using the native Wayland APIs.

No stupid code-generated headers, no extension mess, just a plain and simple widget-framework-agnostic C API in a single header and library to create a window with a titlebar and resizing handles (which needs to look the same as other windows on that system, no matter if Gnome, KDE or anything else is used), a hook for receiving input events, programmatic control over window position and size, being able to switch between fullscreen and windowed mode and being able to query the display DPI and refresh rate (that's the super-luxus requirements list which would make that API better than most alternatives including X11).

Basically enough window system glue to create a window for housing a GL or Vulkan context, but nothing more.

If this library existed and would be guaranteed to exist on each and every desktop Linux installation, I would switch in 30 minutes (it shouldn't take longer to port my code over).

TL;DR: I don't care about the technical details on why X11 is better or worse than Wayland. I only know that X11 provides the required features for my use case, but Wayland doesn't (which is mainly: not having to deal with rendering window chrome that's consistent with the rest of the system, and without having to bring a widget framework like Qt or GTK into the mix - which doesn't make sense if all I need is a 3D rendering context spanning the entire window client area).

libSDL2 exists and is pretty much everywhere, dude.

Can SDL2 render proper client side decorations on Wayland by now that look identical with the rest of the system? Last I checked it couldn't because libdecor couldn't. But googling again it looks like libdecor has special GTK support since quite recently, so maybe the problem has actually been solved (I would be surprised though, because nothing else in the Wayland ecosystem seems to "just work").

> Basically enough window system glue to create a window for housing a GL or Vulkan context, but nothing more.

It called Gtk.

To get that on Windows, you link against user32.dll just to be able to call CreateWindowEx (and have no control, what it drags into your process). On macOS, you link against Cocoa.framework to get NSWindow. Why would be Linux any different?

Just because you have transparent low-level access to display server does not mean, that you have to use it and then complain, that higher level constructs are not available. Windows won't allow you to talk directly over ipc to dwn. Neither will Apple.

To display a fully-functioning window decorations, you need widget library (what do you think popup menus are?). So if you want to spend your life creating a library, that proxies to some configured widget library just for decorations, for those who refuse to use the right layer in the stack, be my guest. If you are not willing to do that, why do you expect others to do it for you?

Does GTK give me KDE's window decorations when running on a KDE desktop or does it look "alien"? Does every Linux desktop setup that runs Wayland have GTK libs installed? Last I checked these were the main show stoppers when linking against a specific widget framework on Linux. There's no least common system standard like on Windows or macOS (X11 was that standard, but oh well...)

> Does GTK give me KDE's window decorations when running on a KDE desktop or does it look "alien"?

No. Just like Win32 or Cocoa doesn't draw foreign chrome, neither does Gtk. Apps are free to draw whatever they want, and many do, like Firefox, Chrome or MS Office.

> Does every Linux desktop setup that runs Wayland have GTK libs installed?

I have yet to see any relevant linux distribution, that comes with display server (not just wayland) and doesn't ship with Gtk.

> Last I checked these were the main show stoppers when linking against a specific widget framework on Linux.

These are not show stoppers; they are subjective preferences. They are also demanding something from Linux that they do not demand from other systems.

> There's no least common system standard like on Windows or macOS (X11 was that standard, but oh well...)

It is, you just chose to ignore it (going full circle; it is called Gtk). You are free to ignore it, but it comes with a price. Complaining about the price without putting in an effort to change it according to these subjective preferences won't get anybody too far.

Reply on news.ycombinator.com