Thanks, ole, for the workflow and the app that makes it possible.

I can't wait to start plumbing the depths of all this new power.

From the ui.load_view documentation:

In Editorial, the path can almost always be omitted (it’ll load the UI that’s associated with the current workflow action automatically).

Just don't do like I did and build a UI in Scratchpad, because I don't think there's any way to then copy it to elsewhere.

My best guess is that it's a crossover error (and, fingers crossed, preview) from Pythonista documentation, since the Pythonista document collection is called a library.

Note: I have no idea whether Pythonista is or is not getting the ui module, and am too lazy to search on it right now. For all I know, it's announced and imminent.

Add a Run Python Script action to a workflow, then click Code Editor, or open the Scratchpad from Console view.

That's where you'll find the full Custom UI editor, as shown in your screenshot, complete with action field.

I still haven't worked out what naming your UI file or library mean.

A simple little workflow tap. Logs various bits of information to the console without affecting the workflow it's placed in.

I'm new to Python, but old to programming, so any constructive criticism is more than welcome.

- Rod

Are you sure that's the right link?

I don't see any change to the Tapper action's script.

You can use an Open URL action and the Editorial URL scheme to open the new version of the file:

editorial://open/yourfilename?root=dropbox

Meaning that any URL parameters that are not reserved by the URL scheme would be available within the triggered workflow as set variables.

Barring that, perhaps a means to get the URL used to invoke a workflow through something like workflow.get_url()?

- Rod

I am open to scripting, and almost mentioned the currently feasible "unpacking" method in my post. :-)

My gut feeling is that JSON would be tough to do in most calling apps, so I'd have to do my own parsing on the receiving end, but it'd probably be a good enough approach in simple cases.

How about a reserved URL parameter prefix for user variables?

Something like editorial://?command=MyWorkflow&usr_myVar=foo, which then does workflow.set_variable('myVar', 'foo') in MyWorkflow's environment before running it.

That way, I could add as many usr_ prefixed variables as I like, and you'd only have to avoid using that prefix in future keywords.