Bug 424485

Summary: GDbus-DBusMenu-Proxy does not work for GTK Wayland apps
Product: [Plasma] plasmashell Reporter: Erin Yuki Schlarb <erin-kde>
Component: Global Menu widgetAssignee: Kai Uwe Broulik <kde>
Status: RESOLVED UPSTREAM    
Severity: normal CC: 4wy78uwh, 7erxk5uav, a.a.klevtsov, alenertz, alexander.huang.y, alexnoyle, andre.vmatos, andriy.parhomenko, andydecleyre, anhollander516, bednarczyk.pawel, bjorn.bidar, blackspart57, boite.pour.spam, chermnykh2001, cirlo_ca, crc2005, cristobal.veas, dapolinario, dashonwwIII, edwin.frank.loeffler, etaash.mathamsetty, eugenesan, gagbobada, gonanza, gudvinr+kde, guido.iodice, hey, howyoung3, indecisiveautomator, j5lx, johnmaverick74, joshwebb84, jsardid, julien.dlq, kde, kdedev, kimiblock, Linus, luisbocanegra17b, mail, me, me, meven29, michal.dybczak, miranda, miren_radia, mvourlakos, nate, pavel23dob, philipp.reichmuth, plasma-bugs, postix, qydwhotmail, sam, sdar, simonmik2006, sysdadmin, szymek.januszek, tbondvagyok, tromzy, uwu, vbspam, xnaxdy, ybjqx3340, yushijun110
Priority: HI Keywords: geezer-jobs, wayland
Version: 6.0.5   
Target Milestone: 1.0   
Platform: Manjaro   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: GTK3 app in Plasma 5.27.6 with no menu at all (neither local nor global)

Description Erin Yuki Schlarb 2020-07-20 20:01:44 UTC
SUMMARY
When running a GTK application using GMenu to export its menus on Wayland, GDBus-DBbusMenu-Proxy will not detect the menu exported by the application and hence will not publish an equivalent DBusMenu representation to com.canonical.AppMenu.Registrar.

STEPS TO REPRODUCE
1. Find any GTK application using `gtk_application_set_menubar(GMenu*)` to set its default application menu and hence exporting it onto D-Bus
2. Launch the application under Wayland
3. Check that the application publishes `${APP_ID_WITH_SLASHES}/menus/menubar` on D-Bus with the respective menu items

OBSERVED RESULT
The application's menu will not be detected at all by GDBus-DBbusMenu-Proxy and hence no Global Menu will be available.

EXPECTED RESULT
GDBus-DBbusMenu-Proxy should detect the menu and publish an equivalent D-Bus menu representation.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian unstable with KDE Neon user for Ubuntu focal
KDE Plasma Version: 4:5.19.3-0xneon+20.04+focal+build5
KDE Frameworks Version: 5.72.0-0xneon+20.04+focal+build7
Qt Version: 5.14.2+dfsg-0+xneon+20.04+focal+build11

ADDITIONAL INFORMATION
The obvious reason for why it doesn't work is because it only probes X11 attributes. Looking at https://wiki.gnome.org/Projects/GLib/GApplication/DBusAPI it is also not in any way obvious to me how auto-discovery of the menu information on Wayland would work at all?

