Announcement

Collapse
No announcement yet.

Fedora Workstation 34 Should Be Very Exciting With GNOME 40, PipeWire Default

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora Workstation 34 Should Be Very Exciting With GNOME 40, PipeWire Default

    Phoronix: Fedora Workstation 34 Should Be Very Exciting With GNOME 40, PipeWire Default

    Fedora 34 due out in April is shaping up to be a very exciting feature release as usual with this Red Hat sponsored Linux distribution continuing to live on the bleeding-edge of the open-source software ecosystem. Fedora Workstation 34 in particular is heavy on updates and new features, led by the GNOME 40 desktop...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    No word on whether Plasma Wayland as default is go or no go for Fedora 34?

    I've been using Plasma Wayland entirely since the 5.21 beta and its been entirely usable, with only a few papercuts

    Comment


    • #3
      im still waiting for xdg-decoration protocol and zwp idle inhibit manager protocol before thinking to move to gnome

      Comment


      • #4
        Originally posted by Aryma View Post
        im still waiting for xdg-decoration protocol and zwp idle inhibit manager protocol before thinking to move to gnome
        I just skimmed the xdg-dec thread you linked - that is some serious stubbornness from gtk/gnome devs, wow. Ultimately detrimental to the Linux desktop and Wayland adoption

        Comment


        • #5
          I'm still very skeptical about PipeWire. I've been testing it on and off in the last weeks. There are still numerous bugs, PulseAudio/ALSA compatibility issues and hardware incompatibilities. It's promising, but it's just too early for a general rollout.

          Comment


          • #6
            Pipewire is a perfect example of how a transition from X.org to Wayland should have happened: all the applications continue to work, the user doesn't notice anything, it's just configuration files that have changed. This is also how Microsoft transitioned from GDI to DirectWrite - all the old applications continue to work, while the new ones are able to get new features.

            Comment


            • #7
              Originally posted by Aryma View Post
              im still waiting for xdg-decoration protocol and zwp idle inhibit manager protocol before thinking to move to gnome
              #217 won't happen. It is not the job of the compositor to draw decorations. libdecoration is the path forward in this new shiny world.

              #20 is part of https://gitlab.gnome.org/GNOME/mutte...e_requests/111 and this is actively worked on right now.

              Comment


              • #8
                Originally posted by Aryma View Post
                im still waiting for xdg-decoration protocol and zwp idle inhibit manager protocol before thinking to move to gnome
                From a user perspective I do not really get why people are so invested in which part of the system is responsible for drawing the window border? You never hear these discussions on Mac or Windows. What is relevant is that the different applications support the system used so they get borders, but other than that I do not get it?

                Comment


                • #9
                  Originally posted by birdie View Post
                  Pipewire is a perfect example of how a transition from X.org to Wayland should have happened: all the applications continue to work, the user doesn't notice anything, it's just configuration files that have changed. This is also how Microsoft transitioned from GDI to DirectWrite - all the old applications continue to work, while the new ones are able to get new features.
                  In what way doesn't legacy applications work on Wayland? There is XWayland for that exact purpose! Ok, XWayland had limitations due to hardware vendors, it also looks bad on multi-dpi setup (but that is a general X issue), but in the general case it works quite well.

                  Comment


                  • #10
                    Originally posted by birdie View Post
                    Pipewire is a perfect example of how a transition from X.org to Wayland should have happened: all the applications continue to work, the user doesn't notice anything
                    Pipewire uses a compatibility layer for its jack and pulse compatibility. Too bad something like this does not exist for Wayland

                    Originally posted by birdie View Post
                    This is also how Microsoft transitioned from GDI to DirectWrite - all the old applications continue to work, while the new ones are able to get new features.
                    The transition was a mess, it took them till Windows 8 Beta to get near perfect compatibility to the old display server back. This new display servers first iteration in Vista was so broken that it was one of the major drivers behind the Vista sucks movement.

                    Comment

                    Working...
                    X