This week in KDE: Offline updates are now optional

I have good news for those of you who are upset by KDE Neon moving to offline updates by default: we’ve made a GUI setting to turn it off (there was already a CLI setting). I get that the nerdy tech crowd is not super thrilled by this new more Windows 10-style update mode. But though you might find it annoying, it really does improve your system’s stability. I can point to literally hundreds of bug reports about problems caused entirely by not rebooting the computer after installing updates. However, in KDE we want you to be in control, so starting in Plasma 5.22, you’ll be able to enable or disable offline updates to suit your preference. This work was done by Aleix Pol Gonzalez:

And yeah, all these update-related options live in System Settings, not in Discover itself

Other New Features

The Global Menu widget now includes a Search field that you can use to quickly locate menu items! (Jan Blackquill, Plasma 5.22)

Discover has gained the ability to update distros using rpm-ostree, such as Fedora Silverblue and Fedora Kinoite (Mariam Fahmy, Plasma 5.22)

In the Plasma Wayland session, screen-casting will now enter “Do Not Disturb” mode by default (though this can be overridden, if desired) (Kai Uwe Broulik, Plasma 5.22)

You can now set screens’ overscan values in the Plasma Wayland session (Xaver Hugl, Plasma 5.22)

Bugfixes & Performance Improvements

Hugely improved Gwenview’s speed, responsiveness, and memory usage when loading and navigating large grid views, particularly for files located on network locations (Arjen Hiemstra, Gwenview 20.08)

Entering your password in the Networks applet no longer causes the networks list to re-arrange itself while you’re typing and sometimes send your password to the wrong network! This has been a problem for quite a while, and we tried various targeted fixes that never fully worked; this time we went for the nuclear option that should finally solve it once and for all! (Jan Grulich, Plasma 5.21.5)

The new Plasma System Monitor app no longer crashes when you select a new display style for any of the sensors (Arjen Hiemstra, Plasma 5.21.5)

Sending files to Bluetooth devices from Dolphin now works again (Egor Ignatov, Plasma 5.21.5)

Discover once again displays firmware updates for eligible devices (Aleix Pol Gonzalez, Plasma 5.21.5)

It is now possible to specify a usergroup for OpenConnect VPNs (Aaron Barany, Plasma 5.21.5)

Long names in System Settings’ Users page no longer overflow (Jan Blackquill, Plasma 5.21.5)

Fixed one of the ways that KWin can crash when using a multi-GPU system (Xaver Hugl, Plasma 5.22)

In the Plasma Wayland session, KWin no longer sometimes crashes when showing Task Manager thumbnails or ending a screen recording/streaming session (Alois Wohlschlager, Plasma 5.22)

Accented and dead keys now work in the Plasma Wayland session when the virtual keyboard is available (Aleix Pol Gonzalez, Plasma 5.22 with Qt 5.15.3 plus KDE’s backported patches)

The Present Windows effect now works in the Plasma Wayland session when activated from grouped Task Manager entries (David Redondo, Plasma 5.22)

The new S.M.A.R.T. monitoring system no longer erroneously warns you that VirtualBox disks are broken when they’re not, or tracks the status for devices without S.M.A.R.T. support at all (Harald Sitter, Plasma 5.22)

When using the new Systemd startup feature, processes that crash at logout or login can no longer either block re-login, or fail to get started at login in circumstances under which they would otherwise launch normally (David Edmundson, Plasma 5.22)

System Settings no longer sometimes crashes when navigating from one QtQuick-based page to another (Jan Blackquill, Frameworks 5.82)

List Items throughout QtQuick-based KDE software no longer exhibit excessive left padding for their icons (me: Nate Graham, Frameworks 5.82)

User Interface Improvements

Digital signatures in Okular are no longer drawn with scary red text (Albert Astals Cid, Okular 21.04)

When dragging a document in Okular using the mouse, the cursor now wraps around horizontally when you reach the edge of the screen, just like it already does vertically (David Hurka, Okular 21.08)

