Summary: | Gui to whitelist/blacklist applications for global menu export (workaround for broken applications) | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | leftcrane <leftcrane> |
Component: | Global Menu | Assignee: | Kai Uwe Broulik <kde> |
Status: | RESOLVED UPSTREAM | ||
Severity: | wishlist | CC: | greengoblin205, kde, mvourlakos, nate, plasma-bugs |
Priority: | NOR | Keywords: | accessibility |
Version: | master | ||
Target Milestone: | 1.0 | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
leftcrane
2019-10-03 08:25:44 UTC
> Libreoffice with GTK3
Don't use that, use the KDE5 VCL, which works better in the latest versions of LO (i.e not the older versions that Ubuntu is shipping).
For the other apps, can you link to the bugs you've filed for the app developers? Even if we work around their breakage on our side by offering a user-facing override, they need to be made aware so they can eventually fit it in their apps.
Sure, problem is that many people are stuck with it (at least by default) unless they are using the latest packages. In general there seem to be issues handling dynamic and lazy loaded menus, or menus that for some reason just don't load in their entirety at the start of the program. This is a different program from LO. Examples of the loading problem: * JetBrains suite (last time I used it), submenus wouldn't load - the bug was reported here. * Copy-Q, uses dynamic menus which cause the global menu to stop being exported: bug report on gh https://github.com/hluk/CopyQ/issues/1206 * Figma desktop, plugin menus and submenus will fail to load intermittently: https://github.com/ChugunovRoman/figma-linux (haven't reported the bug) Seems like there's a pattern, so maybe the problem might be fixable at the level of the toolkit or even the plasmoid. Other kinds of problems have been spotted with LO, Emacs, and Unity 3D, as already mentioned. edit: This is a different *problem from LO. How can we blacklist an app? Clients will see a global menu service is registered and then hide their own. Potentially we could throw an error register window, but even our implementation doesn't check that, it seems optimistic to think these already broken 3rd party ones will. I tested that by `kill -STOP `pidof kded5` and seeing if a newly spawned kwrite had a menu after the timeout. It did not. Given it's a technical feature request rather than a bug report, marking as needsinfo for original reporter. Yeah, silly of me to not have thought of this. I don't think QT clients can be blacklisted, for example. AFAIK, the only ones that can are those that rely on appmenu-gtk module (org.appmenu.gtk-module blacklist/whitelist). So from the list that's only emacs - which should be easily fixable upstream - and that's it. So this is a limitation of DbusMenuProxy. So should we close this bug as an 'upstream' issue? Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Global menu has most of options grayish and unusable, but once I deactivate global menu, these options get into the Unity3D interface and I can normally use those. That sounds like a bug in the Unity app rather than anything we can fix. Please report it to them. |