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.