Global menu is getting cut out

Almost a month later, I cleared out some of the other elements on the top bar and reinstalled the current Global Menu that is present in 19.10. (No PPA, purged as per request) I have shifted the clock to the far right, just before the raven bar, and activated the power strip on the raven bar. I have removed the off button on the bar.

Even though the menus are currently too tightly spaced for my liking they are surprisingly handy, and I think I will keep the Global Menu present for now. I am looking forward to the revised Global Menu is 20.04 :slight_smile:

Good news, it’s fixed in 20.04 :


Far left is pixel-saver ( with 32 characters for title ) then still on left side global menu ( gimp + plugin-registry to be sure to display much menu ) and it’s no longer truncated at the middle top panel.
Ok too in LibreOffice.

Side note : Firefox no longer sends its menu to the global menu applet, you have to hit Alt key to make them appear “in” Firefox, not in the panel.

Canonical have deliberately removed support for global menus in 20.04 and later. The unique 20.04 code patch is very difficult to maintain with each and every firefox version. To reduce the maintainence burden this is one patch that has been dropped

Canonical following Gnome trends while Mozilla does its own thing…

I can hear the burden thing.

I feel held hostage, lol.

FF, Does Canonical’s new position on Global Menu Removal affect your team’s implementation of the Cupertino desktop layout? … a bit of a bummer

I feel like Global Menu Removal sounds like a late 1980’s Cult Classic song…

“removed support from firefox”

So it still works for all other menu based apps.

1 Like

oh thank goodness. I didn’t realize how much I enjoy the global menu until I got it set up

For now I have removed the center position altogether in my fork of 10.5.1 for anyone that does not want a center position cutting off their left positioned global menu or menu applets.

The fork and how to apply it can be found in the ticket I opened with budgie.

Main reason I am interested in this project is that I am trying to do more than just recreate the look of a mac but the feel of it too. I don’t care to learn 2 sets of hotkeys of commonly used apps that are otherwise cross platform.

The dev kinto branch also has a fix in it that will be in kinto’s master soon that patches budgie-daemon to handles App-Switcher better. That has also been submitted as a PR, #1972, to the budgie team already, so patching it via Kinto will not be needed.

Hmm? This (centre position) is resolved in 20.04 … or at least I thought it was.

( but it’s not in 19.10, right ? )

Fixed in 20.04 indeed - and even with snap package like gimp :wink:

I wish that were the case, @fossfreedom. It looks like nothing would cause it to get cut off when there is no center applet but it definitely cut off my global menu in 20.04. I can take a snapshot of it with Sublime Text 3, if needed/wanted.

Please give me a screenshot of what you budgie desktop settings - panel looks like

Bits of confusion here.

@rbreaves what’s fixed is : if no applet in center section of panel then global-menu can extend above that center part. Before the fix, even if the center section of panel was empty ( has no applet in ) global menu could not extend beyond that center position.

@fossfreedom if one puts global menu left aligned in a top panel and any applet in center section of that panel then global menu gets cut out by the applet in center section.

I think rbreaves is looking for another behavior for that center section of panel, like being pushed to right when left section needs more room for the applets it holds. Or just stay « under » / being hid by left section when needed ( I’d prefer the latter ).

Global Menu & Locally Integrated Menus in Unity used to solve that problem another way : if there was not enough room for the whole menu, then a drop down arrow would appear on far right for the last item⋅s of menu.

( why can’t these bits of code regarding Global and LiM be ported elsewhere ? They exist and were efficient. Somehow a mix of pixel-saver + global-menu… )

( doubt : extend or expand ? )

LIM is part of compiz … I.e. the window manager. So if you want LIM capability you cannot achieve this via an applet. It has to be via mutter.

In terms of alternative behaviours of the panel and global menu. I am more than happy for anyone to propose code changes in this area.

The current behaviour for 20.04 is the least invasive and most maintainable solution IMHO.

I understood. To be honest I’d like actual global-menu-applet be part of pixel-saver, because pixel-saver offers what I like, i.e. some configurations + target only maximized windows.

