JakeStanger/ironbar

Fork 0

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

[GH-ISSUE #357] Feature request: workspaces default icon #1534

New issue

Open

opened 2026-05-22 22:52:51 +01:00 by JakeStanger · 8 comments

JakeStanger commented

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

Owner

Originally created by @Pyvonix on GitHub (Nov 13, 2023).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/357

Is your feature request related to a problem? Please describe.
While configuring workspace block, it's possible to assign an icon to specific place. But doesn't look like possible to define a "default" icon for an extra workspace that will be opened/created.

Describe the solution you'd like
The solution could be to add two new configuration parameters for workspaces: default and focused.
These parameters will be used as default values if new workspace is created (e.g. 4, 5, 6, ...).

Example of proposed config:

{
  "end": [
    {
      "type": "workspaces",
      "name_map": {
        "1": "",
        "2": "",
        "3": ""
      },
      "favorites": ["1", "2", "3"],
      "default": "",
      "focused": "⚪",
      "all_monitors": false
    }
  ]
}

Reference of the used example: https://github.com/JakeStanger/ironbar/wiki/workspaces

Describe alternatives you've considered
Currently looking through the GTK's documentation to find a possible way to assign the icon via the style.css.
From my progression: the content keyword isn't supported in style.css and I don't know what will be the behavior between icons assignment inside the name_map and the stylesheet.

Additional context
None.

Originally created by @Pyvonix on GitHub (Nov 13, 2023). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/357 **Is your feature request related to a problem? Please describe.** While configuring workspace block, it's possible to assign an icon to specific place. But doesn't look like possible to define a "default" icon for an extra workspace that will be opened/created. **Describe the solution you'd like** The solution could be to add two new configuration parameters for workspaces: `default` and `focused`. These parameters will be used as default values if new workspace is created (e.g. 4, 5, 6, ...). Example of proposed config: ```json { "end": [ { "type": "workspaces", "name_map": { "1": "", "2": "", "3": "" }, "favorites": ["1", "2", "3"], "default": "", "focused": "⚪", "all_monitors": false } ] } ``` Reference of the used example: https://github.com/JakeStanger/ironbar/wiki/workspaces **Describe alternatives you've considered** Currently looking through the GTK's documentation to find a possible way to assign the icon via the `style.css`. From my progression: the `content` keyword isn't supported in `style.css` and I don't know what will be the behavior between icons assignment inside the `name_map` and the stylesheet. **Additional context** None.

JakeStanger added the

M:Workspaces

T:Module Enhancement

A:IPC

labels

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

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Nov 14, 2023):

Hey, I'm not sure I fully understand this? A workspace will always use its name, or the value in name_map if present. Are you asking for the ability to never use its name, and always use a value from the config instead? What is the use-case for that?

@JakeStanger commented on GitHub (Nov 14, 2023): Hey, I'm not sure I fully understand this? A workspace will always use its name, or the value in `name_map` if present. Are you asking for the ability to *never* use its name, and always use a value from the config instead? What is the use-case for that?

JakeStanger commented

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

Author

Owner

@Pyvonix commented on GitHub (Nov 16, 2023):

Hey, thank for the answer.

I'm talking to the ability have a default name while not defined in name_map.
The use case is: I define workspace's names for 1, 2 and 3. But when I switch to workspace 4, it don't have any name/icon (it toke 4). So, I want to availability to have a default name for this workspace.

@Pyvonix commented on GitHub (Nov 16, 2023): Hey, thank for the answer. I'm talking to the ability have a default name while not defined in `name_map`. The use case is: I define workspace's names for 1, 2 and 3. But when I switch to workspace 4, it don't have any name/icon (it toke `4`). So, I want to availability to have a default name for this workspace.

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Nov 16, 2023):

I think this is a very niche usecase, I can't see much value in being able to set all workspaces to use the same icon as you would almost always want to tell them apart.

Could you not just add an entry for 4, 5, 6, ... into the name_map, or is there something else having this default property would let you do?

@JakeStanger commented on GitHub (Nov 16, 2023): I think this is a very niche usecase, I can't see much value in being able to set all workspaces to use the same icon as you would almost always want to tell them apart. Could you not just add an entry for 4, 5, 6, ... into the `name_map`, or is there something else having this `default` property would let you do?

JakeStanger commented

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

Author

Owner

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

I think this is a very niche usecase, I can't see much value in being able to set all workspaces to use the same icon as you would almost always want to tell them apart.

Could you not just add an entry for 4, 5, 6, ... into the name_map, or is there something else having this default property would let you do?

Some people have this (I used to too) where each workspace is just a dot, and you get workspace by order lol. It'd probably be useful to have a default in this case as defining a bunch of workspaces with the same name is tedious (I got around this with nix) and won't work if you pass the amount of workspaces defined.

@yavko commented on GitHub (Nov 16, 2023): > I think this is a very niche usecase, I can't see much value in being able to set all workspaces to use the same icon as you would almost always want to tell them apart. > > Could you not just add an entry for 4, 5, 6, ... into the `name_map`, or is there something else having this `default` property would let you do? Some people have this (I used to too) where each workspace is just a dot, and you get workspace by order lol. It'd probably be useful to have a default in this case as defining a bunch of workspaces with the same name is tedious (I got around this with nix) and won't work if you pass the amount of workspaces defined.

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Nov 26, 2023):

