Well I know, but I really didn’t mind exploring your workflow by myself. I think I picked up some things on how to use Alfred workflows that were new for me.
(I am only a “casual” coder, main job is social science research.)
I know, but tailoring it is exactly my goal. I am trying to figure out how to display tags instead of creation dates in the Alfred result subtitles. Never worked with sqlite before and have no knowledge of python, but just changing this tiny detail shouldn’t be that hard. Any pointers on how I would I can achieve that?
As far as I can tell, there is no documentation on the python script in your drdraft documentation. (documentation for drfind is also missing, btw.)
It’s quite hard to deduce that from a screenshot of just the steps, but it is exactly why I phrased it as I did.
I’ve not really worked with SQLite before either, but I was a programmer for many years and am quite familiar with working with a number of different flavours of database. There isn’t any public documentation for Drafts’ database structure, so I just figured it out (reverse engineering is far too grand a term for it, but it’s that sort of thing).
If you haven’t worked with databases or with Python before, then I would suggest starting there. Otherwise, you could waste a lot of time trying to figure stuff out, and there is always a chance that if you mess with the wrong database tool or commands that you can corrupt your Drafts data.
Note that while I theoretically could have done quite a few extra things with the workflow, everything I do creation or update-wise is via Drafts. Things can change, and so this is the safest and most reliable approach.
Correct. The documentation site is there to help people get as much use as they can from the workflow and to build their own solutions on top of the workflow (as per the extended use section. It is not intended to provide detail any deeper than that as no one other than me is expected to be modifying the workflow, and I maintain my own additional private documentation for my projects such as this.
The Python code is actually relatively straight forward. As a result, I have very little documentation about it in any case. My personal notes focus on the underlying data structures, variable use & reliance information, general design, and other things that are really only of ongoing interest to me in my maintenance of the workflow.
The documentation is not missing. I think you may have misunderstood some of the documentation. You can find the documentation for drfind here:
Above, you are referencing the documentation page for the external triggers, whereas drfind is an “internal” hotkey trigger.
drfind calls the external triggers dropenuuid, drcopy, or drurl depending upon meta keys held down during triggering. The documentation for these are listed in the Documentation section from the Loading documentation, and the Copying Information pages.
But, if you or anyone else does spot a mistake or an omission in the documentation, please do let me know. I’d very much like to keep them as complete and up to date as I reasonably can.
Hi @sylumer - thanks for the great DrDrafts actions! I have one thing that’s not working though. Whenever I update to the latest beta with DrDrafts the app that is copied to the Application folder cannot be launched - macOS says it’s corrupted. Anything I can do about that?
The first line downloads the update, the second decompresses the update to get the app. The third step removes the existing Drafts app, and the fourth moves the new app into place.
As a first foray into investigating this I would suggest running each command above from the terminal one at a time and examining the output from each one to see if you are encountering any issues. This approach is effectively doing the key steps manually, the other parts of the flow doing things like check the version numbers, close/open Drafts, and output notifications.
Thanks for the quick reply. I didn’t try that yet but got an idea after reading your post, which actually seems to be the reason. All works well if I run that from an account that is an admin account. However, on my Mac I’m normally logged in with an non-admin account, and in that setting it doesn’t work. I tried the individual instructions, and terminal returned an error with the rm command (Permission denied).
Probably totally stupid question, but could the script be changed to e.g. sudo the rm command - ideally with saving the password in the script? (I’m not much familiar with terminal or scripting, but would be able to edit the Alfred workflow if you have a suggestion?)
I think password saving would be a bad idea from a security stand point and I would rather not start applying such things. But, I think I can get it to prompt each time if necessary, in line with how you would normally be prompted to submit credentials - i.e. using a standard secure entry window (from Apple).
I’ve put together a quick test version I would like you to try. It is working for me, but I’m not the best test case as it works for me normally.
Install the workflow, and trigger a forced beta app update via the keyword drbetasudoforce. When you run it you should get a credentials prompt at the stage of replacing the Drafts app.
> Please let me know the result.
I currently have plans to put out an update for the workflow next weekend. I already have a few new things in the pipeline for it, and should be able to add this functionality in (with an admin privileges check) assuming it is indeed a viable solution.
Thanks @sylumer - this works fine! I get the promt as I would when I copy normally, so that’s good. And using the script to update the beta is, obviously, great!
just noticed a minor issue with your find.py: It does not recognize special characters properly, in my case the German Umlaute (äöü). Problem has something to do with character encoding when reading from the Drafts sqlite?
I don’t have much to say other than I installed this, it’s working well, and the whole thing is fantastic! Thanks for creating this Alfred integration!
Just a quick update. Even with a long weekend, I’ve been busier than I had expected to be when I said this. Thanks in part to an important work activity I’m leading tomorrow morning. As a result, the release is not ready just yet. I have a few more features on my list that I want to add into this release. I am going to see how much I can get done this week, and with any luck, at some point very soon I will have everything ready.
But I just wanted to at least confirm that my development version of the workflow contains what I believe to be working fixes for the following two issues that were raised:
The beta update option (thanks @pehein111 for flagging that one), and it will automatically determine if it should ask for admin credentials or not.
A fix for the searching of accented characters (thanks @armenotan for flagging that one) - applied across the board, and took a bit of research and examining of hex codes to figure out what I was looking at and for.
I’ve discovered a new flavour of complexity in character encoding in resolving this one!
Of course, along with the updates to the existing functionality and the new functionality, there will also be updates to the documentation to support it; which takes a while to cross-reference and put together too.
This is really impressive - I’ve been on Alfred since beta 0.8 or so & this might be the best documented workflow I’ve seen.
One issue - I found that the dractionsearch keyword was triggering rather than expanding and letting me enter my query - I changed it to require an argument like the other search keywords (drqsearch and drsearch) and now it works as expected. Not sure if that was intended as default behavior or not.
Thanks. The documentation takes quite a while to put together, but I find that makes it easier for people to use. Well, for me at least. If you have any good examples of Alfred workflow documentation, I’m always open to consider ways to improve what I’m doing. I am sure it is far from perfect, but it’s good to strive for improvement.
The documentation web site is also continuing to grow.
There is an entire new section coming in the ‘Documentation’ section with the next release.
There are some brand new flows that have been documented (and more in the works that will need documenting when I’ve finished tweaking them).\
And some extensions to existing flows … which means I’m doing a lot of updates to existing documentation too.
Thanks for flagging that up. It was certainly not intentional and I’ve made the change for the the upcoming release.
Better handling of accented characters across a large number of the flows.
Beta updates should now prompt for admin credentials if required.
Scripting search list has been updated and I’ve added searching of the beta scripting for good measure; though at the moment they are the same as the beta programme is on hold due to WWDC coming up fast.
You can now specify your own sound for the notification via setting a variable called SoundPath (ref.).
Option to copy web redirect URLs for drafts for when you want to add a draft link to something and it won’t accept a drafts:// URL.
File actions - you can now create/append/prepend/log to drafts direct from file contents using Alfred’s file action functionality.
There is also a new use case that covers how to create a quick action/service that utilises Doctor Drafts to create draft direct from file selections. Basically an equivalent for file actions from the services menu for those who don’t use Alfred file actions often, but do use services often.
I did have a few more things I wanted to add, but other priorities are calling, and I wanted to get the fixes out sooner rather than later.
Please do flag it up on this thread if you come across anything that doesn’t look right
Let me know if you have any good use cases - I’m always open to suggestions to add more to the site.
Do also let me, your friends, family, colleagues, and followers (tweet me at @sylumer on Twitter) know if you are finding the workflow useful.
This makes a huge difference for me, and I haven’t even gotten in the habit of using most of its powerful features yet.
Would love if you built an update function into the workflow; a lot of my other big workflows have it, I can pull up a few specific ones if you need examples.
I’ll certainly consider some notification/update option for a future release. I already have something for updating the Drafts Beta, so why not something for the workflow itself?
HI Thanks for a really thorough workflow. I too cannot create a new draft, when I debug I get the following error Not authorised to send Apple events to Drafts. (-1743) There is no security pop-up and there is no option in security automation to tick this.
