[Tim Wood]

We're possibly going to use this in our fledgling web-thing, and others (dansays, QS, etc.) might find this useful...

As of earlier today there is a 'complete' script command in OmniFocus. This uses exactly the same logic as in the completion cells but presents it in a script-y interface.

Say you have two contexts, "abc" and "car", you can now do:

tell application "OmniFocus"
	tell default document
		complete "a" as context
	end tell
end tell

and get:

{{xml:"<span class=\"match\">a</span>bc", score:15, id:"bxMoRcqDm0g", name:"abc"},
{xml:"c<span class=\"match\">a</span>r", score:0, id:"krLrtHo7Pbe", name:"car"}}

That is, you get a score-sorted array of match records, each with:

• id: the identifier of the matching object
• name: the name of the matching object (currently the full hierarchical name, but we could add both this and the local name)
• score: the numerical score of the match; bigger is better. The result is already sorted, but this might be useful. It isn't scaled to any max value, so a relevance indicator would be hard to do.
• xml: a little XML blob of the 'name' marked up with <span> tags. The default span class name is "match". You can pass an optional 'span class' argument to the command to change this to whatever you want.

Hopefully you all will find this useful; let us know if there are other scripting hooks that'd be helpful too.

[dansays]

This is fantastic! Time will tell whether the latency of AT&T's EDGE network will make autocomplete practical on an iPhone client. Can we limit the number of returns, either to the top X matches or anything above a certain score threshold?

Tangentially related:

Can we have a "next action" on the action object? If an action has child actions and is marked as sequential, there's no way to get the next available child action unless you iterate through the entire collection.

While I'm at it, I just noticed that the "flagged" property can't be set when creating a new action. When you do this...

set NewTask to make new inbox task with properties {name:AddTask, context:TaskContext, flagged:true}

...I expect it flag the task, but it doesn't.

[Tim Wood]

Originally Posted by dansays

This is fantastic! Time will tell whether the latency of AT&T's EDGE network will make autocomplete practical on an iPhone client. Can we limit the number of returns, either to the top X matches or anything above a certain score threshold?

Ah; a fine idea! The score cutoff would be problematic since we are still adjusting the scoring algorithm, but a limit on the number of matches is easy. As of r88293 you'll be able to do:

tell application "OmniFocus"
	tell default document
		complete "a" as context maximum matches 3
	end tell
end tell

Originally Posted by dansays

Can we have a "next action" on the action object?

You should be able to get the 'next task' of a project; each project has a single next task right now, so this is just a property of the project.

Originally Posted by dansays

While I'm at it, I just noticed that the "flagged" property can't be set when creating a new action. When you do this...

set NewTask to make new inbox task with properties {name:AddTask, context:TaskContext, flagged:true}

Hrm; this is working for me. If you have a full example that doesn't work, let me know. Here is what I'm doing (given that I have a context "a" in my document):

tell application "OmniFocus"
	tell default document
		set MyContext to context "a"
		make new inbox task with properties {name:"foo", context:MyContext, flagged:true}
	end tell
end tell

[curt.clifton]

Originally Posted by Tim Wood

Hopefully you all will find this useful; let us know if there are other scripting hooks that'd be helpful too.

I've submitted a few requests for scripting hooks via Send Feedback. Here they are in case others want to second the requests:

• Expanded status of notes
• Expel ancestors and expel descendants (as in OmniOutliner)
• There doesn't seem to be a way to get a list of all projects and folders in order via AppleScript. The dictionary lets you get either the folders or projects, but simply concatenating these lists loses ordering information, e.g., the fact that a top-level project might be between two top-level folders.
  
  Here's a script that comes close to what I want, but suffers the ordering problem:
  
  

  tell front document of application "OmniFocus"
  	activate
  	set topLevelFolders to every folder
  	set topLevelProjects to every project
  	set topLevelProjectsAndFolders to topLevelFolders & topLevelProjects
  end tell

  I think this really gets back to a fundamental issue: the folders, projects, and actions are distinct objects. This makes recursion over the Projects tree more difficult than it need be. It seems like there should be a "tree item" class allowing access to all the properties (like name, note, id, perhaps next action and available actions, …) that are in common. It also seems like there should be a way to access the top-level projects tree. Something like:
  

  tell front document of application "OmniFocus"
  	activate
  	set topLevelProjectsAndFolders to descendant trees of projects tree
  end tell

