JakeStanger/ironbar

Fork 0

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

[GH-ISSUE #90] Always visible workspaces #8482

New issue

Closed

opened 2026-05-23 03:52:21 +01:00 by JakeStanger · 14 comments

JakeStanger commented

2026-05-23 03:52:21 +01:00

Owner

Originally created by @yavko on GitHub (Mar 30, 2023).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/90

Originally assigned to: @yavko on GitHub.

Is your feature request related to a problem? Please describe.

I kinda just want 10 workspaces always showing

Describe the solution you'd like

An option that allows setting a range of workspaces, that are always shown

Describe alternatives you've considered

Maybe a list of workspaces instead?

Originally created by @yavko on GitHub (Mar 30, 2023). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/90 Originally assigned to: @yavko on GitHub. **Is your feature request related to a problem? Please describe.** I kinda just want 10 workspaces always showing **Describe the solution you'd like** An option that allows setting a range of workspaces, that are always shown **Describe alternatives you've considered** Maybe a list of workspaces instead?

JakeStanger closed this issue

2026-05-23 03:52:21 +01:00

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@JakeStanger commented on GitHub (Mar 30, 2023):

Hm, this will be a bit fiddly but I can see the value.

I reckon the best way would probably be to use the existing name_map option, and add some flag along-side that to toggle filtering the entries based on open workspaces.

I think that way it should play nicely with all_monitors too.

@JakeStanger commented on GitHub (Mar 30, 2023): Hm, this will be a bit fiddly but I can see the value. I reckon the best way would probably be to use the existing `name_map` option, and add some flag along-side that to toggle filtering the entries based on open workspaces. I think that way it should play nicely with `all_monitors` too.

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@yavko commented on GitHub (Mar 30, 2023):

Hm, this will be a bit fiddly but I can see the value.

I reckon the best way would probably be to use the existing name_map option, and add some flag along-side that to toggle filtering the entries based on open workspaces.

I think that way it should play nicely with all_monitors too.

Yeah, actually that would be better, maybe making name_map check if the value is either a string or object, then a prop like always_shown, and text for what it should appear as

@yavko commented on GitHub (Mar 30, 2023): > Hm, this will be a bit fiddly but I can see the value. > > I reckon the best way would probably be to use the existing `name_map` option, and add some flag along-side that to toggle filtering the entries based on open workspaces. > > I think that way it should play nicely with `all_monitors` too. Yeah, actually that would be better, maybe making `name_map` check if the value is either a string or object, then a prop like `always_shown`, and `text` for what it should appear as

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@yavko commented on GitHub (Apr 2, 2023):

Oh, yeah, this should also add a new CSS class for inactive ones.

@yavko commented on GitHub (Apr 2, 2023): Oh, yeah, this should also add a new CSS class for inactive ones.

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@Gajus84 commented on GitHub (Apr 12, 2023):

And maybe also the possibility to do the opposite too. Workspaces that are always hidden. Hyprlands Special Workspaces for example.

@Gajus84 commented on GitHub (Apr 12, 2023): And maybe also the possibility to do the opposite too. Workspaces that are always hidden. Hyprlands Special Workspaces for example.

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@yavko commented on GitHub (Apr 12, 2023):

And maybe also the possibility to do the opposite too. Workspaces that are always hidden. Hyprlands Special Workspaces for example.

Yeah that makes sense, but that seems better to be a config option like show_special

@yavko commented on GitHub (Apr 12, 2023): > And maybe also the possibility to do the opposite too. Workspaces that are always hidden. Hyprlands Special Workspaces for example. Yeah that makes sense, but that seems better to be a config option like `show_special`

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 12, 2023):

maybe making name_map check if the value is either a string or object, then a prop like always_shown, and text for what it should appear as

Do you think there would be value in this, as in do you have some workspaces you'd like to always show but some you don't? Implementing it on a per-workspace basis would make things more complex, but is doable if you see immediate value in it.

Assuming the Hyprland IPC exposes whether a workspace is special, filtering those should be trivial.

@JakeStanger commented on GitHub (Apr 12, 2023): > maybe making name_map check if the value is either a string or object, then a prop like always_shown, and text for what it should appear as Do you think there would be value in this, as in do you have some workspaces you'd like to always show but some you don't? Implementing it on a per-workspace basis would make things more complex, but is doable if you see immediate value in it. --- Assuming the Hyprland IPC exposes whether a workspace is special, filtering those should be trivial.

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@Gajus84 commented on GitHub (Apr 16, 2023):

Assuming the Hyprland IPC exposes whether a workspace is special, filtering those should be trivial.

It does via createworkspace>>special:"name".

@Gajus84 commented on GitHub (Apr 16, 2023): > Assuming the Hyprland IPC exposes whether a workspace is special, filtering those should be trivial. It does via `createworkspace>>special:"name"`.

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@yavko commented on GitHub (Apr 16, 2023):

Ironbar uses Hyprland-rs which uses a ADT for workspace creation events, should be even easier

@yavko commented on GitHub (Apr 16, 2023): Ironbar uses Hyprland-rs which uses a ADT for workspace creation events, should be even easier

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@yavko commented on GitHub (May 7, 2023):

I'm going to try implementing this, if thats okay

@yavko commented on GitHub (May 7, 2023): I'm going to try implementing this, if thats okay

JakeStanger commented

2026-05-23 03:52:21 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 7, 2023):

Absolutely, go for it!

My currently thoughts on this are that the best way to tackle it would be to add a new option, similar to the favourites launcher widget option. That can just take an array of workspace names and pre-populate the workspaces with those.

