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):

• appmenu support for global menus CuarzoSoftware/Louvre#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).