deanishe

That's a fantastic idea and an absolutely huge undertaking. Thanks. I'll check it out. www.deanishe.net is hosted on GitHub Pages and the "main site" (such as it is) is built with Hugo. There's no actual content beyond an auto-generated list of what I've been up to on GitHub and Pinboard recently, but that's where the gh-pages branch of Alfred-Workflow ends up, so I figured there should probably be something at the root URL, and I found a Hugo theme based on the Sphinx one I use for AW's docs. Having built a few sites with Pelican before, I have to say that Hugo is bloody awesome. So much faster, so much less buggy.

That doesn't help if the warning is on the same page. Based on which data exactly?

No, not really. I mean the whole workflow (i.e. info.plist, icon.png etc.). Basically the contents of the folder you see when you right-click on your workflow in Alfred Preferences and choose Open in Finder. That should be the root directory or a subdirectory of your repo. That way, people can install the workflow via git clone (plus possibly symlinking it), and submit meaningful pull requests. For example, when possible, I keep the "finished" workflow in a src directory of the repo. I can symlink that directory to Alfred's workflow directory to use the workflow, and other folks can submit pull requests against the full source code rather than submitting an impenetrable binary (the .alfredworkflow file). I keep the actual workflow source in a subdirectory because there's a copy of the compiled workflow in the root. Putting the workflow and the source in the root often leads to people exporting a workflow with a copy of the previous version in it, which has a copy of the version before that in it, etc. etc.

Move/copy operations. For example, if I separately drag 5 movies to a USB stick, Finder will copy all 5 at once. Path Finder queues the operations and copies one after another. It tends to go faster that way, and if it turns out you've copied too much, only the last copy fails. I haven't actually tried it in the above scenario yet. If it does behave the same as Path Finder, then I'll probably stop using Path Finder. Especially because of the issue with Default Folder X noted above.

One thing that we generally recommend: put the workflow source code on GitHub, not just the exported workflow. It makes it much easier for other people to contribute via Pull Requests.

What program do you use to capture the GIFs? The one I've been using doesn't work anymore Regarding your Learn Anything > Alfred Workflows page: Bear in mind that each demo GIF is typically a few MB. You really shouldn't embed more than a couple of them on the same page. Nobody wants to use 1/5th of their monthly mobile data volume looking at a single page. Why don't you instead try to make an awesome Alfred site instead of a single page? Write a review of/article about each workflow instead of recreating the Awesome Alfred list, except with huge GIFs.

https://github.com/deanishe/alfred-packal-search The big problem, imo, is knowing where to start. I.e. what level of skill do you assume on the part of your audience? Once you start writing scripts, a workflow tutorial becomes a combination tutorial on general UNIX scripting, Alfred and one of Ruby/PHP/Python/JS. I definitely think some tutorials touching on Alfred "idioms" would be very useful. I'm reluctant to write any more given the number of hours I've sunk into Alfred-Workflow's documentation. It's not so much that I don't want to write any, it's that I don't want to keep them up to date when Alfred changes. I had to rewrite the Workflow/Environment Variable HOWTO for Alfred 3.4.1, and I really don't fancy having 10+ articles I'd need to update (leaving them out-of-date isn't really acceptable to me).

I use Dragon Drop. I've been looking for a decent replacement for quite some time (in particular, Dragon Drop won't let you stack multiple drops), but everything else pops up at the edge of the screen, not where your mouse cursor is. That's fine on the 11" MBA, but I have a 30" screen on my desk, so the edge of the screen is not a convenient place to drag stuff to.

I use Finder 99% of the time, tbh. I only use Path Finder for copying/moving lots of files because it lets you queue file operations, whereas Finder tries to do them all at once. I tend to avoid Path Finder due to the way Default Folder X handles it. For some reason, DFX assumes that Path Finder folders take absolute priority over Finder ones, even if they're on a different desktop. It's really annoying. If ForkLift also queues local file operations, I'll probably stop using Path Finder altogether: as noted, it's much easier to open a specific pair of directories in ForkLift.

Any chance of shortening the default update interval to a day or two? It seems I always end up downloading the updates manually, as the interval is so long and there's no "check for update now" mechanism

You have to use correct format: {date +1d :yyyy-MM-dd}

