Hacker News Reader

Comment by cycloptic | Hacker News Reader

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.

View on HN

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