I’m looking to improve the indexing of my XMind files in DevonThink. I’ve identified an interesting problem and I think there might be an elegant solution.
How can such a solution be integrated into DevonThink?
Is there a DevonThink API that would allow this integration?
Are there hooks or extension points designed for this type of use case?
For your information, I reinstalled Xmind (new download from their website), and without entering any license codes or purchasing (a long time ago I purchased a license), I created a test *.xmind file. Imported into DEVONthinkI made no other tweaks to DEVONthink nor macOS.
See screen shot.
It also displays in Finder as expected. NOTE: Spotlight is not the software displaying the file…this a red-herring. Spotlight is only a search tool to find files that then use other software to display, e.g. Preview, Finder, using macOS QuickView (or something). All that above my pay-grade and interest.
If I understand the OP correctly, they’re asking about indexing, not preview/display. Spotlight seems to find text in the Xmind files, DT does not. What do you see in this regard?
Probably, because the file name is just “central topic”. I followed the same approach as you but changed the file name to something else – DT does not find “Zentrales Thema” (I’m in the German locale).
So, the text of the central blob is used for the kMDItemTitle attribute, and the other strings are stored in kMDItemTextContent. Both are found by mdfind and the interactive Spotlight search (where the relevant result appears far down the list).
I think that DT should in any case use the kMDItemTitle attribute, and according to the Scripting Dictionary, the metaData attribute should reflect that attribute. But I suppose it doesn’t do that for all types of files (why not?).
Would that be considered a bug? An incomplete feature? @cgrunenberg would know.
As to the kMDItemTextContent attribute – well, that’s a very peculiar thing. In Apple’s words:
Applications can search for values in this attribute, but are not able to read the content of this attribute directly.
Which (kind of) answers @oscille’s original question: There’s no way for DT to get at the other strings in your Xmind files (short of parsing the XML, which is probably a bad idea performance wise). Not even mdls will tell you anything about kMDItemTextContent. Supposedly for privacy reasons – if the attribute were accessible like that, every app on your machine could read every other app’s files content at will. Not necessarily a good idea.
There’s also a thread on Stack Overflow on that topic:
The issue is caused by an internal ID of Xmind’s Spotlight plugin. DEVONthink handles these IDs case sensitive so far but Xmind uses a lowercase ID whereas the SearchKit of macOS (used to load these plugins) prefers uppercase. In the end this conflict causes the issue but the next maintenance release of DEVONthink will be able to handle this.