On systems with slow PackageKit implementations (such as openSUSE-based distros), Discover now presents the initial view a bit more accurately while metadata is still being loaded (Aleix Pol Gonzalez, Plasma 5.22)

In the new Plasma System Monitor app, any page with a search field now focuses that search field by default when the page is loaded, so you can always start typing right away to search (David Redondo, Plasma 5.22)

The Bluetooth applet’s section separator now visually matches that of the Networks applet (me: Nate Graham, Plasma 5.22):

Web Presence

Pablo Marcos re-did Okular’s website to be nice and modern, with the help of Carl Schwan:

…And everything else

Keep in mind that this blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactoring, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org/, where you can find blog posts by other KDE contributors detailing the work they’re doing.

How You Can Help

Have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

This week in KDE: Activities on Wayland

This week the Wayland train continued barreling on, full speed ahead! We picked up a bunch of nice fixes and a big feature:

New Features

The “Activities” feature now mostly works on Wayland! There are a few remaining things to implement to make it 100% comparable to the X11 version, but that should get done in time for the next Major Plasma release (Kevin Ottens, Plasma 5.22)

Sticky Note widgets now have an option to change the font size (Shantanu Tushar, Plasma 5.22):

Bugfixes & Performance Improvements

Zooming in and out in Okular now works correctly when using the “Trim Margins” feature (Gerd Wachsmuth, Okular 21.04)

Media9 PDF movie annotations can once again be played in Okular (Albert Astals Cid, Okular 21.04)

When using Okular’s “Invert Luma/Lightness” setting, the loading page now retains its correct color (David Hurka, Okular 21.04)

Ark can now un-archive zip files with Windows-style backslashes used as path separators (João Silva, Ark 21.08)

Fixed a bug in the Breeze application style that could manifest as a big ugly black square appearing in KMail (Fabian Vogt, Plasma 5.18.8)

Fixed one way that Plasma could crash right after login (John Zimmermann, Plasma 5.21.4)

The Plasma Wayland session will no longer crash if you plug in an external screen while in a non-GUI session (e.g. a virtual terminal) (Jan Blackquill, Plasma 5.21.4)

The Bluetooth applet’s tooltip no longer displays the wrong name of the currently connected device. I originally fixed this 9 months ago in Plasma 5.19.1 but somehow the fix was never merged into Plasma 5.20, so it got broken again. That has now been corrected (me: Nate Graham with help from James John, Plasma 5.21.4)

Ultra-wide screens with a 21:9 aspect ratio are now displayed as “21:9” in System Settings’ Display Configuration page, rather than “64:27” (lol) (Felipe Kinoshita, Plasma 5.21.4)

Fixed one way that KWin could crash with certain low-power embedded GPUs (Vlad Zahorodnii, Plasma 5.21.5)

Maximized GTK app windows are no longer positioned too high in the Plasma Wayland session (Vlad Zahorodnii, Plasma 5.21.5)

Discover’s ability to show you an app’s dependencies now works again (Aleix Pol Gonzalez, Plasma 5.21.5)

Disconnecting a screen in the Plasma Wayland session no longer causes all Qt apps to crash (Vlad Zahorodnii, Plasma 5.22)

Global shortcuts are now working even on non-US keyboard layouts (Andrey Butirsky, Plasma 5.22 in conjunction with a Qt version that has this pending patch integrated)

Plasma no longer lags or hangs when displaying a massive number of tooltips for grouped Task Manager tasks (Aleksei Nikiforov, Plasma 5.22)

The kglobalaccel5 daemon can no longer block re-login by crashing on the previous log-out and then getting stuck (David Edmundson, Plasma 5.22 or Frameworks 5.82; whichever one you get first)

When using a multi-screen setup, the lock screen no longer only displays typed text on the text field of the left-most screen, even if you clicked on the text field on a different screen (Aleix Pol Gonzalez, Plasma 5.22)

The Task Manager’s “Highlight windows when hovering over tasks” feature now works in the Plasma Wayland session (David Redondo, Plasma 5.22)