How many workspaces are we talking here? I can see where you're coming from, but if we're talking maybe 10 it feels like the right answer is to just suck it up and add 10 identical lines to your config, rather than add a dedicated config option to it.

I'm hesitant because it would add yet another config option and all the additional logic to go with it, which is only useful in this specific case that already has a solution. Every new option is something else to go wrong and something else to support, which means additional testing and documentation, so I want to be conservative with them.

@JakeStanger commented on GitHub (Nov 26, 2023): How many workspaces are we talking here? I can see where you're coming from, but if we're talking maybe 10 it feels like the right answer is to just suck it up and add 10 identical lines to your config, rather than add a dedicated config option to it. I'm hesitant because it would add yet another config option and all the additional logic to go with it, which is only useful in this specific case that already has a solution. Every new option is something else to go wrong and something else to support, which means additional testing and documentation, so I want to be conservative with them.

JakeStanger commented

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

Author

Owner

@Pyvonix commented on GitHub (Dec 17, 2023):

I took a moment to think about the best way to present it.

Let's say I want to put the same icon via for my 10 workspaces.
I'll need to produce the following configuration:

{
  ...
  {
      "type": "workspaces",
      "name_map": {
        "1": "",
        "2": "",
        "3": "",
        "4":  "",
        "5":  "",
        "6":  "",
        "7":  "",
        "8":  "",
        "9":  "",
        "10":  "",
      },
  },
  ...
}

It's repetitive, not really efficient way to handle it and produce a lot of config lines while it could just be:

{
  ...
  {
      "type": "workspaces",
      "default": ""
  },
  ...
}

In this case, I assume that the user doesn't want to specify another icon for a specific workspace.

Unfortunately, I don't think I've got the level of Rust required to propose PR yet.
But we could think of the following logic:

Does the opened workspace have a label? (through the name_map)
- Yes: use it and stop there
- No: continue
Does the workspace definition have a default value?
- Yes: use it
- No: same behavior than currently

I think this new parameter could cover a lot of customization cases.

@Pyvonix commented on GitHub (Dec 17, 2023): I took a moment to think about the best way to present it. Let's say I want to put the same icon via for my 10 workspaces. I'll need to produce the following configuration: ```json { ... { "type": "workspaces", "name_map": { "1": "", "2": "", "3": "", "4": "", "5": "", "6": "", "7": "", "8": "", "9": "", "10": "", }, }, ... } ``` It's repetitive, not really efficient way to handle it and produce a lot of config lines while it could just be: ```json { ... { "type": "workspaces", "default": "" }, ... } ``` In this case, I assume that the user doesn't want to specify another icon for a specific workspace. Unfortunately, I don't think I've got the level of Rust required to propose PR yet. But we could think of the following logic: 1. Does the opened workspace have a label? (through the `name_map`) - **Yes**: use it and stop there - **No**: continue 2. Does the workspace definition have a default value? - **Yes**: use it - **No**: same behavior than currently I think this new parameter could cover a lot of customization cases.

JakeStanger commented

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

Author

Owner

@yavko commented on GitHub (Dec 26, 2023):

1 way to implement this could be adding an IPC command that lets you change the name appearing on the bar (which could be used for other things too), which could be used like so (I think, haven't tested):

#!/bin/sh

handle() {
  case $1 in
    workspace*) ironbar renamework $(echo $1 | cut -b 11-) "new name";;
  esac
}

socat -U - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock | while read -r line; do handle "$line"; done

@yavko commented on GitHub (Dec 26, 2023): 1 way to implement this could be adding an IPC command that lets you change the name appearing on the bar (which could be used for other things too), which could be used like so (I think, haven't tested): ```sh #!/bin/sh handle() { case $1 in workspace*) ironbar renamework $(echo $1 | cut -b 11-) "new name";; esac } socat -U - UNIX-CONNECT:/tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/.socket2.sock | while read -r line; do handle "$line"; done ```

JakeStanger commented

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

Author

Owner

@JakeStanger commented on GitHub (Dec 27, 2023):

Hm I hadn't considered approaching it from a scripting angle. I'd be more open to that as it offers more flexibility rather than a single usecase.

There's a few possibilities to explore there in addition to what you've said. A couple that spring to mind immediately:

Ability to use scripts / ironvars in name_map entries (not sure how useful that'd be?)
Ability to provide some name_map_func option that runs a script with the current workspace as an input and uses the result

@JakeStanger commented on GitHub (Dec 27, 2023): Hm I hadn't considered approaching it from a scripting angle. I'd be more open to that as it offers more flexibility rather than a single usecase. There's a few possibilities to explore there in addition to what you've said. A couple that spring to mind immediately: - Ability to use scripts / ironvars in `name_map` entries (not sure how useful that'd be?) - Ability to provide some `name_map_func` option that runs a script with the current workspace as an input and uses the result