It’s been like six or seven years since I first posted in the pinned Applescript thread [url]https://forum.literatureandlatte.com/t/applescript-what-do-you-want-to-see-in-the-scrivener-suite/1888/1], and a lot has changed in the world of automation, mostly related to the absence of Applescript on iOS & the development of alternatives. I’d still like to be able to automate the tasks I mentioned way back then, but I’d agree with the calls for a cross-platform solution.
A lot of my text-related scripting lately has been in Python as well (for Editorial & Alfred Workflows, mostly). Another option is JXA / Javascript (which I’ve also been using with Drafts & 1Writer). And/or a URL scheme that would work cross-platform.
I’m guessing JXA would be the easiest starting point (for the Mac anyway) since it’s built on top of the scripting infrastructure developed for Applescript over decades.
I would love automation support for Scrivener. Though AppleScript isn’t my favourite language since I’m a Python man through-and-through. Back in the day, VoodooPad had pretty good support for Python (and JXA) complete with hooks to Cocoa. I’d love to see that kind of implementation on the Mac version of Scrivener.
Like you Derick, I use and love Editorial for text automation; I’m also a heavy Pythonista user. I was thinking that if Scrivener for iOS supported share sheets then I could use Editorial or Pythonista as poor man’s plugin by sending formatted output to Scrivener. Since I’m not in the beta program, I have no idea if this will work.
After nearly ten years since Keith first created that post, I’ve pretty much given up on it happening though. It’s an advanced feature for advanced users and I guess there isn’t enough demand from the Scrivener user base.
Yes, sorry, the AppleScript implementation was put on indefinite hold. Exposing all of the features users would want (and suggested) through AppleScript would be a huge job, resulting in a massive AppleScript library, and it would mean creating a lot of spaghetti-like pathways through the code to expose deep features to the classes responsible for AppleScript. Ultimately, there wasn’t enough demand to justify the months of work it would take for a one-man coder.
Likewise, there are currently no plans for any other kind of automation or API. That sort of thing would be lovely one day, don’t get me wrong, but right now we just don’t have the resources. I’m a single coder working on both the iOS and macOS versions, having completely failed to find another coder yet who is able to come on board and really get to grips with the Scrivener codebase and help (that is still something I’m aiming for, as I can’t do this on my own forever). Meanwhile, there are two people working on the Windows codebase, but they have their hands full not only catching up to the current Mac version but also trying to reach parity with the next major Mac version, so that our Windows users no longer feel left behind.
It is still something we will continue to evaluate, and if it ever becomes viable we will certainly consider it, but right now there just isn’t the demand or resources, I’m afraid.
I know next to nothing about Macs, but have automated Scrivener functions successfully in Windows via AutoHotKey. There’s no need to wait around for an API, as we can automate an application through its user interface. This article suggests that JXA users can do the same:
By coding to read Scrivener’s binder file into a table, scrape screens, locate and click on buttons, manipulate clipboards and so on, a script writer can create some extremely powerful enhancements, building in the process a toolkit that works well beyond the one application.
Jerome - I’ve done some UI scripting with Applescript (e.g. github.com/derickfay/keynote-to … pplescript ) – the reason I’d avoid it is that it tends to be really fragile and only feasible with fixed UI elements (like the print dialog box in that example) – so anything like the Binder in Scrivener which is going to be in a lot of different states would probably be impossible to approach that way. Reading the Binder directly is an interesting idea - the XML structure looks pretty clear (and maybe it’s documented somewhere?) but I’m at a bit of a loss as to how one might coordinate keep track of the relation between the current UI state and the Binder to make sure AS is scripting clicking in the correct places etc.
If ever this gets taken up again, at this point I don’t think AS would be the way to go. I think URL schemes which can be registered and work cross-platform (think mailto:// ) would be a better approach. Here’s my list of basic commands which I think would cover a lot of the needs expressed in the AS thread:
make new document (in Binder or in path)
set/get contents of document/synopsis/metadata
open existing document (ideally as a hook to the existing infrastructure for Scrivener Links)
get Binder structure (from root or a specific document) in JSON
All the heavy lifting could be down outside, with Scrivener just being called to get and set. Some of this overlaps with the existing (Mac only?) Services as well.
Indeed, the binder is saved to the drive only occasionally. So the string we read back will not track the binder’s moment-to-moment changes, but will nonetheless be our script’s most detailed map of the project. Nor would a scripter have much luck in navigating the binder through recognition and clicks, as an interactive user does. Instead, he’d automate binder travel via the Previous Document, Next Document, and Enclosing Group commands, most likely.
I place a binary rendition of the DocID into Document References, and another into Custom Meta Data. These enable a script to determine which document Scrivener is on, to match up with the corresponding document in the binder string. It’s also quite a trick to get the script to navigate to a particular doc within Scrivener. I’ve been making the case that, in lieu of a comprehensive API, a future version should build these essential capabilities into the UI, maybe meeting scripters a bit of the way.