Kate and other KTextEditor-based apps no longer crash if you delete an open file on disk and choose the “Close file, discarding contents” option in the warning message that appears in the app (Christoph Cullmann, Frameworks 5.82)

Fixed a rare case where Kate and other KTextEditor-based apps could crash when dragging text (Waqar Ahmed, Frameworks 5.82)

Context Menus for text fields inside Kirigami overlay sheets are no longer displayed below the sheet content (Noah Davis, Frameworks 5.82)

In Kate and other KTextEditor-based apps, the code completion pop-up no longer sometimes take up the whole screen width (Waqar Ahmed, Frameworks 5.82)

Text in Plasma tab buttons (such as in the new Kickoff menu) now gets elided when there’s not enough space, rather than overflowing (David Edmundson, Frameworks 5.82)

User Interface Improvements

Konsole’s “Edit Profile” window now displays errors inline, rather than using an ugly modal dialog window (Ahmad Samir, Konsole 21.04):

Okular’s “Continuous” mode is now considered to be a document-specific setting (like the zoom settings are), rather than a global setting (Mahmoud Khalil, Okular 21.08)

Items in the System Settings KWin Scripts now use the “pending deletion” pattern used in many other pages, whereby deleting an item only marks as it as in a “pending deletion” state and it only actually gets deleted when you click the “Apply” button (Alexander Lohnau, Plasma 5.22)

System Tray applets now receive keyboard focus when opened, so they can be interacted with using the keyboard (Eugene Popov, Plasma 5.22)

Hover buttons in the Clipboard System Tray applet’s list items are now top-aligned for tall ones, so that the trash button doesn’t shift around according to height, which makes it easy to click on that button repeatedly to manually prune your history list (me: Nate Graham, Plasma 5.22):

Discover no longer shows a huge weird rapidly-disappearing tooltip while loading the Updates page if the cursor is over any part of it (me: Nate Graham, Plasma 5.22)

The tooltip for the window decoration button used to keep a window above all others now makes its purpose more clear (me: Nate Graham, Plasma 5.22):

The previously somewhat confusing “Keyboard Indicator” applet has been renamed and given a UI overhaul to clarify what it is and what it does (Andrey Butirsky and me: Nate Graham, Plasma 5.22):

The Task Manager tooltip now visually indicates when it’s scrollable by displaying a visible scrollbar (me: Nate Graham, Plasma 5.22)

When using the systemwide double-click mode, it’s now possible to disable “click a selected file’s label to rename it” feature for desktop icons, just as it is in Dolphin (me: Nate Graham, Plasma 5.22)

Discover’s view of an app’s dependencies has received a visual overhaul and now also shows you the exact name of the package for the app in question and also groups the dependencies by installation status (Aleix Pol Gonzalez and me: Nate Graham, Plasma 5.22):

Looks like this will install all of GNOME; guess I don’t wanna do that

All the grid view pages in System Settings now sort items case-insensitively (me: Nate Graham and Alexander Lohnau, Plasma 5.22)

Plasma list items now have left and right margins that are consistent with their top and bottom margins (Noah Davis, Frameworks 5.82)

Various message dialogs throughout KDE software no longer display pointless tooltips saying, “Yes” and “No” when you hover your cursor over buttons whose own text may already be “Yes” and “No”! (me: Nate Graham, Frameworks 5.82)

Web Presence

Check out Niccolò’s video about how to set up a development environment and submit a merge request. Very handy for audiovisual learners!

…Read that as “dev env” not “ded end” lol

…And everything else

Keep in mind that this blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactoring, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org/, where you can find blog posts by other KDE contributors detailing the work they’re doing.

How You Can Help

Have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

How I learned to stop worrying and love the hamburger menu

Yesterday we introduced KHamburgerMenu to the world, and I wanted to talk a bit more about it, because I think it’s a very exciting UI control in ways that may not be immediately obvious.

But first some background: a few years ago I wrote a big long post criticizing GNOME-style headerbars, and one of my complaints was that adopting them requires the replacement of traditional menu bars with hamburger menus. You know, this little thing:

