Tasks & Events from Calendar.app and OmniFocus into Tinderbox

(Andreas Grimm) #1

I need to transfer my calendar-events into Tinderbox.


Bringing over events from Fantastical2.app (either copy/paste or drag/drop) is not recommended here; for StartDates and EndDates aren’t brought along.


Bringing over events from Calendar.app (either copy/paste or drag/drop) works well; since StartDates and EndDates are brought along.


I am missing the backlink option to the respective calendar-event – as displayed e.g. in OmniFocus-Tasks successfully brought over and showing omnifocus:///task/psetesttesttest0qoK0x1u in the URL-attribute.



Bringing over tasks from OmniFocus2Pro.app (either copy/paste or drag/drop) works well; although StartDates and EndDates aren’t brought along.



A backlink is provided in the URL-attribute … e.g. omnifocus:///task/psetesttesttest0qoK0x1u in the URL-attribute.

which attributes are brought along

How does one figure out which attributes an imported note/event/task brought along (like URL-backlink, StartDate etc.)

External task planners to use with Tinderbox
(Paul Walters) #2

Usually when a dragged-in or pasted item creates attributes or assigns values to existing assets, Tinderbox displays these in the Key Attributes for that note. The KA display usually is automatically opened to show you what these adds are.

(Andreas Grimm) #3

Thank you Paul.


I see what you mean and that works perfectly well for tasks brought over from OmniFocus (as described above); since the backlink – assigned to the TB-URL-attribute – is automatically displayed as Key Attribute.


Start and end of Calendar.app-events are assigned to $StardDate and $EndDate in TB. But both aren’t displayed as Key Attributes automatically.


The same applies for files brought over from Devonthink:

  • Although Devonthink-files bring backlink along (assigned to TB-URL-attribute), it is not automatically displayed as Key Attribute.
  • –> Thus, one has to already know for which attributes to look out.
  • If a Devonthink-file has one tag – this tag is assigned to $Tags. But again: Not automatically displayed as Key Attribute.
  • But once a Devonthink-file has more than 1 tag – none of them is assigned to $Tags anymore.


Or take Scivener-projects. One can either drag them in or even open them as new TB-file. All the Scrivener-attributes are brought over – but not displayed as Key Attributes automatically …

… which brings me back to my original question:

How does one figure out which attributes an imported note/event/task brought along (like URL-backlink, StartDate etc.)

(Paul Walters) #4

I believe your second post answers your own question – you listed already what is imported.

OF - drag/paste adds OF url to $URL
DEVONthink – $URL and $Tags
Scrivener – you’ve see already what happens

Scrivener can have custom attributes, so your results may vary from the standard depending on your own set up.

One “figures out” these things by inspection and by reading the release notes for Tinderbox. (I haven’t time to check aTbRef; perhaps @MWRA can chime in.)

(Mark Anderson) #5

…I heard my name. :grinning:

Stepping back, this is an unbounded question: “What from [some app] may get imported, and how do I know?”. Heavy users of [some app] usually follow up with “Why doesn’t Tinderbox find all the things from [some app] that I assume it is providing?”. The reality is less simple.

Those who read the release notes in detail will know some of this integration isn’t simply a case of Tinderbox dropping the ball but requires Eastgate to work with the authors of [some app] (assuming they are even willing) to check sending/receiving apps are doing things the same way. For instance, sometimes [some app] may not document what it puts on the clip board (or in a drag) or mis-declare its data type. As users, we assume this ‘just’ works. My years of beta testing for a variety of apps would suggest otherwise.

This is all a polite roundabout way of saying - are we asking the right question here? The expectation I parse from posts above is an assumption Tinderbox should put all ‘extra’ information, for which it has a suitable (how to tell?) attributes, as KAs. When the unexpected happens, experience shows users blame the receiving app (or the one they use less often/know less well) which isn’t exactly logical.

aTbRef certainly reports support for known apps that have specific per-app support built-in (mainly found here).

