Switch buttons (on/off)

[fluxtendu]

Is your feature request related to a problem? Please describe.
To start/stop some services or containers, I would like to avoid to have two buttons with only one usable at a time

Describe the solution you'd like
A button that switch command and color/icon with the status of a service or container

This feature and the display output of commands and your project would be very useful to me.
(It would replace an android app Smart Command SSH that may inspire you in terms of design and functionality)

Thanks for your work.

[jamesread]

Hey @fluxtendu , thanks for your suggestion :)

Yep, this something that would make a lot of sense - there are several times when this could be useful. I am experimenting in the code at the moment to see how I could implement this cleanly.

One problem that this design has, is every time you'd load buttons, you'd have to check which ones are enabled and which ones are not. That would be fine if you just have a few buttons, but it would very quickly lag and be horrible with more than 5-10 buttons. Probably the best way to get around this is to run checks continiously in the background and cache the result, but that doesn't really seem ideal either.

I'm going to play with the code and see what I come up with :)

[fluxtendu]

The lag will depend on the infrastructure and so I think ideally the refresh settings should be configurable by buttons (automatic every x amount of time, once at page load or even manually if you have a good interface idea)

And after thinking about it, the button should not necessarily change the command, a shell script can do the job. But another command to only get the status seems necessary.
Here is an example (probably badly coded) for docker which only returns the status with the -s parameter:

#!/bin/bash
if  [[ $1 != "-s" ]]; then
	dockerstatus=`docker inspect -f '{{.State.Running}}' $1`
	if [ $dockerstatus == "true" ] ; then
		docker stop $1 > /dev/null
	else
		docker start $1 > /dev/null
	fi
	echo "["`docker ps --format "{{.Names}} {{.Status}}" -a | grep -o $1.* | cut -f2 -d\ `"]"
else
	echo "["`docker ps --format "{{.Names}} {{.Status}}" -a | grep -o $2.* | cut -f2 -d\ `"]"
fi

And here another one (still probably badly coded) for systemd:

#!/bin/bash
if  [[ $1 != "-s" ]]; then
	if systemctl -q is-active $1; then
		sudo systemctl stop $1
	else
		if [ $(systemctl is-active $1) == "inactive" ]; then
			sudo systemctl start $1
			while ! systemctl -q is-active $1 ; do
				if systemctl -q is-failed $1 ; then
					break
				fi
				sleep 1
			done
		fi
	fi
	echo "["`systemctl is-active $1`"]"
else
	echo "["`systemctl is-active $2`"]"
fi

This brings me to another problem: how to interpret the result of the status command which will depend on the commands/scripts? Accepting only true or false answers is probably the easiest way but maybe too restrictive...

[jamesread]

Hey @fluxtendu - your example scripts look fine, and also what I had in mind too (it's a shame it cannot be as simple as systemctl is-active ... to cover both docker and systemd-managed containers though!). I think outputting some sort of true/false for the button state is a sensible start too (could be text, could be an exit code, or similar).

It's probably not a great user experience if users of OliveTin have to write all these "poll scripts" either, so it makes sense to have something out-of-the-box for common use cases like docker/systemd/podman etc. At the moment OliveTin's dependencies are very light though, and that's a nice thing. Taking on responsibility for all these poll scripts (maybe in bash, like you've done, or maybe built-in to the golang code) increases the dependencies and what would need to be tested as well. Not a deal-breaker, but something to be aware of.

But I still like the idea of buttons being enabled/disabled as a whole. I think better when I've tried out a few ideas in code, maybe that will help me feel more comfortable with a design that feels robust.

[jamesread]

Hey @fluxtendu , 3 years later and I finally have had time to implement what became entity support, which people are using to control containers; https://docs.olivetin.app/container-control-panel.html

This doesn't yet allow enable / disabling of buttons, but it's a long way to what I think you wanted?