mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 06:15:21 +01:00
[GH-ISSUE #1038] menu always empty #4545
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#4545
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 @postsolar on GitHub (Jun 8, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1038
Describe the bug
Newly-added menu module pop-up is totally empty.
To reproduce
Steps to reproduce the behavior:
config.jsonthat is just{ "start": [ { "type": "menu" } ] }IRONBAR_LOG=info,ironbar::desktop_file=trace IRONBAR_CONFIG=/tmp/ironbar/config.json ironbarExpected behavior
Menu non-empty
System information:
Configuration
Config
Styles
Additional context
Log
I also tried running the config examples/menu/default.json, same result
Screenshots
This is all I'm seeing when opening menu pop up

@JakeStanger commented on GitHub (Jun 11, 2025):
I'm assuming this has gotta be some weird race condition. If you run
ironbar reloadit should keep the menu client alive and send another init event so that might kick it into life. Does that work?The log also suggests this is a single bar on a single monitor - is that right?
@postsolar commented on GitHub (Jun 11, 2025):
Nope.
Yes. By the way, was the environment variable which I used for logging (
IRONBAR_LOG=info,ironbar::desktop_file=trace) right? I don't recall seeing any debug macros inmenu's own modules so I only useddesktop_filehere.@postsolar commented on GitHub (Jun 11, 2025):
Anyways, here's a full log
ironbar_trace.log
@JakeStanger commented on GitHub (Jun 12, 2025):
Cheers. I think the
menumodule is indeed lacking decent logging at the moment, so yeah that's right for now. I'll see what I can do given the current log, but I may need to go back and add more and get you to try again if I can't get anywhere.@JakeStanger commented on GitHub (Jun 12, 2025):
Do you open the menu popup in that full log? It only initialises on first click.
I'm also wondering if NixOS is somehow to blame, having things in weird places. Yet to explore that possibility though.
@postsolar commented on GitHub (Jun 13, 2025):
I'm pretty sure the exact steps were:
ironbar reloadJust to be sure here's another log where I do exactly this.
ironbar_trace.log
But it looks like
desktop_filedoes find everything it needs, doesn't it?@postsolar commented on GitHub (Jun 13, 2025):
Though running the same Ironbar binary within an Arch distrobox container I do get it to work.
@JakeStanger commented on GitHub (Jun 13, 2025):
Hmmm strange. I'm certainly suspicious of Nix but there's no clear reason yet.
What's weird is your first log did show all the files being located at least. The previous two logs have only shown a couple of entries and nothing else:
It leads me to assume there's an issue with differences in the Nix filesystem structure and files not being in the expected paths that isn't being picked up here for some reason. I'm not sure what would have differed between runs unless you launched it from a different program or had different environment variables or something at the time.
In the first instance, it finds the files. What isn't clear is whether it correctly parses them - if something's iffy with the parser, it could just throw out the file and ignore it.
@Brisingr05 commented on GitHub (Jun 13, 2025):
Using the same config and command, I can kinda reproduce this. The menu module doesn't show anything when clicking on it once or twice, but does work from the third time. See the recording below (IDK what's up with the fonts):
https://github.com/user-attachments/assets/8be500b3-a9b0-4bf0-8712-768932a648cd
Here's the log: ironbar.log
This is in niri, but I can reproduce this on Hyprland as well. Ironbar version is
github.com/JakeStanger/ironbar@4fad5a4d18. I'm also on NixOS.@postsolar commented on GitHub (Jun 13, 2025):
Nothing that I'd be aware of.
In most files,
Exec=line doesn't have an absolute path (i.e. it'sfirefoxand not/nix/store/<...>firefox/bin/firefox). So these would be the same as on other distros.Just to be clear, this is quite different from what I have. In my case, the pop up itself always shows up on the first click, it's just it has no contents (also confirmed this with GTK inspector, no child widgets present).
@postsolar commented on GitHub (Nov 21, 2025):
✔️ doesn't happen anymore