mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 08:15:21 +01:00
[GH-ISSUE #1196] Duplicate Bar Appears After Disconnecting Secondary Monitor #5987
Labels
No labels
A:Build
A:CI
A:Client
A:Config
A:Core
A:Documentation
A:Documentation
A:IPC
A:Testing
A:UX/UI
blocked
BREAKING CHANGE
duplicate
good first issue
GTK4
help wanted
invalid
M:Battery
M:Battery
M:Bindmode
M:Bluetooth
M:Brightness
M:Cairo
M:Clipboard
M:Clock
M:Clock
M:Custom
M:Focused
M:Keyboard
M:Launcher
M:Menu
M:Music
M:Music
M:Music
M:Network Manager
M:Notifications
M:SysInfo
M:Tray
M:Volume
M:Workspaces
partially resolved
P:Critical
P:High
P:Low
P:Medium
pull-request
T:Bug
T:Bug
T:Core Enhancement
T:Module Enhancement
T:New Module
T:Question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/ironbar#5987
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @benoitlx on GitHub (Oct 15, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1196
Describe the bug
A duplicate bar appears on my screen after I disconnect my secondary monitor.
To reproduce
Steps to reproduce the behavior:
Expected behavior
Disconnecting a monitor should remove the associated bar.
System information:
Configuration
Config
Styles
Additional context
Tested on a laptop with two different secondary screens.
Screenshots
@benoitlx commented on GitHub (Oct 15, 2025):
Running
ironbar reloadremoves the duplicated bar afterward.@azertyfun commented on GitHub (Oct 15, 2025):
Hah, funny, I was currently debugging this.
The problem is twofold for me (on Hyprland):
rx_outputs.recv()and GDK. At the time the event is fired,get_display().monitors()does not yet contain the monitor.This is quite tricky to fix. I have a working patch by doing away with
rx_outputsentirely and instead doingget_display().monitors().connect_items_changed(...). But then on top of that GDK sends the event before theMonitoris initialized (connectorisNone), so I had to listen for the Notify event so I can have aconnector. The end result is quite messy (attached below).@JakeStanger To fully fix race conditions I think a proper solution needs to be designed which properly synchronizes the compositor events with GDK before we create the bar. I already spent quite a bit of time on this ugly approach, but does a particular architecture come to mind looking at the problem?
Ugly Patch
@jficz commented on GitHub (Oct 15, 2025):
Same on Hyprland 0.51.1 if that helps.
@JakeStanger commented on GitHub (Oct 15, 2025):
If that's the case, I think you're right. I'd probably approach it with some sort of monitor handling client/service. That would listen to both GDK and Wayland for (dis)connect events in whatever order they come, and only send a connected event when both are present. A disconnected event should be able to rely on either - Wayland would be preference, as that should come in first.
@azertyfun commented on GitHub (Oct 15, 2025):
Sound good.
A couple other things I noticed while experimenting and forgot to mention:
ironbarexits. I assume that's just the event loop closing since there's nothing to manage, and it's fine when running withRestart=Always, but probably not intended behavior.Moveevents are being fired before theInitevent, but I didn't have time to figure out why. Maybe something jumps to your mind immediately?@JakeStanger commented on GitHub (Oct 15, 2025):
I can't say I've ever considered a scenario in which there are no monitors connected but the bar needs to be kept alive. I guess that could occur if you're rewiring your desktop. That could be GTK closing the application when no windows are left? No idea.
It's possible. Everything happening here occurs after the channel is opened, and before the data is sent. There's a good few calls out the IPC in that period.
github.com/jakestanger/ironbar@bab6f570b6/src/clients/compositor/hyprland.rs (L419-L430)If that is the case, moving the
rxcreation further down should resolve that.I've definitely run into the workspace move issue before myself plenty of times though, and so I'll happily take the fix as-is. I will say I am looking to migrate to the new
ext-workspace-v1wayland protocol and stop relying on IPCs for workspaces soon ™️ so I'd hold off doing anything too drastic there. The Hyprland IPC has been nothing but trouble since day one.@azertyfun commented on GitHub (Oct 16, 2025):
I discovered that because my work setup has my laptop plugged in to a docking station with the lid closed, and I was unplugging the docking station to easily disconnect monitors and reproduce the issue, which momentarily left the laptop without any active outputs. I suppose "there's always at least one active output" should be added to a future "List of falsehoods programmers believe about Desktop Environments" lol
@JakeStanger commented on GitHub (Oct 16, 2025):
The most surprising part of that is that you use Ironbar for work lol. That does make sense though, that's definitely something I have done myself enough times.