deanishe

I'm not clear on what it is you're asking. What do you mean by "acceptance"?

If you call an Alfred element with a UI, it's going to pop up. If you don't want that, you need to directly call the downstream element that does the actual work. You probably need to add an External Trigger connected to that element and call it with the appropriate arguments via AppleScript. You can trigger the AppleScript via an Alfred Hotkey.

Düsseldorf? Surely you mean trash multiple files at once?

The workflow you referenced uses switchaudio-osx to do the actual work. You could probably call that quite easily from Hammerspoon instead.

Not with Alfred alone, no. Alfred responds only to user input/actions. You could use Keyboard Maestro to call a workflow. KM can also trigger actions based on other kinds of events, such as attached/detached hardware. I think it might also be possible using a Launch Agent, which is built into macOS.

Alfred isn't an automation application, it's a launcher. So first you need figure out if the application can be automated. If it can, Alfred can launch the automation script. As such, this is first and foremost a question about Optics Pro, so their community would be a better place to ask. It is possible to use AppleScript to "click" menus and buttons, but that's sort of a last resort (it's brittle).

Using my Python library for workflows, you'd use a Script Filter and the code would look something like the below. You haven't provided enough information to actually test it, though (such as the actual API you're using), so this is an untested guess. import sys from workflow import Workflow3, web log = None def main(wf): query = wf.args[0] url = 'https://api.website.com/?domain={}&apikey={}&output=json'.format(query, apikey) r = web.get(url) r.raise_for_status() data = r.json() wf.add_item('DNS test of ' + query) wf.add_item('Expected response: ' + data['expectedresponse']) for i, d in enumerate(data['response']['server']): title = '{} {} - {} - {}'.format( i + 1, d['location'], d['resultvalue'], d['resultstatus']) wf.add_item(title) wf.send_feedback() if __name__ == '__main__': wf = Workflow3() log = wf.logger sys.exit(wf.run(main))

There's more to securely getting a password than hiding the input. In particular, you need to enable Secure Entry so other applications (like Alfred and TextExpander) can't observe the input. This can be done quite easily in AppleScript. If you open the Snippets setting in Alfred Preferences, you'll notice that it tells you that Secure Entry is enabled when this dialog is active. set myPassword to (text returned of (display dialog "Enter your password" default answer "" with title "Password" with hidden answer))

Nope. If you want to change the application that folders are opened in, you need to change the default application for folders. A kludgy alternative is to assign your usual Alfred hotkey to a workflow action that calls Alfred via AppleScript with the keyword for your File Filter/Script Filter. If you want to use Alfred's normal mode, just delete the keyword.

This is an issue with LibreOffice, not Alfred (as you can tell from the fact that TextExpander is also affected). FWIW, I have LibreOffice 4.3.1.2 and it works perfectly with Alfred, Copied and Typinator.

If you paste the data in a code box (the <> symbol), it should be properly formatted.

You, as the only person familiar with Alfred's internal workings, have a different understanding of what arg is versus the rest of us for whom Alfred is a black box beyond its publicly-defined APIs. Totally agree that adding variables (and config) to items and mods is the right solution. That's way cleaner. I don't think that's a very good idea. TBH, I don't believe that checking for JSON, and decoding it if necessary, when the user hits the File Actions/Add to Buffer shortcut or presses ⌘C/⌘L would affect Alfred's performance in any perceptible way. As noted, these actions only apply to single results, and the test+decoding takes milliseconds for a single item. I can understand that it messes with the architecture, however.

Not quite. What I mean is that your regexes only match one line (when the Amex one is fixed). So if you pass several lines into the script at the same time, only the first line will be matched. The rest will be ignored or passed through without being processed. You need a script to split the input into multiple lines and loop through them. Alfred had no native ability to split a single input into several and handle each of them individually, which is what you need. Something like this: import sys query = sys.argv[1] # equivalent to $1 lines = query.split('\n') # separate text into individual lines def process_line(line): """This function processes each line of input using regexes.""" # Processing code goes here # ... # ... transactions = [] for line in lines: processed = process_line(line) # your function that handles each line transactions.append(processed) print('\n'.join(transactions)) # combine parsed lines into single string and pass to next element You could also pass each individual line back into the workflow via an External Trigger, so it is processed by workflow elements, not a script. But in any case, I think you need a script to split the input into its individual lines and loop over them.

I'd say that's a matter of interpretation. From my point of view as a workflow developer, I'm setting a filepath as the arg within the alfredworkflow object. After all, that—and not the JSON—is what Alfred passes as {query} to downstream elements, such as the Debug utility in the workflow I posted. That Alfred passes a different value to File Actions (and ⌘C) than to downstream elements when arg is a JSON-encoded alfredworkflow object, rather than a simple string, strikes me as a quirk of the implementation. Why does passing arg to the File Actions list (or copying it) not count as being passed out of the workflow object? From my perspective, my workflow is done at that point, and there's no situation where Alfred not decoding the JSON would be the preferred behaviour. This seems to be an implementation detail, not a user-facing feature. In terms of performance, I don't think Alfred would ever need to decode more than one JSON object at a time, would it? I can't perform any actions on multiple items at once. That's cool. I'd just like to be able to use different Alfred features together that aren't logically incompatible. Now I have to choose whether to forget about File Actions in my workflow or back out a whole bunch of changes and move back to the way it worked under Alfred 2. And as noted, JSON-within-JSON is a bit funky.

Can you be more specific about that? The workflow uses my Python library, which should take care of gzip content-/transfer-encoding transparently.

That's the way you built it… I do this all the time with Alfred 3. It's a core feature of Alfred-Workflow and extremely useful for avoiding ridiculous numbers of elements in Alfred. In particular, command-line libraries like Click, Cobra and Kingpin allow you to automatically map environment variables to command-line options. That's a fantastic combination and lets you avoid a lot of duplication (i.e. adding a bunch of mostly-identical Alfred elements for every single action). (We've spoken before about the utility of being able to control execution flow from code instead of workflow elements, and this is a good way to do it.) From my perspective (I've already written the code to do it this way), I'd be happy if Alfred just parsed the alfredworkflow object in arg before doing the is-this-a-file test. That's what I consider a "bug", seeing as that's the official way to set variables from an item and I am passing valid paths as the arg encoded within the alfredworkflow object. But overall it would be simpler if there were a variables object within each item: having to insert JSON as a string within another JSON object is tricky, non-intuitive and not exactly elegant. In that case, mods would also need a variables key. And I believe it's also possible to pass other useful stuff via the alfredworkflow object, such as configurations for downstream File Filters (I've never tried this myself). With file:skipcheck the File Actions list opens, but Alfred passes it the JSON, not the arg extracted from it

