[GH-ISSUE #965] Motiviation for ironbar #3106

Closed
opened 2026-05-22 23:54:04 +01:00 by JakeStanger · 3 comments
Owner

Originally created by @ixxie on GitHub (May 10, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/965

Hey,

I'm new to compositors and bars and all that jazz.

So when shopping around for my very first bar, it would be helpful to understand why you made ironbar.

I.e. what are the design principles and implementation details which differentiate it from alternatives like waybar and eww.

Originally created by @ixxie on GitHub (May 10, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/965 Hey, I'm new to compositors and bars and all that jazz. So when shopping around for my very first bar, it would be helpful to understand _why_ you made ironbar. I.e. what are the design principles and implementation details which differentiate it from alternatives like waybar and eww.
Author
Owner

@JakeStanger commented on GitHub (May 10, 2025):

Hey, sure I can give some insight.

Ironbar was entirely motivated by Waybar not doing what I wanted. I pushed a couple of PRs to Waybar, but it came quickly apparent that what I had in my head required a lot of changes, and I realised I'd rather start from scratch than try and learn enough C++.

There were really three main goals I had:

  • Waybar felt clunky and unpleasant to configure. I didn't like that there were so many modules and that you'd need to switch per compositor, I didn't like that the config was all JSON objects, and I didn't like the lack of standardisation between modules. For Ironbar, my first move was to design the config. Making the bar as simple and accommodating to configure as possible has always remained top priority.
  • In Waybar, everything runs on a single thread. This means that if you have an external script that hangs, the entire bar UI hangs with it. Ironbar makes heavy use of async architecture and greenthreads to minimise the chance of that happening (there are some edge cases still, but I try my best).
  • I wanted a richer UI, more akin to a panel you'd find on a full desktop environment. This is where the popup system comes in.

At the time I had no idea of eww or any of the others. If I had, Ironbar may not have happened, but I did shortly find out they existed and it did shape the direction of the bar early on.

I'd say Ironbar aims to sit somewhere between Waybar and eww/ags, in that it's still a bar with premade components, but there are some powerful customisation options available, namely though the custom modules, IPC and Ironvars, and the Lua API (when I get round to finishing that).

I would also like to finish by saying I do think there are good reasons to use the alternatives still. Ironbar meets my needs, but it has gaps. If you want a bar with a wider range of modules, larger userbase and by extension better community support, I'd say use Waybar. If you're looking for absolute customisation, eww or ags are probably better fits.

That got a little rambly, but if you'd like me to expand on anything I can. Cheers

<!-- gh-comment-id:2868780449 --> @JakeStanger commented on GitHub (May 10, 2025): Hey, sure I can give some insight. Ironbar was entirely motivated by Waybar not doing what I wanted. I pushed a couple of PRs to Waybar, but it came quickly apparent that what I had in my head required a lot of changes, and I realised I'd rather start from scratch than try and learn enough C++. There were really three main goals I had: - Waybar felt clunky and unpleasant to configure. I didn't like that there were so many modules and that you'd need to switch per compositor, I didn't like that the config was all JSON objects, and I didn't like the lack of standardisation between modules. For Ironbar, my first move was to design the config. Making the bar as simple and accommodating to configure as possible has always remained top priority. - In Waybar, everything runs on a single thread. This means that if you have an external script that hangs, the entire bar UI hangs with it. Ironbar makes heavy use of async architecture and greenthreads to minimise the chance of that happening (there are some edge cases still, but I try my best). - I wanted a richer UI, more akin to a panel you'd find on a full desktop environment. This is where the popup system comes in. At the time I had no idea of eww or any of the others. If I had, Ironbar may not have happened, but I did shortly find out they existed and it did shape the direction of the bar early on. I'd say Ironbar aims to sit somewhere between Waybar and eww/ags, in that it's still a bar with premade components, but there are some powerful customisation options available, namely though the custom modules, IPC and Ironvars, and the Lua API (when I get round to finishing that). I would also like to finish by saying I do think there are good reasons to use the alternatives still. Ironbar meets my needs, but it has gaps. If you want a bar with a wider range of modules, larger userbase and by extension better community support, I'd say use Waybar. If you're looking for absolute customisation, eww or ags are probably better fits. That got a little rambly, but if you'd like me to expand on anything I can. Cheers
Author
Owner

@ixxie commented on GitHub (May 11, 2025):

Great response, that clarifies things @JakeStanger! I think it would be great to put some version of that in the README for prospective users.

<!-- gh-comment-id:2869608784 --> @ixxie commented on GitHub (May 11, 2025): Great response, that clarifies things @JakeStanger! I think it would be great to put some version of that in the README for prospective users.
Author
Owner

@lordmujin commented on GitHub (May 12, 2025):

I love the FOSS community, I think ironbar has a lot of potential, even when talking about waybar or ags, the way I see it, its a great alternative to use with any wayland compositor, way less bloated than some recent projects, like hyprpanel for example (based on ags), way more stable/organized than waybar, the only sad part is the gaps, but with some polishing it might become one of the main stream bars.
Also because when you search something like "bar for wayland" you are pushed with waybar, eww or ags. I really like the project and I wanted to give a bit of love.
Looking forward for updates, specially for the bug fixes, and eventually some more features :D

<!-- gh-comment-id:2871443526 --> @lordmujin commented on GitHub (May 12, 2025): I love the FOSS community, I think ironbar has a lot of potential, even when talking about waybar or ags, the way I see it, its a great alternative to use with any wayland compositor, way less bloated than some recent projects, like hyprpanel for example (based on ags), way more stable/organized than waybar, the only sad part is the gaps, but with some polishing it might become one of the main stream bars. Also because when you search something like "bar for wayland" you are pushed with waybar, eww or ags. I really like the project and I wanted to give a bit of love. Looking forward for updates, specially for the bug fixes, and eventually some more features :D
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
JakeStanger/ironbar#3106
No description provided.