I would love to be able to have attributes (particularly in the attribute display) which allowed multiple lines of text to be shown, even if it was simply a string with word-wrap.
There’s lots of really useful attribute types for programmatic or data-processing oriented metadata (lists, strings, booleans), but I’d like something aimed primarily at human consumption.
My unscratched itch: I’m putting my thesis together in Tinderbox. I pull supervisory notes from google docs through an agonisingly convoluted route and squeeze them back into my Tinderbox outline. At the moment, I’m adding them on a section-by-section basis to notes set up as a ‘writing’ prototype, to which I’ve added a ‘comments’ attribute, but sometimes these can be longer than a single line of text makes comfortable. If there was a way I could add multiple lines of text, I (as a human!) would find this really useful.
Inevitably, unintended consequences, etc, but some variant of the ‘string’ attribute that showed multiple lines would be really useful, and possibly just a matter of having properties adding to an attribute to specify a line count, and an alternative UI display handling strings with word-wrap, but I know even the most complex tasks can be made effortless by prefixing their description with the word just.
Another approach would be to write the Comments in the text:
...
Comment: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean ligula justo, aliquet eu, mollis in, mollis sit amet, velit. Fusce tristique accumsan urna. Nulla facilisi. Fusce euismod interdum erat. Pellentesque dapibus diam ac justo. Quisque cursus elementum odio. Donec ut massa. Integer semper lectus pharetra dui. Aenean tellus. Curabitur adipiscing, ligula quis pellentesque mollis, ligula pede iaculis elit, a rhoncus diam ligula sed augue.
Suspendisse vitae sapien volutpat nunc tincidunt elementum. Maecenas porta faucibus libero. Nullam ut dui sit amet nunc suscipit pulvinar. Morbi ornare bibendum sem. Suspendisse eros pede, varius vel, rhoncus at, posuere quis, nunc. Morbi tristique. Proin rhoncus, pede quis pretium fermentum, dolor nisi imperdiet massa, ac tincidunt ante arcu ac libero. Vestibulum commodo, dui ac lobortis aliquet, diam dolor tincidunt diam, a sollicitudin purus velit non nulla. Cras magna erat, vestibulum quis, suscipit sed, congue quis, felis.
---
An action could then automatically grab everything between "Comment: " and “—”, and save that in $Comment.
Sorry you had to catch my suggestions again, @eastgate
That would be one way to do it. However, my objection would be that the note text itself was being used for mixed purposes - making multi-select copy-and-paste exports messy, by introducing a layer of cleanup.
One of the best features in Scrivener is a text box to the right of the UI that allow you to enter notes and guidance for the bit of writing you’re doing on that particular section of the document. I’m jealously eyeing that feature, though I’ve moved away from the rest of the software. I could see the ability to have multiple multi-line Attributes (if needed) being really useful (thinks: or maybe I’m just using Tinderbox all wrong!)
Yes, I would agree with you. Inserting a comment like this in the note would be counterproductive; as you point out, the note would become mixed purpose.
My approach to this has been to create a “Comment” child to the note in question. That way, with the comment note, I can, in another attribute, save the comment date and commenter’s name, as well as the comment status to me keep track if I’ve addressed it yet. I use an OnAdd to link the comment to the note and to populate a comments attribute in the note. The $ID of the comment is placed in the comments attribute. I use boolean to suppress the comment form out report output.
If there are multiple comments I’ll have a comments folder and link to the appropriate note.
(It would be magic if ⌃return or ⇧return could add a newline when entering text, as I think return and tab already have very specific roles in attribute sections)
(And some kind of mechanism to fix the number of lines or height of the input area, so it remains visually consistent as you move through notes with the same prototype)
About a year ago I proposed something similar. My idea was that you could ask Tindebox to display a different attribute in what we currently see as the $Text windows for exactly the same purpose you’re noting here. My thought was that there could be an attribute, e.g., $DisplayedValue whose default value is $Text. if the value was some other attribute then the text area would be displayed with the value from the specified attributed, e.g., $DisplayedValue=“Abstract” or $DisplayedValue=“Comment”. This could work in a similar fashion to $DisplayedAttributes today. We could add a field to the inspector. The value could be added to $DisplayedAttributes. The value would be easily manipulated with a stamp or action code. Note, we’d need TBX only accept valid attribute names and only one at a time. If Tinderbox was unable to match what was included in $DisplayedValue it would default back to $Text.
ISTM that as ‘enough’ space is subjective and screen size vary by user (or user’s different work places), rather than an arbitrary number of lines, the ideal patterns is to state how many lines each Displayed Attributes row should have (another list attribute). Otherwise I predict the solution will just call forth request for more configurability as screen/window size varies as does the nature of attribute content.
Thanks @eastgate for sneaking this feature into 9.5.2 . It’s a really neat implementation, just adding a ‘number of lines’ slider to string data types, which I suspect has the least horrendous impact on everything else while still being absolutely what I wanted!
You can even linebreak with CTRL return.
(praying - implying gratitude not expectation - hands emoji)
The new addition is for String-type only (System & User) attributes, set via the Document Inspector, as here.
Note that if you have a 4 line string value that ends (i.e. last character) with a line break, Tinderbox will read that 5 lines. Long text without line-breaks flows into the available space. In either case, if the text overflows the space set the value is shown truncated/terminated by an ellipsis (…) . Note, in some cases the the truncation may occur one line early (leaving the last row/line blank). The attribute lines setting is adjustable ‘live’ (1 (default) to 7 lines allowed) so adjust as needed.
