Global menu

[Alexays]

[varac]

What is this about ?

[Alexays]

Look at kde global menu

[ripefig]

Any progress on this? I'd recommend maybe not a global menu, but a window tile widget that when (right?) clicked brings up a popup palette with a list of all menu items. This way could even access menus for multiple recent windows, without having to focus each window before accessing the global menu. So you just have a window title widget and if the app exports menus there could be some indicator of that fact in the widget.

Also many programs don't use menus at all, so a classic "global menu" wouldn't really be global.

[Kommynct]

I feel like it'd make more sense for something like wofi to handle this.

[WillPower3309]

Any progress on this? I'd recommend maybe not a global menu, but a window tile widget that when (right?) clicked brings up a popup palette with a list of all menu items. This way could even access menus for multiple recent windows, without having to focus each window before accessing the global menu. So you just have a window title widget and if the app exports menus there could be some indicator of that fact in the widget.

Also many programs don't use menus at all, so a classic "global menu" wouldn't really be global.

That would also be something really cool to see, and something I'd likely use on sway. That being said, a traditional global menu would be a really "nice to have" feature for any floating compositors that come out, and would allow waybar to be more compositor agnostic

[puresoul]

Hi, got somehow same idea, but for now it's just simple launcher. Chosed "nwg-menu" as base for my menu, but have a little struggle with on which output will menu open. Because don't using "focus with mouse" in sway, menu opens on workspace (output) with focus and that may not be always the right one :-D

For now I hacked it with ugly double configuration for every output and running menu with right output as "static string" argument.

I already searched for idea how to do it inside gotk3 and finally asked there, if its possible, but got another idea, so my question.

Is there some way how to dynamically (variable?) tell custom module on which output was executed?

Thanks

my hacked menu https://github.com/puresoul/nwg-menu

[OJFord]

What is this about ?

Look at kde global menu

It seems it's a macOS-style menu bar (of File, View, etc.) for the whole workspace, replacing a per-window (on the window) bar, so you only see one - for the focussed window - and it's not necessarily anywhere near the window:

[henriquepicanco]

