3 ms·

There isn't much difference there, but it would be more of an uphill battle if you tried to put everything different that Wayland does into X extensions. That s

There isn't much difference there, but it would be more of an uphill battle if you tried to put everything different that Wayland does into X extensions. That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding. Clients like term, xpdf, and xfig should work fine in XWayland. Window managers won't work without getting ported, but someone has been working on a port of Openbox: https://github.com/johanmalm/labwc https://github.com/johanmalm/labwc

jude- 6y ago
> That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding. Yes, agreed! But why is it _more_ risky to do that than to throw the whole X server concept away and start from scratch? Rewriting such a widely-used piece of infrastructure from the ground up is a super-risky proposition.
- cycloptic 6y ago
  That's mostly a misconception, Wayland implementations don't need to start from scratch. Weston and wlroots are minimal from-scratch implementations, but GNOME and KDE for example do their implementations by re-using most of the code from their X compositor.
  - jude- 6y ago
    Great! So instead of having one standard way to do video/input multiplexing, we have at least four -- GNOME's, KDE's, wlroots, and weston (and probably a smattering of others). If I want to write a program that works with "Wayland," I'm either going to have to test them on all of the widely-used compositors (because of course they're not all going to behave exactly the same way), or I'm going to have to just punt on them. The former option is 4x the work, and the latter option is me telling users "Hey everone, remember that program that used to run everywhere in every window manager ever that you all know and love and depend on to do your jobs? Well, now it only works on GNOME, since that's all the time I have to support it. Good luck non-GNOME users!" EDIT: Before you say "just use a toolkit, it'll take care of everything," I can already tell you that users don't care. They only care that the app that used to work in KDE no longer works in KDE. They're not going to complain to Qt or Kwin; they're going to complain to the app author. So the app author becomes responsible for the additional burden of testing their software in a bunch of different compositors, for zero gain.
    - cycloptic 6y ago
      Is that any different from normal? In my experience, if you're shipping a product on a Linux-based desktop, usually you target a specific set of distributions, i.e. the default configuration of the last few LTS versions of RHEL or Ubuntu or whatever, which at least for those examples all happen to be GNOME based. Customers who come with some weird hacked-up distribution would be on their own for support anyway, they can try it but there's no guarantee it will work. If KDE (or something else) really is doing something different here then you would have had to extend the same amount of effort as you did previously.
      - jude- 6y ago
        Before, a graphical program would run just fine under GNOME or KDE because it wasn't GNOME or KDE handling the video/input multiplexing facilities. But now with Wayland, a graphical program not only needs to target distros, but specific configurations of those distros (i.e. Debian/GNOME, OpenSUSE/KDE, etc.). This isn't helping fragmentation.
        cycloptic 6y ago
        That's only if you're using functionality specific to the DE, which is handled mostly the same as it is under X. GNOME and KDE for example tend to provide their functionality as dbus services. If you just have a simple app that needs no special privileges or features then that will work just the same. If you use GTK or Qt, the transition will be mostly seamless and would only be a problem if you were circumventing that and calling Xlib or xcb directly.
        jude- 6y ago
        No, this happens if the particular Wayland compositor you're running the program on happens to implement a Wayland protocol or extension you use in a "unique" way that causes your app to break. This wan't a problem with X.org because all distros used the same X.org (or, if they used an older X.org, and if that led to breakage, the solution for users was always the same: upgrade X.org). I already explained above why "just use a popular toolkit" isn't a viable solution. Users do not care whose fault it is; all they care about is that your app used to work in KDE and now it doesn't in GNOME (the problem is even worse in Wayland than I'm letting on, because with Wayland, the DE controls the compositor and renderer -- there are so many more ways for the DE-specific code to interfere with the graphical program than there was with X.org).

jude- 6y ago

> That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding. Yes, agreed! But why is it _more_ risky to do that than to throw the whole X server concept away and start from scratch? Rewriting such a widely-used piece of infrastructure from the ground up is a super-risky proposition.

cycloptic 6y ago
That's mostly a misconception, Wayland implementations don't need to start from scratch. Weston and wlroots are minimal from-scratch implementations, but GNOME and KDE for example do their implementations by re-using most of the code from their X compositor.
- jude- 6y ago
  Great! So instead of having one standard way to do video/input multiplexing, we have at least four -- GNOME's, KDE's, wlroots, and weston (and probably a smattering of others). If I want to write a program that works with "Wayland," I'm either going to have to test them on all of the widely-used compositors (because of course they're not all going to behave exactly the same way), or I'm going to have to just punt on them. The former option is 4x the work, and the latter option is me telling users "Hey everone, remember that program that used to run everywhere in every window manager ever that you all know and love and depend on to do your jobs? Well, now it only works on GNOME, since that's all the time I have to support it. Good luck non-GNOME users!" EDIT: Before you say "just use a toolkit, it'll take care of everything," I can already tell you that users don't care. They only care that the app that used to work in KDE no longer works in KDE. They're not going to complain to Qt or Kwin; they're going to complain to the app author. So the app author becomes responsible for the additional burden of testing their software in a bunch of different compositors, for zero gain.
  - cycloptic 6y ago
    Is that any different from normal? In my experience, if you're shipping a product on a Linux-based desktop, usually you target a specific set of distributions, i.e. the default configuration of the last few LTS versions of RHEL or Ubuntu or whatever, which at least for those examples all happen to be GNOME based. Customers who come with some weird hacked-up distribution would be on their own for support anyway, they can try it but there's no guarantee it will work. If KDE (or something else) really is doing something different here then you would have had to extend the same amount of effort as you did previously.
    - jude- 6y ago
      Before, a graphical program would run just fine under GNOME or KDE because it wasn't GNOME or KDE handling the video/input multiplexing facilities. But now with Wayland, a graphical program not only needs to target distros, but specific configurations of those distros (i.e. Debian/GNOME, OpenSUSE/KDE, etc.). This isn't helping fragmentation.
      - cycloptic 6y ago
        That's only if you're using functionality specific to the DE, which is handled mostly the same as it is under X. GNOME and KDE for example tend to provide their functionality as dbus services. If you just have a simple app that needs no special privileges or features then that will work just the same. If you use GTK or Qt, the transition will be mostly seamless and would only be a problem if you were circumventing that and calling Xlib or xcb directly.
        jude- 6y ago
        No, this happens if the particular Wayland compositor you're running the program on happens to implement a Wayland protocol or extension you use in a "unique" way that causes your app to break. This wan't a problem with X.org because all distros used the same X.org (or, if they used an older X.org, and if that led to breakage, the solution for users was always the same: upgrade X.org). I already explained above why "just use a popular toolkit" isn't a viable solution. Users do not care whose fault it is; all they care about is that your app used to work in KDE and now it doesn't in GNOME (the problem is even worse in Wayland than I'm letting on, because with Wayland, the DE controls the compositor and renderer -- there are so many more ways for the DE-specific code to interfere with the graphical program than there was with X.org).