search

kotelnik / plasma-applet-active-window-control

Plasma 5 applet for controlling currently active window.
GNU General Public License v2.0
119 stars 18 forks source link

Global menu malfunctions with non-Qt based apps #78

Open amorozov opened 7 years ago

amorozov commented 7 years ago

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.

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:

Applets:

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

amorozov commented 7 years ago

Non-functioning GM of Firefox in KDE. Top-level items are visible and clickable, bit Functioning GM of Libreoffice in XFCE4/vala-panel applet for XFCE4

kupiqu commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

Vortex375 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

t0msk commented 7 years ago

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

rkunschke commented 6 years ago

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

bidinou commented 6 years ago

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 commented 6 years ago

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

bidinou commented 6 years ago

Wow, thank you so much :-)

rilian-la-te commented 6 years ago

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

rokups commented 6 years ago

@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 commented 6 years ago

It exactly what it do on X11)

rokups commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

I will. Thank you for clarification 👍

t0msk commented 6 years ago

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

rilian-la-te commented 6 years ago

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 commented 6 years ago

Sounds really good :)

sdfg2 commented 6 years ago

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

Chromace commented 6 years ago

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