Which modifiers exactly? And do you have any other programs running that fiddle with what keys do (e.g. Karabiner Elements or BetterTouchTool)? It seems extremely unlikely that this is an issue with Alfred.

Couple of suggestions: The source code of your workflow isn't in the repo, only the Python script it uses. That makes it hard for people to make pull requests. Why don't you use the /usr/local/bin/mvim -f <filepath> command to open the file? This waits until the user closes the window, so you know when the user has actually finished editing the file.

You need to connect a series of Keyword inputs to your Snippet Trigger, saving the input from each to a workflow variable, then calling the next. Then in your Paste template, you can use: Dear {var:NAME}, Thank you for your {var:WHAT}, which we received on {var:DATE}. It's nowhere near as simple, or convenient, as a "form" fill-in in TextExpander or Typinator, but it is possible. And with Alfred you can add additional logic between the inputs if you like.

rsync, rsync, rsync, not rsync Transmit 5 might be okay. Just don't use Panic Sync if you care at all about security. The stupid idiots upload your private keys and passphrases. Transmit also has a scripting dictionary, while ForkLift only has a URL scheme. I think ForkLift is also designed to be a file manager. It's much easier to open a pair of local folders in ForkLift than in Path Finder. Especially with the workflow.

Thanks for the interesting explanation. TBH, I just use a script that runs the Pinboard bookmarklet in the same tab. Have it mapped to ⌘⇧P in Safari and Chrome. I have my own (unreleased) workflow for browsing my bookmarks (because who doesn't?), but yeah, like you say, Alfred isn't really suitable for making a great "add" UI. I might have a crack at it one day, though. I've already written a decent "tagging" UI in MailTo, which is the critical bit, imo. The big problem with a native GUI (apart from figuring out how Cocoa works) is that it'd presumably have to have some level of integration with Pinboard in order to suggest tags, rather than just be a big, dumb form. The huge advantage of a native Cocoa version vs Electron/QT/etc. is that it would start instantly.

Compared to Transmit 4, none. Transmit 4 is a better app (unless you need the Rackspace support). Compared to Transmit 5, ForkLift uses a sensible, secure method to sync your favourites that doesn't involve uploading your private keys (which Panic Sync does, because … actually, I can't imagine why anyone with even half a brain would do something like that). ForkLift 2 is crap, however. It doesn't verify SSL certificates when connecting to WebDAV servers. Mostly one-off transfers, like uploading a workflow I made for someone. I use rsync for anything I upload/download regularly.

Look up macOS error numbers Download | Source code Usage errno [<query>] — Look up an error in Alfred ↩ — Show error details in a Large Type window ⌘↩ — Show file where error is defined in Finder

Browse and open your ForkLift 3 favourites. Download | Source code Usage ftp [<query>] — List/filter favourites ↩ — Open selected favourite in ForkLift

Is something like MacGap or pywebview not up to the job? 100 MB is mental.

I'm not sure what you mean by "arg v object". If you mean the input to a Run Script, ARGV works exactly the same as with any other command-line program. Text is passed as $1 and multiple files are passed as $1, $2 etc. Workflows are not plugins and do not have access to any of Alfred's internal objects. They are external processes. If you want to set breakpoints, you'll have to use a debugger appropriate to the language you're using.

Realistically, I don't think this is possible to do. Even if Alfred were made aware of user-added elements, there's no way it could possibly know whether a user's changes are compatible with the author's. People would end up with broken workflows, and then pester authors for fixes for things they know nothing about.

Use this script instead. It deletes the URLs after opening them. # encoding: utf-8 from collections import deque import os import subprocess import sys csvfile = os.path.expanduser('~/Desktop/links.csv') # load all URLs urls = deque() with open(csvfile) as fp: for line in fp: line = line.strip() if line: urls.append(line) count = 0 if len(sys.argv) > 1: count = int(sys.argv[1]) if not count or count > len(urls): count = len(urls) # open URLs i = 0 while True: if i == count: break url = urls.popleft() subprocess.call(['/usr/bin/open', url]) i += 1 # write remaining URLs back to file with open(csvfile, 'wb') as fp: fp.write('\n'.join(urls))

If they're unresponsive, sure. Better to ask first, and get them to put a big link to the fork at the top of their READMEs.

Do you want the links to always be deleted or only sometimes?