Empty Spaces Are Renamed Upon Lock & Unlock

[iworkinpixels]

Actual: If I have custom names on my workspaces (in this case I am using fontawesome icons, but this bug exists with any custom names) and I lock and then unlock my screen or suspend/unsuspend the comuter, then any empty workspaces are renamed to their corresponding number.

Expected: Workspace names should be preserved when locking/suspending.

Example:

[christopher-l]

Hi @iworkinpixels, thanks for your report.

So I take it you have set a static number workspaces? Did you enable / are you using the extension's "Smart workspace names" feature?

[iworkinpixels]

Yes, I have my OS set to 5 static workspaces, and I have "Smart Workspace Names" enabled in the Space Bar settings.

[christopher-l]

The reason seems to be, that extensions get disabled and re-enabled on lock / unlock. Currently, this triggers a reset of names of empty workspaces. At some point, the idea of "smart workspace names" is of cause to unset workspace names.

Could you describe how you use "smart workspace names"? Do you want workspace names to be reset when initially logging in and then stay persistent?

[iworkinpixels]

I'm indifferent to how it accomplishes this, but if I were to implement it, maybe a config file or setting that maps workspace numbers to names, so that when the unlock event happens, the names are restored?

I want to set my workspace names once, I don't care where, and then have those workspace names be persistent across locks, logouts, suspends, reboots, the works. My workspaces should always be static, 1 is Slack, 2 is the terminal, 3 is browsers, 4 is for non-sensitive personal programs, and 5 is for sensitive things like my KeePassXC window.

I'd like them all to be static (among other reasons) so that I can automatically move certain programs to certain workspaces on load.

[christopher-l]

If I understand you correctly you might want to just disable "smart workspace names". Without this setting, workspace names should be persistent.

[iworkinpixels]

That worked, thank you! I figured that setting was needing to be set so it would rename everything correctly on reboot.

Now I can turn the auto move windows extension back on and get to my next setup tweak!

[iworkinpixels]

So, I just rebooted my computer, and I believe there's another problem... when the computer first booted, the names remained the same as I said in my last comment, but since none of my programs loaded in their respective spaces like they're supposed to (I guess the shell extension Move To Workspace runs after my startup programs open?) I had to move a bunch of stuff around. One of the programs I had to move to the workspace all the way on the right... and I accidentally hit the shortcut to move the program one too many times, which resulted in everything being shifted over by one and so the first workspace is now named "1", and the personal workspace icon fell of the end of the list.

I agree with the user in #23 , and would like it if we could just do a list somewhere of totally static workspace names, but if we can't do that, I'd like to file a bug report that moving a program past the end of the list (so it wraps around to workspace 1) will cause the same issues I was seeing originally, even with Smart Workspace Names turned off.

I can file that as a separate issue if you'd like, just let me know.

Screenshot of after the bug:

[christopher-l]

What do you use to move programs around workspaces? The standard keybindings don't seem wrap around, so I cannot reproduce your issue right now.

I agree with the user in https://github.com/christopher-l/space-bar/issues/23 , and would like it if we could just do a list somewhere of totally static workspace names

That is in fact pretty close to what happens right now. Actually, this extension doesn't manage workspace names itself but it relies on a standard GNOME feature, that saves workspace names persistently. GNOME doesn't expose these names anywhere in the UI to my knowledge, though.

What this extension does is to reflect these names and update them when

• workspaces are inserted or removed through this extension, other extension, or by GNOME itself through the dynamic-workspaces feature
• "Smart workspace names" is enabled and windows appear on unnamed workspaces or the extension gets enabled.

You could find out if the behavior you described is actually caused by this extension by disabling it, reproducing the issue and checking workspace names with the following command before and after:

dconf read /org/gnome/desktop/wm/preferences/workspace-names

There might be some interaction between this extension and the mechanism to move windows around that causes this, but it might also be completely unrelated.

[iworkinpixels]

First of all, thank you for your quick turnaround times on this and your work on helping me debug it, that's rare and I really appreciate it.

As for what I use to move programs around workspaces, I use Pop Shell to move programs around workspaces, and to move between workspaces themselves... I know that this functionality is possible with stock ubuntu 20.04 (minus the tiling WM, of course), but I don't know what the default keybindings are, if there are even any default keybindings.

But under keyboard > Customize Keybindings > Navigation they are listed.

Disabling this plugin and then moving a window from the 5th workspace to the 1st did not reproduce the issue (the output was the same each time... though it may be hard to tell here because of the non-standard font):

❯ dconf read /org/gnome/desktop/wm/preferences/workspace-names
['󰒱', '', '', '', '']
❯ dconf read /org/gnome/desktop/wm/preferences/workspace-names
['󰒱', '', '', '', '']

[christopher-l]

Ok, I see. I suppose Pop Shell does something that causes this extension to move workspace names around then. I'll be afk for some days but I'll have a look after.

Would some kind of "escape" switch to disable manipulation of workspace names by this extension altogether work? That would mean, that rearranging or removing workspaces would no longer be reflected by workspace names.

[iworkinpixels]

I don't know if that would help...

And I'm not real sure what Pop Shell might be doing that would cause this, as it doesn't seem to know or care what the workspace names are, it just maps new shortcuts to moving between them and to move windows between them... do I need to file a bug report on this with them and see what they can tell me about the issue?

[christopher-l]

I would have to check, what exactly causes the issue first. Usually it is some workaround that inserts new workspaces and moves windows around so it seems like nothing happened (unless, you try to keep track of names when rearranging workspaces).

If you goal for now is to just have shortcuts for moving around workspaces, there are GNOME standard keybindings that seem not to cause issues:

• "Move to workspace on the left" / "right"
• "Move window one workspace to the left" / "right"

These can also be accessed via dconf (e.g. with dconf-editor) under /org/gnome/desktop/wm/keybindings

• switch-to-workspace-left / -right
• move-to-workspace-left / -right

[iworkinpixels]

Ok, just wanted to add an update here since I have found out more:

This only happens when I wrap around to the left, not to the right. So if I move it from workspace 5 to workspace 1, the bug doesn't happen. But if I move it from workspace 1 to workspace 5, then the icons for workspaces 1 through 4 are pushed over to the right and workspace 1 is named "1" instead of the slack logo.

And if I repeat the experiment, then the first two workspaces will be named 1 and 2, respectively, with the third workspace being named the slack logo.

But it won't go beyond that. Only the first two workspaces are affected.

I have used my dconf editor to see if there are any conflicting keybindings for Super+Ctrl+Left/Right and there do not appear to be any. I did notice that certain shortcuts refer to the workspaces "up and down" and I do not have those set. I have everything set to left/right.