[kde] [Bug 466107] New: In many KDE applications, there's no obvious way of re-enabling the menu bar and the toolbar unless you remember a keyboard shortcut

[bugzilla_noreply at kde.org]

https://bugs.kde.org/show_bug.cgi?id=466107

            Bug ID: 466107
           Summary: In many KDE applications, there's no obvious way of
                    re-enabling the menu bar and the toolbar unless you
                    remember a keyboard shortcut
    Classification: I don't know
           Product: kde
           Version: unspecified
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: unassigned-bugs at kde.org
          Reporter: guimarcalsilva at gmail.com
  Target Milestone: ---

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

-- 
You are receiving this mail because:
You are the assignee for the bug.