Workspace switcher graphic gets stuck on screen in 18.10

When using a keyboard shortcut to switch workspaces, about 50% of the time the graphic gets stuck on the screen. We’re using these commands with a keyboard shortcut:

/usr/share/budgie-desktop/visualspace/visualspace prev
/usr/share/budgie-desktop/visualspace/visualspace next

and sometimes the graphic of the workspaces will stay on screen until we reswitch workspaces.

Happens on all of our desktops here.


Any output if you run this in a terminal?
What is the output of gsettings get org.gnome.mutter dynamic-workspaces?

The output is: false

Any output when running either

/usr/share/budgie-desktop/visualspace/visualspace prev
/usr/share/budgie-desktop/visualspace/visualspace next

No output, just triggers the action. It also keeps focus and doesn’t allow anything else to be clickable, but clicking on the switcher does nothing, even though it has a visual hover and click effect.

Our keyboard shortcut is ctrl + alt + left or right.

It seems if we let go of ctrl + alt before letting go of left or right, it’s reproducible 100% of the time.


Ah, ok. The shortcut is designed, assuming left/right is just tapped. When left/right is pressed in a sticky way, the jumps to previous/next workspace are unpredictable in any case! Not sure how to fix…

Tapping Ctrl will close the switcher though.

1 Like

Is there some way to just disable it visually entirely? Someone on the team has theirs set to ctrl + shift + 1 for prev and ctrl + shift + 2 for next, and theirs stays locked up even after pressing ctrl or alt again (confirm that fixes it on mine). With those bindings for some reason it needs switched back and forth an extra time to unstick.

Would be nice if we could just disable the visual overlay somehow?

Appreciate your help!

You can: 18.04 Workspace Switching Speed

Budgie Desktop

Awesome! Bookmarking! Thanks!

Just saw this, and wanted to say i have that one 19.04 too. But i have output for that command:

/usr/share/budgie-desktop/visualspace/shownav:240: PyGIDeprecationWarning: Since version 3.11, calling threads_init is no longer needed. See:

I also have it reproducible, but thanks for the ctr tap tip, that does make it go away.

Thanks for mentioning! On the deprecated warning: we are aware of it, there were quite some changes on the new python version, which need to be addressed in the near future. The deprecated warning does not make it break on PEP8 though, and the functionality is not in question.

Thank you guys for talking about this issue here. (as someone who is also affected)

Should be fixed on tomorrows daily build of extras.