nohup budgie-wm --replace & WORKED FOR ME
JF
Thanks for posting that! I have not had it yet, so I have not been able to troubleshoot or attempt.
@fossfreedom - Thoughts? That sounds âbudgie-eskâ does it not?
Correct. This should be reported upstream with a summary of the issues what we have tried and the current workaround.
Sounds like there is a definite gnome settings daemon race condition here on start of the entire window manager process.
YEP! I can confirm jfbourdeauâs nohup budgie-wm --replace & works! I just had the issue immediately after a restart on my laptop (no additional layouts). Tried the command and all works again.
2 Likes
confirmation that this issue is not a specific Ubuntu Budgie issue - https://github.com/solus-project/budgie-desktop/issues/1449 i.e. confirmed that affects Manjaro
2 Likes
When I reported the bug, I reported it on both Launchpad and on the gnome bug tracker.
Just wanted to add that adding this command
nohup budgie-wm --replace &
to the startup applications allows it to work from bootup. I will keep you posted if it cuts out at a later time during normal operation.
Thanks a ton Rocco! One thing to note for the other people in this thread, Iâve assigned the keyboard shortcut to the command⌠That way itâs super easy to run off the top of your head.
I am not sure to get it / understand
for now I manually run nohup budgie-wm --replace from time to time
Basically if you are having the problem where your keyboard shortcuts are not working⌠Run that command. By resetting the window manager, the issue goes away.
1 Like
For clarification, it goes away at least temporarily. If it pops up again, you would need to run the command a subsequent time.
1 Like
Reported via IRC:
gnome settings -> region&language and there, click on âmanage installed languagesâ then changed âkeyboard input method systemâ to none instead of ibus. Logout and login.
Seemingly this fixes this issue. Can anyone do this and verify?
2 Likes
I will try and let you knowâŚ
For now I was running the command mentioned above in the thread, from time to time to fix my problem,âŚ
JF
@foss[quote=âfossfreedom, post:73, topic:140, full:trueâ]
Reported via IRC:
gnome settings -> region&language and there, click on âmanage installed languagesâ then changed âkeyboard input method systemâ to none instead of ibus. Logout and login.
Seemingly this fixes this issue. Can anyone do this and verify?
[/quote]
I made the change - waiting to see if it comes back againâŚ
For now it seam to work for me
But I also noticed a recent update (gnome I think) relating to the same thingâŚ
JF
I must have missed that. Sounds interesting - might be worth running with this for a while ⌠and then later switching back to see if the recent update has fixed this properly.
Since trying the region and language thing, no issues here yet either. I want to know how someone thought of trying that as a fixâŚ
What this is telling me is that it is more likely to be a race condition between ibus and gnome settings daemon. Both intercept keystrokes. Given the history I have seen this goes back to the early gnome 3 days 6, 7 or more years ago. Why 18.04 is particularly prone to this I am not sure
Interesting observation:
In the keyboard settings Iâve deleted the ctrl + alt + T shortcut for the terminal, so it is not defined (Because it didnât work most of the time). Iâve also added a new shortcut to run tilix via ctrl + alt + R. After that I could start tilix via the new shortcut.
Now after reboot a funny thing happened: The shortcuts in the keyboard settings are still defined as I left it. However, now the tilix shortcut with Rdoesnât work anymore, but the combination with T works, although it isnât defined anymore. 
There seems to be another service at work. Iâll try to set the keyboard input to none as suggested.
I had something similar, it did not recognize self-defined shortcuts. But changing the keyboard input fixed all these issues. Is there any downside selecting none instead of IBUS?