New delay action

[Coupe70]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

First of all I would like to thank everbody who contributes to Companion!
It's a fantastic software and I am more than happy to use it.

But for the first time since using it there is a change that really feels like a downgrade for me.
Maybe I'm the only one and maybe I'm missing something important, but I don't see the benefit
of the new delay actions compared to the in-action delays.
Instead the action lists in many of my buttons are twice as long now and much harder to read and maintain.
I was really kind of shocked when I opened my config in the new version...

So with all respect I would like to ask to maybe overthink this change.
Or maybe someone can shed some light on what I'm missing or why it was a necessary change.

Maybe we could at least get a toggle to hide these delay actions?
Maybe a thin red line between actions could show that there is a delay action between them...?

Thank you for reading.

Usecases

[Julusian]

You can read the discussion had while implementing this at #3163 and #2882. But beware that we get sidetracked on naming of other things for quite a while, and I'm not sure we truely address the why of this change.

For me the main reason for changing it was to keep the flow sensible and predictable with the new groups and ui changes. (some of which is coming in 4.0)

Having it as an action allows us to simplify the execution, as well as easily expand what it can do. It is now possible to have a wait which accept variables/expressions. That wouldn't have been possible in the old flow, and would not have fit in the old position of the field.

In 3.5 there is the new 'action group' action, which can contain other actions. In 4.0, will be a 'logic: if' action which can also contain actions. These are laid out in a single column (without the area where the delay field resides).
This gave the challenge of figuring out where to put the delay field. Maybe we could have moved it above the action options, but the worry was that would be confusing having the position vary and blurring the lines on whether this field affects what the action does or how it does it. Having it always above would have made every action taller, when doesnt feel worthwhile when we believe it is a minority of cases which use this field.
By it being its own action, we avoid the ambiguity/confusion of varying, and avoid consuming screen space when it isnt wanted.
It is also worth noting that in 4.0, the layout of the action fields has changed to remove that left area entirely, and in doing so actions have been made a bit less tall. This means the density of actions with waits before them will be similar to 3.4. That change was made too late to make it into 3.5.

You could ask, why not have both the action and it as properties on actions. But that would add clutter and will be confusing to many, with the question being asked 'whats the difference?'.

But a key part of this which hasn't been mentioned yet is, maybe you don't need so many short waits?
The new 'action group' action can be set to run its contents sequentially, instead of all the default behaviour of at once. So those waits which are there to allow X to happen before doing Y, could maybe be removed by using a sequential group.
This doesnt work correctly for every module, but does for many of them.