As pointed out in This Week in GNOME, there’s been some continued work on Variable Rate Refresh for the GNOME desktop. The VRR setting within GNOME Settings continues to be iterated on as the developers iron out how they’d like to present the Variable Rate Refresh setting for users. The developers have been discussing how to best present the option as to avoid confusion as well as how it makes the most technical sense as far as the option goes.

Edit: “Variable Refresh Rate - Roadmap” - https://gitlab.gnome.org/GNOME/mutter/-/issues/3125

  • aport@programming.dev
    link
    fedilink
    arrow-up
    7
    arrow-down
    13
    ·
    10 months ago

    I find GNOME’s “must be perfect” approach to accepting new code counterintuitive.

    One of the largest benefits of having a clean architecture is increased velocity and extensibility. What’s the point in nitpicking over perfection when it takes literally years to merge a feature, arguably one considered basic and essential by today’s standards?

    KDE is on the other side of this pendulum, integrating everything and resulting in a disjointed, buggy disaster.

    Where’s the middle way? It used to be XFCE. What is it now?

    • TheGrandNagus@lemmy.world
      link
      fedilink
      arrow-up
      15
      arrow-down
      1
      ·
      edit-2
      10 months ago

      I definitely get what you mean, and sometimes agree, but tbh I’m glad Gnome is an option for those who want a DE that is uncompromisingly UX-focused and straight up won’t accept changes until they’re damn sure it’ll be production-ready.

      And while they’ve been relatively slow in getting adaptive refresh working, they’ve been very quick with some other things. Idk why it took them this long to sort out the cursor occasionally becoming out of sync with displayed content’s refresh rate, but there must be a reason for it.

      Gnome was at the forefront with Wayland, PulseAudio, they’ve been the biggest pusher of Portals, pretty much all of their GTK4 apps have been designed to also be compatible with mobile devices. Accessibility features on Gnome are also pretty great for a Linux DE.

      As a general rule, I’d say their development process works well, despite there being the occasional holdup.

      And while Plasma obviously isn’t nearly as bug-free as Gnome, it’s come a long way since the Plasma 4/early Plasma 5 days. I still don’t feel I can depend on it the same as I could for Gnome or Cinnamon (compositor crashes bringing down all open apps is a big issue in particular - and is finally due to be fixed in Plasma 6), but don’t underestimate their progress — since like 5.15/5.16 they’ve improved leaps and bounds.

      And with 6 it looks like they’ve learned from the mistakes of 4 and 5’s launches.

    • KarnaOP
      link
      fedilink
      arrow-up
      12
      arrow-down
      2
      ·
      10 months ago

      Quality control is important for a project that is going to be supported for long time, and used by many. Slow but steady is a right approach for open source project, IMO.