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. Or that when the hamburger button is removed at least after a restart it would generate the options in the global menu. 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. The issue that they tell me is "Why is it not in the same place. Why are options buried in sub menus. How do I change it back or to fit me" So having a toggle or having the app be aware that when its present would be useful. I am aware 3rd party apps will not follow this but their usage can be kept to a minimum. I'm not asking to stop changing the ux as you are but, having this as a accessibility option would solve a lot of issues when things do change. My apologies if this is in the wrong area.
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. For QtQuick apps, typically the hamburger menu is custom; unfortunately there's no standard base class they all inherit from, so we'd have to implement this logic in every app (or create a common base class for them to all inherit from, and then implement it there). Let's use this bug report to track it for KHamburgerMenu. Please open a new bug report for every QML app you'd like to see changed (I'm sorry, I know this is a lot of work)
(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. (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. 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. > 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. > 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.
(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.
(In reply to Elite from comment #3) > 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. Yes, it indeed seems like the only fix for this specific request is such a global option. It would probably need to be called something like "Hide hamburger buttons when using a global menu bar". This should be implementable by adding such an option/setting to KDE's global settings. The KHamburgerMenu code could then read it. This would be the most minimal fix to this bug report. However, it would also be a bit of a niche solution. If I try to see the bigger picture, perhaps the option "Hide hamburger buttons when using a global menu bar" could be combined with a global "Prefer using menu bars" check box in system settings. Applications that support both a menu bar as well as a hamburger menu would then show a menu bar by default. Additionally, when "Prefer using menu bars" is selected, KHamburgerMenu would hide itself whenever a menu bar is exported. This latter solution is more difficult to implement though because we currently don't have a good way to toggle the visibility of menu bars globally.
This feels a bit over-complicated to me TBH. I would just always hide the hamburger menu button when using a different menu structure, same as how we automatically hide the in-window menubar when using a global menu. Same logic.
(In reply to Nate Graham from comment #5) > This feels a bit over-complicated to me TBH. I would just always hide the > hamburger menu button when using a different menu structure, same as how we > automatically hide the in-window menubar when using a global menu. Same > logic. What you are suggesting will prevent users from using the hamburger menu if they use any exported menu bar. This was immediately disliked when I had implemented it that way. Kai Uwe Broulik and Ismael Asensio both were unhappy with it soon after KHamburgerMenu became a standard. On the contrary the current behaviour hardly gathered any criticism in years. I bet we will get the same criticism that we got previously if we reverted this, and a lot of unhappy feedback. The only downside of the current state is that users might need to manually remove the hamburger button if they are really bothered by it. This is usually not an issue except for the scenario which Elite described in this bug report.
I'm surprised by that, because we already hide the hamburger menu when there's an in-window menubar; I don't seem why it should be different if instead there's a global menu. Kai and Ismael, if you still feel this way, could you help me understand why?