3 ms·

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

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