this is almost an evergreen but lets bump this topic. what would be very welcome in terms of workflow and learning resource would be of course “fuzzy search”
apart from this, some sort of code completion would help newbies to learn what works with the pin of choice. unity visual scripting does this quite nicely. and this would speed up patching a lot by making logical suggestion hence less category diving each time you add a node.
and then there is still this awkward design (icons), especially the category lines icon which is hard to distinguish from row to row. i know where this is coming from but it doesn’t work visually when you stack them hamburger menus on top of each other.
cool cool cool, i was afraid that this part never gets some love.
to add some thoughts. the interface is so crucial for this whole product, from two perspectives:
the beginner is kinda lost in thousands of nodes and concepts and needs to be taken by the hand aka code completion. even in unity c# script, its a lot easier to grasp than in gamma at the current state (my university experience)
on the other hand, the pro .net developer is used to visual studios code completion and automatic scaffolding, its a fundamental part of the workflow. sure, he can find things easier due to experience but its not a breeze to work with in gamma
one thought concerning the icons of unity vs, sure one could argue having a bug as an icon for debug is kinda silly, but because they have a very visual icon language, you identify most of the things a lot quicker. i’m still no fan of the super abstract icon design of gamma, it doesn’t tell a story.
to make it clear, these statements are totally subjective and people might have different experiences
regarding icons:
Categories are represented as folders, the standard metaphor. Hopefully, this alone is already an improvement(?) Categories that stem from types now get some small icon trying to capture the idea of the data type flavor. The design is still a bit simplistic, but you now can distinguish a Record from Class… You might argue that the data type should be visualized, not its flavor. A Spread shall look different than a Skia Layer or a Color. This of course would be a lot more work but could be worth the effort. We know that the aspect of whether a data type is immutable or not, or whether it is an interface or not isn’t the first question a beginner is asking. However, let’s try this visualization for a while and see if it is of any value, ok?
regarding filtering node browser by type:
we have a proof of concept for that. Would you expect the nodes to be hidden away in folders still or should they just be listed in a flat list? So there are a few things we want to try here still.
this would work better if “often used nodes” are listed first. talking about quad, transform, hsl etc. in unity VS you can tag nodes with a star to push them up in the search result. not sure of this is needed. maybe the search can learn which nodes are often used ?
as soon as you type something, the list is flat but includes categories that match the search. if you don’t type anything, you can explore by category, which is quite helpful too, I think.
hm… categories are also datatypes. why hide them from the search?
Also for beginners: type in spread in the nodebrowser to get to the spread catetgory and then have a look what nodes it offers. How would you imagine a similar search without category display? I’d list the categories always first.
i just don’t like diving into categories, in beta i get a one dimensional list of nodes when i search, same in cables, same in unity VS. seems like common sense. if not, call it personal preference.
as i said, maybe make this optional, like a configurable search ?
I also think flat search is better, since I’ve been browsing thru category like once maybe twice, since i use gamma, most struggle is to find an DataType (a class) that should be connected to some pin and this would end a fail most of the time… In vvvv that was handy when you could switch from flat to category.
You are searching for node and not the category, and it’s much better to have all the data like in’s and outs in one line so you don’t have to move your eyes from search bar and look at some different places (like to the side).
Specially hate when you browsing by some unobvious category hidden ten levels under and you have to start over all the time you add a node…
As well as Ok button because the selection happen already with click or enter.
And Cancel because click outside the node browser or ESC key is already doing it.
In latest previews the node browser shows only the connectable nodes after starting a new link. For sure there’s still plenty of room for improvements, but it already feels so much more comfortable that there’s really no good reason to hold back on it much longer.
Current features
The system looks at all nodes in scope and tests all its pins whether they can be connected or not. Did tests with Stride, Skia and Fuse referenced and performance was suprisingly ok.
The connectable nodes get ordered by how good the types match (same type, super type, generic type) and at what pin position a match was found. For example having a Skia Layer output at hand, nodes which take a Layer on any input are all higher ranked than those which take some generic T or object.
Like the normal view it will hide nodes which are already covered by an adaptive definition in order to compact the list. For example it will only show != [Math] when looking for a node connectable to bool and not all variations like != [Integer32] etc.
It knows about adaptive nodes and will hide those for which no adaptive implementation is available for the given type. For example it will not show a < [Math] node when having a Layer at hand even though its input is generic. However this feature is also rather costly especially for low level types like bool so it might not survive. We’ll see how it plays out.
Current (known) limitations
It doesn’t know about regions and their border control points. For example a normal ForEach will not show up when having a Sequence at hand.
It only tests pins which are visible by default. Would need some more work in the subsequent linking action to traverse the optional pins as well.
There’s no visual separation between exact matches, super type matches and generic matches.
For primitive types the results are still overwhelming. And also the adaptive node mechanism seems to disturb the ordering. For example with a float at hand we don’t see the + node at the very top. Basically the feature that nodes covered by adaptives get hidden plays against the ordering rule here. Needs some thinking and tweaking still.
We should write some sort of minimal distance function for subtype relations and use it for the ordering. Currently that relation is not taken into account and results for sub and super types look a little random.
I actually, thought about an addition, for “Ctrl + .” hotkey, if you select node and press it gives you all the available nodes in same category…
Or all the available nodes with same name…
Or opens node browser with this node selected…
I would love an additional node browser in a separate window like we had in beta. The amount of nodes in gamma is overwhelming and confusing. It would be super helpful having it open persistently and not loosing the category / search you are into after creating a node. This is especially important when you are not sure which nodes you actually want / need or when working with an imported .NET lib.
