KDE Usability & Productivity: Week 83

This week in KDE’s Usability & Productivity initiative is massive, and I want to start by announcing a big feature: GTK3 apps with client-side decorations and headerbars using the Breeze GTK theme now respect the active KDE color scheme!

Pretty cool, huh!? This feature was written by Carson Black, our new Breeze GTK theme maintainer, and will be available in Plasma 5.17. Thanks Carson!

As you can see, the Gedit window still doesn’t display shadows–at least not on X11. shadows are displayed on Wayland, but on X11 it’s a tricky problem to solve. However I will say that that anything’s possible!

Beyond that, it’s also been a humongously enormous week for a plethora of other things too:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

If you’re getting the sense that KDE’s momentum is accelerating, you’re right. More and more new people are appearing all the time, and I am constantly blown away by their passion and technical abilities. We are truly blessed by… you! This couldn’t happen without the KDE community–both our contributors for making this warp factor 9 level of progress possible, and our users for providing feedback, encouragement, and being the very reason for the project to exist. And of course, the overlap between the two allows for good channels of communication to make sure we’re on the right track.

Many of those users will go on to become contributors, just like I did once. In fact, 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.

62 thoughts on “KDE Usability & Productivity: Week 83

  1. Awesome work as always! The vertical panel Kickoff layout bug annoyed me for so long, I’m so happy it’s fixed! Thanks, Nate and all the people who work on KDE.

    Like

    1. Many thanks for fixing that bug! After logging in it’s one of those things I do first – correcting the appearance by selecting one of those tabs. 😉
      By the way, disabling selecting a tab on mouse over (a behavior you can configure – you have to click instead) doesn’t work at initial state too (but only the first mouse over event). Is that automagically fixed too now?

      There is one more similar problem (i.e. wrong initial state of a preinstalled widget) regarding the “default digital clock with calendar popup” and having some holidays activated:
      Sometimes (unfortunately not reproducible) opening it the first time you can see all the days of the current month highlighted. It’s the same highlighting effect you can see on mouse over. When you close the popup and open it again, all the days are not highlighted anymore – the correct state. Is this one a known bug? I couldn’t find any report yet…

      Like

  2. HA! You are watching Baby Wogue’s channel and removing his ammo to complain on KDE ;D. If someone can convert him (???) to Plasma-fanboy(?) it’s you Nate :D.

    As to the bell icon I have mixed feelings. On one side it’s a good decision, on other, the icon itself feels obsolete and ugly. I would rather see some icon resembling message/mail. It would be more coherent with the overall style. Or maybe redesigned bell icon? Anyway, this is a start and probably will be improved later on.

    Discover finally starts to look decent and not so off anymore with the all recent changes.

    GTK color implementation – a big deal! Just awesome! Although I wonder, how will it play out with gtk theming that is built-in in Plasma? Or maybe you plan to get rid of it for native integration solutions?

    On the note of colors, I came to some idea about titlebars. Currently, only Breeze Aurorae theme supports coloring via color settings. Breeze Aurorae is good but Breezmite is probably the second in popularity but it’s static. Maybe I or someone else could use Breeze code to convert it to Breezmite so it could have all Breeze abilities? I would call it Breezmite Colors, or Breezmite Dynamic or something like that. Imagine Breezmite titlebar changing colors with the color theme. This combined with latte color windows can give great effects. Besides, we need updated aurorae themes. Too many of them are stuck in the old paradigm and is not flexible. Breeze themes have so many new features that they start to stand out (positively) or rather the rest of the themes seems to feel obsolete.

    Anyway, I just wonder if I can figure out how aurorae theme works and create a new one based on breeze one? Or if someone else will do it first, I will be glad as well.

    Like

    1. Where is Breeze Aurorae theme located? It’s not in the folder with other aurorae themes? The directory structure of KDE needs to be cleaned up and ordered in a logical way, currently, this is a mess.

      Like

    2. I disagree with a message/mail like icon for notifications, simply because notifications cover way more events than just receiving a message, and it would look just odd. The bell is event agnostic and fits the concept of notifications quite well. As for the actual design of the bell icon, I don’t have an opinion, looks ok, but I don’t mind a redesign.

      Like

    3. To be honest it’s not my favorite bell icon either. But the nice thing about monochrome icons is that they’re easy to change!

      Like

    4. Yeah, these days the industry standard icon for notifications is a bell, so I think it makes to err on the side of familiarity and common iconography.

      Like

  3. Wow! Plasma 5.17 is gonna be awesome!

    However, personally I’m not quiet satisfied with the current scroll bar appearance. To me it rather looks like a misplaced line hanging over list items. 🙂
    Maybe the margin to the right border could be smaller and probably a classical frame or a small 1 px line to separate the list view items from the scroll bar would do no harm.
    In this case the blue selection highlighting would not go beyond the scroll bar respectively behind it, but would stop at a few pixels to its left. Just ideas! 😉

    Like

    1. Please compare the margins of Kickoff and the System Settings list views. They are quiet different and not uniform.

      Like

    2. Konsole’s like KickOff’s. Plus Dolphin’s scrollbars and GTK’s, so it sums up to at least 4 different styles.
      (I should register to edit my posts instead of creating new ones … and to give likes 😛 )

      Like

    3. I agree with you. The overlay-style scrollbar trend is one that I think is probably going to end up disappearing on the desktop, because it’s really not advantageous at all and it introduced a lot of layout and display problems. Check out undefined reference to https://phabricator.kde.org/T9126.

      Personally I want regular old full-size scrollbars with a visually separated track. I think the old-style scrollbars from Plasma 5.0 – like 5.7 were great.

      Like

  4. Any chance the color schemes will ever work with flatpak (without changes to GTK itself, which obv will never happen)?

    Seems like too many things are just “becoming impossible” with the advent of Wayland and containerization/bundling, and yet neither of things have (after nearly a decade) have brought any measurable benefit to users.

    Like

    1. Funny you should ask. 🙂 See https://phabricator.kde.org/D18416 and https://phabricator.kde.org/D22894.

      Ultimately that’s the goal, but to get there, we need to first split the effects so that only the ones that really are about appearance live there, and the other behavioral and internal effects will live elsewhere. Otherwise it wouldn’t be accurate to have effects that radically change the behavior of the system (as opposed to just the appearance) living there.

      Like

    2. In these 2 phabricator threads discussion is about graphical vs desktop. Would it make sense to call them visual effects?

      Like

    3. yeah, this is what i meant. after split. i just proposed another term that you guys seemed to be arguing about.

      Like

  5. 1. I guess zwp_linux_dmabuf won’t work on Nvidia/EGLStreams?

    2. What’s the best place to track the Gitlab transition? Anything newsworthy to share?

    Like

    1. 1. Don’t know, sorry. I had to have the KWin developers explain this frature to me in baby terms to even have a prayer of a chance of understanding it. 🙂

      2. There’s no public place at the moment. IIRC the goal is to do the transition by or a little bit after Akademy, which is next month.

      Like

  6. Plenty off cool things, good work people.
    Breeze-GTK still doesn’t allow removing circle around the close button, like it does in native QT, so there’s a lack of uniformity.

    Like

    1. Yeah, I’d agree. In fact, I think it’s something linux needs in general. The only PIM that seems to work somewhat reliably right now is Evolution, which is what I’m stuck on at the moment. I work 2 jobs in data science and still contribute to my grad school research group; this means I have 3 Gmail and 1 Outlook accounts to manage, all with calendars that I need to keep organized somehow. However, even Evolution has problems, just not as many as the rest of them. I think this is a pretty badly needed niche to fill in terms of linux productivity software.

      Like

  7. I like a lot of these improvements, kudos! 🙂

    But I don’t like the fact that the unread indicator on the notification bell is now gone! I get that it might stress out *some* people, but Plasma is all about options, so can’t you at least provide an optional setting to show the unread indicator once again? That way, everybody’s happy.

    Like

    1. You truly never find out how many people like something until you remove it. 🙂 We can consider making it optional.

      Like

  8. Nice work, as always!

    I just wanted to share something I was thinking about … will it ever be possible to have non-Qt (GTK, Wine) application icons hiding in the system tray panel instead of always being visible on the panel?

    Like

    1. Mmh, no, it isn’t, and apparently it was just something I didn’t know about the Plasma tray; I discovered that i can also hide GTK and non QT apps if i go into “System tray settings” and manually change the visibility of each icon manually to “hidden”; However, if I leave it set to “automatic” practically no application moves to the tray panel, and remain visible on the bar; Based on which choice the application icons are automatically hidden in the bar panel, time? Usage? With Kde’s ones, it happens almost every time automagically…

      Like

    2. “Automatic” requires that the app itself notify the system tray when it needs to be shown and when it needs to be hidden. So presumably the bugs here are the fault of those apps.

      Like

  9. More and more simple changes in order to justify your programmation skills but you’r still arrogant to recognize the high ram and cpu usage on your desktop environment with an estimated ram usage of 1-1.5 GB on iddle state.

    Qt libraries are a cancer.

    Like

    1. You need to learn to type in English first before spewing out nonsense like this. Have you tried GNOME? It’s much worse than what KDE Plasma did now and there is no sign they’ll fix it anytime soon.

      Like

    2. Cumulation of small changes is really what people expect. It makes the DE flexible and it feels better and better in details. Nate is open-minded. Did you even file bug reports to complain? He doesn”t act arrogant while you do and your attitude is a cancer.

      Like

    3. Really? I have about 600 MB of RAM used in idle state, and that’s with two cloud-syncing apps running in the background. I have no idea what kind of stuff you’re running at idle to bring RAM usage to that level. Still, 1-1.5 GB is pretty much one browser window these days, and as a distro-hopper, the only things I’ve seen using less ram are LXDE, XFCE, and maybe MATE (Gnome, Cinnamon, and Unity were all more RAM intensive than KDE as of 2018)

      If you are going to complain about Qt libraries, complain about disk space not RAM usage; this is what people actually complain about. Installing a Qt app in a Gtk environment requires tons of dependencies. However, this is only for the first Qt app. Each successive one takes less additional space; because Qt is highly integrated and these libraries are all re-used. You pretty much need all or none of it (Flatpak is way worse, installing the system to get the first app will set you back 6 GB of space!!!). Since all KDE apps are Qt, putting them all in doesn’t take much disk space at all, because with Qt, you get massive economics of scale.

      As for arrogance, KDE has broken a lot of things in the past, chasing features and ignoring bugs, but guess what? So has Gnome. The overall best track record I’ve seen for projects that listen to users is Linux Mint. However, the amount of work KDE has put into actually listening to people and delivering what people want over the last couple of years is amazing. The advantages KDE has over Mint/Cinnamon is simply that KDE is not dependent on Gnome and doesn’t have to work to fix all the things that Gnome still routinely breaks or removes. So while I still love Mint/Cinnamon, the progress made over the last two years by KDE has finally konverted me.

      Like

  10. I want to translate Fuzzy Clock to Japanese. I found out that I can translate the files in /usr/share/plasma/plasmoids/… but I figured that I’d rather make a pull request, but I don’t know where I can clone the repository or where to submit pull requests to.

    Can anyone please guide me?

    Thanks 😀

    Like

  11. Another blog post, another great week for the KDE Community and KDE Software.

    I won’t be enjoying the improvements for Kate anymore, cause i moved to Vim, but i love to see them same way.

    Plasma improving (we need more Wayland improvements, please). The new notification system (yesss) improves too.

    Big thanks as always to everyone who make all this possible, KDE Community and Nate especially, for allowing us to follow the development of the magnificent KDE Software this close and in this transparent way.

    A huge hug to everyone mentioned above ^^.

    Like

Leave a comment