would be nice to have a scalable node browser to be able to read more of the rows
Do you mean you would get rid of the four buttons in the nodebrowser?
I personally toggle a lot between low-level/non low level and external/non external while patching, so having those buried in the settings menu would result in a huge speed loss for me.
you might argue “shortcuts” but having a quick visualization for those things at hand in the help browser is imo absolutely needed.
I believe we could just :
- Press SPACE to open the node browser
- Type something (with potential use of up and down arrow)
- Press ENTER
not leaving the keyboard would accelerate the process of adding node by just repeating those three steps.
From 10 years ago :
Global default could definitely sits in settings.
Default could be overriden by toggling shortcuts (in the context of an opened node browser) such as :
ALT+F (Foreign, External)
then we could still toggle a lot between low-level/non low level and external/non external while patching but also chain adding nodes without leaving the keyboard.
Agreed, after having used Houdini for a while I really liked throwing down some nodes without having to use the mouse in between.
Houdini also tries to connect (if you want to) the input of the new node to the output of the currently selected node … this obviously would need even more work to figure out the most likely connection, I’d already be happy with being able to create some nodes and manually connecting them after.
slightly node browser related, all tools (cables, unity VS and unreal blueprints) allow dragging out a cable from a pin and on release the node browser opens. pretty much what my initial post showed.
in gamma, you have to do 3 clicks for the same result. click and doubleclick. in theory, the well known “drag cable out of pin” workflow could also work in gamma. right now, the behaviour is odd, when you try to drag a pin, it does start a selection. although the pin is highlighted when you start.
a tiny change but would speed up patching and render gamma a bit more familiar to ppl coming from unreal blueprints and other tools.
i just tried the preview version and looked for the most simple solution i could think of, looking for suggestions for a float32 output pin. i’m getting *[Int2] etc. Am i doing something wrong here ?
@u7angel That’s what I meant in my 4. point above. For primitve types (like float) the ordering is not very good yet. Nodes one would expect higher up show up in the middle somewhere.
ah ok, understood. cables does some scoring (learning from all patchers) for nodes to list popular nodes first. either this or the nodes need to be curated somehow. which you already do (advanced, not advanced)
I wouldn’t mind some telemetry if it leverages the user experience (you can even do it opt-in).
But obviously a way harder task to implement, and involves a serverside service the needs maintenance, for a tool that’s not in-browser already like cables.
Curation sounds more likely from a technical point of view, but also quite unlikely to happen as it’s a lot of work. Maybe this can be crowd-sourced still and also part of the Ctrl+M menu when building libraries.
Giving it some more thought, this can’t be curated. I bet there would be quite some wrong results if you need to give a score manually vs. real world usage.
I find the nodebrowser filter menu quite handy and would not like to switch to the burger menu. this slows me down. It also shows information on mouseover, so no complaints there.
most of the time when patching, I click on a pin, move the line and directly start typing. I think this is as fast as the dragging behaviour you mention.
Colored icons in unity or unreal - yes this makes things look a lot more organized. I like gammas ui design approach but still - not using colors does make things more difficult. And regarding contributions and nugets - it could get really messy when there is no uniform design language for icons.
One complaint that I have is that the nodebrowser does not scroll down when using the arrow keys. When reaching the end of the list it directly jumps to the buttons.
And it could be a little bit faster to open the “configure” menu from ioboxes. Having the menu pop up on a mouseover would already help. And after I tweak the first value it could stay open. To avoid having to keep the curser in all the time.
yeah, fuzzy search obviousely, but that’s already on the agenda.
The meme was for the joke, I don’t personally toggle that much because the categories doesn’t make sense sometimes (to me). @sebescudie 's point is the reason why I suggested shortcuts while those buttons could definitely still be on the node browse (see my UI mockup above).
It’s just that the current design is very strange with grey Playstation button on the top left and grey NES button on the bottom left.
For configure this could be made easier.
- Add a node from the node browser (node is already selected)
- SHIFT+C opens configure on mouse position
2.1 Changing the type would require single click on the textbox instead of double click
- Configure menu disappear on MouseLeave instead of click somewhere while the node keeps its selected state so we can configure again on SHIFT+C (or assign on SHIFT+A or surround on SHIFT+S), or even just pressing C, A or S without SHIFT would do it.
i always use middleclick to reach the configure menu in one click.
it would be cool if this would also work on nodes that can expose an “apply” pin
Little side note - the feature I’m talking about further up will need to be enabled in the settings in upcoming previews.
You finally can resize the node browser.
You also can move it and make it fullscreen with double click. Dragging and going fullscreen works on all the non-interactive areas of the browser.
Is this in the 28.1.22 preview? For me only scaling works.
Also please make it remember the scaling next time it opens.
Oh yeah, I forgot to mention that it remembers the last size. And now let me trigger a new build…
this is not working for me in current preview. just start a link and double click, right?
Yes, just as Elias wrote some comments above.
The why is that it is experimental and @joreg found cases where an entry wasn’t available. So we need to investigate these cases before it’s becoming the default.