KDE Usability & Productivity: Week 85

Usability & Productivity 3 Minutes

I’m not dead yet! KDE’s new goal proposals have been announced, and the voting has started. But in the meantime, the Usability & Productivity initiative continues, and we’re onto week 85! We’ve got some nice stuff, so have a look:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

Published by Nate

Published

36 thoughts on “KDE Usability & Productivity: Week 85”

    1. Hi Nate, thank you for the great work that you are doing! The KDE Usability & Productivity has been a great and very successful initiative and its definitely one of the major factors that made me stick with the KDE ecosystem.
      I am verry happy to see that there is some work being done also with the energy page as I am primarily using an ultrabook nowadays.
      Do you think it would make sense if also timestamps are being included on the horizontal axis of the chart showing the battery percentage? I think this might make the chart mich more easy to read if there are some anomalies in the chart. E.g. if there is a big drop in battery percentage and the user would like to investigate what has caused this, it would be much easier to know when exactly that happened if the time is displayed on the chart as well.

      Thank you again for the amazing work! I am really looking forward to see whats coming next for KDE 🙂

      Like

    5. > Vote invite were sent to everyone subscribed to the KDE community mailing list and everyone with a developer account. Any contributor who didn’t receive one please subscribe to the mailing list to not miss future announcements and send me a quick email (lydia@kde.org) and I’ll send you a vote invite.

      Quote by Lydia Pintscher

      Like

    2. Are you completely crazy to say something like this?

      Go somewhere else with your petty trolling and annoy us no more.
      —
      p.s.: Design is pretty great and I love the details provided.

      Like

    3. Well, I shouldn’t reply a troll just spitting at years of some people’s work but…. You definitely didn’t read those weekly reports carefully. There were tons of stuff being fixed / improved related to essential parts of the KDE ecosystem. (baloo, kwin, usb, samba, memory leaks/efficiency, startup time, cameras/phones support…)

      It fixed tons of issues I had and I cannot thank enough everyone involved.

      Like

  5. Great work, as always! I don’t comment often, but I read your posts every week 🙂

    Here’s hoping the Text for Everyone goal gets some votes — as a Japanese learner, it was pretty hard to get fcitx working properly: I think I hit almost all flaws described in the proposal …

    One minor nitpick: when seeing the screenshot of the “Capacity degradation” change, I was unsure if your battery had 21% capacity left (but then the wording “degradation” doesn’t make so much sense) or if it has 79% capacity left (but this is confusing to me — a reversal from the earlier behavior and what all other platforms I know of do).

    I read the linked discussion afterwards, so I now know it is the latter 🙂 I just wanted to mention that to this end user, it was unclear without reading the discussion first.

    Like

    Reply

    1. Addendum: I think the reason I was confused is because the battery indicator itself displays “percentage of charge left”, so 5% would mean you need to plug in your computer in quickly. On the other hand, if the “capacity degradation” would be 5%, that is a good thing, not a bad thing. This feels inconsistent somehow …

      Like

    2. Yeah, the new text doesn’t seem to be as clarifying as I was hoping. 😦 The old text was “Capacity: 79%” which I found super confusing, but I guess we still need to do better. Someone on Reddit suggested “Battery capacity has degraded by 21%” which might be better. What do you think?

      Like

  6. >>Kate’s advanced search-and-replace regular expression match feature now includes a regex builder helper
    That’s a wellcome addition but design needs to be improved. Current text aligning to right looks really bad.

    Like

    Reply

  9. Nice work as always Nate & KDE Community in general.

    As always with every new Plasma new version incoming, looks terrific. The work with batteries is much appreciated, even that i don’t like laptops that much, but of course, the improvement is obvious.

    Such a shame that Usability & Productivity initiative is close to the end, but of course it has been really fun, marvelous & really interesting. I really hope to keep following you at the near future, even when the initiative is finished, but that of course is in a way, a really good thing, it means you succeed in what you pretended, which was and still is improving usability & productivity in Plasma and KDE Software in general and of course, i really thank you for all the time you’ve been worked at it, for all you guys achieved and of course, for what it’ll come at the future. The ball has started to roll, and i hope it doesn’t stop never, this is a great cause.

    Without anything more to add, as always, all i can do is again, thank you very much to Nate and all people who make this possible, but specially to you, who lead this initiative and showed the progress weekly to us, all the loyal followers you’ve been gaining over the time for you great work.

    Receive a huge hug everyone mentioned above, as always ^^.

    Like

    Reply

    1. You’re very welcome! And don’t worry, the work will generally continue. 🙂 There’s a lot of great stuff in the pipeline!

      Like

  10. I have to say, the Usability and Productivity goal really made the difference when I transitioned from Mint. I tried KDE back in June 2018 when the initiative was young, but a few very annoying bugs and the inability to manage my phone through my computer via MTP made me stick to Mint. One year later, and the difference was huge. I use KDE Neon now simply because new versions of Plasma software are always that much more reliable and better than the old ones and I always want to stay up to date (but I like having a stable base too, and most 3rd party software apps tend to prioritize not breaking under Ubuntu LTS, so Neon is perfect for me at the moment).

    I do have one question though, when I plug in a USB headset, that sound output shows up in my sound settings and I can switch to/from it at will. It even shows up in the first page of “Audio Volume” settings. So far so good.

    However, when I plug an HDMI cable I don’t see anything happening. I have to go all the way to the advanced page and select HDMI as an output option for “Built In Analog Stereo”. However, when I unplug it, I have to go all the way to the advanced menu and switch it back. When I used Linux Mint, it treated HDMI as an alternative sound sink, just like the USB headset. Is there any reason why HDMI is handled differently than a USB headset in this case? I don’t want to file a bug for an intended behavior, but if it is intended, why is plugging/unplugging an HDMI cable so much more complicated than a USB headset?

    Liked by 1 person

    Reply

    1. I had a similar experience as a former Mint user. I briefly switched from a Mac in 2012, but got dissatisfied with Mint and looked for alternatives. I tried KDE but discounted it almost immediately because it seemed buggy and ugly. What a difference a few years makes though!

      The whole multiple sinks vs multiple outputs on a sink distinction is a minor irritation of mine as well, but for me it works: when a new output on the same sink is attached, audio switches over to it automatically. I think what you’re experiencing is a bug, so can you please file it on plasma-pa at https://bugs.kde.org? Thanks!

      Note that until this is fixed, you don’t actually have to go to the advanced page. You can click on the hamburger button in the Audio Volume system tray pop-up and it will let you select which output of that audio device you want to play audio. HDMI should show up in the list while the cable is connected (or at least, it’s supposed to).

      Like

    2. Oh! I see what you mean! When I plug in headphones, the item appears on the “hamburger icon” menu. However, it doesn’t work for me when I plug in an HDMI cable. If it’s supposed to work like that, it would definitely be good enough for me (I might actually prefer that behavior against how the usb headset works). At least I know it’s a bug; I’ll file it.

      As for hopping, my DE-hopping saga went something like

      Mint Cinnamon (2013) -> Unity (2014, due to better UEFI support from stock Ubuntu for a newer laptop)
      Unity -> Gnome (2018 due to Ubuntu killing Unity)
      Gnome (2018) -> Budgie (Hated Gnome, heard good things about Budgie)
      XFCE (2018) Installed on an old laptop hanging around for a project
      Budgie (2018) -> KDE (2018, Budgie was still not mature)
      KDE (2018) -> Mint (KDE had a couple of bugs, MTP connection annoyed me, Mint UI improved a lot)
      Mint (2019) -> KDE Neon (Much more reliable now)

      I think the things I like most about KDE (other than that it’s now stable, beautiful end even.. lightweight? I didn’t even think “debloating” ever happened but it did here) is that the team seems really responsive now, and there’s focus. Not only this, I feel like KDE it is one of the few mature DEs that are not tied to Gnome in some way; this allows KDE devs to not waste tons of time and energy trying to work around the types of unwanted upstream changes Gnome seems to be making with startling regularity. I don’t know if Mint-Cinnamon or Budgie devs would even have enough time to switch to Wayland before 2025 with all the other work they have to do by simply un-breaking upstream Gnome changes.

      Like

    3. Does the HDMI item instead appear as a separate sink, then? If so, then the fact that the audio doesn’t immediately switch to that is a different bug, but one we’re actively working on. Even before that gets done, a patch I recently submitted might help you: https://phabricator.kde.org/D23389

      Like

  11. Hey Nate,

    Can you announce ahead of time when the blog series will end?

    All good things will come to an end but the blog series was a fun read, so it may be worth to know when it will be gone/unavailable, before that happens (since I am very likely to miss that; too much multitasking going on here for me to not get confused about things happening).

    Like

    Reply

  12. Hi Nate ! Any idea if someone is aware of performance-related issues with NVIDIA ? I usually have a perfectly smooth desktop (& games), since the recent NVIDIA related fixes, however, I noticed scrolling in Firefox was OK but clearly not “butter smooth”. I have a 144Hz screen and modified the kwinrc accordingly.

    I compared with Cinnamon/Muffin (and also Gnome/Mutter) and for some reason, in this area, the FF scrolling is absolutely perfectly butter smooth. (mouse wheel / keys).

    In all cases I did force the HW accel in FF and use the same proprietary drivers and no NVIDIA related tweak.

    Cheers !

    Like

    Reply

    1. I’m not aware that 144hz support is something that’s officially supported, nor am I aware of anyone actively working on it. However that can change quickly. 🙂

      Like

    2. Hmm, actually, the smoothness issue doesn’t affect kwin nor games etc. but only FF & some specific apps I guess. Maybe that’s Breeze gtk related ?

      I’m not sure it’s 144 Hz related either. There always was a lack of smoothness when it came to FF scrolling. But I was surprised to see it was absolutely butter smooth under Mutter/Muffin in 144 Hz…

      Hmmm.. 🙂

      Like

    4. How of curiosity, I built “kwin-lowlatency” and wow, even Firefox is now absolutely butter smooth ! And it DOES pass vsynctester.com 🙂

      Like

    5. Yeah, there are a couple of KWin forks or patchsets out there that implement long-standing feature requests like this, or shadows on GTK3 windows on X11.

      The biggest reason why they haven’t been integrated yet is because their implementation makes future related work impossible or unmaintainable, or impairs other use cases, or isn’t Wayland-compatible.

      I know it’s super annoying seeing these issues in KWin that other people have fixed already. But one thing I’ve learned about KWin development is that it’s very important for things to be implemented and fixed in the most technically correct manner, or else it causes huge problems down the road.

      If you have an open channel to the lowlatency patch developers, you could gently encourage them to submit the code upstream to KWin itself.

      Liked by 1 person

Leave a comment