FYI: OO files indexed in DevonThink

I just discovered something that might be of interest to others.

I have long used DevonThink Pro Office as an organizing database for large research projects. But since I keep some information in OmniOutliner (it would take too long to explain why it works for me to use both - just trust me on this), I found I can INDEX my OO files in DT, and they show up in the DTPO viewer (using the Quick Look plug-in) as perfectly formed outlines, with columns and totally functioning disclosure triangles for expanding and collapsing just as if it were opened in OO.

You don’t have to IMPORT the actual file (which has size implications) into DT. DT indexes the OO file and it looks as if it’s actually right there. And now the data in the OO file are indexed along with all the data in the DT database. It’s totally cool.

Anyway, thought someone might like to know …

1 Like

Great tip. I am using this myself, with DT indexing my OmniPresence folders. Works like a charm. I use DT To Go on iOS, and it doesn’t handle OO files natively, so I just keep all my OO files in OmniPresence which I can access via OO2 for iPad, or Finder or DT on the Mac.

Do you continue to use DTPO with OO? How has that been working out for you?

I’m evaluating this method of indexing OO in DTP since searching through my notes using Spotlight Search isn’t cutting it.

Alas, Quick Look does not seem to work on OO files very well in DTPO anymore. OO4 files show up, but with question marks in place of disclosure triangles (and they don’t work as disclosure triangles either).

OO5 files don’t even show up.

I’ll post something in the DT Forums to see if they’re working on this.

That has nothing to do with DevinThink. We have to do QuickLook previews for OO5 through a very different method than before and it hasn’t been finished yet. Spotlight integration also still needs to be updated to work with ooutline files that are saved in the flat format.

Hi Derek,

Thanks for that. Here’s a little more info … someone on the DevonThink forum suggested that when I installed OO5, it ruined OO4’s ability to be seen properly in QuickLook. So I uninstalled OO5, reinstalled OO4, and sure enough, Quick Look works fine.

Which means, basically, if I want to keep using QuickLook with OO4 (i.e., in DevonThink), I can’t test OO5.

But if I want to test OO5, then I give up being able to use QuickLook with OO4.

Is that something you guys can fix?

1 Like

The only way to fix it is to get QuickLook with OO5 working correctly which will be done before release but isn’t a high priority right now. Since .oo3 files are support by OO5, it is not possible to simply let OO4 do the QuickLooking.

Looks like this isn’t supported yet? Do you have it in the roadmap at least? I use DEVONthink to index most files, but OO file contents are unfortunately not accessible.

1 Like

We implemented QuickLook support in OmniOutliner 5 before it shipped. It works fine on Sierra (the shipping OS at the time v5 shipped), but something about sandboxing those plugins seems to have changed on High Sierra and it doesn’t always work there. (But sometimes it does work on High Sierra, which makes this a particularly tricky issue for us to track down. We haven’t determined yet why it works sometimes and not at other times.)

Most of our attention has been on getting OmniOutliner 3 for iOS out the door (so iOS will have support for many of the new features introduced in v5 for Mac), but we plan to investigate and fix this intermittent QuickLook compatibility issue on High Sierra as soon as we can.


+1 on this for me. Thanks guys for looking into it.

Now that OmniOutliner 3 has been submitted and approved, I’ve spent a few days researching the QuickLook issue. It turns out to be a regression in the QuickLook system, which I’ve filed with Apple as RADAR 37174037 (Regression in High Sierra: QuickLook fails when provided HTML content by a plugin).

(I’ve also spent some time exploring alternative approaches to getting this working again. Hopefully we’ll get a timely fix from Apple; if not, it looks like the only real way to solve this involves a fairly big architectural change. I’m willing to go down that road if necessary, but it would sure save us a lot of development time if we could just expect that the QuickLook bug will get fixed.)

1 Like

OmniOutliner 5.3 public test builds are now available with a fix for Quick Look on High Sierra. Please let us know how it works for you–


Quick Look is indeed working here on High Sierra, in the Finder as well as in DEVONthink-thanks! One question on this-should the documents also include a thumbnail preview, as I am not seeing anything but the generic OmniOutliner document icon? DEVONthink even has a command to manually generate thumbnails for documents, and that doesn’t have any effect. In any event, the Quick Look addition is great-thanks!

1 Like

Glad to hear it’s working for you! No, there should not be a file icon. Quick Look for OmniOutliner has always been done by displaying the HTML (Dynamic) export representation of the file which allows for an interactive preview. This however also means there’s no image generated which is where a file icon would come from.

Does this also work in OSX Sierra now? Thank you!

It’s working fir me … even if I drag an alias of an OO outline into DTPO (instead of the original OO file), I still have full use of the file, the disclosure triangles expand and collapse items, etc.

1 Like

Thank you!

I am tending to go to your workflow right now. Finder, OO and DTPO. Could you explain me a bit in detail how your workflow regarding these 3 APPs and Files look like? Thank you very much!

There’s no real “workflow” here for me. It’s just whenever I want to include an OO outline in a DTPO database, I first navigate to the DT folder I want the outline to appear in, then use the File | Index command to select the OO database (wherever it resides) and instantly, the outline appears in the correct DTPO folder. It behaves mostly as if I had imported it - i.e., the disclosure triangles expand and collapse perfectly. The one drawback I’ve found is that if I do a DT search for a word, it will identify the indexed outline, but it will not let me search inside that outline to find the word. But that’s true even if I drag (copy) the outline into DTPO. DT’s Find function will find the outline that the search term resides in, but won’t let me search inside that outline to find exactly where it is.

1 Like

I see. Thank you very much for your explanations! I think Im on the way to implement a new workflow.