This week in KDE: KHamburgerMenu and some good bugfixes

This Week in KDE 4 Minutes

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.

Published by Nate

Published

42 thoughts on “This week in KDE: KHamburgerMenu and some good bugfixes”

    1. Greet to another one! Kinda offtopic here, but yeah, in the linux community it looks like it is not so hard to find a vegetarians. I think that it may be because the linux people are more “thinkable” and responsible for their actions. I mean, of course there are a lot of very good and interesting people who are corpse eaters, but it is an additional pleasure to see a subset of vegetarian people in a subset of linux people.

      Like

  2. Ah, my saturday morning treat !
    Big thank you to the whole KDE community for the amazing work, and thank you Nate for this weekly tour on what’s hot and new!

    I have a little question, for Plasma 5.21, there was an amazing sprint to evolve the Breeze look and feel. While a lot got accomplished, it seems (from Phabricator) that some more tasks needs to be done. But since Plasma 5.21 is out, I haven’t seen much about Breeze Evolution. Do you know if there is some progress happening behind the bushes?

    Liked by 1 person

    Reply

    1. I’m happy to hear menubars are here to stay as I vastly prefer them to the hamburger variety for many reasons. 🙂 But choice is good, as KDE developers know, and if this new implementation makes it easier to have both it sounds like a good option. But I wonder, would this work the other way too? So programs that only have hamburger menus today, like Elisa, NeoChat, Discover, etc can get real menubars on desktop in the future? That would be really nice! Would improve ease of access and discoverability of functions as well as making my whole desktop matched and look uniform! 😀

      Liked by 1 person

    2. Yeah, the ability to move hamburger menus is a big plus (for consistency users more often look to the top left rather than top right and positioning makes a big difference to some) but it’s also adding an unnecessary click versus having the clear text labels of a menu bar, so hopefully having components ready to help developers will encourage inclusive design choices in the main apps. Discover is one that all users need to have as accessible as possible for doing updates.

      Generally the logic should be something like:

      very frequently used option = toolbar button = 1 click
      commonly used option in app with more than a few options = menu bar or main menu of hamburger menu = 2 clicks
      rarely used options = submenus or dialog window = 3 or more clicks

      Liked by 1 person

    3. Almost forgot… toolbar buttons should have an equivalent menu option. It’s not often people forget to do this, but it can really confuse users when things can’t be found in a logical menu structure.

      Liked by 1 person

    5. It depends. Elisa already has a real menu structure that you can see if you use the Global Menu or titlebar Appmenu button. It would hopefully not be too hard to add it to the window itself if that’s your preference.

      I don’t think Discover or NeoChat have traditional menu structures at all. So it’s quite app-specific.

      I once badgered Aleix into putting together a proof-of-concept for in-window menubars in Discover, but it was rather silly since it had almost no items in it. Discover just isn’t the kind of app that has a lot of actions which can’t be adequately presented in the relevant location of the main UI.

      Like

    6. Cool, didn’t know Elisa had that! But yes, in the actual window is what I’m looking for. 🙂 Perhaps I should suggest that.

      Agreed, I can see that menubars might be overkill for Discover right now, especially since there is Muon Package Manager, which I use myself, if you need more advanced functions.

      Generally it would be really cool to have menubars inside the window titlebar, like Unity used to do, but I can understand that is hard to implement and it’s nothing I feel would be necessary as I’m happy with having them inside the window.

      Finally, I once again must mention how awesome it is that you write these posts and take time to answer questions. I will definitely donate some day soon, once things have stabilized a bit. 🙂

      Liked by 2 people

    7. Thanks, I’m glad you find them useful! This blog and user outreach on it do take up about a third of my time (the other two-thirds generally being bug triage, merge request review, and general coordination style stuff) so I’m glad that it’s impactful. 🙂

      Like

  3. This helps a lot in building convergent apps. Consider switching to the hamburger menu automatically when the window is too narrow to display the regular menu 😉

    Liked by 1 person

    Reply

  5. I have a mixed feelings about KHamburgerMenu:
    Positive:
    It’s great to see that actions are grouped! Long lists in traditional menus (found in Kate, GIMP, LibreOffice) is so hard to follow that I’m trying to install “krunner-appmenu” or “plasma-hud” wherever it’s possible.
    Unsure:
    “Basic actions” and “For 83 more items” groups are questionable
    a) A lot of people have different “basic actions”
    b) 3 and more level menus (which I saw on a video from merge request) are not so good for usability (you can accidentally miss with mouse).
    c) I don’t really need separate “Help” group
    Would be awesome to have ability for customization of groups.

    And if we touching this topic, “Thunar”-like ‘custom actions’ and direct usage of “Templates” folder for ‘Create New’ elements would be great. I know that Dolphin has both “services” and templates. But from a user perspective creating .desktop files in specific folders is not really straightforward for such simple tasks.

    Thanks!

    Like

    Reply

    1. As the caption said, the final arrangement in Dolphin is very likely to change. FWIW I also brought up concerns with the “Basic Actions” sub-menu. We are considering changing it to “Actions for [name of currently selected thing” and I think it might be even better if we make that section a group within the top-level menu rather than a sub-menu. We’ve bought ourselves a lot of space.

      Another idea is to make a separate toolbar button that shows a menu with just these context-specific actions for the selected item. MacOS uses to have this concept in the form of an “Actions” button in Finder, and I always really liked the concept. I think they’ve abandoned it these days though in favor of directly showing some relevant actions in the UI, but in a much more limited manner. I don’t think it’s as good as what they had in the past, and I would be interested in resurrecting the idea with a KDE flavor.

      Liked by 2 people

    2. On the one hand, the “83 more options” is positive because it acknowledges that the application is really too complex for everything to be crammed behind a hamburger. But it’s more navigation and clicking, and shouldn’t be a default because of the problems it adds for less able users — unless there’s a system wide setting to not use them that official KDE apps respect, maybe.

      Like

  6. Hello,
    just a question about remplacement of ksysguard with plasma-systemmonitor. Until 5.20 i use ksysguard with its applet and this applet disapear in 5.21 version. So i use the plasma-systemmonitor with its applet and after a few configuration i had my fast proc&mem monitor in my task bar, but i miss the ability to launch plasma-systemmonitor when i click on the applet (like the old applet launch ksysguard). So is their any way to activate this or any plan to implement this ?
    thanks for all your work. I was a long time gnome user that switch a few years ago to kde5 and honnestly gnome is good but i ended tired of gnome dev way (constant breaking change). On kde my question is the first “breaking” change i had in years, so thanks to care of your users habit/taste.

    Like

    Reply

    2. For now you could bind your preferred app to a keyboard shortcut? Usually end up doing that with htop myself as it’s handy for quickly picking out things that are monopolising the processor.

      Like

  7. I suggest by default making the 2nd or top entry in the hamburger menu always be “Show Menu Bar” or similar.
    It would help people who forget the shortcut to re-enable the menu bar after hiding it. I know I’ve been in that situation a few times.

    I would also suggest the last item on the hamburger menu be “Exit” or close application. Some applications hide the window decoration and some users hide it automatically for all maximized applications.

    Liked by 1 person

    Reply

  8. I like the idea about the hamburger so much that I’m used to apply the hamburger version of start menu because it is much more responsive, and immediate on its logical and typical structure.

    Like

    Reply

  9. Kirigami apps still don’t look as good as the more mature QtWidgets ones, the only exception I know being Elisa. Is there some awareness about this? For me, it’s probably a mix of the apps looking like some flat spreadsheet and them not using all the features of the traditional widget styles. I just hope the Adapta and Materia themes once apply nicely to Kirigami apps at some point.

    Like

    Reply

    1. Yes. Kirigami (and other QtQuick) apps are currently styled using qqc2-desktop-style on KDE, whose main feature is that it copies the Qt Widgets look. However, it doesn’t have a lot of things like animations, transitions, etc which gives the apps that “flat” look you mentioned and makes them a bit jarring to use IMO.

      qqc2-breeze-style is in development, and already looks and feels much better. When it is complete it should replace qqc2-desktop-style as the default style.

      Like

    3. > qqc2-breeze-style is in development
      This is a nice development but it isn’t exactly what KDE is known for. What’s going to happen to the rest of the themes? Do future themes have to be made twice now? How does the Kvantum style engine fit in the future of Kirigami applications? I read in 2019 that the Qt devs planned to unify the style engines of the widget and quick frameworks for Qt6. How much of that was a success?

      Like

    4. There is an ongoing discussion about this, but the general feeling is that qqc2-breeze-style is going to end up as a stopgap solution for the PinePhone only, which needed a well-performing theme ASAP. We are still fleshing out our plans for theming going forward into the Plasma 6 and Plasma 7 eras, but until then, qqc2-desktop-style is expected to continue to exist and simply apply the appearance of the loaded QStyle to QtQuick apps. It’s the simplest path, even if it has certain limitations.

      Long-term, one idea is to create a QStyle that is itself essentially a theme engine, as Kvantum is. This theme engine would consume themes that you give it, and the qqc2-desktop-theme would be rejiggered to consume those themes too. One idea is to make the themes using CSS, as GTK themes do. The advantage here would be ease of creation and maintenance. Another idea is to use SVGs, as current Plasma themes to. The advantage of this approach would be (theoretical) compatibility with the existing universe of Plasma themes.

      Discussions are ongoing. 🙂

      Like

    5. As for the discussion you’re referencing, we were told at the time that the Qt Company had some kind of super cool unified theming solution in development, but what actually got shipped turned out to be a bit of a disappointment. It’s basically a variant of what we already do with qqc2-desktop-style: simply using QPainter to render QStyle-drawn elements on QtQuick items. It’s a fairly lazy solution IMO, and quite boring from our perspective because we already have that functionality. So we are looking to do something a bit more ambitious that would actually be a real win.

      Like

    6. Wow, thanks. I hope all these ideas succeed. Thank you very much for the informative answers, Nate! This is a detail of information that is difficult to gather by myself and I appreciate it a lot.

      Liked by 1 person

    7. This. I’m crying when I look at new system monitor, for example. For now it “looks” like a big leap backwards.

      Like

  10. Hi, Nate!
    In time: I liked the KHamburgerMenu! Although many do not like and/or are frightened by the various options that KDE provides, I still prefer to have several options a thousand times than simply not having them and having to resort to some kind of gambling and compromising the system.
    As for bug fixes, I hope this fix will bring back the accents on the keyboards set in br-abnt2 (Brazilian Portuguese). It is complicated to depend on LibreOffice’s automatic of my openSUSE Tumbleweed. 😁
    The evolution of KDE development is visible mainly in the Wayland session (in my case, I use Full Wayland in Tumbleweed) and this is awesome !!!

    Thank you very much for your time in sharing KDE news and improvements and for developing for our “Komunity”!

    Liked by 1 person

    Reply

  11. I’d really wish that the developers could fix the CalDAV integration “bug” in KOrganizer, so that way I could integrate my Zoho Calendar with the whole system. I’ve even opened a bug report but they didn’t answer me yet. ):
    (The problem is simple: the KOrganizer add a “/” in the final of the URL and the request goes wrong)
    For this simple reason I had to change a whole desktop environment. This is really sad because I love KDE Plasma.
    But I read the articles every week and I’ve feel very happy for every progress.

    Like

    Reply

  12. > KHamburgerMenu.
    I think this is partially duplication of “Application Menu”, which is available by “Window decoration -> Titlebar Buttons”. Its disadvantage is that it works only in Breeze theme and probably in Oxygen or Plastic. Its icon is usually placed as circle button, looking like hamburger menu, in top left corner of window (on title bar of course).

    About main menu.
    If sone one doesn’t want to have it as normal top bar, then there is one working well, solution, where menu is placed in title bar. Check this: https://github.com/Zren/material-decoration
    Since some time I use it daily and works very well.

    Like

    Reply

Leave a comment