JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 08:15:21 +01:00

[GH-ISSUE #533] Ghost workspace icons with steam #2984

New issue

Closed

opened 2026-05-22 23:53:03 +01:00 by JakeStanger · 9 comments

JakeStanger commented

2026-05-22 23:53:03 +01:00

Owner

Originally created by @noah427 on GitHub (Apr 6, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/533

Describe the bug
opening and closing the steam window causes the workspace module to leave behind ghost workspaces.

To Reproduce
Steps to reproduce the behavior:

Open steam
Close steam window
Change workspaces
Repeat to make infinite ghost workspace icons

Expected behavior
the workspace icon disappears when the steam window is no longer in it

System information:

Distro: Nixos
Compositor: Hyprland
Ironbar version: ironbar 0.15.0-pre

Configuration

config.json

Videos

https://github.com/JakeStanger/ironbar/assets/40678304/bfb19919-6503-430f-829c-3c191372e639

https://github.com/JakeStanger/ironbar/assets/40678304/3e851ae9-bbe2-4ed1-bf72-a25f0a470ffd

Originally created by @noah427 on GitHub (Apr 6, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/533 **Describe the bug** opening and closing the steam window causes the workspace module to leave behind ghost workspaces. **To Reproduce** Steps to reproduce the behavior: 1. Open steam 2. Close steam window 3. Change workspaces 4. Repeat to make infinite ghost workspace icons **Expected behavior** the workspace icon disappears when the steam window is no longer in it **System information:** - Distro: Nixos - Compositor: Hyprland - Ironbar version: ironbar 0.15.0-pre **Configuration** [config.json](https://github.com/JakeStanger/ironbar/files/14892981/config.json) **Videos** https://github.com/JakeStanger/ironbar/assets/40678304/bfb19919-6503-430f-829c-3c191372e639 https://github.com/JakeStanger/ironbar/assets/40678304/3e851ae9-bbe2-4ed1-bf72-a25f0a470ffd

JakeStanger

2026-05-22 23:53:03 +01:00

closed this issue
added the
T:Bug
label

JakeStanger commented

2026-05-22 23:53:03 +01:00

Author

Owner

@yavko commented on GitHub (Apr 6, 2024):

Unless for some reason steam leaves open clients on that workspace, which prevent the workspace close event, I don't know what else it could be

@yavko commented on GitHub (Apr 6, 2024): Unless for some reason steam leaves open clients on that workspace, which prevent the workspace close event, I don't know what else it could be

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 6, 2024):

There's something funny going on and it's not Steam. You can see in your first video you manage to open a duplicate 3 workspace almost immediately, but I can't easily reproduce that. It's like the existing workspace button is out of sync and shouldn't be there?

If you restart Ironbar, are you able to easily reproduce that in particular? If you are, can you also provide logs with IRONBAR_LOG=debug please?

@JakeStanger commented on GitHub (Apr 6, 2024): There's something funny going on and it's not Steam. You can see in your first video you manage to open a duplicate `3` workspace almost immediately, but I can't easily reproduce that. It's like the existing workspace button is out of sync and shouldn't be there? If you restart Ironbar, are you able to easily reproduce that in particular? If you are, can you also provide logs with `IRONBAR_LOG=debug` please?

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@noah427 commented on GitHub (Apr 7, 2024):

I can reproduce it every single time I restart ironbar. Here's a log file I recorded while I recreated the issue. Hopefully this sheds some light on the problem
log.txt

@noah427 commented on GitHub (Apr 7, 2024): I can reproduce it every single time I restart ironbar. Here's a log file I recorded while I recreated the issue. Hopefully this sheds some light on the problem [log.txt](https://github.com/JakeStanger/ironbar/files/14895424/log.txt)

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 10, 2024):

Right, bear with me because I'm struggling to replicate it and I'm still trying to make sense of the issue.

I've mapped out the workspace state changes below based on the log file. An asterisk * indicates it's focused. Workspaces being added/removed happens before/after the focus event respectively, which is why it's a bit verbose.

The 2nd time that you move to workspace 4, it looks like workspace 3 never receives a destroy event.

[1, 2*]
[1*, 2]
[1, 2*]
[1, 2*, 3]
[1, 2, 3*]
[1, 2*, 3]
[1, 2*]
[1, 2*, 3]
[1, 2, 3*]
[1, 2, 3*, 4]
[1, 2, 3, 4*]
[1, 2, 3*, 4]
[1, 2, 3*]
[1, 2, 3*, 4]
[1, 2, 3, 4*] <-- here, why is workspace 3 sticking around?
[1, 2*, 3, 4]
[1, 2*, 3]

That would indicate Ironbar is probably behaving correctly, as it's interpreting the events it receives and is never told to remove the client.

I would suggest the next step is to find out what the Hyprland event socket is actually sending. You can do something like this:

socat - "UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock" | while read -r line; do echo "$line"; done

The following events are of particular interest:

focusedmon - includes workspace focus change if you change focused output
createworkspace
workspace - focusing a workspace on the same output
destroyworkspace - this is the one you want to watch especially

Also, I could see in your log that each workspace event is received twice. Normally, that'd indicate two running workspace modules (ie two bars on two different screens), but the log suggested you only have a single monitor. Any idea what's going on there?

@JakeStanger commented on GitHub (Apr 10, 2024): Right, bear with me because I'm struggling to replicate it and I'm still trying to make sense of the issue. I've mapped out the workspace state changes below based on the log file. An asterisk `*` indicates it's focused. Workspaces being added/removed happens before/after the focus event respectively, which is why it's a bit verbose. The 2nd time that you move to workspace 4, it looks like workspace 3 never receives a destroy event. ``` [1, 2*] [1*, 2] [1, 2*] [1, 2*, 3] [1, 2, 3*] [1, 2*, 3] [1, 2*] [1, 2*, 3] [1, 2, 3*] [1, 2, 3*, 4] [1, 2, 3, 4*] [1, 2, 3*, 4] [1, 2, 3*] [1, 2, 3*, 4] [1, 2, 3, 4*] <-- here, why is workspace 3 sticking around? [1, 2*, 3, 4] [1, 2*, 3] ``` That would indicate Ironbar is *probably* behaving correctly, as it's interpreting the events it receives and is never told to remove the client. I would suggest the next step is to find out what the Hyprland event socket is actually sending. You can do something like this: ```sh socat - "UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock" | while read -r line; do echo "$line"; done ```` The following events are of particular interest: - `focusedmon` - includes workspace focus change if you change focused output - `createworkspace` - `workspace` - focusing a workspace on the same output - `destroyworkspace` - this is the one you want to watch especially Also, I could see in your log that each workspace event is received twice. Normally, that'd indicate two running workspace modules (ie two bars on two different screens), but the log suggested you only have a single monitor. Any idea what's going on there?

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@noah427 commented on GitHub (Apr 10, 2024):

I actually do have two bars, one on each monitor. Not sure why the logs don't show that. I'll check on the hyprland event socket later today and report back with what I find. My current theory is that there's some issue with applications that spawn floating tiles because that's the pattern I've noticed with the problems so far. Thanks for all your help so far!

@noah427 commented on GitHub (Apr 10, 2024): I actually do have two bars, one on each monitor. Not sure why the logs don't show that. I'll check on the hyprland event socket later today and report back with what I find. My current theory is that there's some issue with applications that spawn floating tiles because that's the pattern I've noticed with the problems so far. Thanks for all your help so far!

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 10, 2024):

Not sure why the logs don't show that.

Ah they do to some extent, but every workspace event is logged on DP-1 and it suggests no workspaces ever exist on DP-2. Which seems wrong and odd. That could be a bug with the actual log code...

@JakeStanger commented on GitHub (Apr 10, 2024): > Not sure why the logs don't show that. Ah they do to some extent, but every workspace event is logged on DP-1 and it suggests no workspaces ever exist on DP-2. Which seems wrong and odd. That could be a bug with the actual log code...

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@noah427 commented on GitHub (Apr 11, 2024):

Here's what I see while reproducing this issue with the socket open

openlayer>>wofi
closelayer>>wofi
activewindow>>,
activewindowv2>>,
activewindow>>foot,noah@noah: ~
activewindowv2>>4375380
activewindow>>,Steam
activewindowv2>>43dfcc0
openwindow>>43dfcc0,1,,Steam
closewindow>>43dfcc0
activewindow>>foot,noah@noah: ~
activewindowv2>>4375380
activewindow>>steam,Sign in to Steam
openwindow>>43d96b0,1,steam,Sign in to Steam
activewindowv2>>43d96b0
activewindow>>steam,Steam
activewindowv2>>43b41b0
openwindow>>43b41b0,1,steam,Steam
activewindow>>steam,Sign in to Steam
activewindowv2>>43d96b0
closewindow>>43d96b0
activewindow>>steam,Steam
activewindowv2>>43b41b0
activewindow>>foot,noah@noah: ~
activewindowv2>>4375380
urgent>>43b41b0
activewindow>>steam,Steam
activewindowv2>>43b41b0
createworkspace>>2
createworkspacev2>>2,2
activewindow>>,
activewindowv2>>,
workspace>>2
workspacev2>>2,2
activewindowv2>>43b41b0
activewindow>>steam,Steam
workspace>>1
workspacev2>>1,1
destroyworkspace>>2
destroyworkspacev2>>2,2
closewindow>>43b41b0
activewindowv2>>4375380
activewindow>>foot,noah@noah: ~
createworkspace>>2
createworkspacev2>>2,2
activewindow>>,
activewindowv2>>,
workspace>>2
workspacev2>>2,2
activewindow>>foot,noah@noah: ~
activewindowv2>>4375380
workspace>>1
workspacev2>>1,1
destroyworkspace>>2
destroyworkspacev2>>2,2
createworkspace>>2
movewindow>>4375380,2
createworkspacev2>>2,2
movewindowv2>>4375380,2,2
activewindow>>foot,noah@noah: ~
activewindowv2>>4375380
workspace>>2
workspacev2>>2,2
activewindow>>foot,noah@noah: ~
activewindowv2>>4375380

@noah427 commented on GitHub (Apr 11, 2024): Here's what I see while reproducing this issue with the socket open ``` openlayer>>wofi closelayer>>wofi activewindow>>, activewindowv2>>, activewindow>>foot,noah@noah: ~ activewindowv2>>4375380 activewindow>>,Steam activewindowv2>>43dfcc0 openwindow>>43dfcc0,1,,Steam closewindow>>43dfcc0 activewindow>>foot,noah@noah: ~ activewindowv2>>4375380 activewindow>>steam,Sign in to Steam openwindow>>43d96b0,1,steam,Sign in to Steam activewindowv2>>43d96b0 activewindow>>steam,Steam activewindowv2>>43b41b0 openwindow>>43b41b0,1,steam,Steam activewindow>>steam,Sign in to Steam activewindowv2>>43d96b0 closewindow>>43d96b0 activewindow>>steam,Steam activewindowv2>>43b41b0 activewindow>>foot,noah@noah: ~ activewindowv2>>4375380 urgent>>43b41b0 activewindow>>steam,Steam activewindowv2>>43b41b0 createworkspace>>2 createworkspacev2>>2,2 activewindow>>, activewindowv2>>, workspace>>2 workspacev2>>2,2 activewindowv2>>43b41b0 activewindow>>steam,Steam workspace>>1 workspacev2>>1,1 destroyworkspace>>2 destroyworkspacev2>>2,2 closewindow>>43b41b0 activewindowv2>>4375380 activewindow>>foot,noah@noah: ~ createworkspace>>2 createworkspacev2>>2,2 activewindow>>, activewindowv2>>, workspace>>2 workspacev2>>2,2 activewindow>>foot,noah@noah: ~ activewindowv2>>4375380 workspace>>1 workspacev2>>1,1 destroyworkspace>>2 destroyworkspacev2>>2,2 createworkspace>>2 movewindow>>4375380,2 createworkspacev2>>2,2 movewindowv2>>4375380,2,2 activewindow>>foot,noah@noah: ~ activewindowv2>>4375380 workspace>>2 workspacev2>>2,2 activewindow>>foot,noah@noah: ~ activewindowv2>>4375380 ```

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 11, 2024):

So in this case you were just switching between workspace 1 and 2? I think I've interpreted the workspace changes as follows:

[1*]
[1*, 2]
[1, 2*]
[1*, 2]
[1*]
[1*, 2]
[1, 2*]
[1*, 2]
[1*]
[1*, 2]
[1, 2*]

(beginning to feel like some advent of code input...)

The log here suggests all is fine. What I might need to do then is try some small-scale test and see if we can pin down exactly where in the pipeline the issue is.

It's damn annoying I can't replicate this myself too.

@JakeStanger commented on GitHub (Apr 11, 2024): So in this case you were just switching between workspace 1 and 2? I think I've interpreted the workspace changes as follows: ``` [1*] [1*, 2] [1, 2*] [1*, 2] [1*] [1*, 2] [1, 2*] [1*, 2] [1*] [1*, 2] [1, 2*] ``` (beginning to feel like some advent of code input...) The log here suggests all is fine. What I might need to do then is try some small-scale test and see if we can pin down exactly where in the pipeline the issue is. It's damn annoying I can't replicate this myself too.

JakeStanger commented

2026-05-22 23:53:04 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 24, 2024):

Going to close this issue as I've had confirmation from @noah427 that various system updates have resolved this

@JakeStanger commented on GitHub (Apr 24, 2024): Going to close this issue as I've had confirmation from @noah427 that various system updates have resolved this