Personally, my approach with first testing using data from [some app] with Tinderbox would be this:

  • Try drag/drop or paste into Tinderbox view pane.
  • See what sort of note is made and if any KA are set.
  • If I suspect other data might/should be there, I’d open Get Info, tear off the pop-over, resize to show more data then select the attributes panel and cycle through the attribute groups to see what’s there - any item in bold is non-default).
  • Check some app’s documentation for what data is put into the drag. In no docs, email [some apps]'s dev any ask for detail
  • With clear detail of what’s in the drag and what doesn’t show up, drop an email to Tinderbox support asking if the omission is by design or if it could be supported. I’d be mindful that not everyone uses [some app] with Tinderbox so asking Eastgate to track [some app]'s development and re-test each release might be more dev work than imagined.

(Andreas Grimm) #6

Thank you Mark A. for your reply, suggestions, and considerations.

Following your link-suggestion, I found out, for example, that using the Event-Prototype in a TB project triggers the immediate display of the Key Attributes ($StartDate and $EndDate) of any event brought over from Calendar.app. Just what I was asking for in the first place.

For those curious:

  1. I wasn’t aware of the interconnectedness of built-in Prototypes (such as “Event”) and Attributes deriving from Calendar.app. But: The Event-Prototype has to be activated (invoked?) manually BEFORE importing the Calendar.app-Event in order to assign Start- and End-Date to the $StartDate and $EndDate attributes.
  2. Drag-Drop-Importing Data from Bookends, however, does not require to activate the built-in Reference-Prototype manually. TB does it itself.
  3. TaskPaper again handles things differently, since it seems to bring its own PrototypeS – namely “Taskpaper Project” and “Taskpaer Task”.

Nice, once one knows.

(Mark Anderson) #7

Calendar. Testing, it uses a prototype ‘Event’ but only if one is found (assumption: it is the build-in Event, but will take a user-made prototype of that name if present). It would seem more sensible for it to add the Event prototype if not present and apply it (in the manner Bookends data does with ‘Reference’).

TaskPaper. I don’t have this app so can’t test. If I read correctly, adding TaskPaper data to Tinderbox causes 2 new prototype to be added to the TBX - "Taskpaper Project"and “Taskpaper Task” (is that a p or a P in the prototype name?). What attributes do the prototypes set?

(Paul Walters) #8

Tinderbox 7 uses “Taskpaper” in these prototypes, although the actual name of the app is “TaskPaper”. The Taskpaper (sic) import process could be improved. TaskPaper “due” tags could be parsed into $DueDate since TaskPaper uses a consistent format for the tag:


Also, notes added to projects or tasks in TaskPaper are not imported as the $Text for that project or task, but as separate Notes in Tinderbox.

TaskPaper has very robust AppleScript support and many contributed scripts – including export to OPML.
I personally prefer to use OPML export from apps that support it (or can support it with custom scripts) and then import that OPML to Tinderbox – since this gives me the greatest control on how data is imported and parsed to built-in and User attributes.

(Mark Anderson) #9

Thanks. So, adding a TaskPaper item, adds 2 new prototypes - and presumably the /Prototypes container if not already present. What KA are defined for two prototypes? I only ask so I can document it correctly, without having seen it myself.

(Paul Walters) #10

The two prototypes have the same KA – $DueDate, $Checked, $Tags – all are built-in System attributes. The difference between the prototypes seems to be that “Taskpaper Project” uses a bold face for $Name and “Taskpaper Task” does not.

I’ve noticed another error in the import. In TaskPaper a project or task is completed by adding the tag @done to the item – TaskPaper then displays the completed item in a strikethrough font. When Tinderbox 7 imports that, it correctly displays the strikethrough text and sets $Checked to true, but if the completed item is a project it does not assign the “Taskpaper Project” prototype (or any prototype) to the item.

It should be noted that the only thing that distinguishes TaskPaper files from any other plain text file is the .taskpaper extension. IOW, one can write “TaskPaper” documents in any plain text editor, using the standard four TaskPaper formatting rules, save as .taskpaper and import those into Tinderbox. The four rules are: project lines end with a colon. Task lines begin with a hyphen. Tags begin with the commercial at. Notes do not have hyphens at the beginning.