Proposal: add a global menu portal

[SimoneRiccardi]

It would be a good idea to have a portal that permits the status bar to show and interact with the application options menu and permits the applications to remove their menu bar, as it happens in macos and kde (https://preview.redd.it/xzl2tdkgixl31.png?width=1423&format=png&auto=webp&v=enabled&s=9ae125c4ad01907f02537ffb7fd0d15835bd4965)

KDE has it's own protocol to interact with the application options, but it would be a better to have a standard way independent from the DE to do that

A global menu permits to be more space efficient ( because it became possible to remove a bar from all applications on screen, leaving more space to the content while using space of the bar that usually would be unused), looks better and create a more consistent environment (the option of the selected application are always in the same place)

[RossComputerGuy]

I am very interested in this as well. I've tried coding in reading global menus and there should be 1 standard way of doing it.

[AdrianVovk]

Why does this need to be a portal, and not just an API implemented by apps and exposed via dbus on the name they own? Similar to org.freedesktop.Application or org.gtk.Application, you could have org.freedesktop.GlobalMenu. Then the DE finds the focused app's dbus name and displays the menu from there

[Mikenux]

A portal is needed when you need to pass information from a (logically) sandboxed app to the system (e.g. the notification portal). The portal code is responsible for validating this information. I think this is the case here because a menu needs to be exposed, and perhaps icons if some DEs use them for the menu. This may also include a way to handle abusive requests to change the menu (if applicable).

[AdrianVovk]

Sending a notification is in immediate and disruptive action. That's why it needs a portal - to prevent apps from abusing the functionality

Just exposing some data on the bus needs no portal and would already work with no changes to Flatpak. Apps can already own their own name on the bus and expose whatever they want there.

An app cannot abuse the global menu any more than it can abuse a menu bar it renders on its own

[alice-mkh]

(I should note that global menu already exists, at least in gtk)

It's just that most apps don't have menubars in the first place.

And as Adrian mentioned, it's on the app's own names so doesn't need any sandbox holes. The demo on the screenshot is running in flatpak, btw.

[Mikenux]

But it seems a standard is needed as per first comments.

Also, if I'm not wrong, if someone also wants icons, this still need a standard validator somewhere.

[Makrennel]

at least in gtk

IIRC, global menu gripes seems to be a largely Wayland specific problem of standardization. KDE apps were using a kwin specific protocol while GTK apps were using a GNOME/mutter specific protocol to replace what was previously a X protocol, and KDE was not willing to implement the GTK protocol because it would be an endorsement of GTK? Something like that.

I think they've marked this as "Resolved upstream" now though, and they are waiting on a Wayland protocol to be merged to fix it.

[alice-mkh]

But it seems a standard is needed as per first comments.

You don't need a portal for that. Standards have existed long before portals have. Portals are specifically dbus interfaces accessible from sandbox too. This doesn't need to be accessible in sandbox, the menu is displayed by the compositor/panel/whatever, apps just provide it. Apps don't need to see each other's menus.

IIRC, global menu gripes seems to be a largely Wayland specific problem of standardization. KDE apps were using a kwin specific protocol while GTK apps were using a GNOME/mutter specific protocol to replace what was previously a X protocol, and KDE was not willing to implement the GTK protocol because it would be an endorsement of GTK? Something like that.

GTK interface does not care about display server. The screenshot above was taken on Wayland btw.

You can make an interface display server-specific if you e.g. identify windows in a certain way, and Canonical's interface was indeed X11-specific (and hacky in many other ways too). GTK one doesn't care - it's defined for an app, not for a specific window.

And no, the GTK interface is not GNOME-specific in any way and GTK never had any X11 protocols for this. It's just dbus, nothing more.

Anyway - sure, a standard would maybe be nice (questionable because GNOME has dropped menubars a decade ago and KDE doesn't have menubars for new apps either + almost no third party apps do), but it has nothing to do with portals either way.

[Mikenux]

@Makrennel: Could you give a link to the relevant Wayland protocol?

@alice-mkh: If the compositor has validation or some equivalent for security, I guess there is no problem. But be careful about what you report as "arguments":

Apps don't need to see each other's menus.

What does this have to do with portals?

KDE doesn't have menubars for new apps either + almost no third party apps do

We're talking about the classic menu here, not actually menu bars. For example, Okular has a classic menu as a menu bar, while Gwenview and Dolphin have it in a hamburger menu.

[Mikenux]

To make sure we're talking about the same thing:

This involves exporting the app menus so that the desktop environment presents them as a menu bar in, for example, its own top bar. The desktop environment (compositor) needs to tell the app that global menu is enabled or disabled so that it can hide its relevant UI elements that have a menu.

This is not about telling the app whether or not to show a menu bar in its own UI.

[alice-mkh]

What does this have to do with portals?

Because that's an example of a thing that would involve a portal. Portals are for allowing apps ask the host for things they can't do themselves. Apps do not need a portal to expose a menu that the host can read. MPRIS does not need a portal. Accessibility does not need a portal. Global menu does not need a portal. Apps would need a portal to read a menu from the host. But that's not how it works.

For example, Okular has a classic menu as a menu bar, while Gwenview and Dolphin have it in a hamburger menu.

None of those apps are even remotely new.

• Dolphin's initial commit is from 2006 - 18 years old.
• Gwenview's initial commit is from 2002, 22 years old.
• Okular's initial commit is from 1997. 27 years old.

New apps are e.g. the ones using Kirigami, like https://apps.kde.org/elisa/. These apps do not have a menubar.

This involves exporting the app menus so that the desktop environment presents them as a menu bar in, for example, its own top bar.

Correct, which does not require a portal, as both me and Adrian have explained.

Did you not see my screenshot? That's it, in the lower left corner. The exported menu.

This is not about telling the app whether or not to show a menu bar in its own UI.

Ironically, this is the only thing in this whole area that would need a portal. Not a new one tho, just a pref standardized in the settings one, like GTK's gtk-shell-shows-menubar.

This is not about telling the app whether or not to show a menu bar in its own UI.

Of course it's not, no one was even talking about that. Where is that even from, lol?

[Makrennel]

@Makrennel: Could you give a link to the relevant Wayland protocol?

The KDE discussion I was referring to: https://bugs.kde.org/show_bug.cgi?id=424485

The Wayland protocol needed: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/52

[alice-mkh]

So yeah, associating menus with specific surfaces. Fair enough, I mean if you want per-window menus, then you do need that, yeah.

[Mikenux]

@Makrennel: Thanks!