If there is some way to match the application window with the GtkApplication's unique D-Bus name it should work, but I'm not sure such a facility exists?
Comment 1 Erin Yuki Schlarb 2020-07-20 20:37:40 UTC
(Note: Mostly I'm looking for hints where and how this should be implemented as its pretty obvious that there is no support for this as of now. I maybe should also mention that I know that `appmenu-gtk-module` exists, but that is a crude hack that eventually should be phased out and replaced by the native support where possible.)
Comment 2 David Edmundson 2020-07-20 22:14:55 UTC
We need to get the correct DBus service name + path for the appmenu for a given window.

Currently we look at an X property of the window for KDE's appmenu and GTK's appmenu then write back a new service and path to our proxy.

We have a wayland protocol for KDE's one
GTK/mutter have a wayland protocol for GTK's one

Wayland protocols are strictly between the compositor and the client and are not sniffable or editable.

To match that design we would need to:
implement https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/wayland/protocol/gtk-shell.xml in kwin

This is very problematic as announcing we support this means GTK will then "know" we support all the things on here - it's also unstable as a protocol and GTK specific.

We also then need to somehow write our proxy path back in a way that kwin keeps (in a brand new protocol bespoke to the proxy)

Then we would need changes on top to copy what we do for appmenu and then proxy that data from kwin through plasma-window-management protocol to the client.
Comment 3 Erin Yuki Schlarb 2020-07-22 03:55:12 UTC
So, I spent the last couple of hours of reviewing the involved stacks (thanks for the pointers!) and understanding your reply. As it is, implementing gtk-shell in kwin + plasma + GMenu-DBusMenu-proxy doesn't look very appealing anymore.

From what I gathered, the most forward way within the current architecture for getting this to work, would be to add a new special KWin <-> GMenu-DBusMenu-Proxy Wayland protocol that forwards gtk-shell's set_dbus_properties data to the proxy and has the proxy use org_kde_kwin_appmenu_manager to push the converted menu data back into KWin were it is then treated as if it came from the client directly. Does that sound about right?

That said, the much nicer solution would be to implement support for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/33 . Do you think they could be convinced to do that? ;-) [As in: Would it be worth the time to even try to implement that, or is that time better spent to getting a Plasma-specific codepath to work?]

PS: Looking through the other gtk-shell stuff it looks like at least modal, present/raise, startup-id and system-bell have no equivalent in wayland-protocols anywhere. Should this be tracked in some issue anywhere?
Comment 4 David Edmundson 2020-07-22 08:56:29 UTC
>As it is, implementing gtk-shell in kwin + plasma + GMenu-DBusMenu-proxy doesn't look very appealing anymore.

Yeah, ultimately I think we need to re-architecture some parts.

>org_kde_kwin_appmenu_manager to push the converted menu data back into KWin were it is then treated as if it came from the client directly.

You can't do that, it'd have to be a new protocol where you can manipulate other clients.


>https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/33

I don't think that as-is helps a lot, GTK doesn't use AppMenu's so they wouldn't be using that protocol.

If it was made into a more generic protocol that attached any DBus service to a window that would be very useful.

>PS: Looking through the other gtk-shell stuff it looks like at least modal, present/raise, startup-id and system-bell have no equivalent in wayland-protocols anywhere. Should this be tracked in some issue anywhere?

Yeah, we need to get them into upstream.
Comment 5 Erin Yuki Schlarb 2020-07-22 10:26:47 UTC
Assuming we got something like https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/33 but for org.gtk.Menu, that would 

Would it be an acceptable solution to move GBus-DBusMenu-Proxy into plasmashell? Or is that undesirable for some reason?

On a more fundamental level: At least GTK devs seem to believe that com.canonical.dbusmenu is a horrible mess and org.gtk.Menu is much better. Any opinions on this?
Comment 6 David Edmundson 2020-12-15 23:45:28 UTC
>Would it be an acceptable solution to move GBus-DBusMenu-Proxy into plasmashell? Or is that undesirable for some reason?

IMHO it's the cleanest. Abstract in library code to build a QMenu, no matter the source. Rather than importing and exporting again.

Seems like we have a plan.
Comment 7 Björn Bidar (Thaodan) 2021-03-21 18:16:32 UTC
*** Bug 423409 has been marked as a duplicate of this bug. ***
Comment 8 Björn Bidar (Thaodan) 2021-03-21 18:16:41 UTC
*** Bug 424181 has been marked as a duplicate of this bug. ***
Comment 9 Björn Bidar (Thaodan) 2021-03-21 18:16:51 UTC
*** Bug 431899 has been marked as a duplicate of this bug. ***
Comment 10 phrxmd 2021-12-23 11:55:33 UTC
While this is not fixed, is there a workaround to force GTK3 apps to show the menu in the application window instead? 

