• Possibly linux
    link
    fedilink
    English
    arrow-up
    28
    arrow-down
    17
    ·
    2 months ago

    I personally think it is a very bad idea to “speed run development” of protocols. This will only lead to broken designs which will then cause each desktop top do things differently.

    Wayland protocol development is slow and heavily debated in order to make sure everyone is happy implementing them. You want all desktop to use the same spec and this could lead to additional desktop specific protocols which would totally break compatibility.

    In short, this is a really bad idea and should be rejected by everyone

    • 𝘋𝘪𝘳𝘬@lemmy.ml
      link
      fedilink
      arrow-up
      48
      ·
      2 months ago

      I personally think it is a very bad idea to “speed run development” of protocols.

      Stalling the development of protocols for nearly a decade is bad, too.

      They should talk and meet somewhere between “Just develop in production!” and “I personally dislike it for non-technical reasons, so I will block it for everyone!”

      • olympicyes@lemmy.world
        link
        fedilink
        English
        arrow-up
        10
        arrow-down
        1
        ·
        2 months ago

        Wayland development is crazy. The features it needs to include are those that Mac OS and Windows support. The debate should be around implementation, not the necessity. I’m still on Xorg in 2024 because of idiosyncrasies in Wayland that I don’t want to deal with, particularly regarding HiDPI and screen sharing. I personally wish Wayland were developed by the Pipewire team. Maybe something would get done.

      • Possibly linux
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        4
        ·
        2 months ago

        The problem is that you could end up with protocols that certain desktops don’t want to implement.

        • chameleon@fedia.io
          link
          fedilink
          arrow-up
          13
          ·
          2 months ago

          That already happens constantly and I’d consider this the consequence of it, rather than the cause. You can only issue so many vetoes before people no longer want to deal with you and would rather move on.

          The recent week of Wayland news (including the proposal from a few hours ago to restate NACK policies) is starting to feel like the final attempt to right things before a hard fork of Wayland. I’ve been following wayland-protocols/devel/etc from the outside for a year or two and the vibes have been trending that way for a while.

          • Possibly linux
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            2 months ago

            No one will use a fork of Wayland. That would be suicide. The Wayland project will continue no matter what other things people are working on. I can see a separate project forming but it strongly doubt it will have any traction.

            If you recall back to the days of the yearly internet people said the same thing about TCP/IP

    • skulkingaround@sh.itjust.works
      link
      fedilink
      arrow-up
      26
      ·
      edit-2
      2 months ago

      I’ve been waiting for HDR and color management for like 5 years now and it feels like progress is dead in the water and now we’ve ended up with two custom implementations between KDE and gamescope. Heck, Kodi has supported HDR for ages when running direct to FB.

      I know it’s tricky but geez, by the time they release an actual protocol extension we’ll already have half a dozen implementations that will have to be retooled to the standard, or worse yet we’ll have a standard plus a bunch of fiddly incompatible implementations.

      • Possibly linux
        link
        fedilink
        English
        arrow-up
        4
        ·
        2 months ago

        HDR is a little more standardized as there was a meeting sponsored by Red hat to work it out

        Eventually gnome will get support and maybe some others after that

        • GoodEye8@lemm.ee
          link
          fedilink
          English
          arrow-up
          6
          arrow-down
          1
          ·
          2 months ago

          So another 5 years? IMO HDR is the perfect example why protocol development needs to be sped up. HDR is roughly a decade old at this point and (if we exclude custom implementations) we’re still in the process of working it out.

    • winterayars@sh.itjust.works
      link
      fedilink
      arrow-up
      23
      arrow-down
      1
      ·
      2 months ago

      That depends on how you speed it up. For example, the Covid vaccines were “accelerated” compared to normal vaccines but they did that by spending additional money to run the steps of the process in parallel. Normally they don’t do that because if one of the steps fail they have to go back and those parallel processes are wasted. For the Covid vaccines, the financial waste was deemed worth it to get the speed up of parallelization.

    • Mactan@lemmy.ml
      link
      fedilink
      arrow-up
      9
      ·
      edit-2
      2 months ago

      I personally think it is a very bad idea to “speed run development” of protocols. This will only lead to broken designs which will then cause each desktop top do things differently.

      and thus we have slow development which has resulted in absent designs, which has caused each desktop to do things differently to fill the gaps