One day, Wayland will truly take over the Linux world, but it's not quite there yet with plenty still using X11 due to various problems some of which the new Frog Protocols aim to solve.
  • visor841@lemmy.worldEnglish
    16·
    22 hours ago

    I think “speed up Wayland development” isn’t quite right, tho it will probably feel that way to end user. It’s about getting experimental protocols into the hands of users in a formalized manner while the stable protocol is still being forged. This already exists in certain forms e.g. HDR support being added before the protocol is finalized, but having a more formalized system is probably pretty helpful for interoperability, e.g. apps having to work with different DE’s.

    My biggest is concern is whether there’s a possibility this will actually slow down Wayland development by pulling attention away from the stable Wayland protocols in favor of Frog Protocols. But hopefully the quicker real world usage of the new protocols will bring more benefits than the potential downside.

  • Leaflet@lemmy.worldEnglish
    6·
    20 hours ago

    I doubt this will have much of an effect. Compositors already implement protocols that aren’t in upstream yet.

    All this really is is putting some of those protocols in a GitHub repo and giving them a nice name. Gamescope will naturally implement them because frog works on gamescope. KDE might implement a few. Gnome and wlroots probably won’t implement them because (1) Gnome prefers a more lean set of protocols and likely won’t adopt a protocol until it’s “finished” and (2) Simon Ser, the wlroots main maintainer, is very involved with upstream protocols and would rather see development happen there.

  • electricprism@lemmy.mlEnglish
    2·
    17 hours ago

    Due to Wayland naming schema I’m having trouble decoding this title.

    So Wayland, a protocol, is needing the addition of other protocols?

    Is this like how we call Linux and Linux distros both Linux?

    Does this make it a Wayland Distro?

    • Chewy@discuss.tchncs.deOPEnglish
      5·
      15 hours ago

      tl;dr
      Read the first sentence after each citation ;D

      So Wayland, a protocol, is needing the addition of other protocols?

      Yes. What we know as Wayland is the Wayland core protocol and a few other protocols that are absolutely necessary for desktop use (stable).

      Then there is staging, which is not necessarily implemented by all compositors, e.g. fractional scaling.

      Unstable also exists, which is even easier to get a protocol into (idk the exact requirements, likely the amount of support and explicit dislike by contributors).
      These are often only used by a subset of compositors with e.g. XDG decoration allowing compositors to announce to clients (windows) that they support server side decorations (top bar with close/minimize/maximize buttons). This isn’t implemented by Gnome, but most other desktops support it.

      Different desktops also have their own protocols, which are published so that apps targeting those desktops can implement them. Some are also supported by other desktops, if they think they are suitable for them.
      E.g. wlr layer shell makes status bars possible, which are used by basic compositors like Sway or Wayfire. KDE also supports it, even though it was originally created by wlroots.

      Does this make it a Wayland Distro?

      In a way you could say that a compositor is a Wayland distro, as it implements a subset of Wayland protocols.

      In the end this is good, because it allows for rapid development and discontinuation of protocols. E.g. if a better protocol comes around, both protocols can be supported at the discretion of every compositor.

      The goal was to solve the problem of X11, where Xorg still has to support drawing UI by itself, even though no program or toolkit uses it anymore (the 80s were very different). The Wayland core is so minimal there shouldn’t be any issue with using it for a very long time.

      Also, Wayland was developed by people with the goal to use it in automotive and other industry applications, where basic desktop functionalities, like multiple windows or session lock, aren’t useful.

  • just_another_person@lemmy.worldEnglish
    2·
    21 hours ago

    Gaming development iterates and moves a lot faster than general desktop integration development, so this makes sense. Honestly the slowness is just because all the projects involved need more people and bandwidth at the QA and approval levels. There’s a YON of activity in the projects downstream, but everything is backed up in reviews. I’m kind of glad a Valve adjacent project is pushing this, otherwise there would be a lot of fragmentation to do this in various other ways. The downside of course is getting developers in certain studios to actually work through this instead of just going for Windows support.