Announcement

Collapse
No announcement yet.

Wayland-Protocols 1.19 Released With Governance Guide, Updated XDG-Shell

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

  • Wayland-Protocols 1.19 Released With Governance Guide, Updated XDG-Shell

    Phoronix: Wayland-Protocols 1.19 Released With Governance Guide, Updated XDG-Shell

    Coming a month after Weston 8.0 and a few weeks after Wayland 1.18 is Wayland-Protocols 1.19 (and subsequently Wayland-Protocols 1.20 over a snafu) as the collection of Wayland protocol specifications...

    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
    Repositioning pop-ups? Isn't that on of the missing important features that has been rejected so far?

    Comment


    • #3
      Originally posted by 144Hz View Post
      R41N3R Stuff needed by GNOME usually gets in. That’s pretty much the only rule.
      Sounds aweful and idiotic

      Comment


      • #4
        R41N3R It is. But, as I once wrote already, there's no Wayland platform out there. Gnome is its own thing, then there's everything else. Fragmentation FTW.

        144Hz Your world has a really, umm, "interesting" dictionary. Because here in the real world, one DE getting preferential treatment is the exact *opposite* if meritocracy.

        Comment


        • #5
          Originally posted by 144Hz View Post
          R41N3R Stuff needed by GNOME usually gets in. That’s pretty much the only rule.
          What do you expect? Wayland devs are under no obligation to bend backwards to accommodate some random dude's obscure compositor written as a hobby project. If you desperately need some additional features for your non-GNOME desktop, the onus is on you to 1. implement them and 2. convince the upstream devs that it's really, really worth it to pollute their codebase by merging them in. And if you can't convince them, it's up to you to fork Wayland and hope that it will fly. That's how FOSS has always worked.

          Comment


          • #6
            What meritocracy?! Then why does the Code of Conduct and Outreachy exist?

            144Hz seriously you disturb me to no end!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

            Comment


            • #7
              144Hz Can you even show me proof of meritocracy on GNOME nowadays?

              (plus why are we talking about GNOME? get back on topic, this is about Wayland in general)

              Comment


              • #8
                Originally posted by tildearrow View Post
                144Hz Can you even show me proof of meritocracy on GNOME nowadays?

                (plus why are we talking about GNOME? get back on topic, this is about Wayland in general)
                Wayland "in general" means mainly GNOME, with KDE as a distant second, and a bunch of more or less experimental projects that hardly anyone uses outside of niche applications (Sway etc.)

                Comment


                • #9
                  Originally posted by tildearrow View Post
                  What meritocracy?! Then why does the Code of Conduct and Outreachy exist?
                  What if an Outreachy psychiatric patient decides to "identify" as having merit? It's up to GNOME to rise up to zer/xih Lived Experience(tm).

                  Comment


                  • #10
                    Originally posted by jacob View Post
                    What do you expect? Wayland devs are under no obligation to bend backwards to accommodate some random dude's obscure compositor written as a hobby project. If you desperately need some additional features for your non-GNOME desktop, the onus is on you to 1. implement them and 2. convince the upstream devs that it's really, really worth it to pollute their codebase by merging them in. And if you can't convince them, it's up to you to fork Wayland and hope that it will fly. That's how FOSS has always worked.
                    Kwin and wlroots are not "some random dude's obscure compositors". They did implement stuff themselves, and said stuff did make it upstream - xdg-decoration and idle-inhibit are in wayland-protocols. But there is a problem, in that the two protocols I just mentioned aren't a requirement but are merely "optional". Making wayland-protocols effectively meaningless.

                    Advocating forks on the window-system level is beyond silly. Such fragmentation doesn't help anyone, it doesn't help application developers - who need to have environment-specific code in their app for each environment they intend to support or limit their app to a single environment, and it doesn't help users - who have a limited number of applications to choose from and can't mix and match applications from different environments.

                    Diversity at the application level is good. But the underlying plumbing needs to be unified to allow interoperability. This exists in the X world thanks to standards like EWMH. This *could* exist in the Wayland world in the form of wayland-protocols, but it doesn't work in practice when protocols necessary for interoperability are "optional".

                    Canoncal was blasted into oblivion for creating Mir instead of making Unity a Wayland compositor. Rightfully so. But here you are, advocating for the same scenario - fragmentation at the windowing-system level.
                    Last edited by Gusar; 02 March 2020, 11:30 AM.

                    Comment

                    Working...
                    X