Question About Installing ThoughtAsylum Drafts Library

I’m trying to install the ThoughtAsylum Drafts Library and I understand that I need to install the core action group which provides a JavaScript library for the other related action groups. The problem is that I can’t find the link to download this core action group. I’ve attached a screenshot of the ThoughtAsylum page in the Drafts action directory for reference.

I must be missing something basic.

Any suggestions?

Charlie

That is the page in the directory for the core group itself. If you scroll to the bottom of that page, there is an “Install” button.

The links are out to the other related groups.

1 Like

Wel,l I knew it was something basic. Thanks

I’ll join Charlie in the “I’m sure I am missing something basic” department.

I was just listening to the very interesting episode of the always fun and useful Automators podcast with Stephen Millard as their main guest. That’s how I decided to explore ThoughtAsylum myself.

Bravo Stephen if you read this! And thanks for all your work. I had seen some reference to ThoughtAsylum and I might even have installed it together with almost any other action in the repository in my first weeks of fascination with Drafts (also big thanks to Greg Pierce for creating such incredibly useful tool which I also discovered via the Automators podcast!). Even though I still have not managed to get it to work, hearing about what you have accomplished and the amount of work you’ve put into it makes me have a lot of respect and appreciation for you.

Now, here’s the problem. Even though, I made sure I paid attention to Rosemary Orchard’s reminder to install the core action group first, I can’t get any of the actions in ThoughtAsylum to work. When I try, I get the following error message:

“Script Error: Error: The file “tad.js” couldn’t be opened because there is no such file.”

What is the something basic that I’m missing? Can anybody lend me a hand? Thanks in advance.

Josep M.

Having installed that core action group, you also need to run the TAD-Setup/Refresh action from within that group. The action downloads the necessary JavaScript libraries for the other actions.

From the ThoughtAsylum website:

First of all, before you use any of the ThoughtAsylum action groups, you must run the TAD-Setup/Refresh action in this action group. This action will download some JavaScript libraries, one of which the vast majority of actions in the set of ThoughtAsylum action groups are built on.

Hope this helps.

Ooops :face_with_hand_over_mouth:! I was not missing something very basic; I just had not paid enough attention. This is something that was also mentioned in the Automators podcast: Stephen had done a great job with the documentation and people should read the documentation. I obviously didn’t.

My apologies and thanks wightwizard for your help and patience!

1 Like

Glad to hear folks are trying it out, but I’m wondering, is there anything I can do to make it more obvious that this set-up step has to be run on first download (and subsequent updates)?

It’s at the top of the description of each of the action group descriptions in the directory, but do I need to make the instruction more prominent in some way?

I think there will always be a (large?) proportion of people that don’t read instructions before trying something, be that a new phone, TV or application. Part of the difficulty you face here here is that, in Drafts actions, we are so used to just downloading the action/group and it being ready to use.

I know this would be a pain and don’t know if it would even be possible, but is there a way to trap the missing JavaScript error and change the message to say you need to run this action first or (and this would probably slow execution down) at the start of each action run a test to see if the JavaScript modules exist?

Perhaps you could have the set-up action in an action group of its own at the very top of the list and name the action TAD-Setup/Refresh - RUN FIRST or something of that ilk?

Otherwise, I can’t think of a way to get the message more seen.

Just quick ideas off the top of my head. I don’t know how plausible any of them are.

Thanks for writing and publishing the suite. I have only used a very small percentage of it, but that is expanding as I get to know it. It is a fantastic and useful resource.

Because the call to the main library action (TAD) gets used so frequently I always wanted to keep it as lean as possible on checking and downloading content. Also, there’s a bit of a dance to do about downloading the library files before trying to use them. But on the other hand it is loading an ever growing file, and I do want to make things as easy as possible for people without triggering any of the file checking activities that do slow things down; checking iCloud from Drafts can be slower than expected sometimes and that would not be a great experience when running an otherwise quick action.

I’m going to mull this one over a bit more. I’ve had a few ideas come to mind that are worth exploring I think.

Thanks for making me re-check my thinking on this :thinking:

1 Like

You might start thinking about the large library dependency, in general. It’s pretty fast to load, but not free.

I’ve played around with a variety of actions in the group and haven’t noticed any lag, per se, but there is some point at which having the load that library will be a noticeable hit on performance…especially, say, in an action you use frequently with a keyboard shortcut while typing to format text.

Every time an action that relies on it runs, it has to load the file and the JavaScript interpreter has to compile it.

I have not profiled it, and like I said it’s not noticeable in my testing - but I’m running on recent hardware. I may be overrating it as a possible concern, but worth remaining aware of as your action set grows.

1 Like

I’ve been keeping an eye on that since day one. I had some issues loading it from file at one point which is why there’s an option hidden away in the core action group to actually load the library from an action. But that issue only lasted for one beta build - I can’t even recall which one it was. Since then it’s simply flown no matter what I’ve run it on, and while my Mac is relatively recent, my i*OS hardware is far from being new!

But rest assured, it will be something I keep an eye on. If it does become an issue, I’ll look into compressing the code. I’m pretty sure I can’t just get away with minifying it. But I’ll tackle that when it’s an issue and I can test against something.