mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 11:15:20 +01:00
[GH-ISSUE #986] Does not launch on Croissant compositor #3116
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#3116
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 @kode54 on GitHub (May 17, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/986
Describe the bug
The bar does not launch and fails due to a compositor disconnect on croissant. The developer has already debugged a similar issue with waybar months ago, but apparently still affects both sfwbar and ironbar. Developer says the waybar issue was that the client app was expecting the compositor to instantly roundtrip straight from surface creation to sending the configure event, which the client app will then expect to instantly roundtrip directly to creating and assigning a buffer to the surface.
To reproduce
Steps to reproduce the behavior:
Expected behavior
ironbar should wait until it receives a configure request before configuring surfaces, and should wait until this is accepted before allocating and assigning a buffer. If it already does this, then I am being BSed by the compositor author.
System information:
Configuration
The default config.corn from the listed version, with no changes.
Config
Styles
Additional context
Screenshots
@kode54 commented on GitHub (May 18, 2025):
I must apologize, since the dev of croissant only thought it may be the same issue. And they just said it works for them. So something is clearly wrong in my desktop setup to make it not work, and it's PEBKAC or something. Sorry again. :/
@kode54 commented on GitHub (May 19, 2025):
Okay, it seems it may be an issue with gtk-layer-shell, and it only affects systems with two or more displays. Awaiting further information from anyone looking into it.
The sfwbar developer attempted a workaround using _roundtrip, which livelocks when opening the popup menus created by the bar. Changing it to a _dispatch() call fixes the CPU usage, but it still hangs on popup creation.
I need to test how ironbar reacts to that.
@JakeStanger commented on GitHub (May 20, 2025):
This is almost certainly an issue with spec compliancy within the compositor.
The Wayland code is abstracted behind the
wayland_clientandcalloopcrates, and does not deal with any of the bar rendering (gtk3 and gtk-layer-shell crates do all of that) so there's very litle I can do here. I'm also unwilling to make changes that core to the bar for the sake of one compositor when it works without issue on others.github.com/JakeStanger/ironbar@60b42c4d94/src/clients/wayland/mod.rs (L254-L256)@kode54 commented on GitHub (May 22, 2025):
The bug affected other bar apps using gtk-layer-shell as well. A fix has been tagged in the 0.9.2 release of gtk-layer-shell, including the popup lock up issue that I found in the initial fix.