Because the button’s icon looks like a hamburger, gedit? I’ll show myself out now

Specifically, here are the problems I see with GNOME’s hamburger menus:

  • They are mandatory with the headerbar design because there is no place to put a traditional in-window menu bar.
  • To condense the entire app’s non-visible functionality into a small hamburger menu, you have to remove a lot of features, making it unsuitable for large and complex apps because there’s simply no way to fit in all the functionality.
  • GNOME hamburger menus don’t show keyboard shortcuts, so they fail to teach users how to become more proficient right at the point of use for each feature.
  • GNOME headerbar items can’t have custom drag behaviors in order to preserve window draggability, so they don’t let you click-and-hold to open, slide the cursor over an item, and release to select that item.
  • GNOME hamburger menus are implemented as a widget inside the app’s window, so they can get cut off if the window is too small–reinforcing the need to avoid putting too much stuff in them (EDIT: apparently this is fixed in GTK4 on Wayland):
lol (note: laughter is only applicable to X11)

Our grass isn’t that much greener

However, I think at the time I was being too kind to traditional menu bars to help me make my argument. Over time I have sometimes found myself frustrated with how hard it is to actually find anything quickly in traditional menu bars. Every time I use a GNOME headerbar app, I have to admit that as an infrequent user, I appreciate the approachability and speed of their simple and consistent hamburger menus. The apps feel friendly and easy to use, not overwhelming as some KDE apps can be (though I think we’re getting better about this). And I think our flagship apps’ use of huge menu bar structures is a part of that feeling of overwhelmingness. If we’re being honest with ourselves, we need to admit that traditional menu bars can suffer from a variety of well-known problems that we can’t just ignore:

  • Menu bars are designed to show everything, so they are inherently duplicative; a button visible in the toolbar or status bar still needs an item in the menu bar. This causes the menu structure to become enormous with medium to large apps. Because menu bars are not context-aware, they’re always full of disabled menu items that you have to ignore, or wonder why they’re disabled. Thus it becomes harder to find any given menu item since you need to mentally filter out all the irrelevant ones.
  • Menu bars require strict categorization for every action which can become nebulous or nonsensical. Why are the “New Tab” and “Quit” menu items typically in the File menu? Why is “Search” in the Edit menu? Why is “Donate” in the Help menu? Because there weren’t any better places to put them without adding even more top-level menus, which would make everything harder to find. And depending on the toolkit or OS, an app’s “Preferences/Configure” item can be found in the Edit menu, the Tools menu, the Settings menu, or even somewhere else entirely!
  • Finding anything in a menu bar is slow. There are generally between 4 and 12 top-level menus, and because items are imperfectly categorized, in practice you end up having to just scrub through all of them to find what you’re looking for. With big apps, menus are very long, so this takes forever. macOS goes so far as to offer a menu item search feature just because it’s usually faster to search than to actually use the menu structure!
  • Because a traditional in-window menu bar consumes a row in the window’s header area, it wastes all the space to the right of the menu, and can cause the header area to become quite thick when it also has a titlebar, a toolbar, a tab bar, a URL bar, and so on. This can add up, especially for laptops with 16:9 aspect ratio screens.

So if the grass isn’t greener on the other side, but it isn’t greener on our side either… where can we find some green grass? It can’t be a barren wasteland everywhere!

UI design has to be better than this, at least somewhere! (with apologies to the U.S. state of Nevada, which is not all this ugly)

A place for everything, and everything in its place

For big apps with lots of features, menu bars are probably here to stay. They aren’t perfect, but humanity hasn’t yet figured out something appreciably better: hamburger menus can’t fit everything without becoming insane; ribbons take up much more space and suffer from the same categorization problems; sidebars take up even more space; trying to put all the controls inline with 100% context sensitivity becomes overwhelming. The jury’s still out on this one.

And this is fine: since KDE apps don’t use headerbars, there is a place for a powerful app’s menu bar to live without infringing on any other UI element’s turf. We fully support traditional menu bars and we always will!

