The version is 16.08.0. With the menubar hidden, a button is added to the toolbar (without consent). Unlike every other toolbar button, this button cannot be removed, it cannot hide its text, it cannot use custom text, it cannot be re-ordered, it cannot use a custom icon, and it cannot be added when the menubar is visible. Reproducible: Always Steps to Reproduce: 1. Hide menubar 2. Find a new toolbar button 3. Try to change it in ways that every other toolbar button can be changed Actual Results: Unlike every other toolbar button, this button cannot be removed, it cannot hide its text, it cannot use custom text, it cannot be re-ordered, it cannot use a custom icon, and it cannot be added when the menubar is visible. Expected Results: Like every other toolbar button, this button can be removed, it can hide its text, it can use custom text, it can be re-ordered, it can use a custom icon, and it can be added when the menubar is visible.
This is intentional. If you could disable, remove, or alter the control button, there would be no way of accessing its functionality or restoring it to default settings. People could get themselves trapped with Dolphin in an unalterable state.
(In reply to Nate Graham from comment #1) > . . . there would be no way of accessing its functionality or restoring it to default settings. People could get themselves trapped with Dolphin in an unalterable state. I think this is completely false. If the menubar is still available within the window decoration or using a global menubar plasmoid, you can always accessing/restore via that menubar (Settings > Configure Toolbars). If the menubar is not available, the control button could always be added/removed from the toolbar by right-clicking the toolbar. If the rationale for this limitation is based only on a false understanding, please reopen.
Furthermore, your explanation did not touch at all on the ordering limitation, or the text-visibility limitation, or the text-customization limitation, or the icon limitation, or the visible-menubar limitation.
Thanks for the comments, Andy. I'm not a Dolphin maintainer--only a bug screener--but I have to imagine that the button is unalterable to prevent users from accidentally hiding or defacing it, and then not easily being able to get back the button or the menubar. You are right, though, about possibly being able to access the menu through a global menu plasmoid, or an application menu window button. And it's true that if the button was just a standard button, you could manipulate it via the normal means, and get it back that way if you accidentally removed it. Re-opening; thanks for helping me understand your perspective.
The tool button is quite a hack and added manually to the tool bar and not managed by KXmlGui (which provides all the customization options). That's why you cannot alter it at this point.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/71
*** Bug 427437 has been marked as a duplicate of this bug. ***
Git commit 6610d74b9c44437a3ed37c18ad205eb5d2dfd907 by Felix Ernst. Committed on 30/03/2021 at 10:07. Pushed by felixernst into branch 'master'. Introduce KHamburgermenu This commit introduces the hamburger menu, which is a general menu button, to frameworks. It substitutes the menu bar meaning that it will act non- existent when the menu bar is visible. When there is no menu bar or it is hidden, the KHamburgerMenu will take on all of its responsibilities. The hamburger menu is supposed to only feature actions which are not already visible for the user in other parts of the UI. It will try to do so automatically but methods are available to make it aware of toolbars, menus, etc. When both the menu bar and toolbars are hidden, users might find themselves in a situation they do not know how to recover from. To avoid this, KHamburgerMenu is supposed to be added to context menus where it will only be visible, when no other menu is available. The menu also features a special sub-menu advertising actions which are only available through the menu bar and would crowd the hamburger menu. M +4 -0 src/CMakeLists.txt A +410 -0 src/khamburgermenu.cpp [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] A +184 -0 src/khamburgermenu.h [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] A +163 -0 src/khamburgermenu_p.h [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] A +87 -0 src/khamburgermenuhelpers.cpp [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] A +133 -0 src/khamburgermenuhelpers.h [License: LGPL(3+eV) LGPL(v3.0) LGPL(v2.1)] M +10 -0 src/kstandardaction.cpp M +14 -0 src/kstandardaction.h M +1 -0 src/kstandardaction_p.h https://invent.kde.org/frameworks/kconfigwidgets/commit/6610d74b9c44437a3ed37c18ad205eb5d2dfd907
I fixed this with https://invent.kde.org/system/dolphin/-/commit/a4be53fb997ea2f844f2ca4a590c073a50fcbbf6. Nate removed my commit message by mistake so this wasn't closed automatically which probably made it so I wasn't mentioned in his blog either. It's fine who wants fame and fortune anyway. 🥲 Replace custom hamburger/control menu with KHamburgerMenu Use the new KHamburgerMenu from KConfigWidgets instead of the Dolphin-specific Control menu. This makes it so the position, appearance, etc. of the hamburger button can be changed like any other. This was commited on Apr 29, 2021 3:22pm GMT+0200.
I wish one could edit comments here. That reads way more passive aggressive than I intended. I was kidding.
My bad, sorry. :(