Version: (using Devel) OS: Linux Installed from: Compiled sources The showMenubar kstandardaction is always checked on launch. The problem seems to be in kdeui, as ALL apps I tried have the problem, EXCEPT those that use a workaround (-> setting the checked value after the initialisation of the menubar and the createGUI() ex: gwenview, kopete). I was told on kde-devel (irc) that this is a workaround that shouldn't be used ... So instead of patching the other apps (dolphin, okular, etc) to use such a workaround, I'm posting a bug here ! I think the best solution would be that the gui creation systems automatically alter the checked state of the kaction (when instanciating the gui) to sync it with the state of the menubar (hidden or not). I'd be gratefull if some of the more knowledgeble devs could tell me if this is indeed the correct fix (or if I should just use workarounds) ;-)
Of course you have to add the showmenubar button to a toolbar and hide the menu too see the bug.
I tested dolphin and okular from current trunk with the "show menu bar" action in the tool bar. Both applications correctly initialized the state of the action button, but I am not sure if this has been fixed in the individual applications, or in kdelibs.
I confirm the show menubar action doesn't behave the same across applications. There are several bug reports assigned to different apps explaining the menu item says 'show menubar' when its already visible, with no effect - except that the item says 'hide menubar' - on first click. Applications doesn't always remember the state when starting. Some application doesn't obey the standard shortcut (konsole, but there might be a conflict with shell shortcuts as i use ctrl-m). Some applications doesn't provide the ability to hide the menubar (kmail-juk-kalarm, ...) The show menubar code (in kdelibs if i understand) should correctly handle the state on application startup. And i don't know if i should open another bug/request, but all applications should be checked/cleaned too not use a workaround anymore, allow to hide the menubar and obey the standard shortcut. A lot of bugs could be closed too btw. Regards, Charly
The "Show Menu Bar" standard action is indeed initialized to "checked", regardless of the actual state of the menu bar widget, which is created much later, after a call to createGUI. After creating the menu bar, the application has to adjust the state of the action. A single line "showMenuBarAction->setChecked(menuBar()->isVisible())" does not seem a lot of code to implement this. Compare this to the code required to make the showMenuBarAction work in the first place. Applications have to connect the trigger slot to a stub function that calls setVisible() on the menubar. You could argue that this should be done automatically, too. Applications that request the showMenuBarAction should not only make sure that toggling this action changes visibility of the connected menubar, but also make sure that changes in visibility are reflected in the action. This also applies to the showStatusBarAction. QWidget does not emit a signal when the visibility of a widget changes. Implementing the requested feature would require event filters, which is much more overhead compared to the single code line (compare the KFullScreenToggleAction, which explicitly handles the synchronization of the action and the actual window state). I see this "workaround" implemented in Dolphin, as well as in Okular. For Konsole, the fix may involve more work, as the action is also added to the context menu. Please file a bug for Konsole, or reopen an existing one. If you see more applications that keep the menu item checked on launch, please file a bug report for them.
Should we reconsider please? I spent literally a day to debug this for Ark, until I faced with a workaround in Dolphin, occasionally. It definitely looks like a bug (or at least we don't want such behavior anyway), didn't see for implementation details though. https://invent.kde.org/utilities/ark/-/merge_requests/124#note_503172
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann