Conditional widgets Stage 1 #849
Labels
Enhancement
This issue is about a new feature rather than a bug.
Low interest
Importance of this issue seems questionable for the bottom-line..
Mental load
Is related to API usability.
The issue is that at this point I have:
etc etc.
So there is about 10 conditional widget in Auburn codebase. Most of them define additional
@ScriptProperty
to control the appearance of the disabled widget.All points towards a smallish Condition interpreter that can parse and evaluate an expression tree at given points in time (typically, when a listened parameter changes). For now the expression tree is implemented in Auburn codebase in a lame fixed way ( a set of && or || expressions, with 2 operators, and up to 12 operands).
Ideally we want:
The expression itself is evaluated when it's value may have changed.
This evaluation will happen for many widgets, even inside audio thread as part of a host setParameter, and myst be quick!
This will allows the agreeable idioms:
widget.enableIf(string expr);
to control the .isDisabled statewidget.showIf(string expr);
to control visibilityAny widget has such a conditional extension. This will avoid the existence of:
Stage 1
CondLogic
as a lazy extension of allUIElement
. It's a set of || or && expression, suitable for most purposes but not very readable..isEnabled
and.isDisabled
. By default true, unless the condition is created and return false.Now the sub-class are easier to write, but there are still multiple subclasses. This is 80% of the value.
Stage 2
.enableIf
call to UIElement that created theCondLogic
andwidget.enableIf
* Perhaps find the semantic way to express al kind of disabled re-coloring.
The text was updated successfully, but these errors were encountered: