[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.