Global menu malfunctions with non-Qt based apps

[amorozov]

Recently I've finished the setup of global menus for all kinds of applications and found that the applet works properly only for Qt (Qt4 & Qt5) based apps & Chromium (58.0.xx). Apps built upon other widget sets experience some different problems with the global menu.

• Libreoffice (5.3.2) doesn't notice global menus at all, drawing its menus right within the window as usually
• WPS Office doesn't notice it as well.
• Firefox 53.0 and Skype for Linux 5.1.0 do see the global menu and successfully draw the top level items of the menu in the applet, but no any actual menus.
• Additionally Skype eats one of the CPU cores completely all the time.

What's interesting is that vala global menu applet for XFCE4 works with all the problematic applications on the very same set of libraries and settings without any noticeable problems.

Libraries involved in the process:

• appmenu-gtk-module-git 0.4.4.r37.gfb9116d-1 (a subproject from vala-panel-appmenu, replacement for unity-gtk-module)
• appmenu-qt4 0.2.6-1
• libdbusmenu-glib 16.04.0-2
• libdbusmenu-gtk2 16.04.0-2
• libdbusmenu-gtk3 16.04.0-2
• libdbusmenu-qt4 0.9.3+16.04.20160218-1
• libdbusmenu-qt5 0.9.3+16.04.20160218-1

Applets:

• plasma5-applets-active-window-control-git r90.27442e1-1
• vala-panel-appmenu-xfce-git 0.4.4.r39.g3a0080f-1

Please suggest what tests should be performed to find out why GM don't work as expected

[amorozov]

. Top-level items are visible and clickable, bit

[kupiqu]

It's known that the global menu of plasma doesn't work with gtk applications as they don't use the same protocol.

Firefox and Libreoffice, I think, use their own thing, which doesn't work with the global menu, so yes, so far global menu only works with Qt applications...

It's also known that electron applications have that problem of CPU, you can use the following to show the menu in the app and workaround the issue: ELECTRON_FORCE_WINDOW_MENU_BAR=1 /usr/bin/skypeforlinux

Note that this is not a problem of the widget, so opening a bug in kde would be a better fit, although it mostly relates to non-kde applications anyway, so although I think some work is being done to support more apps, things in this regard are complicated...

[ChALkeR]

@amorozov Skype issue is in fact an Electron bug (Skype is Electron-based), reported here: https://github.com/electron/electron/issues/8455. You can use the ELECTRON_FORCE_WINDOW_MENU_BAR=1 work-around for that.

[snippins]

Getting the menu gtk apps is not so hard IMO. I added the unity-gtk-module (or topmenu-gtk-module) to the GTK_MODULES variable at startup. After thatI notice that the i3-hud-menu script (i3 is actually not necessary) is able to extract the menu and show a HUD for gtk (and qt) apps:

Follow is a modified and working version of that script HUD.txt.

[rilian-la-te]

But qmenumodel does not ported for now for Plasma appmenu. And KDE's appmenu able only to read DBusMenu proto (not MenuModel). On Qt, we cannot do GDBusMenuModel.get() and then gtk_menu_bar_new_from_model(model). We need to reimplement all GtkMenuTracker private machinery for QMenu. (And QAction is not a same thing than GAction, so, we cannot directly translate GMenuModel to QMenu).

[snippins]

@rilian-la-te Yeah I kinda understand that after reading your code + kde code recently. What a dump assumption to make by me. - _ -

[Vortex375]

What is required to provide compatibility with gtk based apps, in general? I would like to start experimenting with this but I am currently lacking some knowledge.

I thought that libdbusmenu provided the protocol, so as long as applications use that, they should be compatible. But I guess that was wrong.

Also, is it possible to implement a workaround for the electron bug? The bug report on the electron ticket was updated to indicate that it affects only KDE (and no other global menu implementation).

[rilian-la-te]

There are 2 protocols. One is implemented by libdbusmenu (and many other implementations), and another implemented in GLib.

If you want to start experimenting, try this repo. At least, make it build:) At most, look to qmenumodel library into repo, and made a QMenu compatible layer.

[sdfg2]