I think I prefer that to having name_map have two separate formats, and two separate responsibilities. My fear is otherwise the logic becomes more complex than it needs to be, and it becomes more complicated to configure.

For special workspaces, it might make sense to either just add in logic to always ignore it, or add a new ignore_special option.

Of course if you have other ideas, let me know.

@JakeStanger commented on GitHub (May 7, 2023): Absolutely, go for it! My currently thoughts on this are that the best way to tackle it would be to add a new option, similar to the `favourites` launcher widget option. That can just take an array of workspace names and pre-populate the workspaces with those. I think I prefer that to having `name_map` have two separate formats, and two separate responsibilities. My fear is otherwise the logic becomes more complex than it needs to be, and it becomes more complicated to configure. For special workspaces, it might make sense to either just add in logic to always ignore it, or add a new `ignore_special` option. Of course if you have other ideas, let me know.

JakeStanger commented

2026-05-23 03:52:22 +01:00

Author

Owner

@yavko commented on GitHub (May 7, 2023):

My currently thoughts on this are that the best way to tackle it would be to add a new option, similar to the favourites launcher widget option. That can just take an array of workspace names and pre-populate the workspaces with those.

On it

I think I prefer that to having name_map have two separate formats, and two separate responsibilities. My fear is otherwise the logic becomes more complex than it needs to be, and it becomes more complicated to configure.

Oh, time to scrap that then, anyway I was doing this

For special workspaces, it might make sense to either just add in logic to always ignore it, or add a new ignore_special option.

I forgot, time to add that too

@yavko commented on GitHub (May 7, 2023): > My currently thoughts on this are that the best way to tackle it would be to add a new option, similar to the `favourites` launcher widget option. That can just take an array of workspace names and pre-populate the workspaces with those. On it > I think I prefer that to having `name_map` have two separate formats, and two separate responsibilities. My fear is otherwise the logic becomes more complex than it needs to be, and it becomes more complicated to configure. Oh, time to scrap that then, anyway I was doing this ![image](https://user-images.githubusercontent.com/15178513/236706475-152cee12-e2e3-47b1-9fea-1d36abce8af0.png) > For special workspaces, it might make sense to either just add in logic to always ignore it, or add a new ignore_special option. I forgot, time to add that too

JakeStanger commented

2026-05-23 03:52:22 +01:00

Author

Owner

@yavko commented on GitHub (May 7, 2023):

I've encountered an issue, since by design these workspaces don't exist in the compositor, there is no way to know their monitor or their id, so how do I decide where to show them? Should it instead be an array of maps? Or a map of strings, the strings being the monitor name?

@yavko commented on GitHub (May 7, 2023): I've encountered an issue, since by design these workspaces don't exist in the compositor, there is no way to know their `monitor` or their `id`, so how do I decide where to show them? Should it instead be an array of maps? Or a map of strings, the strings being the monitor name?

JakeStanger commented

2026-05-23 03:52:22 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 7, 2023):

I'd say a map of monitor names to workspaces to include would be clearest:

So to always show workspaces 1 and 2 on DP-1, and always show 3 and 4 on DP-2:

{
"favorites": {
    "DP-1": [ "1", "2" ],
    "DP-2": [ "3", "4" ]
  }
}

The only problem with that is that if you have separate configs per monitor, or if you have all_monitors enabled, you're going to end up duplicating that. So I'd say this is a case where accepting two formats would make sense? So favorites can also take just an array of names, in which case it would apply it to all monitors:

To always show 1, 2, 3 and 4 regardless of monitor:

{
"favorites": ["1", "2", "3", "4"]
}

Again, I'm open to ideas here - if you have other thoughts do let me know (or just run with them and I'll pick them up in the morning).

I'm not sure if the monitor name is currently passed in the context object, but if not it'd make sense (and hopefully be trivial) to add it.

@JakeStanger commented on GitHub (May 7, 2023): I'd say a map of monitor names to workspaces to include would be clearest: So to always show workspaces 1 and 2 on DP-1, and always show 3 and 4 on DP-2: ```json { "favorites": { "DP-1": [ "1", "2" ], "DP-2": [ "3", "4" ] } } ``` The only problem with that is that if you have separate configs per monitor, or if you have `all_monitors` enabled, you're going to end up duplicating that. So I'd say this is a case where accepting two formats would make sense? So `favorites` can also take just an array of names, in which case it would apply it to all monitors: To always show 1, 2, 3 and 4 regardless of monitor: ```json { "favorites": ["1", "2", "3", "4"] } ``` Again, I'm open to ideas here - if you have other thoughts do let me know (or just run with them and I'll pick them up in the morning). I'm not sure if the monitor name is currently passed in the context object, but if not it'd make sense (and hopefully be trivial) to add it.

JakeStanger commented

2026-05-23 03:52:22 +01:00

Author

Owner

@yavko commented on GitHub (May 7, 2023):

The only problem with that is that if you have separate configs per monitor, or if you have all_monitors enabled, you're going to end up duplicating that. So I'd say this is a case where accepting two formats would make sense? So favorites can also take just an array of names, in which case it would apply it to all monitors:

Yeah that's probably the best way

@yavko commented on GitHub (May 7, 2023): > The only problem with that is that if you have separate configs per monitor, or if you have `all_monitors` enabled, you're going to end up duplicating that. So I'd say this is a case where accepting two formats would make sense? So `favorites` can also take just an array of names, in which case it would apply it to all monitors: Yeah that's probably the best way