JakeStanger/ironbar

Fork 0

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

[GH-ISSUE #403] Make wlr-foreign-toplevel-management a feature flag #5762

New issue

Closed

opened 2026-05-23 01:52:53 +01:00 by JakeStanger · 5 comments

JakeStanger commented

2026-05-23 01:52:53 +01:00

Owner

Originally created by @thmasq on GitHub (Jan 11, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/403

Originally assigned to: @thmasq on GitHub.

The context:

Currently Ironbar requires the wlr-foreign-toplevel-management protocol is a hard requirement, and the program will panic if it is not available. This protocol is essential for the launcher and focused modules of Ironbar, because it gives waybar access to context menus for the running programs, and also their status within the compositor.

Reasoning:

This protocol is not universal, with quite a few compositors out there currently not supporting it, such as Gnome's Mutter, KDE's Kwin, and compositors made using Smithay. There is a very interesting discussion in the mailing lists for Wayland, where Gnome's Jonas Ådahl raises some security concerns related to the protocol, as it breaks breaks client isolation. This could make a point for use-cases where this extra security is necessary.
Additionally, users who do not want to display running applications could simply disable the feature to reduce compilation time and have an overall leaner desktop.

Solution

Create a new feature flag in the modules category called runner, and have it disable both the launcher and focused modules, which depend on the toplevel manager. The client code will also have to be modified accordingly to disable the checks that would otherwise make the program panic.

I plan on trying to implement this feature by the next month as I'm kind of busy for now, but I think I can do it.

Originally created by @thmasq on GitHub (Jan 11, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/403 Originally assigned to: @thmasq on GitHub. #### The context: Currently Ironbar requires the [wlr-foreign-toplevel-management](https://wayland.app/protocols/wlr-foreign-toplevel-management-unstable-v1) protocol is a hard requirement, and the program will panic if it is not available. This protocol is essential for the `launcher` and `focused` modules of Ironbar, because it gives waybar access to context menus for the running programs, and also their status within the compositor. #### Reasoning: This protocol is not universal, with quite a few compositors out there currently not supporting it, such as Gnome's Mutter, KDE's Kwin, and compositors made using Smithay. There is a very interesting [discussion](https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg39978.html) in the mailing lists for Wayland, where Gnome's Jonas Ådahl raises some security concerns related to the protocol, as it breaks breaks client isolation. This could make a point for use-cases where this extra security is necessary. Additionally, users who do not want to display running applications could simply disable the feature to reduce compilation time and have an overall leaner desktop. #### Solution Create a new feature flag in the modules category called `runner`, and have it disable both the `launcher` and `focused` modules, which depend on the toplevel manager. The client code will also have to be modified accordingly to disable the checks that would otherwise make the program panic. --- I plan on trying to implement this feature by the next month as I'm kind of busy for now, but I think I can do it.

JakeStanger closed this issue

2026-05-23 01:52:53 +01:00

JakeStanger commented

2026-05-23 01:52:53 +01:00

Author

Owner

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

[For reference, this originates in #402]

Thanks for opening the issue.

I'd prefer to have two separate feature flags which match the module names to better align with the current flags - this gives more control as somebody may want focused but may choose to not compile in the much heavier launcher module to reduce the binary size.

Based on that, the related Wayland client code should be behind an any condition, which enables it if either feature flag is enabled. There should be an example of that somewhere in the code already.

Also just to surface it here - the clipboard module already does this (albeit with a single flag) so should be a good example to follow.

@JakeStanger commented on GitHub (Jan 11, 2024): [For reference, this originates in #402] Thanks for opening the issue. I'd prefer to have two separate feature flags which match the module names to better align with the current flags - this gives more control as somebody may want `focused` but may choose to not compile in the much heavier `launcher` module to reduce the binary size. Based on that, the related Wayland client code should be behind an `any` condition, which enables it if either feature flag is enabled. There should be an example of that somewhere in the code already. Also just to surface it here - the `clipboard` module already does this (albeit with a single flag) so should be a good example to follow.

JakeStanger commented

2026-05-23 01:52:53 +01:00

Author

Owner

@thmasq commented on GitHub (Jan 11, 2024):

I see, that's a good point indeed. It wouldn't hurt to make it as modular as possible if we can, and I don't think it would be a lot harder to implement. Perhaps it might be an interesting idea to separate the modules in tiers of support (similar to how rustc does platform support), I was thinking, but for that I should open another issue after this one is closed. This idea needs more thorough thought, but it would be nice for users to know what modules are expected to work on different implementations of Wayland. Just a thought that passed my mind, really.

@thmasq commented on GitHub (Jan 11, 2024): I see, that's a good point indeed. It wouldn't hurt to make it as modular as possible if we can, and I don't think it would be a lot harder to implement. Perhaps it might be an interesting idea to separate the modules in tiers of support (similar to how rustc does platform support), I was thinking, but for that I should open another issue after this one is closed. This idea needs more thorough thought, but it would be nice for users to know what modules are expected to work on different implementations of Wayland. Just a thought that passed my mind, really.

JakeStanger commented

2026-05-23 01:52:53 +01:00

Author

Owner

@thmasq commented on GitHub (Jan 11, 2024):

As a POC, I tried just deleting the parts related to the launcher and focused modules, and can confirm it runs on Pinnacle just fine. Now to put this under feature flags. To be honest I'm not sure if I can disable some feature of the wayland crate to save compile time, but it doesn't look like they have feature flags that are relevant.

@thmasq commented on GitHub (Jan 11, 2024): As a POC, I tried just deleting the parts related to the launcher and focused modules, and can confirm it runs on Pinnacle just fine. Now to put this under feature flags. To be honest I'm not sure if I can disable some feature of the wayland crate to save compile time, but it doesn't look like they have feature flags that are relevant. ![Screenshot from 2024-01-11 17-21-56](https://github.com/JakeStanger/ironbar/assets/78622691/5e6cc4f5-0f59-4b01-a772-b90db9a1ea01)

JakeStanger commented

2026-05-23 01:52:53 +01:00

Author

Owner

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

Perhaps it might be an interesting idea to separate the modules in tiers of support

For now I'd probably say no to this. Fixing this issue is an easy win to get the bar running on other platforms, but I will be continuing first-class wlroots support, while everything else will be an unofficially supported bonus. As the bar matures, I may look to change that.

@JakeStanger commented on GitHub (Jan 11, 2024): > Perhaps it might be an interesting idea to separate the modules in tiers of support For now I'd probably say no to this. Fixing this issue is an easy win to get the bar running on other platforms, but I will be continuing first-class wlroots support, while everything else will be an unofficially supported bonus. As the bar matures, I may look to change that.

JakeStanger commented

2026-05-23 01:52:53 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jan 14, 2024):

Resolved by #404.

@JakeStanger commented on GitHub (Jan 14, 2024): Resolved by #404.