Title

  • lloram239@feddit.de
    link
    fedilink
    arrow-up
    13
    arrow-down
    3
    ·
    10 months ago

    The issue isn’t just that the features had to be reimplemented, but that they were not part of Wayland to begin with. Wayland does only do the most basic stuff and leaves everything else to the compositor (aka Gnome or KDE). That means every compositor will implement their own hacky version of the missing functionality and it takes ages until that gets unified again, so that apps can actually use that functionality.

    Wayland is a classic case of an underspecified software project, they do a thing and they might even do it well, but what they are doing is only a fraction of what is actually needed for it to work properly in the real world. That’s why we are 15 years later and the new “simpler” Wayland is still not ready.

    • deluxeparrot@thelemmy.club
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      Wayland does only do the most basic stuff and leaves everything else to the compositor (aka Gnome or KDE). That means every compositor will implement their own hacky version of the missing functionality and it takes ages until that gets unified again, so that apps can actually use that functionality.

      Would this functionality be mostly the same? Could they get together to make a shared libcompositor that implements the bulk of the functionality? Or is it so tied to specifics of the desktop environment that there’s little commonality. In which case, Wayland not doing it would be the right call.

      • ReakDuck@lemmy.ml
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        10 months ago

        I think wlroots is the standardized thing. Many WMs use it but desktops need to switch over to it afaik. I think KDE talked about doing this for plasma.

        I am unsure what wlroots really is and maybe its not a libcompositor you were talking about but similar.