Currently with GTK3 apps on KWin Wayland 5.23.4 I get no menu at all (unless I force the app into XWayland mode with GDK_BACKEND=x11), which is not satisfactory.
Comment 11 Erin Yuki Schlarb 2021-12-25 19:17:42 UTC
(In reply to phrxmd from comment #10)
> While this is not fixed, is there a workaround to force GTK3 apps to show
> the menu in the application window instead? 
> 
> Currently with GTK3 apps on KWin Wayland 5.23.4 I get no menu at all (unless
> I force the app into XWayland mode with GDK_BACKEND=x11), which is not
> satisfactory.

Weird, Wayland GTK3 applications always show the menu in-window here, X11 GTK3-applications show it in the global menu. This makes sense given that KWin-Wayland does not implement the GTK-Shell Wayland extension at all.
Comment 12 phrxmd 2021-12-25 19:39:00 UTC
(In reply to Alexander Schlarb from comment #11)
> > Currently with GTK3 apps on KWin Wayland 5.23.4 I get no menu at all (unless
> > I force the app into XWayland mode with GDK_BACKEND=x11), which is not
> > satisfactory.
> 
> Weird, Wayland GTK3 applications always show the menu in-window here, X11
> GTK3-applications show it in the global menu. This makes sense given that
> KWin-Wayland does not implement the GTK-Shell Wayland extension at all.

Should I report this as a separate bug and what would be the place to do it?
Comment 13 David Redondo 2022-01-12 16:29:47 UTC
*** Bug 426253 has been marked as a duplicate of this bug. ***
Comment 14 phrxmd 2022-02-11 20:25:51 UTC
I reported the "no local menubar in GTK3 application windows" issue separately as bug 450038.
Comment 15 David Edmundson 2022-02-14 23:24:39 UTC
*** Bug 450038 has been marked as a duplicate of this bug. ***
Comment 16 Aleksana 2022-07-11 15:54:49 UTC
Any work on this?
Comment 17 Gerry Agbobada 2022-08-10 07:41:42 UTC
Hello,

I don't know if any easy enough solution for this bug has been found (and I'm definitely not claiming to have one), but I think it's worth considering adding this bug to the showstopper list [1], as not being able to access the menu from GTK apps vs. Qt apps feels like a big enough regression to me when going from X11 to Wayland.

[1]: https://community.kde.org/Plasma/Wayland_Showstoppers
Comment 18 Aleksana 2022-08-10 17:37:47 UTC
*** Bug 448452 has been marked as a duplicate of this bug. ***
Comment 19 Aleksana 2022-08-10 17:40:09 UTC
*** Bug 454943 has been marked as a duplicate of this bug. ***
Comment 20 phrxmd 2022-08-12 08:53:22 UTC
(In reply to Gerry Agbobada from comment #17)
> Hello,
> 
> I don't know if any easy enough solution for this bug has been found (and
> I'm definitely not claiming to have one), but I think it's worth considering
> adding this bug to the showstopper list [1], as not being able to access the
> menu from GTK apps vs. Qt apps feels like a big enough regression to me when
> going from X11 to Wayland.
> 
> [1]: https://community.kde.org/Plasma/Wayland_Showstoppers

+1 on adding this to the Wayland Showstoppers list. Currently I have to start GTK applications with `QT_QPA_PLATFORM=xcb` if I want to access any menu functions - otherwise I get no menu at all, global, in-window or otherwise.
Comment 21 phrxmd 2022-08-12 08:55:20 UTC
*** Bug 453600 has been marked as a duplicate of this bug. ***
Comment 22 phrxmd 2022-08-20 09:43:39 UTC
In addition, shouldn't this be "High priority" aka a "15-minute bug"? 

There's 8 duplicates and the problem appears in the default configuration as soon as you enable the global menu on Wayland - people are highly likely to use GTK applications and having their menus inaccessible is a problem.
Comment 23 Nate Graham 2022-08-20 13:50:39 UTC
Wayland-only issues aren't 15-minute bugs at this point in time because Wayland isn't the default Plasma session yet. Also, this affects only people using a non-default widget. It's listed on https://community.kde.org/Plasma/Wayland_Showstoppers, though.
Comment 24 Tohur 2023-01-17 00:00:05 UTC
I have found that any of the affected GTK apps you can force x11 and the menus work. Like so GDK_BACKEND=x11 appname
Comment 25 indecisiveautomator 2023-04-23 21:40:40 UTC
FWIW Forcing X11 is not ideal when using a scaled display in a mixed-scale setup, as the window will be blurry.
Comment 26 gonanza 2023-05-11 12:17:48 UTC
Wayland gets default on KDE soon. Does this change this case?
Comment 29 Naxdy 2023-08-09 12:21:57 UTC
@Fushan can you elaborate on this? Global menu is still not working for me in GTK (wayland) apps. Or is this a separate issue?
Comment 30 phrxmd 2023-08-09 18:28:36 UTC
Created attachment 160873 [details]
GTK3 app in Plasma 5.27.6 with no menu at all (neither local nor global)

What version should that be fixed in? According to that kded commit, it should work in 5.27.4. 

However, I just tested with Inkscape 1.2 on 5.27.6 and the behaviour with GTK3 apps on Wayland is the same: 
- by default on Wayland, nothing in the global menu, and no menu bar in the window either (see screenshot)
- if I add Inkscape to the `org.appmenu.gtk-module` blacklist, I at least get a menu bar in the window
- if I start Inkscape with GDK_BACKEND=x11, I get the global menu.
Comment 31 Naxdy 2023-08-09 18:32:35 UTC
For me, global menu is still in the GTK3 apps, not in the global menu bar... This is on Plasma 5.27.6 & GTK 3.24.37.

I'm reopening this, hoping for some more info.
Comment 32 phrxmd 2023-08-09 18:35:59 UTC
(In reply to Naxdy from comment #31)
> For me, global menu is still in the GTK3 apps, not in the global menu bar...

But you do get a menu at all, even if it's in the app window? I don't get that either, I reported that as bug 450038 but got referred back here.
Comment 33 Naxdy 2023-08-09 19:41:49 UTC
Yes, for wayland GTK apps I get global menu in the app, but not in the global panel. For XWayland GTK apps, I get it not in the app, but in the global panel.

For qt6 apps I don't get a menu anywhere, but that's a completely different issue (which has already been reported).
Comment 34 phrxmd 2023-08-11 13:46:24 UTC
Updated my OpenSUSE to Plasma 5.27.7, and to GTK 3.24.38 (which according to GNOME Gitlab should have the patch), and I still get no menu. Does this need anything else? Or is there additional information I can provide to help debug this?
Comment 35 Alex Noyle 2023-11-04 17:01:38 UTC
I am also still not seeing GTK global menus on wayland. They appear on the applications themselves, wasting a lot of space.

OS: Void Linux
KDE: 5.27.9
Comment 36 boite.pour.spam 2023-11-21 13:28:07 UTC
For what it's worth, it's still not working in 5.27.9: 

Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.5.11-1-MANJARO (64-bit)
Graphics Platform: Wayland

Any GTK application will not display a menu (either in their window, either in the global menu). 
When run with GDK_BACKEND=x11, the global menu is working and present, so it's definitively a wayland issue.

I couldn't reproduce  phrxmd's trick with the blacklist so I can't say if it works.  

Running dbus-monitor while launching inkscape and looking for menus returns:
```
method call time=1700572973.581778 sender=:1.378 -> destination=org.freedesktop.DBus serial=46 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender=':1.378',interface='org.gtk.Actions',member='Changed',path='/org/inkscape/Inkscape/menus/menubar'"
method return time=1700572973.581787 sender=org.freedesktop.DBus -> destination=:1.378 serial=45 reply_serial=46
method call time=1700572973.581789 sender=:1.378 -> destination=:1.378 serial=47 path=/org/inkscape/Inkscape/menus/menubar; interface=org.gtk.Actions; member=DescribeAll
[...]
method return time=1700572974.650189 sender=:1.378 -> destination=:1.378 serial=48 reply_serial=47
   array [
   ]
```
Comment 37 Guido 2024-02-28 14:47:49 UTC
I realised that in dconf there is a run-on-wayland entry under org.appmenu-gtk-module.

Despite this, the menu is not shown in the KDE global menu applet.
Comment 38 John 2024-02-29 12:22:07 UTC
With the Global Menu button on the window titlebar, LibreOffice's menus are vanished.

(it seems that disabling global menu is the only alternative...)
Comment 39 Méven Car 2024-03-01 12:04:29 UTC
I wonder if accessibility API (https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/) could be leveraged to access any accessibility compliant application menus.

Sort of like with selenium-at-spi. https://planet.kde.org/harald-sitter-2022-12-14-selenium-at-spi-gui-testing/
Comment 40 Nate Graham 2024-03-04 19:26:13 UTC
Promoting this to be a 15-minute bug since it's Wayland-only and the Wayland-session is the default in Plasma 6 now.
Comment 41 postix 2024-03-20 17:31:10 UTC
*** Bug 444609 has been marked as a duplicate of this bug. ***
Comment 42 Eugene San 2024-04-21 00:32:26 UTC
I know Plasma 6 is the main focus nowadays but the bug still affects Plasma 5 which is still shipped on Neon and upcoming Kubuntu 24.04 Plasma 5.27.11 and going to be an issue for a LOT of users and for a LONG time.
Comment 43 Björn Bidar (Thaodan) 2024-04-29 01:20:58 UTC
(In reply to Guido from comment #37)
> I realised that in dconf there is a run-on-wayland entry under
> org.appmenu-gtk-module.
> 
> Despite this, the menu is not shown in the KDE global menu applet.

From interaction with the developers of the other globalmenu panel there's specific work needed to support Wayland for GTK3 apps, not sure
if this applies to KDE panel.
https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/blob/master/subprojects/appmenu-gtk-module/src/platform.c?ref_type=heads#L236
Globalmenu for GTK4 through dbusmenu-gtk is dead as there are no global GTK plugins anymore.
Comment 44 Fushan Wen 2024-06-06 16:23:13 UTC
I have some ideas that doesn't require touching kwin but given GTK still supports X11, the bug is not that urgent to fix. I suggest removing the bug from the HI list until GTK drops its X11 support.
Comment 45 Naxdy 2024-06-06 16:28:26 UTC
I don't have any opinions on the priority of this issue, but I would like to point out that "use xwayland" is not a satisfactory workaround most of the time. Aside from global menu, apps perform differently under xwayland compared to wayland.

For example, on-screen keyboards have a much harder time detecting text fields. Certain apps update at a lower frame rate when running under xwayland, compared to X11 (for example VSCode/VSCodium, which is electron, therefore GTK).

And this of course is leaving aside the fact that the X socket is inherently insecure compared to the wayland protocols, so running sandboxed (e.g. flatpaks) apps under xwayland is undesirable based on that fact alone.
Comment 46 Eugene San 2024-06-06 18:36:45 UTC
I agree with Naxdy.
Workarounds might work if you need to deal with a couple of apps that misbehave.
I rely on several GTK apps and am forced to either run X11 session or maintain custom .desktop files (with GDK_BACKEND=x11) and deal with stuff Naxdy described under wayland.
Comment 47 Nate Graham 2024-06-08 00:08:34 UTC
At the KDE level it looks like this isn't actionable until https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/52 is merged. Since one precondition for merging will be draft implementations, and KDE is interested in it, there *will* be an implementation and hence we don't need to keep this bug report open as a reminder. I'll add it to https://community.kde.org/Plasma/Wayland_Known_Significant_Issues#Waiting_on_new_Wayland_protocol so we have an additional reason not to forget. :)
Comment 48 Björn Bidar (Thaodan) 2024-06-16 01:27:42 UTC
'
Since you change the bug report to resolved upstream doesn't it mean
it's closed now?
Comment 49 Fushan Wen 2024-06-16 05:07:29 UTC
Git commit 981502839f9ff4297983f728a1c689dbc2233a3e by Fushan Wen.
Committed on 16/06/2024 at 05:07.
Pushed by fusionfuture into branch 'master'.

appiumtests: test getting menu items from GTK window

1. Open a window with two hidden submenus
2. Match strings in the widget

M  +1    -1    appiumtests/applets/CMakeLists.txt
M  +63   -1    appiumtests/applets/appmenutest.py
A  +43   -0    appiumtests/applets/appmenutest_window.py

https://invent.kde.org/plasma/plasma-workspace/-/commit/981502839f9ff4297983f728a1c689dbc2233a3e
Comment 50 Marco Rebhan 2024-12-12 21:42:39 UTC
*** Bug 495658 has been marked as a duplicate of this bug. ***