Let’s keep the bugs separated from the feature discussion.
I am not sure if this is a bug or not, but it does feel a little strange:
When you start to make a joint, the whole wire is selected.
But when you try to make another joint, the selected joint is moved.
btw, great work, the changes feel thoughtful and well done.
But I still don’t understand this improvement that was made some time ago. Why can’t I create a node or patch above the point where I started patching? I would consider this a bug as I encounter this on average 3-5 times per session.
May I suggest what I suggested earlier? Perhaps you could try to detect the direction of travel? It’s not difficult to implement and would probably solve this problem. Click, see where the move was made, use that as a tendency. Or perhaps an even bolder suggestion. Now that we have wires that can stretch from node to node without clicking, why not detect whether they have been clicked from above or below?
in the versions 101 or bigger. this should work. that’s what I meant with:
- if you drag a link out of a pad, IOBox, or control point the drag direction determines the link direction, which feels logical.
please double-check that you are indeed running version 101. I can’t confirm the problem.
I am not sure if this is a bug or not, but it does feel a little strange:
When you start to make a joint, the whole wire is selected.
not sure. It seems like the little control point is still selecting when you grab the link. That’s why it is moving on drag-selection. It could be seen as a bug. When grabbing the link the control points should deselect. Or is it a feature? ;)
1 Like
Hm, you are right. But I noticed that it only works with drag, interesting.
Also there is corner case when it’s not working
I think it would be cool in this case to look at where the click was made - above centre or below centre and use that as a tendency, maybe with a little hinting of the direction
this is how it should behave. please check the Setting called
If this is too big your little downward movement didn’t get detected. If the region is too big it detects your larger gesture, which mainly goes to the right.
The smaller the number the faster it goes into drag mode, which can result in sloppy clicks by pens or high-dpi mice getting detected as a drag. So don’t make it too small, but also not too big ;)
As an experimental feature, can you add an option to enable this behaviour by default, not just for dragging? I’d really like to try it as standard.
please also look my suggestion above:
In 99% of cases, when a user creates a node nearby, especially in tight, fast-patching environments, they will make a move strictly to the left or right, but intuitively aim down or up the point - at the arrow prompts.
In general, detecting the direction of travel is a very good move. But you need a deeper hint inside this behaviour.
About the problem @yar is describing… could it be an option to only change the link direction of a BCP, pad, IOBox etc. when the mouse is hovering within a certain area around it, say only in a radius of 10px? And if the mouse is further away, the current direction stays the same?
1 Like
Do you mean that the direction chosen by such a gesture can be changed back to the beginning of patching?
There is a new preview 109, where those border control points and pads and ioboxes got some more tweaking.
When you click on the connector you get the both-directions behavior which was introduced as it was too hard to understand where to click to get it right.
When you click above or below the connector you now get the feature back that you can decide early.
Dragging still is yet another way to decide early.
thank you, this is fixed in latest.
change log
- drawing attention of the user to the input and output indicators of the pins (same hover color as hover color in node browser) in the hope that people start drawing links less often on the node which leads to all the frustration. again giving view space more say in the decision how big the interaction area of a pin is
- fix for resize indicators & resize area. pins have higher priority
- all datahubs have an extra interaction area for connection gestures above and below.
- interaction detection: combining view and world space approaches. links and datahubs get picked by a refined cursor size (view space); independently datahubs now can have that extended world space interaction area. By that all zoom levels get the best of both spaces. the different cursor sizes get computed once and elements can work with what feels appropriate
- connected datahubs come with a less bold interaction area to make it easier to click the link
- selecting links via marquee doesn’t get disturbed by nearby pins (pick reason “select” filters out pin views)
- making sure that resize cursor and connection-direction indicators only appear when this is what would happen
- making sure sloppy clicks in general are clicks (until they are not and become detected as drags). we had a situation where depending on drag-area setting some clicks were not a click, nor a drag leading to the frustration of being too stupid to click
- patch explorer main button reacting on each click (not filtering out double clicks, allows for a quick peek)
- region view: improves interaction detection speed. all child views formerly got checked twice
- pick reason “hover” removed. Is conceptually the same as pick reason “any” by not giving much context info
- control points and pads allow deciding upon direction on click (and indicate this)
- moment tinting in regions wasn’t quite right. fixes #6533
- fix: comment movable again
- styling the direction indicators
3 Likes
Right now its not possible anymore to change the direction after your first decision, so its basically the same as before. What I meant with my previous post is that it should be possible to change the direction from up to down or the other way after the initial click, when you are directly over the pad.
1 Like
Before the “both-directions-behavior feature”, you needed to find a small area inside the connector, which wasn’t visualized.
I would say it’s not the same thing, as you now as an instructor can explain your favorite way of interacting. There are different ways to phrase it now, but with those extra interaction areas, you can clearly map one behavior to one visual entity… and you have click and drag. So in my view all of this together should be sufficient.
I also though about that already. But Space key is already taken and I am already confused with all the modifier keys, so rather preferring the current solution, which already is way more flexible and much easier to interact with than how it was.
But ok: do you have a suggestion for the modifier key? And is this something you would want to explain in a beginner workshop?
1 Like
Hey, no I don’t mean by pressing another new key. The solution of this thread (Beginners struggle with starting a link from the bottom of an IOBox) was perfect.
I just suggest the area in which one can flexibly change the direction should not be possible anywhere in the patch, but only if the distance between the mouse and the pad from which the link is drawn is below a certain threshold. Like that, somebody could drag a cable out at the bottom and move it to the side without the direction of the link jumping to the top, which is the problem @yar is having.
EDIT: BELOW
This case should not “pass through”/switch:
But this case should:
1 Like
Oh, I see. Didn’t get the proposal…
Well, ok it’s yet another solution, but now that 2 or 3 solutions already exist I would like to propose giving those some more test driving before adding a 4th solution. If this keeps bugging people we can come back to this. It sounds easy enough to implement. The only critique would be: yet another area that either isn’t visualized or it is. Both have their irritation potential.
I guess the current solution is a bit straightforward.
Well, right now it would be visualized, as the arrows appear again once the mouse is hovering the pad, right?
The arrows ideally stay in the configuration when the link gesture started, indicating how the system interpreted you click or drag.
Ah: ok, you are saying that when hovering directly over that thing again is like saying: misclick, sorry, dear mouse handler, may I restart please. Yes maybe. But in certain scenarios it will undo your downwards commitment only because you now crossed that think again on the way up…
1 Like
I think it could be perfect, if the arrows just stay exactly how they are right now, and the link switched to the top in the very moment, the single arrow to the top appears.
Edit: could be perfect
Ok I understand it this way: there are three areas sitting over each other, which when you cross them will switch the link to upwards, both or downwards. It sounds not so awkward anymore.
1 Like