Regarding behavior of the different sections of panel, I guess it’s out of reach ( only upstream may change these ) ? My understanding is those different section ares « flat » and share the same « surface » aka the whole panel. Maybe ability to indicate this or that section is above others could do the trick ?

It seems so. Just my curiosity here : the fix for menu getting cut out is only related to global-menu-applet, or did it imply changes in panel too ?

Debian and Ubuntu hold a small patch to budgie desktop … specifically the panel to hide a panel section if there are no applets in the section container. We don’t maintain globalmenu.

In terms of combining pixelsaver and global menu. I agree that would make sense.

We already maintain pixelsaver since the original author disappeared. Again though, the community has to step up here if they want bigger changes like these proposals.

I am not looking to push the center, especially if it is empty anyways, but I will do another Budgie install that is fresh and demonstrate the issue there.

@fossfreedom I apologize that does appear to be the case, that the Debian and Ubuntu maintainers must hold their own patch vs what is in the master branch here github.com/solus-project/budgie-desktop.

My issue came from recompiling the original budgie-desktop from that repo and not realize that the fix in Ubuntu Budgie is in fact separate, so when I replaced it with the original I lost the fix. The reason I replaced it was because I was needing to apply my own fix to resolve an Alt-Tab shortcut key issue that exists in both the original repo and the Debian/Ubuntu maintainer’s version.

I guess I would need to track down the small patch(s) that the Debian/Ubuntu apply or submit my Alt-Tab fix as another patch for them to potentially include assuming I am not able to get it upstreamed to the original.

The patch is in the patches folder

apt-get source budgie-desktop

Note. Upstream has made it clear previously that they do not support the global menu hence why the patch hasn’t been upstreamed.

So do keep your alt tab issue very separate.

As an aside what is the alt tab issue?

Additionally I see you have a script improving osx to linux usability. If your script had the ability to undo the changes then I would be happy to consider it as part of the Cupertino layout option.

BTW I am the debian and ubuntu budgie desktop maintainer

1 Like

Sure, I do need to do a little more polishing of Kinto before it’d be ready for a distro. It is really simple to stop it though (sudo systemctl stop xkeysnail) and a full uninstall can be kicked off by a shell script and some arguments (although not well documented as I expect people to simply run the ./setup.py to be guided through the uninstall at the moment. Main reason is that I support 2 versions of Kinto at the moment, xkb and udev implementation, latter being the better and latest one.).

The Alt-Tab issue comes from them hardcoding for the release of Alt or Super instead of a modifier key mask.

I am going to apologize now for this next part - mac like keybinds can be difficult to explain sometimes because of the care that has to go into retaining normal hotkey behavior at the same… which is probably why I appear to be the only person crazy enough to have a real project that attempts to address it fully and not on some one off per an app basis (although there is still a very small amount of that too).

To activate Alt-Tab with my Kinto project I have to have it tied the physical Alt key which is actually mapped to Ctrl and while Ctrl is being held down Kinto also remaps Tab to another F key above F12 to ensure no hotkey conflicts - and this is what I change the binding to in the Budgie DE for Alt-Tab App Switching. I do not map to the regular Ctrl-Tab binding because many standard apps, code editors, and browsers use that to traverse tabs. The real physical Ctrl-Tab combo is still Ctrl-Tab due to my xkeysnail/kinto app config properly mapping that too.


Also my patch is based off of another individual who revoked their pull request due to fear of possibly not understanding the full implications of making this change and not getting feedback.

Original patch - mention
https ://github.com/solus-project/budgie-desktop/pull/1668

He also mentioned that capslock would hang it up if activated. I did fix the capslock issue though and have done quite a few local tests with no ill effects, so I am pretty certain this fix would not have any bad side effects. If you feel the need to investigate it further though I would understand.

My patch (for some reason I had to break these links to make this post)
https ://github.com/solus-project/budgie-desktop/pull/1972/commits/260ad50c9a4765700174a8d1f53481786e7512dc
https ://github.com/solus-project/budgie-desktop/pull/1972