[GH-ISSUE #249] [Launcher] More indicators for where applications are #1513

New issue

Open

opened 2026-05-22 22:52:45 +01:00 by JakeStanger · 1 comment

JakeStanger commented

2026-05-22 22:52:45 +01:00

Owner

Originally created by @donovanglover on GitHub (Jul 18, 2023).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/249

Is your feature request related to a problem? Please describe.
Would be cool if there was a way to differentiate applications on the same workspace from applications on different workspaces.

Describe the solution you'd like

CSS class for applications on the current monitor
CSS class for applications on the current workspace
CSS class for applications in special workspaces
CSS classes for applications in any named workspace

Describe alternatives you've considered
Per-window indicators instead of per-application, although this adds complexity.

Originally created by @donovanglover on GitHub (Jul 18, 2023). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/249 **Is your feature request related to a problem? Please describe.** Would be cool if there was a way to differentiate applications on the same workspace from applications on different workspaces. **Describe the solution you'd like** - CSS class for applications on the current monitor - CSS class for applications on the current workspace - CSS class for applications in special workspaces - CSS classes for applications in any named workspace **Describe alternatives you've considered** Per-window indicators instead of per-application, although this adds complexity.

JakeStanger added the

T:Module Enhancement

M:Launcher

A:UX/UI

labels

2026-05-22 22:52:45 +01:00

JakeStanger commented

2026-05-22 22:52:45 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jul 18, 2023):

I can see the use-case but my initial thoughts are that this is going to be too complex.

The issue I see here is that the launcher module does not currently have any idea of workspaces. Under the hood it uses wlr_foreign_toplevel, and wayland/wlroots currently lacks workspace support.

This would therefore require tracking all workspaces and windows via the compositor's IPC, and then cross-referencing that with Wayland. Apart from the added complexity, this would box the module in to only work on Sway/Hyprland. I suspect the changes would be complex enough that it would be hard to stick them behind a flag too, so you couldn't switch it off and use on other compositors.

@JakeStanger commented on GitHub (Jul 18, 2023): I can see the use-case but my initial thoughts are that this is going to be too complex. The issue I see here is that the `launcher` module does not currently have any idea of workspaces. Under the hood it uses `wlr_foreign_toplevel`, and wayland/wlroots currently lacks workspace support. This would therefore require tracking all workspaces and windows via the compositor's IPC, and then cross-referencing that with Wayland. Apart from the added complexity, this would box the module in to only work on Sway/Hyprland. I suspect the changes would be complex enough that it would be hard to stick them behind a flag too, so you couldn't switch it off and use on other compositors.