Geometry Nodes: Word Wrap UI Change For String Node (Please)
In Geometry Nodes typing text into a String Node will display the text up until the node width cuts off the single line. You can resize the node to see the full text, but it will all be displayed on the same line. This makes sense! It visually communicates that Blender is processing the string as a single line of text without any consideration to how the text may appear in the Geometry Nodes Editor. If you want to join multiple strings into a larger body of text, you can use the Join Strings node. So, what's the problem here?
I believe that Geometry Nodes is being held back by the lack of a word wrap display feature in the String node (or another node, perhaps a Note node) that will display string data inside of a word wrapped text box. The ideal functionality would be to separate the described word wrapping feature from the base presentation of the String node, either as a button or as a separate node. The limitation this introduces is that it limits the ability for the user to interact with string data in an easily readable/scannable way. Before I outline the ways I believe this missing UI functionality is holding back Geometry Nodes, I want to clarify that I am not advocating for a Multiline String node and that I am not advocating for any change in the functionality of the String node or the way Blender processes strings.
Use-case 1: Easy in-node documentation. I understand that it may not be desirable to encourage users to leave String nodes all around their node trees, but I believe that having easily digestible paragraphs that are readable, draggable, and usable in the node system creates node systems that are way more user friendly than the current standard practice. The benefits outweigh the concerns, in my eyes at least. What's further is that String nodes with this UI update could also be documentation that participates inside of node chains, allowing for a new method of Developers interacting with the users of their node groups or node chains. With the "Find in String" node, developers could make a switch that finds a specific word (for this example, let's use "carrots") in the string and use the Count output to drive a switch. If the connected String is easy to read inside of the Geometry Nodes editor, the user of the node group/chain could easily search the String node for the word (in this example "carrots") and edit it right where it is easily found. Using this setup, developers could create interactive or demonstrative documentation inside of their tools. Or even fully fledged tutorials that check to see if the user has typed "Done" in the String before moving on to the next easily readable/scannable String.
Use-case 2: Collaboration between projects, or even just a user going back to an old file they don't remember, would become easier if users would be presented the content of the String node in an easily recognizable way. With the current way the String node cuts off what content it displays users have to resize each node to try and identify the content it contains. When adding any more text after the node width adjustment, the user is forced to resize the node again in order to retain a current understanding of the contents of the node at a glance (I understand that you can hover over nodes, but scanning the node chain at large is very useful for debugging which is where this point about String text display comes in).
Use-case 3: The user could plan out nodes with visible and readable descriptions before committing to making the node structure or actually connecting nodes together. An example of this would be when a user is making a node chain but has to leave the computer soon. They have the idea of what nodes they want to use, and they can even describe their ideas of how they want to use those nodes, but they don't have the time to make and connect all of them. Especially not without risking hastily compromising the node chain they already have up and working. So perhaps they create the nodes, don't connect them, and then log off the computer, right? Sure, but then how will that user guarantee that they will remember the intent they had with those nodes once they return? They'll just be staring at default nodes. Maybe they change some settings before they go, but even that doesn't guarantee that the user will remember why they changed those settings before their absence. I believe that the solution to this issue would be a couple of quick String nodes (or Note nodes, like I stated before). The user could write down their intentions for each node that they have in mind and even put those String nodes exactly where they intended to put the nodes they're describing. Being able to freeze in place thoughts and intentions inside the node chain itself in such a way that's easily readable and editable is incredibly powerful.
Use-case 4: It allows people to use Geometry Nodes as an idea board. Yeah, this use-case isn't as functional or hardcore as the others, but it's something I've wanted to be able to do for a while. Using Frames for all of the "make text in the editor" points I've made so far isn't a functional solution as frames have a maximum character limit. I've wanted to be able to use Blenders excellent node system to organize my thoughts within the same 3D project that I'm working for a long time now. People like me enjoy tinkering and making systems, so the idea of being able to make a Geometry Nodes system that works as a kind of Mind Map that generates a 3D Mind Map is super cool to me, but impossible if I'm working with single line string nodes that have to be expanded to be barely readable.
I'd like to end this feature request by saying that I love and admire both the Blender software and the team that develops it. I've just felt frustrated at trying to work on this functionality on my own by trying to make Python scripts to change the String node UI or make a custom editor to make a word wrapped display for text. I've tried my best to make a constructive compromise with my own desires for a String node that displays multiple lines, but I've come up short every time. So, I'm having to appeal to the developers for help or insight into this feature. Whether it be a new Note node that displays differently than the more technical/formal String node, an option on the String node itself, or an idea that I have not been able to conceive yet, I hope I have been adequately able to get across my case for this feature. Thank you for your time and consideration in reading this and have a great rest of your day!
9 Comments
Does this WIP patch do what you want? Besides word wrapping it also adds multi line text.
Oh, DUDE! This is SO much better than finding a $20 in your jacket pocket a week after losing it. I don't think this is quite what I was envisioning (the scroll feature is interesting, but I was thinking that it'd be more of an auto-fit functionality), but I thought that I wasn't going to be able to find anything resembling a solution for this issue for a long time. Thanks so much for linking this, and I'll definitely test this out and dig into it more in the coming days!
Wow, I have needed this!
Would the string node benefit from a word wrap so to allow the user to read a long string in one go instead of scrolling through it? Sure!
But points made about how it would help document the node tree, that's going south IMHO.
You mention the frame node and how you don't like it due to its character limit, but that's just a good feature to be requested about it! In the meantime, it already fills the role of being a note node pretty well:
Let's also not forget that we have other documentation tools!
You can use the annotate tool to scrible text, figures, lines, polygons, anything you want. And we also have reroute nodes that let you sprinkle some simple strings of text without the visual clutter a frame node could bring:
There are also some existing feature requests to expand the node trees documentation capabilities, e.g. to have a note section in the sidebar for each node (there's been an addon for it ):
Firstly, thanks for your reply and the effort you put into it! I hadn't even considered using both the text editor and frames and I'm really glad that something like this exists. However, it's a two-step process that's almost assuredly not used widely in the community. Not to rely on anecdotes too much but I've never seen that kind of setup before and I'm pretty deep in using community made tools and assets. Would you please elaborate on why you think using String nodes, or a node that's functionally a String node, for documentation inside of the Node Editor would be going south?
The string output that the String node has is actually pretty important for documentation, as is outlined by the "interactive documentation" idea I tried to use as an example in the feature request. Additionally, I tried to make clear in the request that I wasn't advocating for any change to the core presentation of the String node itself but rather giving additional functionality to it or creating another node to fill that purpose. So, if the enhanced String node or "Note" node isn't used for documentation, then nothing is lost. But if it is found to be useful, the Blender developers would have data as to an area of UI development that may need more attention. Again, I'm not certain I have an understanding of your position on the documentation utility of my feature request, so I'll refrain from making any assumptions.
And also, I'll just say that I 100% use the reroute nodes and renaming them all the time. I'm so glad you brought that up, because I was afraid to in the feature request because I wanted to highlight the broadest utilitarian benefit of the request (that being documentation and interactive tutorials). However, I'm on the more niche side of the community in the sense that I like to use Blender for all kinds of different purposes than its main functionality. This is why I really want Blender to also support rich text editing in the text editor. For my niche interests I currently use renamed reroutes, value nodes and frames to make a kind of "Mind Map" with the connections between reroutes being the connections between the traditional bubbles of a Mind Map. I just think that readable String nodes, or a Note node, would benefit both my weird purposes and the general user. The addon you linked is cool as well and I think it shows that there is at least some room for further development in node tree documentation for the devs to explore. I really love the annotate tools, but I know that they're not everyone's favorite since they're freehand for text.
I hope we agree that there should be word wrapping in the String node in some fashion at the very least. With the Blender videos/tutorials I've watched, I've seen creators having to resize the String node very often alongside adjustment, so I know that I'm not the only one who's ever had this on their mind. Thanks again, I know the screenshots and thoughtful reply takes effort and I appreciate that.
It's like asking a postal card to be bigger, because while it lets you write on it, it doesn't have enough room to fit a whole letter to your friends without having to use multiple of them or write in tiny chicken scratches. And you also think it would be nice to use them to make mindmaps.
Well, it's correct to observe that we could use more room on postal cards, but postal cards are tailored to a purpose: carry a specific short text and maybe a nice picture, to be treated in a specific way by a postal system that has specific limitations, requirements and needs like size, weight and costs.
You can use a postal card for other means than what it is designed for. And you can find different sizes of postal cards too.
But you will have a hard time making changes to a postal card to make it do whatever you want without making sacrifices in what it's meant for.
And at the end of the day, if you want to write arbitrary lenghts of texts and mindmaps and scribbles, all that for the sole purpose of documenting or emulsifying ideas, and share them to people around, we have notebooks and pencils for that.
The string node is meant to carry a string of text to be processed in geometry nodes. That's your envelope. You like it because you can write directly in it, and you can plug it to other nodes to make it like a mind map. But it's not its job.
The frame node, is the notebook. You discard it because you can't write directly in it, but that's something that could be requested (in fact it already has been) and updated in upcoming Blender versions.
The reroutes and annotations are the pencils that bring even more capabilities that could be expanded on.
For example:
All that to say again: wordwrap on string nodes for visibility, sure why not. But hoping to make the string node into a note/mindmap node, there are suited nodes for that, which we can enhance or make new better suited ones for.
I understand the argument you're making but I (kind of) disagree with your assessment and postcard analogy. My disagreement is that the fundamental difference between the frame tool (if it were to change to be able to include text) and an enhanced String node (or a Note node) is that the frame cannot expose the content of the string to the node chain and therefore cannot benefit from the operation nodes of the string node family. I understand, from what I can gather about your reply, that you do not want the functionality of documentation (or the other use-cases I outlined) to mix in with the designed functionality of the String node. The example being that a post card is designed for a purpose and changes should be kept in line with that vision. Blender is a software that has seen the adoption of many different functionalities as the software has grown and matured throughout the years.
The addition of the Bit Math nodes is a great example of that growth as it does something that's primarily useful for computer emulation and isn't particularly tailored to the general user of Blender. It's a set of nodes that are designed for a purpose, like your postcard, but that purpose being something more niche or technical. I believe that the purpose of allowing for users to experiment with interactive text-based tutorials or documentation is a worthy purpose to build a tool for, and I can recognize that changing the pre-existing String node would both improve that node and allow for the exploration that I believe is valuable. That is why I included the documentation example in my request instead of just making the point that it would be more readable and user-friendly. I think exploration and experimentation is a worthy bonus to highlight in a request for a UI change. I understand that you're reticent to have Blender design a node around the purpose that I've outlined, but my point is that the benefits should be additional and incidental to the change and not the guiding philosophy moving forward. I just thought it'd be worth it to highlight the benefits that people like me would see from the base change, however unique or experimental that benefit may be. The idea of a "Note" node is just a compromise to get a word-wrapping String node without changing the String node itself. I truly believe that the additional readability has value beyond the visual boon the user will get if the change is implemented.
"The string node is meant to carry a string of text to be processed in geometry nodes. That's your envelope. You like it because you can write directly in it, and you can plug it to other nodes to make it like a mind map. But it's not its job." - I think this quote is representative of the different pages we are on. I do not like the String node because I can write directly on it, I think that its ability to output its content for interactivity is valuable and essential to additional benefits I described earlier. A more readable word wrapped String node would enhance the functionality of the Find in String node as well, since it would allow the user to easily scan the node for a word. That ability to easily scan the node for a word also allows developers to intentionally not include a word inside the enhanced String node, which would drive a change in the node chain upon the word's addition to the enhanced string node. This dynamic exists right now and is functional, but without the ability to easily scan the String node it breaks the reasonability of the dynamic in implementation. Expecting the user to scan a long single line of text for a word to change, or to make sure a word hasn't been added, is unreasonable. The visibility change would make that expectation reasonable. The string of text that is meant to be processed in geometry nodes could be utilized for other purposes than it's processing alone without sacrificing any of that processing or presentation at all.
I also have previously stated that I wanted to refrain from bringing in my niche usage of the String node and Mind Mapping tools into the request since I can acknowledge that my niche usage isn't a justification for an entire software to change. So, with respect to your Mind Map example, I completely agree with it except for the part where it relates back to the string node. I'd be over the moon for development into the Layout nodes and tools in the Node Editor. I use Mind Maps in Geometry Nodes to also drive the actual output of the node. 3D text will be output from the Geometry Node system when a String contains a specific word, and another 3D Text will be output when the String does not contain that word. The inability for the Frame node that's connected to the text editor to directly output the contained string is the limitation that I mentioned in my request. I will again reiterate that I have no expectation of my niche or meta usage of these tools to be a consideration in their development, but I think that my personal benefit is also worth disclosing or bringing up in a feature request like this. So yes, the design considerations of the String node should stay as they are, and I believe that my proposed change would benefit those considerations as well.
I'd like to urge you to consider the utility that I'm describing outside of my personal Mind Mapping usage, which I am likely only joined in by less than a dozen people. The value in being able to create a text node that is easily readable and outputs its contained text is multifaceted because it can interact with other nodes. Imagine creating a system where one String box with a fair amount of text in it ends with this sentence: "...Once you have read this entire paragraph, please write the numerical number one in the parentheses: ()" This String box is connected to a Find in String node that looks for "1" in it. This setup would create a way to let the person who reads the String box change it in the specified way (by adding 1), which would change something in the node tree (like switching between node groups that the Geometry Nodes system outputs to show the user the difference between them). This setup can be done already, but if the String node has a fair amount of text in it, it's a pain to scan to edit or read the text. In the above example, the expectation of the user would be to read that entire String in one line that takes up a large amount of horizontal room in the Node Editor and then edit the very end. It's an unreasonable expectation and breaks the flow of the node chain. I understand if you find this use-case to be incongruous with the intended functionality of the String, but my previous point about how nodes can have additional functionality that doesn't guide their design direction still stands. I also believe that the actual functionality of the switching and explaining is worthy of consideration on its own when evaluating this proposed change, even if it shouldn't be considered when designing or updating the String node by the developers.
That was a really long way to say that I don't think that the string node should be updated because there is no reason not to. I think that there are a few reasons that the change could actually incidentally create new processes that users use which empowers them to innovate even further. It's funny because we definitely agree on the fundamental point here, we're just on different pages on the "why." I think that's totally cool, and I appreciate all the time you've spent discussing this with me.
There are lots of places in Blender where word-wrapping would be helpful. So although I didn't read this wall of text, I agree with the idea. Upvoted.
Thanks, and lol, I will learn to summarize one day, God willing.