special workspaces showing randomly

[fdev31]

Sometimes special workspaces are showing, while it's not expected (it can be very annoying if you use a lot of them).

I was able to fix it by adding:
if (workspace.starts_with("special")) return;

at the start of void Workspaces::on_workspace_moved(std::string const &payload) in the workspaces.cpp file of the hyprland module.

I didn't see how it was implemented regarding #1983 so this might not be the expected solution.

[Syndelis]

Can you describe your issue further? When the special workspaces do appear, do you see any windows registered to the workspaces when running hyprctl clients -j?

[fdev31]

It happens using pyprland & the scratchpad extension, using special workspaces for each scratchpad, and clients are moved from/to it on demand.
I can only produce this issue on a multi-monitor setup, when the client is moved to special > monitor 1, then back to special, then to monitor 2 (for instance). Unfortunately this is not 100% reproducible and I need to repeat the same actions a few time to produce the issue.
It "adds up", meaning at some point I may have 10 times the same special workspace name showing in the workspace list...

[Syndelis]

It "adds up", meaning at some point I may have 10 times the same special workspace name showing in the workspace list...

That's a very important information, as it can help find out what's happening. I'll make a patch with some logs so you can run against and paste the output here after reproducing the problem

[fdev31]

It "adds up", meaning at some point I may have 10 times the same special workspace name showing in the workspace list...

That's a very important information, as it can help find out what's happening. I'll make a patch with some logs so you can run against and paste the output here after reproducing the problem

Just poke me and I'll install the git version to run some tests.

[Syndelis]

Sorry for taking a while, @fdev31, had a busy weekend! Before running against any patches, could you check Hyprland's IPC to see if the workspaces are correctly reported as destroyed after you remove all windows from them?

To do so, please run this command and reproduce the issue:

socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock

Afterwards, please attach a file with the output!

Output Example

When creating and destroying workspaces, you should see something like this (excluding the comments):

# When I summon a new special workspace:
createworkspace>>special:scratchpad
activespecial>>special:scratchpad,HDMI-A-1
activespecial>>,HDMI-A-1

# When I leave it unfocused without any windows:
destroyworkspace>>special:scratchpad

[fdev31]

