SUMMARY While filling bug 466101 I noticed UX a problem that affects multiple KDE applications, like Konsole, Gwenview and Dolphin: You can effectively get in a state where you have essentially no way of controlling an application if you hide the toolbar of an application that uses the hamburger menu (or hide the menu bar and the toolbar). While this might be intended by the user, the only way to recover from that state is by knowing the shortcut to bring the menu bar (CTRL+M or CTRL+SHIFT+M in Konsole) and re-enabling the toolbar there. I thought about showing a message telling them about a keyboard shortcut when that is the case, but I realize that's not good enough due to relying on a keyboard (which the user might not have on a touch-only device) and relying on the user's memory (check a more detailed explanation in bug 466103). Considering that most third-party applications do not allow fully hiding those elements, and that with the advent of the Hamburger Menu and other modern interface paradigms the toolbar became essential for interacting with applications (instead of only being a place to put the most commonly used tools,) maybe options like these should not be so easily accessible anymore. They could still be controllable by a environment variable or by launching KDE applications individually with command line options (e.g. --hideui or --hide-menu), which would be easy to do by expert users but would prevent common users from getting in a seemingly unrecoverable state. They could even be controlled by Window Rules if technically possible. STEPS TO REPRODUCE 1. In Dolphin, Konsole, or Gwenview, select in the menu the option to hide the toolbar (if an application doesn't use the Hamburger menu, hide the toolbar and the menu bar) OBSERVED RESULT The UI disappears because nowadays everything is in the toolbar, including the hamburger menu. In the past, that wasn't a big concern because at least the window would have the menu bar, and hiding everything required two steps, however, with the advent of the hamburger menu, the toolbar became an integral part of the application and not only a place to access the most used functions. A message is also not enough to prevent user error in this case because it relies on users remembering what they have to do to bring things back, and the hide toolbar functionality most of the time doesn't even have a dedicated keyboard shortcut to be toggled anyway. Even if it had an associated shortcut, users of touch only devices wouldn't be able to activate it. EXPECTED RESULT There should be an easy way of going back that doesn't require keyboard shortcuts and doesn't rely on the user's memory, or at least, if there's a use case for it, hiding essential UI elements should be made harder to do. SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 5.19.0-32-generic (64-bit) Graphics Platform: Wayland Processors: 6 × Intel® Core™ i5-9400F CPU @ 2.90GHz Memory: 15,6 GiB of RAM Graphics Processor: AMD Radeon RX 570 Series
If you hide both the menubar and all toolbars, we assume you're a technical expert who wants the most minimal UI possible, which is why it's permitted. Regardless, the assertion is actually not correct; in Konsole, Gwenview, and Dolphin, if you hide both the menubar and the toolbar, you can still get to the menubar in the context menu, from which you can re-enable the hidden UI elements. So there is in fact a way to get them back without remembering a keyboard shortcut. Clearly you didn't find this so maybe it's not enough. But I struggle to think of something that would be better. At a certain point, you have to let adventurous users explore and potentially break things.
(In reply to Nate Graham from comment #1) > If you hide both the menubar and all toolbars, we assume you're a technical > expert who wants the most minimal UI possible, which is why it's permitted. > > Regardless, the assertion is actually not correct; in Konsole, Gwenview, and > Dolphin, if you hide both the menubar and the toolbar, you can still get to > the menubar in the context menu, from which you can re-enable the hidden UI > elements. So there is in fact a way to get them back without remembering a > keyboard shortcut. > > Clearly you didn't find this so maybe it's not enough. But I struggle to > think of something that would be better. At a certain point, you have to let > adventurous users explore and potentially break things. Hm, I totally missed(In reply to Nate Graham from comment #1) > If you hide both the menubar and all toolbars, we assume you're a technical > expert who wants the most minimal UI possible, which is why it's permitted. > > Regardless, the assertion is actually not correct; in Konsole, Gwenview, and > Dolphin, if you hide both the menubar and the toolbar, you can still get to > the menubar in the context menu, from which you can re-enable the hidden UI > elements. So there is in fact a way to get them back without remembering a > keyboard shortcut. > > Clearly you didn't find this so maybe it's not enough. But I struggle to > think of something that would be better. At a certain point, you have to let > adventurous users explore and potentially break things. I missed the menu on the context menu because I really didn't expect it to move there. I should have investigated more before trying to file a bug report (and writing a wall of text in the process 😆). Maybe any state where the menu gets hidden should show a message telling the user it can still be accessed with the context menu, the same way there's a message that tells you the keyboard shortcut to bring back the menu.
Yeah, or just a notification.
>Maybe any state where the menu gets hidden should show a message >telling the user it can still be accessed with the context menu, the same >way there's a message that tells you the keyboard shortcut to bring back >the menu. I don't think this can be implemented in frameworks because it is up to the applications to add the hamburger menu (or some other way to get back some sort of menu) to their context menus. They could also have a button on the UI to re-enable the toolbar, or they could decide that the toolbar is purely optional in their application and wouldn't want to add anything to the context menu to re-enable it or the menu. We also can't assume that the application would have a menu bar so we can't advertise the Ctrl+M shortcut. Similarly we can't even assume that the application has a toolbar because KHamburgerMenu doesn't need to be placed on a toolbar, so we can't tell users about such an action either. All in all, unless all right-clicks and all context-menu opening were to be routed through KHamburgerMenu (which seems like a bad idea), I don't really see a way to ever implement this in frameworks. -- Oh, even worse! I forgot that the same issue applies for applications that don't even use KHamburgerMenu. We would have to show a dialog for them any time the menu bar is hidden because we can't know if a hamburger menu is implemented in the toolbar. So, while I understand the basic argument, this might not be an actionable bug report for frameworks. I want to add though that if I (or anyone) doesn't see a way to technically implement something, it might just be that I/they simply don't have the right idea on how to accomplish something.