This would be a very, very, very (I've already said "very"?) awesome module for the Waybar.

[dmacvicar]

@Alexays I gave this a shot as I have been using labwc with Waybar, and one of the few things I am missing are global menus.

tl;dr: the whole appmenu story is kind of broken in Wayland if you are not on KDE / GNOME.

Getting a quick and dirty menu module to display the menu of an application was quite straightforward, as long as I hard-code the dbus menu service and path for a running application. All the required infrastructure is part of GIO DbusMenuModel.

Eg. for transmission-gtk

The non-trivial part is for the module to get the current active window and from there the service/object path of the dbusmenu.

The original com.canonical.AppMenu.Registrar worked in a way apps would register those dbus properties with their Windows Id, so that the bar could keep the association. This is even unnecessary as the information is also set as xprops (_KDE_NET_WM_APPMENU_OBJECT_PATH / _KDE_NET_WM_APPMENU_SERVICE_NAME and _GTK_APP_MENU_OBJECT_PATH and _GTK_MENUBAR_OBJECT_PATH)

This does not work in Wayland. Apps would set bogus WindowId=1 or skip the registrar, and there are no xprops.

For Wayland, Plasma sets those props in a Qt extended surface protocol, but then the menu bar needs to talk to the compositor off-band to get this information, as there is no way to get this information from Waybar.

Gtk apps do something similar with another specific protocol (gtk-shell), which can't be used by Waybar. One would need the compositor to implement it and then Waybar would need a way to access this (IPC, like sway provides). This would tie the module with the compositor.

From there I suspect there are a few additional roadblocks to get the apps to automatically export their menus. Eg. keepassxc would only export them (under Wayland) when com.canonical.AppMenu.Registrar service is running (?). But I don't have the full picture here.

I started the module as a fork of the taskbar, hoping that the foreign top-level protocol would give me the starting point of activated windows. But the information it provides about the top-level is not enough to from there get to the dbusmenu services from that top-level.

I am a bit out of ideas 🤔. Perhaps I am missing something on how the protocols can help here.

Last thing floating in my mind was some kind of heuristic. Going from top-level app-id (provided by the protocol), to scan the whole session bus for the dbusmenu interface and try to match 🙈.

Some resources:

• https://docs.gtk.org/gio/class.DBusMenuModel.html
• https://blog.broulik.de/2016/10/global-menus-returning/
• https://wayland.app/protocols/kde-appmenu
• https://wayland.app/protocols/gtk-shell
• https://chromium-review.googlesource.com/c/chromium/src/+/3481665
• https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/blob/master/subprojects/appmenu-gtk-module/src/platform.c?ref_type=heads

[probonopd]

Great feature addition, appreciate it 👍 👍 👍

Do you fully understand https://blog.broulik.de/2016/10/global-menus-returning/? (I don't but I figure that they use "Qt’s Extended Surface protocol" as a replacement for X11 atoms.) It specifically talks about Wayland and I can confirm that the global menu implementation in KDE Plasma works under their Wayland compositor, kwin_wayland. Maybe it'd be helpful to run a KDE Plasma session, configure a panel with the global menu there, and use it for comparing what they are doing there?

Which brings me to the point: With Wayland, it seems that Qt has its own protocols, which may or may not be supported by non-KDE Wayland compositors. So it'd probably be worthwhile to check whether wlroots already supports "Qt’s Extended Surface protocol". And as a result, things like global menus need to be implemented specifically for each compositor... argh!

Cross-reference (what a coincidence):

• https://github.com/CuarzoSoftware/Louvre/discussions/15

[dmacvicar]

This is, as I understand it because the extended surface protocol is between the app and the compositor (Kwin). The menu applet can talk off band with Kwin (probably dbus).

An obvious path is the foreign_toplevel protocol. If you as a bar/taskbar implement this protocol, the compositor will tell you about the surfaces that become focused/toplevel and give you an API to activate them. This is eg. used by Waybar taskbar. It does not however provide the information to get the menu (DBUS service object path).

A potential "right" fix, as I understand it, could be to implement both the Qt surface protocol and the Gtk shell protocol in wlroots, and extend the foreign toplevel protocol to carry this information to bars/taskbars/menubars. Then this would work with sway, labwc and others. I could be totally wrong here and would need to get some expert opinion. Another solution would be to hook into the toolkits and carry both the dbus info and the surface activation info off-band (eg. via dbus).

[probonopd]

I hope this can be done in a compatible way so that we don't end up with different protocols for achieving the same end result.

[dmacvicar]

I tried the offband approach too: built a gtk module that knows when any windows is focused. Plan was to extend the registrar to send this info, in addition to the dbus information.

It was going well until I ported to gtk-4 and horror :scream: : there are no longer general-purpose gtk modules in gtk-4.

Following the discussion, the removal of the modules and hacks seems reasonable, but this question was not addressed:

What we lost and we are asking is how we can recover the possibility to auto-export the menu without depend of the decision of the developer of the Gtk application. How we can do by our self for example:

Conclusion:

• Gtk4 apps have a way to export the menu bar by using GMenu,which not all apps use (port from GtkMenu)
• Gtk4 apps do not seem to export them by default. Seems like an opt-in? (see gtk_application_impl_dbus_publish_menu )
• Gtk4 can't be forced to display them with hacks like modules

Can we even force a (ported to GMenu) app Gtk4 app to export its menus?

At this point I even forgot how I got the transmission app working with Waybar and a GMenu Dbus client (above), given that is linked to Gtk4. Or was I using the Qt frontend?

[skela]

Might be some useful stuff in Fildem that might help here as well? https://github.com/Weather-OS/Fildem-v2

I've got a global menu in qtile, and frankly i don't understand how people can use tiling window managers without them. I very much want to use hyprland with the waybar, but the lack of a global menu feels wrong to me.

Having a widget in the waybar that appears if the focused window has a detected menu, and a keyboard combo shortcut to bring up the menu. That would be fantastic.

[OJFord]

I've got a global menu in qtile, and frankly i don't understand how people can use tiling window managers without them.

What's the connection? If anything I would think using a tiling wm makes it more likely the window is further away from the menu location, which is what I don't like about them even without tiling (e.g. using someone's Mac). Happily using sway without one, and i3 before that.

[dmacvicar]

Please lets keep the conversation focused. I am not collecting personal desktop preferences, but concrete information on how I can move forward the protoype I have for Waybar.

I posted a summary of what the challenges are:

• Waybar is not a compositor, therefore it can only get info about activated windows via foreign_toplevel protocol, which only gives a handle and events on activation, but not info about their dbus interfaces. Some bars like KDE/Gnome extensions can get windows and dbus interface activity via the compositor because they have special APIs for it. Eg. TaskManager library in Plasma, wich Plasma appmenu applet uses.
• gtk3 apps need a special module, which does not exist (nor can exist) for gtk4. The module works with a service registering X11 dependent IDs
• gtk4 apps seem to expose the dbus information via a special gtk_shell protocol, which gnome-shell understands and has access to (being a compositor)
  • this menu is however, not exported by all applications automatically, and can't be influenced from the environment whether they do or not
  • when they do, it is the GIO DBusMenu protocol, which ironically, it is the easy to implement for waybar as a client.
• Qt apps are in good shape, because they export the menu, but in order to know the service location, you either use the X11-based registrar service, or you are compositor speaking the Qt surface protocol, which KDE does.

The best information I coult get is to dissect whether the following use-cases are possible, or whether someone has implemented them (all on pure-Wayland):

• a Qt app displaying a menu in some bar, not under KDE
• a Gtk4 app exporting the menu, not under Gnome
• a Gtk3 app, exporting the menu, not using the appmodule, or the menu not being displayed by a compositor plugin or extension, but a completely separate program

Otherwise, it would be best to start with labwc or an interface at the compositor level, which then bars can hook into (something like sway IPC).

[alexhulbert]

I think this should be possible on the hyprland wayland compositor with a hyprland plugin. Another plugin called "hyprriver" adds support for an extra wayland protocol and keeps track of metadata at the output level. The file that actually handles this is here. Similar code could be written for the qt surface extension protocol, which would allow the plugin to communicate the dbus object path and service name for the focused window to waybar. It would also allow plasma-hud to work on wayland as well. I almost want a global menu enough to write the plugin myself, but writing a hyprland plugin to work with the qt surface extension would be a little too much work for the effort. However, if someone else gets a working proof of concept to println the APPMENU_SERVICE_NAME and APPMENU_OBJECT_PATH of a given window when it makes a wayland protocol request, I'm happy to take it the rest of the way by keeping everything recorded in a variable, setting up the process communication and writing a waybar module. Also, I think some combination of the following allows non-qt windows to have the same KDE_WM appmenu properties added to them:

• setting the GTK_MODULES env var to appmenu-gtk-module (with the associated package installed)
• running kded5 in the background and then loading the appmenu module with qdbus org.kde.kded5 /kded org.kde.kded5.loadModule appmenu
• running the gmenudbusmenuproxy daemon

I think this would make it so the GTK stuff doesn't need to be considered as a separate case. I'm not sure how exactly GTK4 fits into this picture, but I'd imagine if the above kde components don't already support GTK4, they will soon.

[Sodivad]

Hi we actually do not use qt-surface-extension for this (anymore? this was before I joined devleopment) but have our own protocol for appmenu . Related is the standardising effort https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/52