widgets: execute shell commands from more keywords

[Acumane]

Draft PR for extending shell command execution to other keywords (position, color, dots_text_format, etc.)

This scuffed but functional first commit only works for a label's position.

[Acumane]

Maybe all concerned types should take strings (internally) so that we needn't duplicate the work of formatString() for command parsing. Then each keyword can perform it's own type validation on that string.

I haven't taken a peek at the recent changes to the animation system, but it'd also be neat if these state changes could have transitions.

[PaideiaDilemma]

I personally really don't like this.

While I understand the desire to have certain options be dynamic, I think launching shell commands is not a good way to achieve that.

In hyprland you have hyprctl keyword, and a hot reloading config to allow for those kind of dynamic updates.
Having that in hyprlock would probably be overkill, but still a much saner approach to archive this.

I also don't like that we would potentially have to wait for n shell commands before actually drawing the widget at the correct position/size etc.

The label text is special, because it is just text, takes rather long to render anyways and does not result in a huge amount of underlying complexity.

[alba4k]

In hyprland you have hyprctl keyword, and a hot reloading config to allow for those kind of dynamic updates.

While I agree on an ipc being a bit overkill, I would like to remind you that this is exactly how dynamic changes are handled in hyprpaper, via hyprctl hyprpaper ...

Having something like hyprctl hyprlock ... could make sense for stuff like this, although I don't really know how it would work or how it would be useful. Also, hyprpaper is usually always running, while hyprlock is not.

This hyprctl implementation could also handle something like lock/unlock I guess, acting as a wrapper for, respectively, hyprlock (via hyprctl hyprlock lock) and pkill -s SIGUSR1 hyprlock (via hyprctl hyprlock unlock). Imagine hyprlock running as daemon, this would allow for faster locks and unlocks, although it would be of limited usefullness