JakeStanger/ironbar

Fork 0

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

[GH-ISSUE #212] [Accessibility] Using ironbar with a keyboard #4315

New issue

Open

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

JakeStanger commented

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

Owner

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

Is your feature request related to a problem? Please describe.
It would be cool if there was a way to use ironbar with a keyboard.

Describe the solution you'd like
Other taskbars let you tab between buttons and open/close popups with the keyboard.

Describe alternatives you've considered
Using another application with keyboard support when no mouse is available.

Originally created by @donovanglover on GitHub (Jul 3, 2023). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/212 **Is your feature request related to a problem? Please describe.** It would be cool if there was a way to use ironbar with a keyboard. **Describe the solution you'd like** Other taskbars let you tab between buttons and open/close popups with the keyboard. **Describe alternatives you've considered** Using another application with keyboard support when no mouse is available.

JakeStanger added the

T:Core Enhancement

A:UX/UI

labels

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

JakeStanger commented

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

Author

Owner

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

Hey, I'm always happy to improve accessibility. The work in #91 is currently laying the groundwork for this. I aim to add some support for remotely controlling parts of the UI, with the ability to open/close popups coming first. You'd then be able to set up keybinds to do this via the CLI.

Once that's in place, I will start looking at extending that to some module-specific features (for example, being able to focus/open a specific item on the launcher).

I'll also have a look at keyboard focus in general so you can tab-focus and open popups directly - it may be that I add a command that toggles keyboard focus on/off, so you can run that (probs via a keybind), then tab to where you need to be.

@JakeStanger commented on GitHub (Jul 3, 2023): Hey, I'm always happy to improve accessibility. The work in #91 is currently laying the groundwork for this. I aim to add some support for remotely controlling parts of the UI, with the ability to open/close popups coming first. You'd then be able to set up keybinds to do this via the CLI. Once that's in place, I will start looking at extending that to some module-specific features (for example, being able to focus/open a specific item on the launcher). I'll also have a look at keyboard focus in general so you can tab-focus and open popups directly - it may be that I add a command that toggles keyboard focus on/off, so you can run that (probs via a keybind), then tab to where you need to be.

JakeStanger commented

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

Author

Owner

@Schweber commented on GitHub (Jan 21, 2024):

I just saw that you added the autohide feature in the new release, thank you for that.

Would it be possible to make the bar unhide when switching workspaces (with an extra setting), so that i don't have to use the mouse to make the bar unhide and get information about the workspace situation?

@Schweber commented on GitHub (Jan 21, 2024): I just saw that you added the autohide feature in the new release, thank you for that. Would it be possible to make the bar unhide when switching workspaces (with an extra setting), so that i don't have to use the mouse to make the bar unhide and get information about the workspace situation?

JakeStanger commented

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

Author

Owner

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

That isn't a feature I'd want to add directly into the bar as it's very specific & implementation would vary for every compositor. I am open to making it easier to script though, so if you have ideas around that let me know.

You should be able to do that already with a little script to listen to workspace change events from your compositor IPC, and then use the ironbar set-visible -v <bar name> command.

@JakeStanger commented on GitHub (Jan 21, 2024): That isn't a feature I'd want to add directly into the bar as it's very specific & implementation would vary for every compositor. I am open to making it easier to script though, so if you have ideas around that let me know. You should be able to do that already with a little script to listen to workspace change events from your compositor IPC, and then use the `ironbar set-visible -v <bar name>` command.

JakeStanger commented

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

Author

Owner

@Schweber commented on GitHub (Jan 22, 2024):

That isn't a feature I'd want to add directly into the bar as it's very specific & implementation would vary for every compositor.

Hmm, doesn't the bar in the end execute a command like "mark workspace 2 as the active one instead of workspace 1" to which "unhide the bar" could be added as an option? I mean, the compositor specific things are already taken care of before the bar is content that it shall change its state to show a different active workspace, right? (i'm not much of a programmer at all, it's just the way i imagine the process)

You should be able to do that already with a little script to listen to workspace change events from your compositor IPC, and then use the ironbar set-visible -v <bar name> command.

I see. Thank you, i'll try that.

@Schweber commented on GitHub (Jan 22, 2024): > That isn't a feature I'd want to add directly into the bar as it's very specific & implementation would vary for every compositor. Hmm, doesn't the bar in the end execute a command like "mark workspace 2 as the active one instead of workspace 1" to which "unhide the bar" could be added as an option? I mean, the compositor specific things are already taken care of before the bar is content that it shall change its state to show a different active workspace, right? (i'm not much of a programmer at all, it's just the way i imagine the process) > You should be able to do that already with a little script to listen to workspace change events from your compositor IPC, and then use the `ironbar set-visible -v <bar name>` command. I see. Thank you, i'll try that.

JakeStanger commented

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

Author

Owner

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

You're right in that the code to talk to the compositors is already there, but it's not that simple to implement as it's a separate area of the code. All of the workspace code is isolated to two places, neither of which (should) have access to high-level things like controlling the bar:

The service code, which connects to the compositor IPCs to send/receive events.
The module code, which consumes the service and controls the user interface.

These are both behind the workspaces feature flag. There is nothing technically stopping the main bar code from additionally consuming the service and listening to workspace change events, but this is a lot of additional complexity for little gain (as I say, this should be achievable already via Ironbar's IPC). For example, currently the workspace service is only started when the module initialises. If it was required for the option, then additional logic to handle unsupported compositors may be required. Individual options being behind a feature flag is also something I'd like to avoid, as it can become confusing to keep track of.

If you do have any issues getting the CLI to behave as you'd expect, let me know and I'm more than happy to look at ensuring that works as a solution.

@JakeStanger commented on GitHub (Jan 22, 2024): You're right in that the code to talk to the compositors is already there, but it's not that simple to implement as it's a separate area of the code. All of the workspace code is isolated to two places, neither of which (should) have access to high-level things like controlling the bar: - The service code, which connects to the compositor IPCs to send/receive events. - The module code, which consumes the service and controls the user interface. These are both behind the `workspaces` feature flag. There is nothing technically stopping the main bar code from additionally consuming the service and listening to workspace change events, but this is a lot of additional complexity for little gain (as I say, this should be achievable already via Ironbar's IPC). For example, currently the workspace service is only started when the module initialises. If it was required for the option, then additional logic to handle unsupported compositors may be required. Individual options being behind a feature flag is also something I'd like to avoid, as it can become confusing to keep track of. If you do have any issues getting the CLI to behave as you'd expect, let me know and I'm more than happy to look at ensuring that works as a solution.