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
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
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)
I’ve updated Kinto now to include my Alt-Tab patch on top of your fork until it is able to be merged officially.
Additionally I plan make Ubuntu Budgie the first Linux Distro to have a tray app for Kinto and once that happens I will try to repackage in it for inclusion with Ubuntu Budgie. I really do like this distro and it probably impresses me the most and I have tried a lot of distros lol.
I am curious to know what you think of the supposed Qt rewrite coming for Budgie, if you guys plan to follow that path or possibly do a Mate thing and simply keep maintaining this fork of it? I would assume it may just be a wait and see sorta thing.
That was a proposal from a few years ago.
It has now been dropped from upstreams plans. They have decided GTK4 + a replacment for mutter for the window manager is the preferred route. No timeframe has been given.
I might should create a separate thread, because none of this relates to the original thread subject title any more.
So the PR that had been accepted to fix the Alt-Tab issue ended up being pulled back out of the upstream repo. I have re-submitted it though addressing the issue(s) it introduced.
Additionally I have just completed the system tray app for Budgie to fully control Kinto after install. I plan to also create a separate system tray app for Gnome, XFCE and KDE before merging this new code into Kinto’s master branch.
Only thing I am not quite sure how to do is add the Kinto Applet automatically after it installs, so the user does not need to use the GUI to add it the rest of the way.
That’s not how budgie applets work. You have to manually add the applet via budgie desktop settings.
If the applet is an app indicator then it will auto appear after running … e.g. if set to autostart
I see… I guess I based my work on an existing Applet not realizing I should have been using an App Indicator instead. I would prefer that, although I think it to be best to create 2 services/apps at that point. It would resolve the issue of needing people to configure/add the applet to the panel.
Many upstream changes may depend on GTK4 and that is in the hands of Gnome.