Going all-in on a Wayland future
blogs.kde.org
Well folks, it’s the beginning of a new era: after nearly three decades of KDE desktop environments running on X11, the future KDE Plasma 6.8 release will be Wayland-exclusive! Support for X11 applications will be fully entrusted to Xwayland, and the Plasma X11 session will no longer be included.

cross-posted from: https://lemmy.world/post/39342270

Well folks, it’s the beginning of a new era: after nearly three decades of KDE desktop environments running on X11, the future KDE Plasma 6.8 release will be Wayland-exclusive! Support for X11 applications will be fully entrusted to Xwayland, and the Plasma X11 session will no longer be included.

  • LeFantome@programming.dev
    965·
    1 day ago

    “For most users, this will have no immediate impact. The vast majority of our users are already using the Wayland session”

    So happy to read this as there is always somebody still claiming that “Wayland does not work” and “nobody wants to switch to Wayland” just because they have not.

    Also great to see that the plan is for Wayland on FreeBSD as well so the Open Source desktops can stay aligned. GNOME on FreeBSD is more problematic, not because of Wayland but because of Systemd.

    • golden_zealot@lemmy.mlEnglish
      20·
      1 day ago

      The problem isn’t really with Wayland not working though, it’s with other software not being caught up to work fully with wayland.

      For example, in X, I can have my single screen windows work laptop display to my multi-monitor linux machine with remmina and be able to interact with the laptop as if it had multiple monitors.

      Remmina cannot do this with Wayland as far as I have been able to determine.

      Clearly not the fault of Wayland, but also kind of a pain in the ass that there are issues like this since some other maintainers/devs haven’t implemented what is required in their software yet.

        • flying_sheep@lemmy.ml
          173·
          1 day ago

          It’s understandable on some level: if you’re suddenly no longer part of the majority tribe you know you’ll get fewer bug fixes and so on.

          So bullying and FUDing people into staying with your tribe could pay off.

          What I don’t get is how they don’t realize that they’ve lost. PulseAudio (through PipeWire) is here to stay. Systemd is here to stay. Wayland is here to stay.

          Maybe they just like being contrarian if they can’t win.

          • BunScientist@lemmy.zipEnglish
            63·
            1 day ago

            The main thing is that pipewire is a drop-in replacement because of how it works, wayland isnt

            • Auth@lemmy.worldEnglish
              1·
              3 hours ago

              xwayland makes things a near drop in replacement for wayland and people still complain.

            • flying_sheep@lemmy.ml
              21·
              10 hours ago

              What made you think that that’s a relevant answer?

              I specifically said PULSEAUDIO is here to stay, you know, as opposed to manually managing a trillion ALSA devices.

              Then I mentioned PipeWire to placate the nitpickers who would point out that PulseAudio (the implementation) isn’t actually around anymore, only the device management paradigm.

              And somehow you honed into that word, completely ignored everything around it, and said some stuff that sounds vaguely related to the topic at hand, yet has no actual meaning.

              Why?

              • grue@lemmy.world
                1·
                1 hour ago

                I still have almost no idea what PulseAudio and PipeWire even do, aside from them being two of five(!) different audio-related subsystems that any given sound problem might be related to. (The others being OSS, ALSA, and JACK, which I also don’t understand.)

                • flying_sheep@lemmy.ml
                  1·
                  1 hour ago

                  OK, let’s see if I remember well:

                  OSS is obsolete.

                  ALSA is a basic primitive way to do play audio streams integrated into the kernel.

                  PA is an abstraction on top of ALSA that helps with network stuff, per-application volume control, …

                  JACK is an alternative to ALSA/PA for low latency professional use cases: you can plumb it yourself, connect inputs/outputs, …

                  PW is an efficient implementation of both PA and JACK, which is better than the original PA in latency.