However for smaller apps with less functionality, a menu bar can be overkill. As I mentioned earlier, I think a well-designed hamburger menu is quite pleasant to use, even if its implementation in GNOME is quite limiting and suffers from technical restrictions. If only there were a way to have the advantages of such a clean and friendly setup for small-to-medium apps, without any of its disadvantages…

KHamburgerMenu to the rescue

And this is where KHamburgerMenu comes in. While designing it, we were conscious of the problems with GNOME hamburger menus and specifically set out to avoid them, while also trying to match it to KDE’s existing technical and cultural conventions:

  • The hamburger menu provided by KHamburgerMenu is optional; if you just don’t like hamburger menus, you can use a full traditional menu bar if you like. And apps that are so powerful and complex that they demand the use of a full menu bar do not have to adopt KHamburgerMenu at all if they don’t want!
  • A KHamburgerMenu toolbar button is just another ordinary toolbar button, so you can move it to another place, give it some text, change its icon, or remove it entirely if you are a fussy advanced user who wants no menubar and no hamburger menu. It’s your choice! The system adapts to you, not the reverse.
  • KHamburgerMenu menus provide emergency access to the full menu structure in case the curated set of actions isn’t enough, which eliminates the need to remove features to conform to the new UI style for apps that do adopt it!
  • KHamburgerMenu menus show keyboard shortcuts, so they teach the user how to become more proficient in using the software!
  • KHamburgerMenu menus let you click-drag-release to quickly trigger an item!
  • KHamburgerMenu menus are traditional menus, so they aren’t limited to the dimensions of the window even on X11, further reducing the pressure to make them as small as possible!
  • KHamburgerMenu can modify the contents of its menu according to what’s visible on the toolbar. For example in Dolphin, the menu can avoid showing the “Sort By” item because this would be redundant with the one on the toolbar, but if you remove that button from the toolbar… it can become visible in the hamburger menu!
Again, this layout is not final! 🙂

I think KHamburgerMenu will truly bridge the gap for KDE’s moderately powerful QWidgets-based apps like Dolphin, Okular, Gwenview, Konsole, KWrite, and KCalc–providing the space savings and pleasing single entry point of GNOME-style hamburger menus, without its drawbacks of being inflexible, mandatory, limited in size, hiding keyboard shortcuts, and requiring that adopting apps remove functionality. If we get it right, our flagship apps will feel much more approachable while not losing any of their powerful features or customizability. Doing this in a flexible and optional way is more work, of course–and if we’re honest with ourselves, it will probably lead to more corner-case bugs. But that’s the KDE way. 🙂 We have to be true to who we are, even when we march boldly into the future!

This week in KDE: KHamburgerMenu and some good bugfixes

Today I’d like to introduce an interesting new component that will eventually be rolled out in many KDE apps with menubars: KHamburgerMenu. This re-usable component allows QWidgets-based apps to show a custom hamburger menu w2hen the main menubar is hidden, like Dolphin already does. In fact, we are in the process of porting Dolphin’s custom implementation to use KHamburgerMenu. Here’s a sneak peek of the early alpha work:

NOTE: this layout is not final and is highly likely to change!

Adopting KHamburgerMenu offers KDE apps many features and advantages:

  1. It offers an escape valve for users who hide the menubar by accident! This is a surprisingly serious problem, and KDE’s bugtracker is littered with reports from users who did not figure out how to show their menubar again!
  2. It allows users who want maximum vertical space to choose to hide the menubar without losing GUI access to the menu items, or having to activate the titlebar-based menubar or global menubar (maybe they don’t like those; we’re all about choice in KDE after all!).
  3. Being a re-usable framework, KHamburgerMenu can be applied to KDE apps besides just Dolphin.
  4. Though the hamburger menu shows a curated assortment of items from the main menubar, the app’s full menu structure is available from a sub-menu on the bottom (See “For 83 more actions:”, in the screenshot above) so nothing is ever completely hidden. This means that the curation of items can be more selective because there is no longer a need to cram everything into the main level to make sure it isn’t totally invisible to the user. This will result in hamburger menus whose contents are short and relevant.
  5. The new hamburger button is just a regular toolbar item like all others, so you can relocate it, rename it, change its icon, or remove it entirely if you really do want to hide the menubar and not use a hamburger menu.

