You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That's a good point, but what is the use case where a GNOME user wouldn’t have bash installed? I feel like anyone who installs this extension would (knowingly or not) expect bash commands to work, and changing might potentially break commands for some existing users.
I'm using chimera linux, and bash is not installed by default. I suspect there are other distros out there that do the same, since Gnome doesn't enforce having bash installed.
And I'd at least hope that users of the extension are not depending on bash-isms within the extensions commands config itself.
Anything more complex than a single command and an if-else case should, in my opinion, go into it's own script, with a proper shebang.
But ultimately it's up to you of course ^^
In my opinion this is a safe change, and a simple "hey the shell used changed" within the changelog would be warning enough.
This sounds like a great idea especially for cases when a user has "Keep Toggle State Synced" on with low polling interval, since sh might have a better performance than bash.
For example on Debian based systems, where /bin/sh is not just a symlink to /bin/bash, but rather a link to a more light-weight dash POSIX shell.
In my experience it's always better to stick with POSIX shell unless you explicitly need to use some bash-specific features, which should not be the case for short one-shot commands.
@fluvf That's a good point that anything complicated requiring specific bash-isms should be in a script, not in the actual command entered into the extension. However, I've learned not to underestimate the "creativity" of some users. Even for my use case I have several long commands chained together using && entered in the command fields (but that shouldn't be affected switching to POSIX).
@idzikovsky Thanks for the additional information. What distro are you using?
I will look into this more and do some testing and likely make this change (or at a minimum give the user the option to change).
And I'm currently working on another similar extension (but I'm considering ditching it and use this one, because it has almost all the capabilities I need), where I also use && and || in commands while using sh as a command interpreter.
I've been writing shell scripts for a lot of years, and I don't see how having an ability to use bash-specific syntax can provide any significant benefit in this paricular case. Basic POSIX shell syntax is very capable.
@StorageB
I was going to open new issues for that later.
Main things that I need is to have more button states (on/off and error), and something like an option to rerun status check for all buttons when a button is clicked.
With having this feature it would be possible to implement something like a radiobutton.
Here is my use case:
I have two speakers and one wireless headphones that can be turned on and off.
I have this script which allows to activate any named sink or check whether it is enabled or not.
So by having those two features and with a help of AI I was able to make this switcher:
So now I can see which of those three selected sinks are available and quickly switch between them.
The default settings interface does not suit my needs, since one speakers connected to a smart plug and every time I activate them I need to turn the plug on, and when I deactivate them I need to turn the plug off.
Also, this way is much more convenient than using the default tools.
And the 3rd minor thing is that it would be good to be able to pick a custom icon file for a button. In example I used SVG files from the Twitter Bootstrap icon set.
Custom icons are currently supported as noted in the User Guide
Save the icon in: ~/.local/share/icons/, reboot, and then enter the icon name (without the file extension).
Having the state of all buttons update on a button click is a good idea. Feel free to open an issue for that, and I'll see if I can add that.
I don't think I want to introduce multiple button states. If a use case is complicated enough to require a custom button state, a dedicated extension (like a dedicated audio switcher extension), may be a better approach.
However, someone requested the ability to change the button name based on a command output. I think this could be used for your situation to display the state in the name based on an output from your script. For example the toggles could look like this (the red/green indicator added manually just for this example)
Activity
StorageB commentedon Apr 29, 2026
That's a good point, but what is the use case where a GNOME user wouldn’t have bash installed? I feel like anyone who installs this extension would (knowingly or not) expect bash commands to work, and changing might potentially break commands for some existing users.
fluvf commentedon May 8, 2026
I'm using chimera linux, and bash is not installed by default. I suspect there are other distros out there that do the same, since Gnome doesn't enforce having bash installed.
And I'd at least hope that users of the extension are not depending on bash-isms within the extensions commands config itself.
Anything more complex than a single command and an if-else case should, in my opinion, go into it's own script, with a proper shebang.
But ultimately it's up to you of course ^^
In my opinion this is a safe change, and a simple "hey the shell used changed" within the changelog would be warning enough.
idzikovsky commentedon Oct 19, 2026
This sounds like a great idea especially for cases when a user has "Keep Toggle State Synced" on with low polling interval, since
shmight have a better performance thanbash.For example on Debian based systems, where
/bin/shis not just a symlink to/bin/bash, but rather a link to a more light-weightdashPOSIX shell.In my experience it's always better to stick with POSIX shell unless you explicitly need to use some bash-specific features, which should not be the case for short one-shot commands.
StorageB commentedon Oct 21, 2026
@fluvf That's a good point that anything complicated requiring specific bash-isms should be in a script, not in the actual command entered into the extension. However, I've learned not to underestimate the "creativity" of some users. Even for my use case I have several long commands chained together using && entered in the command fields (but that shouldn't be affected switching to POSIX).
@idzikovsky Thanks for the additional information. What distro are you using?
I will look into this more and do some testing and likely make this change (or at a minimum give the user the option to change).
idzikovsky commentedon Oct 21, 2026
@StorageB
I'm using Ubuntu.
And I'm currently working on another similar extension (but I'm considering ditching it and use this one, because it has almost all the capabilities I need), where I also use
&&and||in commands while usingshas a command interpreter.I've been writing shell scripts for a lot of years, and I don't see how having an ability to use bash-specific syntax can provide any significant benefit in this paricular case. Basic POSIX shell syntax is very capable.
StorageB commentedon Oct 21, 2026
Ok thanks, I'll work on making this change.
What other capability do you need that is missing from this extension?
idzikovsky commentedon Oct 21, 2026
@StorageB
I was going to open new issues for that later.
Main things that I need is to have more button states (on/off and error), and something like an option to rerun status check for all buttons when a button is clicked.
With having this feature it would be possible to implement something like a radiobutton.
Here is my use case:
I have two speakers and one wireless headphones that can be turned on and off.
I have this script which allows to activate any named sink or check whether it is enabled or not.
So by having those two features and with a help of AI I was able to make this switcher:
So now I can see which of those three selected sinks are available and quickly switch between them.
The default settings interface does not suit my needs, since one speakers connected to a smart plug and every time I activate them I need to turn the plug on, and when I deactivate them I need to turn the plug off.
Also, this way is much more convenient than using the default tools.
And the 3rd minor thing is that it would be good to be able to pick a custom icon file for a button. In example I used SVG files from the Twitter Bootstrap icon set.
StorageB commentedon Oct 24, 2026
@idzikovsky
Have you tried something like the Quick Sound Switcher extension or other audio switcher extensions?
https://extensions.gnome.org/extension/9788/quick-sound-switcher/
Regarding your feature requests:
Custom icons are currently supported as noted in the User Guide
Save the icon in:
~/.local/share/icons/, reboot, and then enter the icon name (without the file extension).Having the state of all buttons update on a button click is a good idea. Feel free to open an issue for that, and I'll see if I can add that.
I don't think I want to introduce multiple button states. If a use case is complicated enough to require a custom button state, a dedicated extension (like a dedicated audio switcher extension), may be a better approach.
However, someone requested the ability to change the button name based on a command output. I think this could be used for your situation to display the state in the name based on an output from your script. For example the toggles could look like this (the red/green indicator added manually just for this example)