• Script based access to meta-data fields. I'm thinking of something like the conduit settings in OmniOutliner.

[dansays]

You should be able to get the 'next task' of a project; each project has a single next task right now, so this is just a property of the project.

Here's my situation:

When an action is marked as completed in OF Mobile, an AJAX call is made back to the server. If a subsequent action is then made available by the completion of this task, the detail is returned to the client and added to the list dynamically. This is easy with a project: if the containing project is sequential, just mark the task as completed and get the next action.

However, it's messier when you have a parallel project that contains a sequential task with children. In that case, if the parent of the completed task is sequential, I have to jump back, iterate through the entire list of child tasks until I find a match, and then return the next task.

It would be a lot cleaner if I could just ask for the next action of the parent.

[dansays]

Hrm; this is working for me. If you have a full example that doesn't work, let me know. Here is what I'm doing (given that I have a context "a" in my document):

I ran into a situation with the recently added "complete" verb: this didn't work...

tell first document of application "OmniFocus"
	complete "a" as context
end tell

...but when I typed your sample code verbatim...

tell application "OmniFocus"
	tell default document
		complete "a" as context
	end tell
end tell

...it worked fine. Shouldn't these two blocks of code return the same result? I suspect my flagged context issue may be related, since our code is identical apart from the nested tells.

[Tim Wood]

Originally Posted by curt.clifton

There doesn't seem to be a way to get a list of all projects and folders in order via AppleScript. The dictionary lets you get either the folders or projects, but simply concatenating these lists loses ordering information, e.g., the fact that a top-level project might be between two top-level folders.

You should be able to use the 'section' class, which is a superclass of project and folder for this:

tell application "OmniFocus"
	tell front document
		set MyNames to {}
		set MySections to every section
		repeat with MySection in MySections
			set MyNames to MyNames & {name of MySection}
		end repeat
		
	end tell
end tell

Sadly, AppleScript's inheritance "support" isn't that great and you can't easily do something with the array directly ("name of every section" doesn't work, hence the repeat in the example above). Hopefully we'll figure out a workaround for this or it'll get fixed in the future.

Originally Posted by curt.clifton

It seems like there should be a "tree item" class allowing access to all the properties (like name, note, id, perhaps next action and available actions, …) that are in common.

In fact, OmniFocus has a 'tree' class :)

The distinction is somewhat technical, but it is an improvement from what we had in OmniOutliner, at least in some respects - opinions may differ... :) In OmniFocus, our outlines are represented by a tree. Each tree has a list of child trees. Additionally the 'document window' (distinct from normal windows so that you can avoid getting the inspectors and such!) have 'sidebar' and 'content' tree properties. The elements of the tree may or may not be data-bearing objects. For example, the 'inbox' is a tree that isn't in the data file itself, but is present in the view. Likewise, when collating by date, there are tree nodes to represent the date collation ranges.

