Hacker News Reader

Comment by cycloptic | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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

Sure but that's not any different if your application depended on some other GNOME or KDE specific API. If KDE decides an API is KDE only and GNOME doesn't want to make their own implementation then there's not much that you could ever do about that. The point with using a toolkit is that it's an abstraction layer that handles the differences between window systems and implementations for you. It would be better if you mentioned the specific reason why your app is breaking because that would likely be a bug in the toolkit.

Except now the whole X server is part of a GNOME-specific or KDE-specific API.

The bug is "Wayland makes it so programs don't reliably run anymore because they are no longer guaranteed to work with all window managers and desktop environments." It's an architectural flaw.

Not really, shared functionality there is in the core wayland protocol and in the standard set of wayland extensions, or in some other standard dbus interface. (generic ones usually go in the org.freedesktop namespace) If you depend on GNOME-specific or KDE-specific APIs then yes, you would have to deal with those being unsupported outside. Not much has changed there.

sigh In one ear, out the other.

Reply on news.ycombinator.com