Try to force the link with space key.
Does it work then? Sorry afk
ah, i think i get what is going on here…
linking from MutableArray to Sequence is working.
linking from Sequence to MutableArray is not working.
as a mutablearray is also a sequence, but not vice versa.
the confusion comes from the green highlight, that lights up in both cases. when starting the link at the sequence, one thinks it can be connected to the mutablearray, which even is true, but this can swap the link.
when hovering the pad a second time vertically and therefore forcing the link direction, the green highlight is no more.
maybe the green ‘connectable’ indicator on ioboxes should indicate the direction, e.g. light up above or below the pad?
that works and results in a red link, because of the inheritance described above
3 Likes
Yeah, that’s right. That’s all I’m saying.
Actually, I personally understand what this is about.
But imagine yourself in the place of a beginner or a person less experienced in programming.
I’d also like to point out that when I’m in the “fluent-fluid-power-patching” state, such UX glitches feel like hitting a wall at full speed. You can’t even tell what’s going on, something just doesn’t connect, even though the hint is leading you.
1 Like
in this situation, you think you can connect the sequence to the spread.
when hovering, you see, that the link direction would be reversed (because it’s the only valid option)
i’d go for the green highlight should also indicate the link direction. like so.
or so, if both directions are possible
i see that this approach is different from the current approach and bit’s questionable if both could work well together:
the main difference is, that atm. (0196) the link direction is determined on how you start the link (move mouse up or down after click) and the shown approach is determining the link direction by the target.
3 Likes
Let me come back to this finally.
So currently we have 3.5 modes:
- A) Both up & down still possible (showing sources and sinks in green)
- u) currently indicating up
- d) currently indicating down
- U) Upwards (only sources in green)
- D) Down (only sinks in green)
only in A) we’d need these (beautiful) two green connectors. With U) and D) it’s already clear (however those two guys still would make it even clearer what will happen).
It’s a nice solution, but let’s see if there are others.
Currently, there is some logic when to switch between A)u) and A)d). One rule leads to the behavior we see above. And then there is some logic that switches to U) or D): when you come back to the start and move out again…
If we get rid of the A) feature altogether maybe everything gets clearer.
We kind of loose a feature, but it’s a lot easier to explain what happens:
- When starting the link - no matter if via drag or click - the direction U) or D) gets decided somehow. @yar has a clever solution for that. Another solution is to just have a defined area, which when you leave the Y position of the mouse is the deciding factor, which could have the benefit of an easier-to-explain gesture
- When not happy you come back or press a modifier key to switch
The main point here is that maybe the whole A) thing is just a bit too magic. And we should strive for simplicity.
What do you think? Worth a try?
1 Like
@gregsn Thanks!
We should clarify which version we are testing all this from. It will take some time to get used to it. In general, I’ve already noticed a lot more natural behaviour and everything feels quite good. But we’ll have to get into it and collect cases.
Do I need to turn anything on/off to use these settings?
@yar I improved the auto-segmentation of the links, but the behavior stayed the same for the last three weeks. So maybe this already makes it feel less irritating. Or it’s a matter of getting used to some behavior.
But to be clear: what I am suggesting above is not implemented yet. I’ll let you know which version to try.
1 Like
@gregsn Really looking forward to getting into this, I’ll try to read more carefully and respond later.
I would like to report two bugs:
- Aborting a link with Escape does not work anymore.
- When enabling panning with Space, the hand icon does not disappear when releasing Space, until the mouse is moved again.
Also two suggestions, but not really bugs: When panning I would suggest to show an icon of a hand with all fingers stretched, and not only the index finger. Also this icon could be shown when panning with the right mouse button.
Hey,
Maybe I lost track of things, but it looks like starting a link “the old way” (click-a-pin-and-release) and typing something does not open the node browser anymore.
In my second attempt, I’m typing on the keyboard but the node browser does not show up.
Am I missing something?
Thanks!
The link direction gesture now got simplified. Some bugs got tackled. Please have another try. Thanks!
2 Likes
Oh, one more (hopefully tiny) thing:
first, i love the tweaks and all the recent improvements!!
especially the intelligent node filtering in combination with dropping a link or doubleclicking is super comfortable.
The idea is to add pads to the intelligent node filtering list.
I could imagine that pads appear simply the same way as when just doubleclicking in an empty patch like we are used to:
To make the mockup complete. imagine i have that Size (Vector2) pad in my patch and in drop a link from a Vector2 InputPin, I’d get smth like this:
note
Obviously, the pad-list is filtered, and the Name, XElement, default and delay pads don’t show up because they’re not Vector2s.
What do you think?
With 244 I no longer see IOBox as an option in the node browser at all when dragging out links with filtering on?
That seems a bit unfortunate, since I came to like to just select them from the browser instead of using a shortcut (which still works).
Direction flipping close to the pinhead works well for me.
Dragging on an IOBox left to right works for me, but when I rightclick on an input pin directly I still have to drag up and down…? IMO that should be the same, otherwise we’re worse off than before musclememory-wise ;-)
I still wonder if the colour IOBox could be somehow simplified to not need four different shortcuts/directions, that feels totally overengineered.
Somebody once mentioned to just drag on the value you want to change instead of all that complex overhead (I got used to it but it took me quite a while and I honestly see no point in this).
Would that be possible?
And of course the values should also stay visible with lower alpha values…
Anything specific we should look at?
I also start to loose track a bit… ;-)
Cheers,
Tom
That was an option in beta and looked like this.
Did not like it much and never used it anyway. Much more clicking. The other was rgba slider per channel which is the least fun to work with imho. Guess the shortcut is my fav still since i am so used to it.
Hm. I never really used beta so can’t compare, but what I meant was, that I would want to click and drag on the individual H - S - V - A values in the IObox directly instead of differentiating between them through 2 directions and 2 shortcuts (basically like 4 float IOBoxes in a row).
The entries are long enough to be easy enough to “hit” and I do not see the value of the shortcuts.
I also do not see how that would be more clicking?
I much prefer HSV/HSL over RGBA too, but the current system is way more complicated than necessary IMO. I often even use HSVtoRGB nodes instead of RGBA IOBoxes since I found them so weird to use and the Alpha problem so annoying.
But just my 2 cents of course.
Cheers,
Tom
Yes thats how it works in the screenshot. Most left field is the resulting color. the 4 to the right are the fields you drag (HSVA). You still need to click, drag, release, move cursor to other field, click, drag… Thats what i mean with more clicking.
The system right now is the fastest i can imagine. just pan around and press two keys to change what value you affect. guess in part its also just a matter of muscle memory.
Ah, okay.
Well, I totally hate the current color IObox with a passion but I can use a HSVtoRGB node instead and won’t die from it… ;-)
Cheers!
Tom
Had finally a chance to test latest (stable) V6.0 since an updated, compatible FUSE package is available as -pre now and noticed that IObox is still not an option when working with the node browser in connectable mode.
I feel this as a bug, since it often is very convenient to be able to create an IObox without holding any key, directly from a drag-and-dropped link.
While I can ESC out of preselection mode or click the X, it feels wrong to me, since an IObox actually IS connectable (and makes a lot of sense as a top-option).
I hope this will come back - it was there and great before.
Thanks and cheers!
Tom
1 Like