Each tree can have a name, id and value (the data-bearing object it represents, if any); the name and id are the same as the data bearing object, if it has one. In some cases, we generate names and id for other tree nodes (collation groups don't have them currently, but if someone needs that, log a request).

The tree represents what the user can actually see on screen, while the 'projects' relationship on document (for example) is the whole set of immediate top-level projects, ignoring any filtering that the user might have in place. This is necessary since each window can have is own filter settings, sort orderings and expansion state. The 'tree' is thus almost like UI scripting, but much closer to OmniFocus and less fragile.

Originally Posted by curt.clifton

It also seems like there should be a way to access the top-level projects tree. Something like:

tell front document of application "OmniFocus"
	activate
	set topLevelProjectsAndFolders to descendant trees of projects tree
end tell

The top level projects should just be 'projects of MyDocument'. Unlike OmniOutliner, we have taken a more traditional AppleScript route, having the elements on each class be defined to return the directly related objects, instead of the flattened tree of objects. This makes the suite a little more accessible to new scripters, I hope, and also makes the implementation easier. We may add support for read-only tree-flatteneded relationships ("flattened sections of MyDocument" or "flattened tasks of MyProject" maybe) if there is enough demand for it. Probably not for 1.0, but maybe 1.x.

Originally Posted by curt.clifton

Script based access to meta-data fields. I'm thinking of something like the conduit settings in OmniOutliner.

This is in our bug list right now; hopefully it will make it in before 1.0. I'll add your request to the bug.

[curt.clifton]

Thanks for your help, Tim!

Originally Posted by Tim Wood

You should be able to use the 'section' class, which is a superclass of project and folder for this..

Ah, I had looked at section but hadn't noticed that project and folder extend it. The section class is essentially undocumented currently. I know it's extra coupling, but it would be nice if the section class description said more than "A section of the document." Perhaps, "A folder, project, or other section." ("A section of the document" is misleading, since folders also have sections.)

Originally Posted by Tim Wood

Sadly, AppleScript's inheritance "support" isn't that great and you can't easily do something with the array directly ("name of every section" doesn't work, hence the repeat in the example above). Hopefully we'll figure out a workaround for this or it'll get fixed in the future.

That would be great, eventually. Looping over items in AS is so slow, but all my scripts so far have needed to recurse over individual nodes anyway.

Originally Posted by Tim Wood

In fact, OmniFocus has a 'tree' class :)

I saw that and had guessed that it was a standard tree abstraction with the nodes being cells containing the actual objects. Unfortunately, I hadn't yet figured out how to do anything with the trees directly. I think I've got it now:

tell application "OmniFocus"
	tell front document
		tell document window 1
			set theContent to content
			log (name of every tree of theContent) as rich text
			log (name of every descendant tree of theContent) as rich text
		end tell
	end tell
end tell

But I think there is a bug here, either with the documentation here or the implementation. The documentation for the descendant tree class says it is "the immediate child trees of a tree in the user-specified sort ordering." But the second log line in the script above logs every node in the content pane. The first log line gives just the top-most trees, i.e., the child trees of the content tree.

Originally Posted by Tim Wood

Each tree can have a name, id and value (the data-bearing object it represents, if any); the name and id are the same as the data bearing object, if it has one. In some cases, we generate names and id for other tree nodes (collation groups don't have them currently, but if someone needs that, log a request).

I would love to see at least names for collation groups. I'm working on a script that exports the current view to OmniFocus so I can take advantage of more refined formatting and printing capabilities. I can imagine also wanting to export the current view to OmniGraffle. Having "missing value" has the name of the collation groups isn't very helpful.

Thanks again for the help, and for the attention to Applescript support!

[Tim Wood]

Originally Posted by curt.clifton

The section class is essentially undocumented currently. I know it's extra coupling, but it would be nice if the section class description said more than "A section of the document." Perhaps, "A folder, project, or other section." ("A section of the document" is misleading, since folders also have sections.)

OK; I've updated it to "A portion of a folder or document; either a project or a folder." Further verbiage tuning will probably ensue, but this is a bit better.

Originally Posted by curt.clifton

But I think there is a bug here, either with the documentation here or the implementation. The documentation for the descendant tree class says it is "the immediate child trees of a tree in the user-specified sort ordering." But the second log line in the script above logs every node in the content pane. The first log line gives just the top-most trees, i.e., the child trees of the content tree.

Oops; that's a documentation bug. I've updated it to read, "All the descendant trees in the user-specified sort ordering, listing each tree, then its children and so forth."

Originally Posted by curt.clifton

I would love to see at least names for collation groups. I'm working on a script that exports the current view to OmniFocus so I can take advantage of more refined formatting and printing capabilities. I can imagine also wanting to export the current view to OmniGraffle. Having "missing value" has the name of the collation groups isn't very helpful.

OK; 'name' should work for the most of the rest of the visible tree nodes as of 88346.

Originally Posted by curt.clifton

Thanks again for the help, and for the attention to Applescript support!

You bet! I'm excited by all the scripting activity going on in the alpha testing group!

[curt.clifton]

Originally Posted by Tim Wood

OK; 'name' should work for the most of the rest of the visible tree nodes as of 88346.

Outstanding! Thanks!