We spent an enormous amount of time working on bug-fixing and polishing tasks for Plasma 6.1 this week. It was a big release, and there were some rough edges around the new edit mode. So we put qui…
  • theshatterstone54@feddit.uk
    53·
    5 months ago

    The Ocean and Oxygen sound themes now include bell sounds, so our automatic “make the system bell not not make you want to commit homicide” transformer can get its sound from those themes

    Relatable

  • thingsiplay@beehaw.org
    18·
    5 months ago

    I wish the team would just spent an entire year of bug fixing and refining user experience without adding new features or making big changes such as the new desktop edit mode. Don’t get me wrong, this is super exciting too, but for the complex nature of KDE it would be good if they keep a bit of focus after a major release.

      • D_Air1@lemmy.ml
        12·
        5 months ago

        I swear I think of this every time someone mentions kde should just fix bugs. I follow Nate’s blog weekly and try to keep track of any other work that is going on. 90% of any kde release is polishing, bug fixing, and refactoring or outright replacing old code that was causing issues. For some reason, people seem to consider colors changing from blue to red a new feature.

      • thingsiplay@beehaw.org
        1·
        5 months ago

        I guess you meant this as a joke, but for clarification, I meant no big changes such as new desktop edit mode. I wish the team would just focus of bug fixes and enhancements without introducing new elements or changing things up in a big way like this.

        • carzian@lemmy.ml
          17·
          5 months ago

          This isn’t a joke. Often times rewriting features like this will allow the code to be more streamlined and use the latest KDE library features. This is brining new features using modern and more maintable code that solves long standing issues. Fixing the old code sometimes isn’t worth the effort for a variety of reasons (based on unmaintained libraries, the original code might have been written a while ago so it’s had many revisions of fixes that necessarily complicated the code, etc.)

          • thingsiplay@beehaw.org
            1·
            5 months ago

            You misunderstand me. They can write new code and be ready when the bug hunting phase is over. The end user only gets bug fixes. Later they can backport any new feature after the phase.

            • Brickardo@feddit.nl
              4·
              5 months ago

              I don’t think anyone has misunderstood you here. You misunderstood what you wrote in your first comment. The new desktop edit window is not proposing any new functionality that wasn’t there, but showcasing it in a more streamlined fashion. That’s in itself refining the user experience, which is exactly what you wanted.

              • thingsiplay@beehaw.org
                1·
                5 months ago

                I don’t agree with you and explicitly listed it in my first reply as an example of what I consider a big change.

                • Brickardo@feddit.nl
                  3·
                  5 months ago

                  The problem here is that we are dealing in largely imprecise terms. If we instead turn to semantic versioning for inspiring what we’d consider a large change, then Plasma 5 -> 6 is a big change, breaking previous API.

                  The new desktop edit effect is largely irrelevant under this rather precise terminology.

    • krolden@lemmy.ml
      1·
      5 months ago

      It seems like a lot of the new features also fix old bugs by replacing the way they function.

  • mrvictory1@lemmy.world
    17·
    5 months ago

    In KWin’s new (off-by-default) “Hide Cursor” effect, you can now turn off hiding it after inactivity, and only hide it while typing (Vlad Zahorodnii, Plasma 6.2.0. Link)

    Does Plasma Bigscreen still receive updates? This feature would be very useful with it. Arch’s bigscreen package is unfortunately stuck at 5.27