https://bugs.kde.org/show_bug.cgi?id=434877
--- Comment #51 from Mark <mark...@gmail.com> --- (In reply to neobrain from comment #50) > (In reply to Nate Graham from comment #44) > > We know this is an issue; that's > > why it's open and in the CONFIRMED state. Further criticisms don't help > > anything. if you want to help, try to fix it. > > Thanks for acknowledging the issues. I think by making the new system > monitor the default while it still has such tremendous regressions compared > to the old one, it's easy to think that the gravity the change had on some > users was not anticipated. > > > Nobody wants to spend their (often free!) time reading [...] their product > > being insulted. > > I love the optics of the new system monitor. Do you personally consider the > new one a suitable replacement of the old one in the near future, though? > > I can get behind the "the old one wasn't maintained" reasoning, and I'm > really happy y'all have already resolved many of the ~10 bug reports I > raised about the new one (as constructively as I could). Meanwhile since > you're asking for empathy towards maintainers, is it difficult to conversely > see that users would be unhappy to see such massive usability downgrades in > everyday tooling? > > Wouldn't it save a lot of energy for all of us if we let these things bake a > little bit further instead of over-eagerly changing defaults? I've had the > same sentiment for the QML rewrite of the KCM modules, where the end result > turned out to be a great improvement in the long run but the initial > roll-outs had been very bumpy. That is a rational way to think but not how most open source is developed in general. And, frankly, for good reasons too. Open source is volunteer free own time dev work which very often is a dev passionate about something and building it. That passion is a lot harder to keep up when your feature works but it's not performing well. It's the good old 80-20 rule. They can do 80% of the work (the new feature) in 20% of the time and are happy about it. The remaining 20% takes 80% of the time and is fine tuning it to a point where it works well and stable. It's this 20% where open source very often falls short. I get it! I have that "bad habit" too. Usually in releases though this is being caught by people who test or by people who are very picky about new changes. I'm guessing plasma-systemmonitor went through without that. That is still fine too! But given that this very bur report is from early 2021 it should've been obvious that replacing KSysGuard with plasma-systemmonitor was not the best decision and that the default should've been ksysguard where plasma-systemmonitor would be available too. > > > Anyhow, the offer stands. If a return of KSysGuard is acceptable then I'm > > willing to put in the time and effort to get that done. > It is not a long term solution, I know that. It's an intermediary fix till > plasma-systemmonitor is in good shape again. > > I'd also really appreciate if this proposal could be nodded off. I do want > to see the new applet return one day, or perhaps shipped side-by-side (as I > think it already was at least on my distribution). I'd encourage the side-by-side approach too. With ksysguard being the default! -- You are receiving this mail because: You are watching all bug changes.
