search

Alexays / Waybar

Highly customizable Wayland bar for Sway and Wlroots based compositors. :v: :tada:
MIT License
6.35k stars 691 forks source link

Global menu #288

Open Alexays opened 5 years ago

varac commented 5 years ago

What is this about ?

Alexays commented 5 years ago

Look at kde global menu

ripefig commented 4 years ago

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 commented 4 years ago

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

WillPower3309 commented 3 years ago

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 commented 2 years ago

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 commented 1 year ago

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:

KDE global menu

henriquepicanco commented 1 year ago

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

dmacvicar commented 10 months ago

@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

grim-2023-11-18-183452

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:

probonopd commented 10 months ago

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

dmacvicar commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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:

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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:

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

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 commented 7 months ago

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:

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 commented 5 months ago

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