Global Menu no longer working

meven · July 3, 2025, 7:54am

NO.

This protocol needs application support that is patches to Qt AND GTK.
This would be kinda horrible to do this forcefully for a distro and hard to maintain.
See “FOSS has limited resources”.
Worse GNOME has its own incompatible solution for GTK applications, they just don’t care about making a proper protocol so that all compositor and toolkit can use the same generic solution.

tldr; GNOME and Sway devs don’ t want to admit anything to the standards they don’t want to support themselves, for their own reasons, even when there is huge demand.
This was happening for fractional scaling for a while but other compositors pushed it forward (Making sure you're not a bot! no GNOME/GTK ACK one can notice neither ACK or implementation )
The only way forward IMO is staging/experimental implementation in KWin (and other interested compositors), then we can have applications pushing for it, like what happened with fractional scale. Then GNOME devs will have to listen to reason and follow the hurd eventually.

Guido_I · July 3, 2025, 8:43pm

Wayland is making free software free only on paper. Red Hat and GNOME decide to not implement protocols despite popular demand. I think Wayland is a disgrace.

8py · July 3, 2025, 9:54pm

Since the text menu works and the button menu doesn’t it seems like it is just a bug. Not sure what all this other noise has to do with anything. To repeat myself again: I do not use wayland, nor do I intend to any time soon. Should have nothing to do with patches, or Ubuntu or any of these other things that are being mentioned. Probably just a simple bug, if it wasn’t the text based appmenu would also not work.

Joanne · July 3, 2025, 11:27pm

I don’t like the language used here and it touches the edges of the code of conduct in my opinion. I moved to KDE a decade ago from other desktops because I felt the community was a lot friendlier but I can’t say it anymore. Recently this demonizing of other projects and volunteers have been happening a lot and using a drama youtuber who gets paid from causing outrage is another reason for its raise.

tldr; GNOME and Sway devs don’ t want to admit anything to the standards they don’t want to support themselves

and it’s their right to do so, isn’t it? I wouldn’t want their ideas that don’t align with KDE’s to dictate how KDE works and it’s fair for them to do the same. Treating other projects as enemies doesn’t help anyone.

This was happening for fractional scaling for a while but other compositors pushed it forward (Making sure you’re not a bot! no GNOME/GTK ACK one can notice neither ACK or implementation )

They did implement it and I see them discussing the details in the comments “Robert Mader, 3 years ago, Did a draft for Mutter at …”. Again, no point in demonizing volunteers, as Simon said “That’s not a very nice way to ask for ACKs, nor push the Wayland ecosystem forward. -1.”

Then GNOME devs will have to listen to reason and follow the hurd eventually.

Again, not nice to peer pressure other projects to accept conventions they don’t want by riling up the public against them.

I’ve been in this community for ages and have only observed this happening more and more often and I don’t like it. This was also unnecessary and comes across as ‘sore loser’ behaviour:

github.com/xapp-project/libadapta

Consider which forces you want to support

opened 10:24AM - 19 May 25 UTC

closed 02:12PM - 19 May 25 UTC

jpetso

This is more of an opinion than a request, I'd expect that the issue will be clo…sed after consumption and that's fine. In the [introductory blog post](https://blog.linuxmint.com/?p=4840), you write the following: > Whether we downgrade or fork applications, I know many of the GNOME developers are as sad as we are about this fragmentation and duplication of efforts. We were talking about extracting epub support in Xreader last week and making a new app. It would take between a week and a month to achieve the level of functionality we see in something like Foliate, but what’s the point long-term? Wouldn’t it be better for Foliate to work outside of GNOME and for us to use it? > > Within our XApp discussions we talk about Qt, GTK3, application alternatives, forks and rewrites. What we looked at recently is slightly different. How do we make GNOME apps continue to work outside of GNOME? > > Is there anything actually wrong with them once they follow the theme and provide proper window controls? First up, I'd like to commend your consideration for this issue of fragmentation and duplication of efforts. I strongly agree that this is an important issue, probably responsible to a certain extent in holding back free desktops from wider adoption in the mainstream. With a project as significant as Linux Mint, it's good to know that decisions to fork and diversify efforts are not made light-heartedly. It is also uncontroversial that fragmentation exists right now. Apart from XApps, KDE has long been maintaining its own ecosystem, COSMIC Desktop is about to popularize another new stack with all of the basic tools, and of course there are others. These are all meant to be themeable and to integrate well into also other desktop environments. In practice, there may be a few more snags to overcome, but the will is there, the goal is achievable. For GNOME this is a non-goal. Their design philosophy assumes that you use the GNOME desktop with GNOME apps. Their goal is not to make apps *support* GNOME but instead for apps to *become* GNOME. This philosophy of appropriation informs not just colors and button shapes, but extends to architectural and UX concerns as well. The two first issues opened for this project (libadapta) are called "[Support global menu bar](https://github.com/xapp-project/libadapta/issues/1)" and "[Option to force server side decorations](https://github.com/xapp-project/libadapta/issues/2)". As a knowledgeable engineer, you will be well aware that neither of these can make sense with GNOME apps because they are specifically designed around the lack of these elements. Adding some hack to enable these features in libadapta would always result in a subpar experience. Without asking you to go into any particular direction, I would like to point out that by supporting the GNOME ecosystem, by joining forces with libadwaita apps, you will be making that ecosystem stronger at the expense of everything else that still holds on to the dream of a personalized desktop experience. You can undo color limitations in libadwaita, but in the long-term you will be forced into the technical and ideological direction that GNOME wants libadwaita apps to go. Like Proton's fate is to accept Microsoft's DirectX design choices and implement them on Linux as good as possible with hopefully not too long of a delay, the libadapta approach essentially provides an emulation layer for GNOME apps with no real say in the long-term direction of their development. If this is an acceptable trade-off to you, then that's that. However, please do consider that your development strength could also be thrown behind existing non-GNOME apps that hold up the ideals of cross-desktop compatibility and theme support. Instead of admitting defeat to the uniformity of the GNOME ecosystem and joining them, Linux Mint could strengthen the competition that still believes in a common Linux platform for apps, rather than a [GNOME platform](https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linux-platform-1/). This is admittedly the harder way and there is no guarantee that it'll work out. Thank you for reading and all the best in your endeavor, whichever way it goes.

I’m sorry to say this, but as stubborn as GNOME devs are, they never go after third-party projects trying to convince them to avoid KDE and Qt nor have they tried to peer pressure other desktops into following their paradigms. In fact I often see them on r/linux suggesting users to use KDE or XFCE if they are looking for something else.

8py · July 4, 2025, 1:34am

@EliteAMDGamer
@meven
@Joanne

If there is not something related to the issue that I am having in anything you’ve got to say, could you start a new thread or go away. Okay, thank you in advance.

I mean don’t get me wrong, I agree with a lot of what you are saying and really hope plasma 7 has x11 support, but I guess we’ll see. Just a topic for another post. I seriously cannot stand wayland. I mean if it matures significantly over the next 2-3 years, then maybe I’ll check it out but right now it is not worth using in my opinion (breaks too many things, heard it uses slightly more cpu, literally pointless for my use case, etc..etc…). Should probably get away from systemd too one of these days, but that too, is a topic for another thread.

EliteAMDGamer · July 4, 2025, 1:59am

I fully agree with you an yeah I’m 100% for standards as its 2025 an long over due.
I would love a kwin implementation. As I’ve been wanting zed to implement the feature for just basic support for non hamburger menus. Setting to always show menu bar · Issue #22869 · zed-industries/zed · GitHub I would prefer it use the global menu but one step at a time. Though since electron supports the current kde global menu protocol maybe it could support the newer one. Maybe flutter? Though I bet they wouldn’t move tell after the implementation is fully made.

@8py sorry about that.

I can also replicate your issue. Normal menu is fine but the hamburger one is broken. In wayland as well.

8py · July 4, 2025, 2:15am

@EliteAMDGamer

Yes, that is the exact issue I was referring too. Thanks for the confirmation for wayland and x11. So, it must be a bug somewhere.

@Guido_I

Can you link to the bug you were referencing earlier as updating the system update did not fix it? Want to make sure someone does not need to file a new bug for this issue.

Guido_I · July 4, 2025, 5:20pm

506170 – Global menu widget doesn’t work in single-button mode 506170 – Global menu widget doesn't work in single-button mode

8py · July 5, 2025, 11:36pm

Thanks @Guido_I
I added a comment to the bug that it still persists in 6.4.2-1 on Arch Linux. May have to wait until next release, not really sure.

meven · July 8, 2025, 9:43am

I agree with you, some of my statements were very blunt, emotionally motivated, incorrect and inaccurate.

Feel free to flag this so other moderators can state on it.
I am a moderator but I don’t want to be involved in this conversation.

poljpocket · July 8, 2025, 2:23pm

Just to add to this. For me, the collapsed global menu works as expected and it seems, at least for Wayland, the issue has been fixed.

My system versions:
Operating System: Arch Linux
KDE Plasma Version: 6.4.2
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.5-arch1-1 (64-bit)
Graphics Platform: Wayland

8py · July 9, 2025, 8:12pm

@poljpocket
Oh, I see. Maybe the fix is just for wayland/wayland specific?

I’ll edit my other post on the bugtracker to include this info. Thanks for the update.

8py · July 9, 2025, 8:19pm

@meven
It seems like the overly excited commentary has ceased. If it turns into some type of flame war I’ll close this thread right away, because that is not what this thread is/was meant to be about. Just a singular issue.

Guido_I · July 10, 2025, 5:37pm

It is not clear to me why this requires a wayland protocol. The global menu is exported via dbus. What does wayland have to do with it?
QT applications correctly export the menu to Wayland.
GTK applications do too, but only when launched with XWayland.
So the problem is, if anything, GTK-wayland’s global menu plugin. Wayland in itself doesn’t have much to do with it.

I recently discovered by chance that if I launch Chromium with GDK_BACKEND=x11 chromium --ozone-platform=wayland it happens that Chromium is launched as a Wayland client but nevertheless the global menu is correctly exported.

Guido_I · July 10, 2025, 5:41pm

you are right, I tried it and the single button does not work in X11. Nobody cares who uses X11.

8py · July 10, 2025, 6:12pm

They probably just don’t customize their system that much. My system is pretty plain besides my panel (window buttons, custom commands, etc..), well and klassy.

Guido_I · July 10, 2025, 6:25pm

I don’t think that’s the problem, looking at the code of the fix there is a check that concerns only Wayland.

if (KWindowSystem::isPlatformWayland() && view() == CompactView) {
            m_currentMenu->popup(pos);
            connect(actionMenu, &QMenu::aboutToHide, this, &AppMenuApplet::onMenuAboutToHide, Qt::UniqueConnection);
        }

8py · July 10, 2025, 10:08pm

Oh, I see. Well, that is unfortunate. Bad feels on this one. I really hope that they fix it for both wayland and x11. Just have to wait and see I guess.

meven · July 11, 2025, 7:34am

It does not matter if that’s implemented with Dbus or with Wayland. The current PR for Wayland exposes a Dbus entry point, so it even mixes approach to minimize the work to transition from previous X11/Dbus implementation.

The main point is to standardize things, so that the support can be widespread and not just reserved to part of the ecosystem.