Scripting: Allow setting starting value and tooltip in Dialog add widget methods

[eishiya]

A common pattern when writing scripts that use Dialogs is something like

let widget = dialog.addColorButton("My Color");
widget.color = defaultColor;
widget.toolTip = "My explanatory tooltip";
widget.colorChanged.connect(function(state) {/*do stuff*/});

/*the widget variable is never referenced again after this*/

This makes code building dialogs rather verbose because one needs multiple statements to set all the properties one wants, and because one has to keep a variable to reference the widget to set all those properties. A few of the widget-creating methods, such as addCheckBox, already take a starting value, making using them a little cleaner to create.

For all of the add[Widget] methods, it would help if they all had optional parameters for the starting value and the tooltip, so one could do e.g.

let widget = dialog.addColorButton("MyColor", defaultColor, "My explanatory tooltip");
widget.colorChanged.connect(function(state) {/*do stuff*/});

Or, if the scripter really wants a one-liner and only has one signal they care about, they could even do

dialog.addColorButton("MyColor", defaultColor, "My explanatory tooltip").colorChanged.connect(function(state) {/*do stuff*/});

A starting value is probably more often needed than a tooltip, so it should come before the tooltip in the parameter list. These methods will also need to be careful to not interpret null as false or some other "valid" value, for those cases where the programmer wants to skip setting a starting value but still wants to use the tooltip parameter.

With these additional parameters, one would be able to add fully usable widgets with less code, and would usually only need to keep references to those widgets around if they need to modify the widget elsewhere, e.g. to change whether it's enabled in response to other widgets changing.

On Discord, bjorn and I discussed accepting signal handlers as parameters too, but because some widgets emit multiple signals, doing so would probably still have to be pretty verbose, requiring either separate parameters per signal necessitating passing null values, or using a map to name the desired signal(s), e.g. { currentIndexChanged: function() {/*do stuff*/} }. The latter is still somewhat verbose and would require the add[Widget] method to be aware of which signals are available, a complication avoided by sticking with Signal.connect(). We concluded that it's probably best to leave signals out of this, even where there's only one possible signal.