Bug 424485

Summary: GDbus-DBusMenu-Proxy does not work for GTK Wayland apps
Product: [Plasma] plasmashell Reporter: Erin Yuki Schlarb <erin-kde>
Component: Global MenuAssignee: Kai Uwe Broulik <kde>
Status: CONFIRMED ---    
Severity: normal CC: 4wy78uwh, 7erxk5uav, alenertz, alexander.huang.y, alexnoyle, andre.vmatos, andriy.parhomenko, andydecleyre, bednarczyk.pawel, blackspart57, boite.pour.spam, chermnykh2001, CoelacanthusHex, cristobal.veas, dashonwwIII, edwin.frank.loeffler, etaash.mathamsetty, gagbobada, gonanza, gudvinr+kde, hey, indecisiveautomator, j5lx, johnmaverick74, joshwebb84, kde, kimiblock, Linus, luisbocanegra17b, me, me, miranda, miren_radia, mvourlakos, nate, philipp.reichmuth, plasma-bugs, postix, quarckster, qydwhotmail, sam, simonmik2006, starterx4, szymek.januszek, tbondvagyok, tromzy, xnaxdy, ybjqx3340
Priority: NOR Keywords: wayland
Version: 5.19.3   
Target Milestone: 1.0   
Platform: Debian unstable   
OS: Linux   
Latest Commit: Version Fixed In:
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 [
   ]
```