This post is in part a response to an aspect of Nate’s post “Does Wayland really break everything?“, but also my reflection on discussing Wayland protocol additions, a unique pleasure that I have been involved with for the past months.

Before I start I want to make a few things clear: The Linux desktop will be moving to Wayland – this is a fact at this point (and has been for a while), sticking to X11 makes no sense for future projects.

By switching to Wayland compositors, we are already forcing a lot of porting work onto toolkit developers and application developers. This is annoying, but just work that has to be done. It becomes frustrating though if Wayland provides toolkits with absolutely no way to reach their goal in any reasonable way.

Many missing bits or altered behavior are just papercuts, but those add up. And if users will have a worse experience, this will translate to more support work, or people not wanting to use the software on the respective platform.

What’s missing?

  1. Window positioning
  2. Window position restoration
  3. Window icons
  4. Limited window abilities requiring specialized protocols
  5. Automated GUI testing / accessibility / automation

I spent probably way too much time looking into how to get applications cross-platform and running on Linux, often talking to vendors (FLOSS and proprietary) as well. Wayland limitations aren’t the biggest issue by far, but they do start to come come up now, especially in the scientific space with Ubuntu having switched to Wayland by default. For application authors there is often no way to address these issues.

    • @[email protected]
      link
      fedilink
      011 months ago

      @atzanteol guy at sh.itjust.works can’t get shit to work :)

      jk

      at the same time, besides maybe rendering my screen 0.0000001ms faster than X, i can’t tell you anything it does in any way better or different than X
      puts pictures + words on screen, yay