Omni is releasing version 5 of omnioutliner (still in beta) and they have changed the file format. I noticed today that devonthink is no longer able to find words inside the file when doing a search. This might not be surprising, since it is a new format except that spotlight (and Alfred as well) search within the new format w/o any trouble. Omni tends to use pretty open formats, so I’d be surprised if it’s something they’re doing (esp since spotlight sees inside the files).
Thank you for your quick reply. I understand your point about it being beta, but since things like spotlight and alfred, neither of which likely even know about omni’s existence, work well, I was wondering if there’s something else I should be doing. I tried a couple other things as well, and everything seems to see inside the files w/o problems except for devonthink. Good advice though about having both the release version and the beta version under the same account. Perhaps that somehow causes confusion for devonthink but not for other apps. I’ll try removing one.
One clue is that devonthink misidentifies the file type as XML, while outside of devonthink it is correctly identified as an “OmniOutliner Document.” Given that finder identifies it correctly, it’s not clear (at least to me) that the problem is OmniGroup’s mistake, as the type seems to be registered correctly.
OmniOutliner “files” are packages – special folders that OS X treats as if they were files. You can look inside a OmniOutliner package by command-clicking it and choosing “Show Package Contents” from the contextual menu. There are several files inside the OO package – the .xml file inside the package is where your data are stored. DEVONthink gets its information about files/packages, and file preview, from OS X.
Thanks for the reply. I usually just use the terminal to look inside them, as they are just directories in the filesystem. But both the old and the new Omni format had a fairly simple xml file called “contents.xml” in the directory/package that held the file proper. And then other directories for attachments etc.
Omni actually didn’t change much in the contents themselves. In both the old and the new format there’s a single contents.xml file. To see if they made subtle changes, I saved the same Omni file in both old and new format then just did a unix diff on the two contents files:
The diff command showed there were some changes to key names, but not wholesale differences.
As a test, I saved a file in the new format and then changed the extension from ooutline (the new extension) to oo3 (the old extension). Then devonthink correctly found text within the file. I also tried stuffing the contents.xml file from the oo3 package to the ooutline package, and now devonthink couldn’t find text in the file (good that this isn’t biology as there’d surely be ethical concerns with that kind of genetic tinkering ). So it seems that it’s really just the extension that’s causing the problems. I’d guess that devonthink believes that the new format is a pure xml file, but since the package is not simply an xml file it fails to search it properly.
So the question is: how does one tell devonthink to pick up the extension information that OSX and the finder already have registered?
I just updated DTPO this afternoon. The release notes said that the new version is compatible with Omni’s new ooutline filetype. Thanks for getting to this issue so quickly. I just tested it and found the following:
If I ask DTPO to open a .ooutline file with the external app, it correctly opens it with Omnioutline.
The internal preview pane in DTPO just shows the file as garbled. It looks like it’s interpreting it as binary (not sure about that).
DTPO will not find a word inside the ooutline file.
Again, thank you for working on this. It’s a very helpful feature of DTPO to be able to read those omni files!
Does anyone know how to make DTPO look inside the new omnioutliner files? A DTPO version from a month or two ago said that the problem had been fixed, but I still find that DTPO can’t read the new OO files. I’ve tried saving the OO files as both flat files and as packages, but no joy either way. Perhaps I’m just doing something foolish. Any help would be greatly appreciated.