3 ms·

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 wil

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?

m4rtink 3y ago
Well, someone would still have to maintain a huge chunk of X indefinitely for that to work. :P
- flohofwoe 3y ago
  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.
  - bitwize 3y ago
    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.
    - flohofwoe 3y ago
      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).
      - bitwize 3y ago
        libSDL2 exists and is pretty much everywhere, dude.
        flohofwoe 3y ago
        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").
      - vetinari 3y ago
        > 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?
        flohofwoe 3y ago
        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...)
bitwize 3y ago
> 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.
- ehvatum 3y ago
  > 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.
  - eikenberry 3y ago
    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.
creatonez 3y ago
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.html https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...)

m4rtink 3y ago

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

flohofwoe 3y ago
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.
- bitwize 3y ago
  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.
  - flohofwoe 3y ago
    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).
    - bitwize 3y ago
      libSDL2 exists and is pretty much everywhere, dude.
      - flohofwoe 3y ago
        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").
    - vetinari 3y ago
      > 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?
      - flohofwoe 3y ago
        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...)

bitwize 3y ago

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

ehvatum 3y ago
> 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.
- eikenberry 3y ago
  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.

creatonez 3y ago

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.html https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...)