Alfred 3.4 (850) type = file is ignored on feedback items when workflow variables are also set via arg (i.e. arg is a JSON-encoded alfredworkflow object). Run the following workflow or build your own Script Filter around the JSON feedback. You can hit right-arrow on the first item with a "plain" arg to access File Actions. File Actions don't work on the second item, however. Demo workflow. Script Filter feedback: { "items": [ { "title": "Path, no vars", "subtitle": "This works with File Actions", "type": "file", "arg": "~/Desktop" }, { "title": "Path, with vars", "subtitle": "This doesn't work with File Actions", "type": "file", "arg": "{\"alfredworkflow\": {\"variables\": {\"var1\": \"val1\"}, \"arg\": \"~/Desktop\"}}" } ] }

Updated with some Alfred 3 goodness. Now auto-reloads results when an update completes Auto-updates list of repos when settings have changed Better handing of remote/origin URLs Can handle more URLs (not just GitHub and Bitbucket) Add "meta" app `Browser`, which will open the URL in your default browser Clearer naming of applications in settings: app_1 -> app_default, app_2 -> app_cmd etc.

PHP/Python etc. all support regular expressions. They are all passed into the script, yes. But your regular expressions will all only recognise one line.

FWIW, you can enter ä/ö/ü by pressing ⌥U (for the umlaut) and then the letter you want the umlaut on (a/A/u/U/o/O etc.) ß is ⌥S.

That's the same issue. System Events gives you Process objects, not Application ones, so you don't have access to the application's dictionary/methods

Normally, they're in ~/Library/Application Support/Alfred 3, but if you sync your workflows between machines, they're in whichever directory you've configured as your sync folder (Alfred Preferences > Advanced > Syncing).

Here's an edited version. It doesn't work, but it shows you how to properly set variables. I don't think the workflow can work unless you run it for each line of input separately. Alfred doesn't let you process multiple items at once, which is what you're trying to do (i.e. multiple transactions). Realistically, I think you're going to have to write a script in PHP/Python/Ruby/JS to do the parsing, so you can handle multiple lines at once.

If you're having problems with a workflow, please post the workflow. Screenshots are not enough. The problem is most likely that you aren't actually sending any input to the Show Notification element, but without having the actual workflow, I'm just guessing.

Upload it somewhere and post the link. Dropbox will do.