| Summary: | GDbus-DBusMenu-Proxy does not work for GTK Wayland apps | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Erin Yuki Schlarb <erin-kde> |
| Component: | Global Menu widget | Assignee: | 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) | ||
(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.) 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. 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? >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. 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? >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.
*** Bug 423409 has been marked as a duplicate of this bug. *** *** Bug 424181 has been marked as a duplicate of this bug. *** *** Bug 431899 has been marked as a duplicate of this bug. *** 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. (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. (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? *** Bug 426253 has been marked as a duplicate of this bug. *** I reported the "no local menubar in GTK3 application windows" issue separately as bug 450038. *** Bug 450038 has been marked as a duplicate of this bug. *** Any work on this? 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 *** Bug 448452 has been marked as a duplicate of this bug. *** *** Bug 454943 has been marked as a duplicate of this bug. *** (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. *** Bug 453600 has been marked as a duplicate of this bug. *** 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. 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. I have found that any of the affected GTK apps you can force x11 and the menus work. Like so GDK_BACKEND=x11 appname FWIW Forcing X11 is not ideal when using a scaled display in a mixed-scale setup, as the window will be blurry. Wayland gets default on KDE soon. Does this change this case? IIRC the bug has already been fixed for a while. https://gitlab.gnome.org/GNOME/gtk/-/commit/a40126e1f91a0cc8c45203d9ff229f65952eb541 https://invent.kde.org/plasma/kde-gtk-config/-/commit/1608cf03670c71d85f110a7d2dda1c576e939032 @Fushan can you elaborate on this? Global menu is still not working for me in GTK (wayland) apps. Or is this a separate issue? 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.
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. (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. 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). 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? 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 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 [ ] ``` 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. With the Global Menu button on the window titlebar, LibreOffice's menus are vanished. (it seems that disabling global menu is the only alternative...) 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/ Promoting this to be a 15-minute bug since it's Wayland-only and the Wayland-session is the default in Plasma 6 now. *** Bug 444609 has been marked as a duplicate of this bug. *** 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. (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. 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. 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. 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. 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. :) ' Since you change the bug report to resolved upstream doesn't it mean it's closed now? 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 *** Bug 495658 has been marked as a duplicate of this bug. *** |
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?