Setting properties with ScriptingBridge

It’s interesting to discover that bypassing Applescript and going directly to compiled code yields such a large efficiency, so much so that I am a little surprised that DEVONthink hasn’t incorporated an API to bypass Applescript altogether.

Your use case is highly unusual. And learning Swift is not something many people would be inclined to do, especially when there is such strong AppleScript (and more indirectly, JXA) support already built in. Renaming items are usually done in process, e.g., when importing, not en masse. And such renaming is capably handled via smart rules, batch processing, or a person’s own scripts.

I’m trying to standardize on a single language as much as possible in our small office to avoid the overhead of having to be multilingual in SQL, shell scripts, python, swift, applescript

I don’t understand why Swift would be your de facto choice. Perhaps it served a purpose for this specific task, but unless you’re going to moonlight creating Mac/i*OS apps, many tasks are better and more simply served with AS and/or JXA.

PS: Depending on your role within the company, being multilingual may just be a requirement. I’ve had to know far more than AppleScript in all my years in the corporate world. :slight_smile:

2 Likes

I guessed that I was unusual when almost no one knew anything about scripting bridge.

Our dataset is largely financial documents which arrive digitally with a variety of useless names, We’ve standardized on a naming schema that allows us to quickly find related documents by institution, client, issue date, account number, and content type of document. These can’t be determined from DEVONthink criteria nor from AppleScript directly, and thus requires content analysis with regular expressions to parse the document’s text.

I used a painfully slow AppleScript script for years, and then tried implementing a python version. But I’ve chosen Swift because it has a lot of interesting syntactical and data structure features, and given that we are an all-Mac office, I decided to standardize on a language with first-class Apple support. Moving to a “real” language has allowed a more efficient, structured, and readable code base as well as access to an enormous library of supporting utilities.

Further, with this approach I could conceivably talk to both scanning software and DEVONthink in the same program, taking a scanned document, parsing it, and handing the finished product off to DT3. This would make for an ideal workflow where anyone in the office could simply run a simple app to scan/parse/tag/file incoming documents with no intervention. We’ll see.

1 Like

Good luck with your project!