Tristate buttons

For long running task where the initialization phase takes a long time, it would be useful to have an intermediate state between OFF and ON.
In this state the button could be in disabled (grey) state, cannot be pressed. And when "check" function reports ON, then it could turn ON.

Do you plan to have this feature?

I think this could be a nice feature to have, but I'm curious what is the use case where a task would take long enough to justify this?

I saw your fork of this extension and that is a very nice (and long overdue) refactor of the code! Are you planning on a pull request to merge this? If so, a couple of questions on the intermediate state:

is it possible to get stuck in the intermediate state if a task fails or for some reason doesn't complete?
is it running the pending check at the command sync interval? If so, if user has the interval set to something large like 60 seconds, does that mean the toggle would show the intermediate state for 60 seconds even if the task completed in a few seconds?

Yes, I'm planning to create a pull request, and I have to admit, I was a bit nervous — so it’s a big relief that you like the changes and don’t see them as stepping on your toes.

I'm starting up a service in a VM. The startup is already happens in the background, and the script won't exit until the VM is stopped.
Yes, it can get stuck, and in my usecase it needs manual intervention to fix it. I don't really know (yet) what would be the generic solution
Currently yes, command sync interval is used. And yes, it will be in pending state until the check reports it to be done. We can introduce a new timer for this case, if you wish.

The code refactor is great and just something I haven't had time to do. The extension started small and has added features over time that has resulted in messy code that is hard to maintain.

There is only one major issue I see with the refactor:

Changing settings keys will completely erase all commands and settings for existing users. The existing naming is bad, but I haven't changed them for this reason. If you want to change them, there needs to be a migration function that updates the new keys with values from the old ones for existing users when updating to the new version. I recently had to do something similar with my other extension.

For the intermediate button state issues:

If the button is unresponsive after clicking, I'm concerned the typical user will think there is something wrong like the UI is frozen, and this will come across as a bug not a feature. We could add the option to enable this feature under the Toggle Behavior section (off by default), and when enabled the user could have a separate timer to check the pending status (although the additional timer sounds like unnecessary complexity, as checking at the next interval check is probably fine since the user manually enabled this function and understands why the button is unresponsive). What are your thoughts?
I'm not sure either how to prevent a "stuck" scenario for every possible use case. This is something I'll have to think more about as well.
Are you using the toggle to turn off the VM as well? If you're only turning it on, you could use an "Always off" button that just sends one command to turn on, and there is no need for an intermediate state.

I haven't touched the backup files structure, exactly for this reason. So a migration path could be to export your settings, and reimport in the new version. And also it could be done automatically.
This could be a way forward
Well...your example in the readme can have this misleading case. You try to start the systemd service, it fails to start, so your button will never get to ON state. And the user will try to push it again. So I think it would be more meaningful to show the user that "yes, we have received your intent to start it and we have done our best, but the service is still not in a running state".
The turn off command is a "ssh VM sudo poweroff", and the check command will show the pending state, so it's also put into pending state. And I really want to prevent the user (currently only myself) of clicking it again...

Migration should be automatic. See this example - it sets a "v13-migration-complete" key to true after migration happens so it only happens once after upgrading. The migration function can then be removed in the following release. Old keys must remain in the schema along with the new ones for the migration to happen. I'm open to better methods as well.
let's plan on adding an option to turn on this feature then unless you come up with a better idea later
True, the toggle state could be incorrect. Using the sync option would correct the state (there was also a request for DBus support that seems like a good idea) However, if the intermediate state is "stuck" then the user must manually reset the extension to be able to use the button again.
Got it.

Ok, I'll make that happen, How about we introduce a "settings-version" key, this could contain "13" and so on, so that the migration process could read the version, if it can migrate then it will do it.
I have no idea how the schema migration happens? Would that mean that the project would need to have all the settings from version 1? (I'll read the documentation...)
Ok, I'll add a toggle button for the Toggle button :)

Great! I'm not sure how the "settings-version" key would work, but need to make sure migration only happens once. Note that when using the "Reset to Default" option, it currently resets all keys to default values. Need to make sure this doesn't reset the migration key or whatever is used to track that, otherwise it would overwrite new values the user entered with the legacy keys when the reset button is pressed.

You can't access a key if it isn't in the schema, so you need to have both the old and new keys. In a future release, the old keys can be removed from the schema as existing users will already be migrated and they won't be needed for new users.

Hello! I was hoping to add some new features to this extension, but wanted to use your refactored code. Would you be willing to open a pull request from a branch based on your first two commits for the refactored code? I can continue to develop it and create the schema migration portion.

Hi, Sorry for not being active lately. I'll open the pull request.

Navigation Menu

Repository navigation

Tristate buttons #26

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Tristate buttons #26

Description

Activity

StorageB commented on Feb 19, 2026

dromie commented on Feb 19, 2026

StorageB commented on Feb 19, 2026

dromie commented on Feb 19, 2026

StorageB commented on Feb 19, 2026

dromie commented on Feb 19, 2026

StorageB commented on Feb 19, 2026

StorageB commented on Apr 20, 2026

dromie commented on Apr 20, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions