A few more wishful VL feature requests for the benevolent devvvvs to consider.
A way to copy automatically assigned pin type-annotations to clipboard. So you can paste them when manually typing a pin.
Because when you a dealing with a complicated type like a delegate or a dictionary it can be easy to make an error. Either that or the autocomplete dropdown includes types that already exist somewhere in the patch.
Text labels on links. Many of the UI features I’m requesting below I solve currently by putting a manual text box label on top of a link.
Visual differentiation in the UI between a spread, a spread of spreads, an empty spread and a single object. Possibly as a debug mode.
I think the conceptual difference between single objects and spreads of objects is one of the critical design features of VL.
For example If I was writing a textbook to teach VL I would need a visual way to show this concept for students to understand it. It’s totally critical to the logic to see if the context I am operating on is a spread of objects or a single object and where and how this transforms.
A way to mark yellow mutable warning links as ‘read only’.
A ‘read only’ link would only permit downstream operations that, well, only read. Returning red nodes or links otherwise. . And if there were two links and one was marked read only then the mutable warning would clear from the remaining link leaving it normal.
This is because when I have yellow links in the final patch I have already managed the warning. One is the ‘true path’ where objects will be changed. The other paths are read only. I want a way for this to be indicated visually to someone looking at this part of the patch, they don’t have to trace through further logic to see which branch is read only.
Export VL graph as SVG of current view, and display in forums as zoomable graphic same as the real VL editor.
In my other big debug feature request I touched on my ideas for how VL might handle navigating between instances of a function. In terms of looking at instances it would also be great to instantly see if a change you made in an operation broke any instances of other functions that use that operation.
if you say spread vs single value, you probably mean any type of collection vs any type of non collection. right? that would be Spread, Sequence, Dictionary, HashSet, Array, List, …?
Maybe a way to turn on a text label on the link to show exactly the type if that’s important?
Because it would be crazy to have a different line type for every possible collection type… unless it’s not?
Maybe it’s not so crazy? There could be a ‘line style’ editor that you could associate with datatypes on a per project basis. So it has defaults for single object vs collection, but if I made a custom datatype Dictionary(Foo,Bar) I could also give it a specific line style for this project… Ok it’s a bit crazy.
I would also like to see it at a glance if a collection contains 0 objects. Often I find myself wondering ‘why isn’t this working now?’ and I realise it’s because something I did earlier accidentally cleared all my objects and I need to re initialise. If I knew I’d cleared the objects the moment I did it that would be helpful.
Although spread count is something that has to be checked on a per frame basis so I would also want it would be a switchable debug tool…
in the settings you can enable the tooltip for links, i’d say that solves 80% if your issue… but i’ve just tested it and it’s not working anymore. i’ll make an issue for that. the tooltip would show start and end of the link as well as its type.
when pressing CTRL while hovering a link you already see the links type. this tooltip is not active by default as it gets on ones nerves pretty quickly. but of course it could become a setting…
the problem with labels on links is that there is no good place to position them automatically. at the beginning? at the end? in the middle. any choice only works for some cases. so you’d want to be able to position it yourself, which comes very close to what you’re already doing, except that it would follow the link around if you moved it. and that just didn’t climb the priority ladder yet…
regarding svg export of patch: yes will be possible at some point
readonly links: to my understanding the reason why this isn’t trivial is because we don’t know if a node reads or writes. but maybe @gregsn or @elias can elaborate on that
For displaying the link types a tooltip doesn’t solve the long term problem. I want a way to show type and ‘collection-ness’ of all links in a static screenshot, at a single glance. Not only in the live VL editor. I think this would make VL a stronger visual programming language because having the types represented directly on the patch is a better visual explanation of the logic.
It would cause some clutter and you would have to space patches appropriately to make them look good but I would like the option to do this.
Good point about labels on links.
Also happy to hear about SVG.
Happy to wait patiently to see both of these features one day.
Readonly links: Ok even if there’s no check that it’s read only it would still be useful if I could visually mark one link as a read only link and clear the mutable warning from the other link. I will manage which is read only (I already have to do that) but at least the logic of the patch is visually clear.
this mark would not be on the link, but on the input pin where the link ends. each pin could hint the compiler that it will only read the input data. the advantage is that the developer of the node, who actually knows what happens with the data marks it and all link to this pin would automatically know that it’s read-only. we are thinking of that since while…
leaves the case of nodes where you have no influence on the definition, there it could be an additional application side property that you can override when you really need to force it.
