i’ve been considering about interactive types, and this discussion could lead onto that
e.g. if you make a type, you should inherit IViewableType
Then you define how the type will be drawn in interaction scenarios, e.g. :
- Mouse hover on pins
e.g. Image type.
If i hover my cursor over the pin, I could actually see the image frame that was being fed (obviously this would only work for CPU based types, initially not textures)
then you could also have IBackwardsViewableType
This type instead carries the preview from nodes connected downstream.
To keep in line with general VVVV dataflow rules, we should not use the preview data in the evaluaton of node outputs, but it is useful for GUI elements
e.g. VideoControl type
The ‘standard part’ of the type contains the control signals (e.g. playstate, seek position, do seek).
The backwards viewable part ‘sucks’ video preview data from nodes downstream (e.g. a VideoPlayer which it is controlling)
It’s essentially a bit like an enum (data concerning the options are propagated backwards up the graph).
We would also need to be able to deal with:
- Viewing multiple potential values for the same slice simultaneously (e.g. Timerliner)
Not 100% sure at all how to do this.
But ideally would want to be able to bring up a GUI element for the following operations:
- Right click on an input pin
Essentially an IInteractableType has a special sort of constructor, which is called in order to instantiate that type without having a node produce it. This would also lead to there being a default value (as there is for Value,Color,Enum inputs). And the value of the type could be affected through self driven GUI elements which are triggered on the IOBox/right click actions.
The separate modes of interaction could perhaps be dealt with by different interfaces.
Perhaps this could be drafted with an ITimelinerInteractableType (similar to an IInteractableType+IBackwardsViewableType above)
With the example being a VideoPlaybackControl type, for use with a video player.
(Then perhaps later extend for use with IOBoxes, other GUI interactions)
ok. bit too much all at once and definitely dancing onto the wrong side of feasibility :).