Hi everyone. I greatly appreciate Tinderbox’s scripting implementation which allows to integrate it with other apps.
I have created a script that exports PDF annotation notes from my app, Keypoints (which isn’t released yet), to Tinderbox. The export process and the Tinderbox notes created by this script can be seen in the screencasts linked in a Keypoints forum post.
To further improve the notes created in Tinderbox I’d like to create rich text notes. I.e., instead of creating a Tinderbox note with plain text like this:
I’d like to create a rich text note like this:
This would allow to maintain the various text colors as well as keep in-text links clickable. (btw, the export script will also recreate the cross-links between notes as regular Tinderbox links)
So, I’d like to create rich text notes via AppleScript, ideally directly via a script class property that e.g. accepts RTF text, i.e. w/o the need to select each note and paste content.
I’d like to offer a suggestion. The use of Apple Script could work, but it can be complex and may limit the accessibility of your offering since most people (at least in my experience) do not use it.
If I were to use your product, which sounds quite exciting, I would prefer if the highlights were NOT in RTF but rather were formatted with a predictable pattern, e.g., markdown or something like [Red]. This text is read[/Red]. [Yellow]This text is read[/Yellow], [Note]This is a personal note[/Note]. I could then use any number of the Tinderbox streaming parser notes to transform the text. I could steam it, parse it, or transform it (e.g., remove the flags and have Tinderbox apply the color). I’ve also seen apps where the color is placed in TBX as an RTF, e.g., Highlights, in which case I use TBX action code to pull out the colored text.
@eastgate may have some tricks up his sleeve to help you with your integration to TBX.
The notes text in (and exported by) Keypoints is actually not RTF but MultiMarkdown text (with a few syntax additions). So it’s fully parseable. The rich text styling of this Markdown text is only done in addition to make it easier to read & use.
In fact, my app also parses the note’s Markdown text itself and generates a full relational model from it. This model is then used for the scripting API, so you don’t necessarily need to parse the note yourself but instead can get/set the note’s title/label/tags/rating/publication/etc directly. This is also what my exporter script uses: It fetches the relevant note elements from the Keypoints API directly and, in turn, directly sets them again via the Tinderbox API.
Most users will not need to be aware of the inner script’s workings, they would just run the script.
If the source is (a flavour) of Markdown, it might be simpler just to pass that. Tinderbox supports 2 Markdown flavours: Markdown (default) and CommonMark. So, as long as not needing any Markdown code only used by MultiMarkdown†, transferring text in Markdown generic form might save a lot of bother.
Tinderbox action code does have some internal Action Code methods to set a limited palette of 'rich features, e.g. StyledString.bold(). Those method cover bold, italic, strikethrough, and font size, and font colour. Whether they are exposed directly to AppleScript I’m not sure. Using script Debugger’s Dictionary explorer on the Tinderbox app AppleScript dictionary might be a good route forward.
A more Tinderbox-idiomatic approach would be to store states like ‘read’, ‘processed’, etc., as attribute values which can be shown in the UI as Displayed Attributes.
So, apart from your intent for personal use, populating Tinderbox attributes might be more useful for the general Tinderbox audience (and save you so text gymnastics in AppleScript).
HTH
†. Users can actually call other Markdown scripts such as MultiMarkdown from Tinderbox, but this is non-default and might go beyond the interest/effort/skill of many users.
Thanks, AFAIK, the scripting implementation doesn’t offer to set RTF text, hence my request.
My script will pass the raw body text in MultiMarkdown format (as pictured in the above screenshots). This is also done to facilitate the possibility of a two-way sync. I.e., I would like to avoid changing the body text of the generated Tinderbox notes too much, as this will make syncing changes back to Keypoints way more tricky.
But, of course, a separate script could be made which may apply greater changes to the generated note’s body text.
This is actually what my script does. As shown by the screencast and the above screenshots, the script parses all relevant elements and directly sets a plentiful of Tinderbox attributes (more than what is shown via DisplayedAttributes), and even creates Tinderbox links between the notes.
My request was just about making the exported body text of the note (which is in MultiMarkdown format) more legible by styling it as rich text, which would also then maintain the original in-text links. But, of course, it will also work without this.
Have the script copy the rich text, and then have the script paste it in Tinderbox to create the new note. Get the id of that new note, and add the attributes and perhaps move it where it ought to be.
Create a folder of RTF notes with the text of each note. Drag them into Tinderbox to import. Now, your script’s task is to import the attributes.
I’d be open to adding a rich text attribute to notes, but I’m away now and I’ve got another trip (probably) in September, so keeping me off the critical path for the present would be a good thing.
Hi, thanks for the suggestions! I’ll try the first one. The second one I’d like to avoid since this would require some manual interaction by the user. Right now, my script’s full export functionality just requires a menu call (or press of a keyboard shortcut). Also, I want to maintain the feature where the script can update existing notes in Tinderbox (which have been exported via a prior script run). This might also rule out the first approach. In general, having an RTF text attribute added to the note class would be ideal. But there’s no hurry. Thanks again!
Looks like you have a possible way ahead, which is good.
If you want to do this, I suggest your script adds a new user attribute, e.g. KeypointsID into which you can seed a UID vaue. Then, if using AppleScript to synch you can search for the noe with your ID—which might have changed its title ( its Tinderbox Name attribute) or it’s location in the document. But your inserted custom ID should be a unique match to a note regardless of name/location.
Though not exhaustive, I’ve some Tinderbox-related AppleScript sript notes in aTbRef here: Applescript
Yes, thanks, my script already exports the note’s unique ID to a user attribute called KeypointsID, and the URL will be also unique and contain that ID. The script can already update existing notes successfully.
That said, I wish that Tinderbox’s AppleScript command find note in could also be used to find notes by a certain user attribute (or at least the URL and/or ID attributes). This would be very helpful but that’s for another request…
Your scripting-related pages at aTbRef were of great help to me, many thanks for that!
I too have less spare time than usual, and haven’t tried that but for a $KepointsID value of XYZ123 you could evaluate an action expression that is find($KeypointsID=="XYZ123"). That should return† the $Path for the desired note that you can then use with the AppleScript find command.
Not sure if that helps any…?
†. Assumption: the note title ($Name) and its ($Path) are unique in the Tinderbox doc. So a note like “My thoughts” might not be unique.