Has anyone been able to get gtk global menu bars working with the repo @rilian-la-te posted? I followed the instructions (I'm on Arch), and it works with Chromium but nothing else GTK. :-(

[rilian-la-te]

For KDE it is just template repo now. Feel free to write your own applet.

[t0msk]

What is status of this? :) Is someone working on GTK compatibility?

[rkunschke]

I'm interrested too. But still can't do it myself.....

[bidinou]

I was wondering, maybe this could belong to the KDE Usability & Productivity initiative, cf. https://phabricator.kde.org/T6831

Progresses made in the past weeks / months are extremely impressive, cf. : https://pointieststick.wordpress.com/

[rilian-la-te]

Here is a WIP fix for X11: https://phabricator.kde.org/D10461

[bidinou]

Wow, thank you so much :-)

[rilian-la-te]

It is not me who wrote it) I just monitor GlobalMenu feature in KDE)))

[rokups]

@rilian-la-te implementation you linked depends on _GTK_APPLICATION_OBJECT_PATH and _GTK_WINDOW_OBJECT_PATH X11 properties. However for some reason many applications do not expose them. Any idea if exposing these properties would be something that appmenu-gtk-module could do?

[rilian-la-te]

It exactly what it do on X11)

[rokups]

Hmm i have it installed and enabled but for some reason it does not work with all applications. Pluma/sublime/virt-manager all have just:

_GTK_THEME_VARIANT(UTF8_STRING) = 
_GTK_MENUBAR_OBJECT_PATH(UTF8_STRING) = "/org/appmenu/gtk/window/0"
_GTK_UNIQUE_BUS_NAME(UTF8_STRING) = ":1.225"

Firefox/thunderbird doesnt have any GTK xprops at all. Libreoffice has all required props though. Any idea what could be going on here?

[rilian-la-te]

Firefox is not supported (it is not GTK, only mimics) _GTK_MENUBAR_OBJECT_PATH and _UNITY_OBJECT_PATH is enough for vala-panel-appmenu.

You should comment it on KDE Phabricator, than _UNITY_OBJECT_PATH also need to be supported. (it is set by gtk-module to avoid clashes with properties mentioned by you)

[rokups]

Comment from person working on gmenu-dbusmenu-proxy:

but I need to get all the actions to show them properly in a menu, only the action (not the menu entry) knows whether it's enabled or checkable/checked

From the rest of conversation with him i understood that my previously mentioned missing properties are vital for proper menu proxy. Unfortunately without them menu proxy would work with a very limited set of applications.

[rilian-la-te]

No, it is not vital.

MenuModel protocol consitsts for 5 items:

1. AppMenu - with property _GTK_APPMENU_OBJECT_PATH
2. MenuBar - with property _GTK_MENUBAR_OBJECT_PATH It is a menu models, it is how menu should drawn on screen. One can be missing, and then incomplete menu should render: a) If AppMenu is missing, you will miss menu entry with application name (vala-panel-appmenu renders stub in place of missing AppMenu) b) If MenuBar is missing, you will miss all menu entries except entry with application name. c) If both are missing, you will not see a menu (Protocol is incorrect)

And 3 providers of actions. Actions is required to get menu react on user changes.Providers:

1. Application (_GTK_APPLICATION_OBJECT_PATH , prefix app) - it is actions from all application (not bound to a particular window)
2. Window (_GTK_WINDOW_OBJECT_PATH, prefix win) - it is actions from current window, as it set by a developer of application
3. Unity (_UNITY_OBJECT_PATH, prefix unity) - it is non-standard, but widely used action path for set a stub actions (when window actions is not supported by app developer). If any of this are missing, this menu items should be rendered as disabled. But if menu using actions only from one category - it can be used as a normal menu. Setting this all is not required for functional menu. One will be enough, if menu is using actions only from one group.

So, I think developer is doing someting wrong. Can you send it to him?

[rokups]

I will. Thank you for clarification 👍

[t0msk]

So it means that we can have a GTK menu in KDE global menu widget?

[rilian-la-te]

Yes on X11, when mentioned project will finished (if it will not, I will fork and finish it, when I will have time). But Wayland will take much more.

[rkunschke]

Sounds really good :)

[sdfg2]

This is excellent news, it always felt 'so close', I'm glad to know it's on its way :-)

[Chromace]

Good news on this front. http://blog.broulik.de/2018/03/gtk-global-menu/