For some reason, and I don’t know why. The alt+tab keyboard shortcut is getting reset back to default after each reboot / login.
The key is in dconf database at /org/gnome/desktop/wm/keybindings/switch-applications. When I se the value to ['fail'] or [] and then restart the PC. It comes back to ['<Super>Tab', '<Alt>Tab'].
But when I login with Gnome (Xorg) instead of Budgie. The keybinding is not reset back to defaults. So while I know it’s something in Budgie doing this. Unfortunately I cannot determine which components, or if it’s a legacy component that got reinstalled during the dist upgrade.
Another thing is that the default keybinding brings up the old Icons only style vala tab switcher. And not the new graphical alt+tab switcher? Or am I mistaken about that new program not being meant for alt+tab?
My current belief is that the code is lurking somewhere in bugie-extras vala, don’t really understand how it works. However got the dconf references in it. See here:
Ah right. So you are trying to remap alt tab to your own keyboard settings?
Budgie as far as I understand the code grabs hold of the switcher signal.the key combination for that signal is defined by that gsettings key.
Previews control sets that gsettings key to an empty string to turn off budgie controlling the switcher. Previews then defines a global hotkey alt tab etc to display the previews switcher. So enable that via previews control.
If you want a different key combination for the graphical switcher then let me know because the mechanism is not gsettings based.
Yes - the alt tab is being defined elsewhere in my custom keyboard shortcuts. But when Budgie restarts, it then redefines the alt-tab in that key. Which is a higher priority and then disables my custom shortcut.
Sorry but I did not follow the reasoning for this behaviour. If I go into my gnome settings, and intentionally disable a keybinding there manually. It should remain disabled. Because that was a user configuration choice. And I can just as easily use the dconf editor of gnome settings gui programs to reset that value back to default…
I am getting confused by the terminology here or the necessity of this action. It’s not happening in Gnome, so it’s budgie messing about with my settings! An unwelcome behaviour.
Because all Budgie needs to define is a command that I can bind to the keyboard myself. Then I can use the existing keybindings mechanisms of gnome to redefine that keyboard shortcut myself to something else of my choosing, right? Or am I missing something else here? Like you don’t want to shell out to another process because that incurrs an overhead / delay etc?
I enabled the “Run previews” and “Show windows of all workspaces” checkboxes.
Rebooted
Now the dconf database settings were NOT overwritten.
…This is like some weird reverse logic going on here. That I don’t understand.
Now the thing is actioning my custom keybinding instead. Is that normal / expected behaviour? I just wanted to see what the new switcher looked like. To see if it was a better choice.
The other difference after upgrading (from 19.10 to 20.04) is that it’s really laggy to bring up the 3rd party switcher program now (skippy-xd). It used to be instant. Now there is a noticeably short delay, and with every every alt-tab cycle. Don’t understand that either.
Maybe the native switcher would be better! But I cannot seem to get it to appear for me - it just brings up the old Icons only style one. It doesnt matter if the the new app thingy (“Previews Control”) is enabled or not.
The bug report is specific to the default budgie switcher. budgie is resetting the gsettings key to its default expected key combination on logon. That is something in the budgie-wm code at a guess.
Previews is external to all of this - there is no way for previews to hook into the switching mechanism because that is strictly controlled by the window manager. Ideally previews should actually be in the window manager itself but that would need acceptance by upstream; they repeatedly say no new capabilities until budgie v11 - hence why Previews is strictly external to the window manager. Previews avoids the startup/delays of process startup via a separate “previews” process enabled on logon.
Now - previews control should set that gsettings key to an empty string string - but it won’t do that if it see’s a gsettings setting that it wasn’t expecting. So if you want to see the new previews you need to reset the gsettings key back to its defaults - log out and login.
in dconf watch, and shows the default value in dconf editor gui. This is equvalent to the “Unset” <=] backspace action in gnome setting utility.
OK so the dconf value is not user set anymore. Then I reboot the computer. Or logout / login.
Then what happens to those 2 dconf keys?
Well they somehow get set to [''] which is the empty user value. And I don’t know how this happen. But the value is no longer default.
And (according to your last comment here). That means the new graphical switcher will not show / be visible. Because it checks that setting? Even though setting for graphical switcher is enabled, it will not be trigger-able due to missing keyboard shortcut. Now I can set it to default value during my login session. But it’s not going to show up. Because for it to redetect that I have to logout again… but then login and it will set the vey value back to [''].
None of this is the slightest bit intuitive. It’s all really highly confusing!
[edit] Hmm… perhaps I can at least trigger the graphical switcher via a dbus message instead? If it’s been loaded up and running in memory? Perhaps that might help?
the '' value is set by the budgie-extras-daemon process - its enabled and does its work when you have previews enabled.
As I mentioned previously - the alt+tab/super+tab/alt+’ and shift variants of those are all defined by budgie-extras-daemon - it doesn’t use the gsettings keys to do its business - it just ensures '' is set so that the budgie-wm (window manager) doesn’t invoke the default switcher when you alt+tab.
If you are not seeing the Preview switcher in action then that’s something we will need to work together to understand what is going on (… but its late and I’m going to find a very warm duvet now…)
Hey @fossfreedom just wanted to get back to you and let you know that the previews tool was showing / working on my local system as you had expected / described. The matter was rather confusing, however thanks to your explanations (more clear than mine). It has been possible for me to understand a lot better now what the hierachy of software components is. And therefore what to do about it.
System is back to working how it was before the upgrade. And basically just had to enable the previews feature to hijack the default alt tab bindings. But then also override the preview binaries itself and disable them from getting launched and executing. This now seems to solve the issue I was having.
It permits the use of an alternative 3rd party alt+tab switcher (skippy xd). Actually I was hoping to ditch skippy this time around (by now). However it still seems to have certain features / benefits over these other ones.
