HI, so much content about scripting, but all I saw was about running actions from within Drafts.
My scope would be different: I want to access a (fixed) draft from an macOS-shell.
Basically I want to search the content of this Draft and display it (grep, sed etc.). This draft contains sort of a little text based database
If this works manually I want to integrate this in to an Alfred list filter.
Is there an example or other hints for me?
Sorry, if the question is overly stupid with an easy to find answerâŚ
Take a look at this thread and the Alfred workflow for the basic premise.
Also take a look at the URL scheme info. AppleScript support for accessing Drafts is still pending, so Iâd say that URL access is the way to go for now in exploring this.
I tried to use the URL-scheme way (which seems the only way as of now anyway).
But:
1.) I noticed that I donât know who to use these URLs from a Bash script. curl doesnât recognize the scheme.
2.) The natural URL_action would be âgetâ, but I need something to understand the back-reference URL. => so I decided to use ârunactionâ instead together with the App-action âCopyâ.
But the documentation is unclear to me: There is a mandatory âtextâ parameter and the expected âuuidâ paramter is not there.
If anyone has a suggestion it would be great, but donât waste your time with me.
You donât have to use the text parameter in your action, so you can just pass in an empty string.
Since you are opting to use runaction, it doesnât need a UUID because actions run against the currently loaded draft.
You could use the text parameter to pass in a specific UUID, or have one specified in your action. Then have your action scripted to work on the draft specified by your uuid rather than the current draft instance, draft.
It could certainly be easier with more automation options, but I donât believe it is inaccessible - the example Alfred workflow linked to earlier is an example of this. Iâm sure many others like myself also have some similar things on our Macs. Inn regards to it being a Mac thing; yes some tools are only available on the Mac (e.g. shell script, AppleScript, use of Marked2), and likewise, some things are only available on i`*OS (e.g. Shortcuts).
Ultimately do note that this request was posted in the âDrafts for Macâ forum and explicitly references the Mac and Alfred (a Mac only app). I think that makes it relatively clear that the solution being sought is Mac specific rather than seeking something cross-platform.
Thank you sylumer for your quick and good looking reply, which I have to work through later.
The hint to xcal is definitely a great step forward. I will try to use this, sound perfect.
If runAction always refers to the current draft, it is useless for my purpose. I hoped I can direkt it to a draft with a given UUID (which would make a lot of sense fpr the API design IMHO - but I am so grateful about Drafts on Mac and how far it is already after a short period of time, so no complaints).
(And Yes, I have the Alfred workflow installed: useful in itself, but could learn only little in relation to my âprojectâ. All 4 actions more or less only send something (fire and forget) and not receiving specific conents and dealing with it).
It will display the content of the draft whose UUID I put in the x-callback-url. I think from what you have described that this would allow you to work with the draft you want.
Not at all. All good I was just trying to clarify for you.
The script only uses an alert, thereâs nothing in that code to set any sort of response explicitly.
The runAction x-callback-url action doesnât have any return options defined to it unlike say create or get. See the documentation for details about what actions do and do not have data return options built in.
For Shortcuts Iâd use the usual workaround of grabbing the clipboard, running the action modified to put the result on the clipboard, then reading the clipboard back when back in Shortcuts and once I have it, restoring the original clipboard.
I admit Iâm not following this entire thread (busy week!), but I would note that the /open URL can also take an action parameter, which then executes the action on that specific draft, something like:
In my opinion the problem is of the chicken-and-egg kind.
It is hard to get the UUID of a draft in the first place.
If the UUID is available the interface is pretty strong and very good!
But to get the UUID - e.g. via a search - not a problem in an action - than to pass it back out.
@sylumer told me to use a file or clipboard based workflow and this works OK.
What I would love to see from you is a /get_uuid_list?query=Traft.Content&search=Title that has a return value of a JSON-array with all UUIDs that match.
I found this missing search in other apps (like Bear).
Until then I will use your great app and the astonishing people in this community and use the clipboard.
I think you are thinking URL schemes can work like HTTP, and they do not. You canât pass a response to a custom URL scheme, itâs just a URL that gets handed off to an app.
Callback URLs are a way to workaround this when apps agree on separate custom URL schemes and implement ways to call each otherâs URLs, but that not the same thing as requesting data. You can never get data back from a call to an appâs custom URLs. Thereâs no server processing the data and returning a response.
The âxcallâ hint already was very good. Used with âget uuidâ it displayed a little JSON object with the content of the draft to STDOUT. So this could be used for my purpose.
The hint to send âget uuid & action=copyâ made it even better for me, the content of this drafts comes in macOS pasteboard and I can work with âpbpaste |â on the the text content.
In the Draft application UI this draft will be selected (which was surprising, but doesnât bother me).
In HTTP, you made a request from a URL, and get a response.
When opening a URL for an app, the system (iOS or macOS), simple using the scheme (before the colon in the URL) to determine which app can handle that URL, then opens that app with the URL as an argument. There is no two communication, no response to the original requesting process.
x-callback-url was developed as a spec to allow apps to communicate two-way over custom URL schemes by agreeing on a format for URL query parameters that can include other URLs, which an app can then use to return to the original calling app. If you use them, you include a URL as the x-success parameter in a URL to Drafts, then when Drafts is done with whatever the URL requested it to do, it will open that URL - with, in some cases, additional parameters added (like the retParam value) to pass information back to the original calling app.
This is not something you can just utilize directly from another scripting environment, however, because you need an app running somewhere that is able to handle the response URL. That is what the xcall command line tool does.
I was just trying to clarify for you.