I am experimenting with an early draft of a script which differs from the bundled “Add as To Do to OmniFocus” in four minor respects:
The due date can be specified with a variety of relative or absolute expressions, from interval string expressions like today +7d through simple … month labels to short absolute date strings.
The name of the reminder can be edited.
The link(s) in the OmniFocus note text are displayed in human-readable form (DT record names) rather than as raw UUID strings.
More than one record can be selected and linked to in the reminder
To install, copy to ~/Library/Scripts/DEVONthink (where ~ is your home folder).
It can then be run from the global scripts menu, or assigned to a keystroke by something like FastScripts or Keyboard Maestro.
(Note that it will not run from Devonthink’s own script menu which displays scripts in folders descending from ~/Library/Application Support/DEVONthink Pro 2/Scripts, and currently seems unable to handle scripts using Applescript’s run script method.)
Not extensively tested, so usual precautions apply: back up your data before experimenting.
Thanks for posting this Rob-very promising! I’m not getting the expected results with dates and I’m wondering if it is something on my end or in the script itself. My system is set for the standard US date formats, but if I enter the following in the dialog, here are the results in OmniFocus:
Accept the default ‘today +7d’: Due 12/7/11 @12:00AM in OmniFocus
‘now +7d’: Due 12/7/11 @12:00AM in OmniFocus
‘now +2w’: Due today at 2:00AM in OmniFocus
The scripts were all run ~5:30AM my time, using version 003 and 004 of the script. Suggestions?
I’m going to speculate that the dates issue is due to differences in the PPC and Intel sides of the universal OmniFocus app. Looking at the script, there is a reference to “Contents:Resources:” & “OF_DateLib.scpt”. Using a PPC, I don’t see this script in the OmniFocus app’s Contents>Resources folder.
Korm - It seems that DT can’t run my date parsing library from its script menu. I had thought this might be because it was a separate script in the resource bundle, but the problem persists even if all the code comes up into the top level script. DT engineers will have a better sense of why, but I think their script launching mechanism may choke on the use of “run script” which I need for the parsing of date strings.
i.e. to use this script, or a derivative thereof, you would either have to launch it with something like a FastScripts or Keyboard Maestro key binding, or drop the parsing of arbitrary dates.
[Though there might be scope for raising this as a DT bug - the script launching code of the OmniFocus toolbar, for example, has no problem with run script in general, or this library in particular, which is taken from my Where in OF script http://bit.ly/OF-Find]
Greg Switching my locale and date format to US month/day/year has not sufficed to reproduce the problem which you report. A couple of questions:
Which version of OS X are your running ?
What happens if you enter a simpler date like “tomorrow” or “1/1/2012” ?
Got it! I understand just enough AppleScript to get in over my head. I did take a peek at the OF_DateLib.scpt and I’m guessing that the on DateExpression section should not look like this, in plane, black-text typeface?
Well, I guess that the system differences could be a factor - I there were some changes to applescript date processing in Snow Leopard. The thing would be to trace execution through the DateExpression() function, and see where things go adrift. I’m afraid I don’t have a 10.5.8 PPC system to try that with …
In the meanwhile you could also try expressions like:
today + 7 * days
now + 1 * days
(The black string literal which drew your attention in the code is, in fact, correct. Is is assembling an expression to pass to run script)
If, however, you have provided a link to version 007, it might be worth using 008 above, which I have just edited to make it compatible with the AppStore-purchased version of OmniFocus.
(OmniGroup have appended the string “.appstore” to the bundle identifier of that version, which will, of course, break a number of existing scripts. My solution is to use the more generic four-character signature code.)