Since watch node has only 1 pin, it can only display 5 characters. It would be nice to have a way to make the node wider (or have some other way to display longer strings). I suppose it could be made into a variadic node & just ignore the extra pins, but that seems kind of kludgy… Could it be given a grip to resize without adding extra pins? Should it be more like comments?
I see two possible solutions:
- Implementation of #937 should make strings visible on their own since they are technically labels
- Making resize handles like we see for comments as you suggested
Which one will work better in your opinion?
This would be a nice general solution that covers more cases. The down-side is that for the watch node, you don’t know the size of the label ahead of time. Would you grow the node while in debug mode? If you grow it in debug mode, would you shrink it again if the string gets shorter? (probably not…)
If you will not be growing the node in debug mode, I guess you could leave it up to the user to create a label to force the maximum size…The alternative would be resize handles.
The comment resize-handle is different than the variadic resize handle. It would be possible to have both on a node. Would allowing users to resize the node to hold text be better than auto-sizing? That would provide the option of leaving nodes smaller/truncated for those who want it.
With auto-sizing, I think you would need to shrink the node if another node was placed over it (or the node in question was moved next to another node). What size node do you display while moving the node around? Smallest, largest, what it was before moving, or keep changing based on where you are in relation to other nodes? For extra credit, you could size the moving node based on where it is going to be put 
Yeah, not so trivial questions.
The more I think about the problem, the more I’m leaning toward manual resize for watch nodes. As for comments. It simply makes sense and sounds intuitive enough although not a part of some larger principle.
Technically that’s possible, of course. I doubt usability though. Actual hotspot areas to begin dragging are intentionally larger than the gripper elements themselves. Otherwise, much more precise cursor positioning would be required from a user. If we make multiple grippers on the right side, the hotspots will interfere.
We should really involve UX designer here 
Perhaps, he will add some ideas.
We could probably get around the over-lap of grippers by moving variadic gripper up a little. Top-half (maybe a little more) of edge is variadic, bottom is node size. The risk of grabbing the wrong one is low, but it would be annoying if you were constantly getting the wrong one.
The watch node could be made manually re-sizable even if you don’t decide to allow manual re-size in general.
Additional questions for implementation (if manual resizing of node is implemented in general):
Is text-gripper setting an absolute size, or relative? This will only make a difference on variadic nodes where base node size can change. I would think it should be an absolute size. If you use text-gripper for +1, you don’t want to still add +1 if variadic gripper is used to add 2 more pins.
If someone resizes node to see more text, then resizes variadic larger than text, do you remember absolute size set by text-gripper in case variadic is decreased later? (i.e. on variadic nodes, does text-gripper set a minimum size that is remembered if variadic gripper makes the node larger, or will increasing varidic, then decreasing go back original node size?) I think either way is valid; a decision just needs to be made.
Yeah, that’s something we should done in the first place as it’s a clear and intuitive improvement
Both decisions sound counter-intuitive. We definitely have a conflict for the width dimension between variadics and adjustable nodes. One possible solution is to avoid two resize modes in a single node completely:
- No width adjustment at all (except for specials like comments and watches)
- No width adjustment for variadics (why?)
- The width adjustment is done with an absolutely new mechanism which does not involve dragging the right border (wut?)
The first option looks most solid for now.
I wasn’t thinking of it as a conflict as much as design decisions that need to be made. If variadic has minimum # of pins, you might want the node wider for the label. If you increase the variadic count beyond the label size, the label size become irrelevant (at least until the variadic count is reduced again).
I guess you would almost need to display the node with its original width (ignoring text resizing) when the variadic gripper is grabbed; otherwise you don’t have an easy way to add 1 more variadic pin if we already have +2 width for label. The alternative would be to say the text resize is +2 instead of a static size and the text gripper could be used to make the node narrower after variadic count is increased, which might be more intuitive now that I think about it… bah…those pesky details…