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
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
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.
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.
@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.
@fossfreedomif 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… )
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 ?
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.
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
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)