Bug 424485 - GDbus-DBusMenu-Proxy does not work for GTK Wayland apps
Summary: GDbus-DBusMenu-Proxy does not work for GTK Wayland apps
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Unclassified
Component: Global Menu (show other bugs)
Version: 5.19.3
Platform: Debian unstable Linux
: NOR normal
Target Milestone: 1.0
Assignee: Kai Uwe Broulik
URL:
Keywords: wayland
: 423409 424181 426253 431899 448452 450038 453600 454943 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-20 20:01 UTC by Alexander Schlarb
Modified: 2022-08-12 08:55 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 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 Alexander 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 Alexander 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 Alexander 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 Alexander 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. ***