Firm Widgets (Proposal)
One of the features of Kyma – being able to quickly create hot values that display in a VCS is great for development of an idea but can also be a bugbear when working on complex projects or recombining existing work.
The issue is that VCS widgets and their layouts are lost when a hot value is renamed as is often necessary when recombining work. Existing solutions like the prefixer address the problem but not completely to my mind. The result is a lot of time is spent repeatedly formatting and setting up VCS objects and layouts.
Some good work has been done around this but to my mind VCS objects and layouts are still far too fragile and as a result, take up more development time than they should.
Keeping in mind that SSC may have something already in the pipeline to deal with exactly this, I’ve still been thinking about an approach to this issue. There will be some holes and gaps in this idea (I have a few ideas I havent described here just to keep this simple) and there may well be a better approach but here goes.
Short of a complete re-approach, I think what’s needed is a means to create and save VCS widgets and layouts as an object that can be handled more like other ‘sound’ objects in a Kyma sound structure.
I havent worked this out completely yet but to my mind there is some logic in modifying the Annotation prototype (if possible) to be able to contain new VCS objects I'll call 'Firm Widgets' and 'Firm Layouts', and extend or augment the VCS Editor with something like the 'Widget Table' as described below.
To create a hot value with a new firm widget put a colon* between the exclamation point and the hot value name eg. !:aHotValue.
*a colon is suggested as example, possibly a different character
When a Firm Widget is defined it is also given a unique identifier that cannot be seen or edited.
When the sound is compiled, the VCS containing that firm widget is also converted into a Firm VCS. A Firm VCS contains Firm Widgets and any other conventional hot values, the difference being once a Firm Widget has been defined, it (and the Firm VCSs associated with it) exist as objects attached to the Annotation prototype that will remain in the project even if its associated Hot Value gets deleted or renamed.
An extension of the VCS editor design: an editable table of existing VCS Hot Values and any Firm Widgets providing the means to convert existing Hot Values into Firm Widgets and see and edit the relationships of hot values as inputs and outputs of firm widgets.
In this table you could create new Firm Widgets and attach them as Child objects to an existing hot value or even nothing. One application here is creating a large version of a VCS Layout and then a small version that can be used as a sub layout or alternative layout but this would also enable mapping of a firm widget to an arbitrary number of other hot values and potentially setting up quite complex mappings (and can of worms).
A Firm Widget has an input parameter: ‘Hot Value’, and an output parameter ‘Connected To’, both of which link by default to the hot value. Both of these parameters (or links) can handle being empty or broken which is what happens if the colon is removed or the hot value is otherwise renamed. Perhaps a broken or missing link could be displayed in a particular format if Kyma detects the break.
It makes sense that it should be possible to connect one or more Hot Values as destinations for a Firm Widget’s output. Using code in the input and output fields is also an enticing idea but I’ll leave it there.
I hope I've described this clearly, happy to discuss.