So I think I was mistaken about the "adding up" thing, it's just that I have many of them and they start with the same prefix... about the test, those workspaces should NEVER show, regardless of if they are created/destroyed, isn't it ? (When I show one, with single monitor setup, it never shows...)
I had one special workspace showing just by plugging a screen ("minimized" workspace - while I'm not showing it but it was displayed before I plugged the screen), here is the log before/after I plugged the screen:

createworkspace>>1
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>TermLog,journal
activewindowv2>>563ce9995460
workspace>>9
focusedmon>>DP-1,2
activewindow>>brave-browser,special workspaces showing randomly · Issue #2646 · Alexays/Waybar – Brave
activewindowv2>>563ce99bd180
moveworkspace>>2,DP-1
moveworkspace>>special:minimized,DP-1
monitoradded>>DP-1
destroyworkspace>>1
moveworkspace>>3,DP-1
openlayer>>waybar
activewindow>>WLR Layout,WLR Layout
openwindow>>563ce9919ba0,2,WLR Layout,WLR Layout
activewindowv2>>563ce9919ba0
openlayer>>wpaperd-DP-1
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
activewindowv2>>563ce99bf160
activewindow>>brave-browser,Brave Search – Brave

Another try, withoug plugging/unplugging anything, I switch screens & show/hide special workspaces a few times, worked fine but the last one which made the special workspace visible:

moveworkspace>>special:scratch_term,DP-1
movewindow>>563ceb7abb70,2
activewindow>>WLR Layout,WLR Layout
activewindowv2>>563ce9919ba0
activewindow>>kitty-dropterm,~
activewindowv2>>563ceb7abb70
movewindow>>563ceb7abb70,special:scratch_term
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
focusedmon>>HDMI-A-1,9
activewindow>>TermLog,journal
activewindowv2>>563ce9995460
moveworkspace>>3,HDMI-A-1
focusedmon>>DP-1,2
moveworkspace>>3,DP-1
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
openlayer>>rofi
closelayer>>rofi
activewindow>>,
activewindowv2>>,
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
closelayer>>waybar
closelayer>>waybar
openlayer>>waybar
openlayer>>waybar
movewindow>>563ceb7abb70,2
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>kitty-dropterm,~
activewindowv2>>563ceb7abb70
movewindow>>563ceb7abb70,special:scratch_term
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
focusedmon>>HDMI-A-1,9
activewindow>>TermLog,journal
activewindowv2>>563ce9995460
moveworkspace>>3,HDMI-A-1
focusedmon>>DP-1,2
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
moveworkspace>>3,DP-1
movewindow>>563ceb7abb70,2
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>kitty-dropterm,~
activewindowv2>>563ceb7abb70
movewindow>>563ceb7abb70,special:scratch_term
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
focusedmon>>HDMI-A-1,9
activewindow>>TermLog,journal
activewindowv2>>563ce9995460
moveworkspace>>3,HDMI-A-1
moveworkspace>>special:scratch_term,HDMI-A-1
movewindow>>563ceb7abb70,9
activewindow>>kitty-dropterm,~
activewindowv2>>563ceb7abb70
activewindow>>kitty-dropterm,~
activewindowv2>>563ceb7abb70
movewindow>>563ceb7abb70,special:scratch_term
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>TermLog,journal
activewindowv2>>563ce9995460
focusedmon>>DP-1,2
moveworkspace>>3,DP-1
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550
moveworkspace>>special:scratch_term,DP-1
movewindow>>563ceb7abb70,2
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>kitty-dropterm,~
activewindowv2>>563ceb7abb70
movewindow>>563ceb7abb70,special:scratch_term
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550

[fdev31]

When creating and destroying workspaces, you should see something like this (excluding the comments):

Looks like our configurations/usages are very different! I never create or delete workspaces explicitly...

I made one more test where I isolated the sequence producing the issue a bit more, here is the "prologue":

movewindow>>563ceb7abb70,special:scratch_term
focusedmon>>HDMI-A-1,9
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
moveworkspace>>3,HDMI-A-1
openlayer>>rofi
closelayer>>rofi
activewindow>>,
activewindowv2>>,
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
closelayer>>waybar
closelayer>>waybar
openlayer>>waybar
openlayer>>waybar
movewindow>>563ceb7abb70,9
activewindowv2>>563ceb7abb70
activewindow>>kitty-dropterm,~
movewindow>>563ceb7abb70,special:scratch_term
activewindow>>TermLog,journal
activewindowv2>>563ce9995460
activewindow>>TermLog,top
activewindowv2>>563ce9996ff0
focusedmon>>DP-1,2
moveworkspace>>3,DP-1
activewindow>>kitty,socat - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock\n
activewindowv2>>563ce98ae550

And then I guess the first line of this sequence (showing the special workspace on a given screen) made the issue:

moveworkspace>>special:scratch_term,DP-1
movewindow>>563ceb7abb70,2
activewindow>>TermLog,journal
activewindowv2>>563ce9995460
activewindow>>kitty-dropterm,~
activewindowv2>>563ceb7abb70

[Syndelis]

There's a lot of info on these messages, so I'll break them down here:

Looks like our configurations/usages are very different! I never create or delete workspaces explicitly...

I think there's a misconception here. Creating and destroying workspaces are processes that Hyprland does; if a workspace is focused and it was previously empty (no windows) then it's created just in time for you to switch to it. Then, if said workspace is left empty and unfocused, it is destroyed. The only exception to this rule are workspaces explicitly set as persistent in Hyprland's configuration.

about the test, those workspaces should NEVER show, regardless of if they are created/destroyed, isn't it ?

Workspaces will show if they exist in the bar that corresponds to that monitor. If hyprland/worksaces.all-ouputs is true, then existing workspaces will show up on every monitor's bar, regardless if there's a match or not. Additionally, workspaces in hyprland/worksaces.persistent-workspaces will also show up, even if they don't exist.

The exception here are workspaces whose names match any regexes in hyprland/worksaces.ignore-workspaces.

The tl;dr here is: if a workspace exists and you didn't configure it to be ignored, then it will be shown in at least one of your bars.

When I show one, with single monitor setup, it never shows...

Probably related to the configurations I mentioned. Please attach your waybar config so we can be certain that's the case.

I had one special workspace showing just by plugging a screen ("minimized" workspace - while I'm not showing it but it was displayed before I plugged the screen), here is the log before/after I plugged the screen:

Judging from these lines in the log:

moveworkspace>>2,DP-1
moveworkspace>>special:minimized,DP-1
monitoradded>>DP-1

Hyprland decided to move the workspace special:minimized to the newly plugged monitor. This workspace seems to already exist and that could be either because it's persistent, was focused on the other monitor or because it had windows on it.

---

I was going to comment on other inputs and logs you gave, but it's pretty hard to tell what's happening while not seeing the screen or Hyprland's current state. Could you re-reproduce the problem and post the output of the following commands both before and after reproducing the problem? Also, send in the IPC's logs again.

hyprctl workspaces -j

hyprctl clients -j

hyprctl monitors -j

and, if you're running Hyprland ≥ 0.32.0:

hyprctl workspacerules -j

[fdev31]

I kind of disagree with your remarks, what you mention applies to normal workspaces, not the special ones... there is even a special config to handle that ("show-special") and I provided a patch fixing the problem... are we talking about the same thing?
Special ones are NOT displayed in a single screen situation (so I guess the default is to NOT show special workspaces, which makes sense) and only appear in some occasions on multi-monitor setups - that's the bug I reported.

Here is my config:

    "wlr/workspaces": {
        // "disable-scroll": true,
        "all-outputs": false,
        "on-click": "activate",
        "persistent_workspaces": {
//            "1": [],
        },
        "on-scroll-up": "hyprctl dispatch workspace m+1",
        "on-scroll-down": "hyprctl dispatch workspace m-1",
        "format": "{icon}",
        "format-icons": {
            "1": "",
            "2": "",
            "3": "",
            "4": "燎",
            "5": "蓼",
            "6" : "",
            "7" : "更",
            "8" : "󰭹",
            "9" : "亮",
            "10": "👽",
            "default": ""
        }
    },

[Syndelis]

are we talking about the same thing?

Actually, you're right, we might as well not be. You haven't provided any images or the output of clients/workspaces I've asked for; so far I've been left to guess what you're seeing based on what you say.

and I provided a patch fixing the problem...

Your patch seems to edit some of Hyprland's workspaces module code, but your config uses wlr/workspaces. Maybe you're not even using the same module as I am!

I'm glad you manged to fix the problem for you, though :)

I won't be commenting further; learn some manners.

[fdev31]

Haha, thanks for the remark, at some point I switched so my configuration refers to "wlr/workspaces" but "hyprland/workspaces" is what I'm using, so I guess I have no configuration at all... so that explains the confusion :)

I didn't send a screenshot yet but I will, but it's pretty basic:

instead of showing "normal" desktops only (eg: "1 2 3") it will show SOME special desktops if more than one monitor is used (eg: "1 2 3 foo bar baz" if foo, bar & baz are special workspaces, having the "special:" prefix).

[fdev31]

To help with the understanding, here is a manifestation of the bug:

here are my workspaces:

❯ hyprctl workspaces
workspace ID 2 (2) on monitor DP-1:
	windows: 2
	hasfullscreen: 0
	lastwindow: 0x55fc8d9e1ac0
	lastwindowtitle: …/dev/std/pyprland

workspace ID 9 (9) on monitor DP-1:
	windows: 2
	hasfullscreen: 0
	lastwindow: 0x55fc8db3da50
	lastwindowtitle: top

workspace ID -98 (special:scratch_term) on monitor DP-1:
	windows: 2
	hasfullscreen: 0
	lastwindow: 0x55fc8ae877c0
	lastwindowtitle: ~

workspace ID -97 (special:scratch_volume) on monitor DP-1:
	windows: 1
	hasfullscreen: 0
	lastwindow: 0x55fc8b068bb0
	lastwindowtitle: Contrôle du volume

I was expecting to get some feedback about the change I propose, so I may clean it using existing functions & make a PR...

Note: "hyprland/workspaces" is in use, without any specific configuration