https://bugs.kde.org/show_bug.cgi?id=501871
--- Comment #3 from Elite <eliteamdgam...@gmail.com> --- (In reply to Felix Ernst from comment #2) > (In reply to Nate Graham from comment #1) > > Yeah, it makes sense to only have one menu structure visible, not two. This > > is the reason why we automatically hide the hamburger menu button when the > > in-window menubar is visible. > > > > In QtWidgets apps, we could make KHamburgerMenu hide itself when it detects > > a global menu. > > It used to be that way, but we actively changed this in > https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/46 and > received far fewer complaints since then. I think the current state is way > better on average than hiding KHamburgerMenu when a global menu exists. So I > think we need a different solution. Perhaps this could just be a option in settings the user can enable or disable. As that would solve most of if not the full request. > (In reply to Elite from comment #0) > > I manage quite a few users in several places in the US. that have limited or > > no mobility and navigate the system with their eyes, mouth, or sometimes a > > vary shaky finger. While most can see fine some do not. > > > > I'm requesting a setting that can be toggled or some other way that when a > > global menu is present it removes hamburger buttons from kde apps that it > > can be.Ardour > > Is the mere existence of the hamburger button a big problem? I understand > that it is annoying having to manually remove it from every application, but > I am trying to identify the core issue of this bug report. I would assume > ignoring the button is not that big of an issue because many UIs have > buttons that the user does not care about. Most of the users I'm talking about in this request have challenges. Let's say the wallpaper changes from blue to green it end up with the nurse being called. Most are X mac users. So I set up most everything as closely as possible and remove anything that causes a stir. I personally can't be around every user every time they add something. The main goal is to keep everything other then the browser KDE it's easier to maintain. I also can not reliably expect a user who's use of right click depends on a blink sequence that is quite unreliable to manually remove it from every app. But yes the sight of it affects some. It's no fault of the user it's just how they are. > > Or that when the hamburger button is removed at least after a > > restart it would generate the options in the global menu. > > There might be a misunderstanding there. Hiding the hamburger button has no > effect on what shows up in global menus. If a global menu does not show all > options of an application, that is because those applications do not export > their menu structure to the global menu. > > You are probably experiencing this issue mostly with more recently invented > KDE applications, right? Those are Kirigami applications and many of them > have hamburger buttons but do not export a global menu structure. The only Kirigami app I have seen like that I think would be tokodon? At the least none of the users I've interacted with have had that on their system. > > Why, > > when your way of movement is you have to look at a point to move the > > mouse. look at one point for long time to right click. When it's in one area > > that stays the same you can map things to make it far easier to use. > > Hamburger menus or buttons on apps can't really be mapped with that in mind > > since they can always be in different places. > > I am not sure if this helps, but I actually added a generic keyboard > shortcut for opening the menu. Pressing F10 in applications that use > KHamburgerMenu should either open the hamburger menu if it is visible, or > open the first in-application menu bar menu. This has been changed one and a > half years ago in > https://invent.kde.org/frameworks/kconfig/-/merge_requests/222. If an > application does not support that, it can be considered an application bug. > > I am currently not sure if I fully understood the issue we are trying to fix > here. Elite, if it seems like we are talking past each other, please let me > know. We might need more context to identify the best path forward. I can't really map shortcuts for them as they are mostly paralyzed from the neck down. The other issue is the menus not really coherent. Less shown is not better in this case. The equivalent of "Edit" "Actions for current view" is just honestly not clear and is a bit to complicated for some. What I think would help is a button in settings that can be used to shut off the hamburger menu for the kde apps that need it like Dolphin for example. When the global menu is activated. -- You are receiving this mail because: You are watching all bug changes.