Big thanks to Felix Ernst for this work! It has been merged for Frameworks 5.81, and we are working on porting Dolphin and Gwenview to use it, hopefully to land in their 21.08 releases. And hopefully more will be coming too.


Some of you may be wondering, “Does KDE plan to kill off the menubar the way GNOME did? Have your feelings on this matter changed since you wrote a scathing criticism of headerbars and hamburger menus back in 2018?” My answers would be 1) no, we have no intention of killing off traditional menubars especially for large and complex apps, and 2) yes, my personal feelings on Hamburger menus have changed somewhat over time, particularly because KHamburgerMenu is engineered to avoid what we see as the drawbacks of the GNOME-style hamburger menu. However, I’ll have to expand on that in another blog post because this intro section is getting waaaaay too long! So stay tuned.

Edit: here you go: https://pointieststick.com/2021/04/03/how-i-learned-to-stop-worrying-and-love-the-hamburger-menu

Anyway, here’s the rest:

Bugfixes & Performance Improvements

When Dolphin is configured to restore history on launch (as it does by default), if it is launched with a URL corresponding to a location that was already open last time, it now opens and focuses that location, rather than opening a redundant new tab for it (me: Nate Graham, Dolphin 21.04)

It’s no longer possible to use Dolphin’s “Mount ISO” action to mount the same ISO image multiple times (Kwon-Young Choi, Dolphin 21.04)

The FortiSSLVPN networkmanager plugin now works (Pedro Gomes, Plasma 5.21.4)

Single-keyboard-layout setups in the Plasma Wayland session no longer fail to load your keyboard options and variants (e.g. alternative Caps Lock behaviors) (Andrey Butirsky, Plasma 5.21.4)

Task Manager entries for apps capable of showing a numbered badge in the corner no longer sometimes pointlessly show a badge with the number zero in it (Bharadwaj Raju, Plasma 5.21.4)

Syncing your font size to the SDDM login screen now works in the case where the system is using its default font size, but that size differs from the default font size of the login screen (Eugene Popov, Plasma 5.21.4)

You can once again create new files on a writable FTP share using Dolphin’s “Create New…” menu (Méven Car, Frameworks 5.81)

The image thumbnailer no longer sometimes crashes when taking a screenshot (Méven Car, Frameworks 5.81)

The Baloo file indexer is now more reliably able to notice when files have been renamed or moved (Stefan Brüns, Frameworks 5.81)

User Interface Improvements

Gwenview’s initial window size the first time you launch it is now a more reasonable 1020×700 (me: Nate Graham, Gwenview 21.04)

Taking into account user feedback from last week regarding the new Plasma applet config dialog appearance, we decided to revert the changes and go back to the customary KDE style in the absence of consensus and work to simultaneously change all settings dialogs to use a new style (Marco Martin, Plasma 5.22):

Search fields in Discover and the “Get New [thing]” dialogs now automatically initiate a search a few seconds after you finish typing, if you haven’t already pressed the Enter key by that point (Dan Leinir Turthra Jensen and me: Nate Graham, Frameworks 5.81 and Plasma 5.22)

The Digital Clock Applet’s option to always display the local timezone is now presented in a clearer way in the settings window (Momo Cao, Plasma 5.22):

When using our Breeze GTK theme, scrollbars in ancient GTK2 apps now look more similar to Breeze-style scrollbars in Qt apps (Marco Rebhan, Plasma 5.22)

…And everything else

Keep in mind that this blog only covers the tip of the iceberg! Tons of KDE apps whose development I don’t have time to follow aren’t represented here, and I also don’t mention backend refactorings, improved test coverage, and other changes that are generally not user-facing. If you’re hungry for more, check out https://planet.kde.org/, where you can find blog posts by other KDE contributors detailing the work they’re doing.

How You Can Help

Have a look at https://community.kde.org/Get_Involved to discover ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.