vitor

You run them in Alfred. In doubt, run the second. It will probably take a while to finish. Welcome to the forums.

Without testing, what’s likely going on is that you’re using "{query}" instead of {query}. You’re quoting it, meaning the text is being interpreted as a single element instead of the three you want. And you don’t need the Arg and Vars Utility. You’ll get the same result by using Text as the Argument in the Hotkey.

Here’s a variation of what I use.

That’s why I linked you to comprehensive resources. You’re supposed to check them to get an overview and ask about what isn’t clear. A forum isn’t a good medium for an extensive explanation. We’d only be repeating what’s in those resources. You specifically asked how osascript and JavaScript relate. That’s the entirety of your top post.

You can use JavaScript as you know it and have access to some OS functionality and app automation. Look at the last link: Apple shows you how to do the same thing in both languages. Try it. That site is contained, simple, organised, and a good starting point. A rare case of acceptable Apple documentation. JavaScript for Automation matters if you need to do something only AppleScript can but instead of using an awful, atypical, underpowered, unpopular language (AppleScript) you want to use an awful, familiar, popular language (JavaScript). If you don’t have a use for AppleScript, you probably don’t have a use for JavaScript for Automation. You seem to have a goal in mind but are asking abstract open questions without context. If you know what you want, ask that and provide what you already know. If you don’t yet know what you want, check the provided resources and return with specific queries. Otherwise it’s difficult to help you. We’re on the fourth answer and I have no idea what answer you’re looking for. You need to rethink the question.

No, it’s just another language with access to (mostly) the same functionality and APIs. You do what you already did in AppleScript but in JavaScript. This isn’t an obscure feature or related to Alfred—if you search online for “JavaScript for Automation” you’ll find specifics, like the Wikipedia link above, the JavaScript for Automation Cookbook, and Apple’s own Mac Automation Scripting Guide which includes examples in both languages.

JavaScript for Automation on Wikipedia.

You’re looking at the File Buffer.

It’s not feasible without an unreasonable amount of work or making the Workflow considerably slower.

You’re also likely to be able to do it in a few lines of AppleScript without needing to install anything else. But @giovanni’s comment above stands: you can tell a Workflow to change your output device then open Zoom, but not monitor when it’s opened via other means. If you open it like open -Wa 'Zoom', the execution of the Workflow will halt until you quit Zoom. At which point it can run another AppleScript to switch back the device.

The likely reason was explained a few posts back.

@Stooovie Update to the latest Alfred pre-release and it will be fixed. Details:

Script has been updated to allow running command in current tab.

There’s no two-letter EN country code in the standard, and if there were I doubt it would refer to the USA (much more likely it would be England, thus use £ / GBP). Calling the variable a country code is as confusing as calling it currency. Keep in mind that even “dollar” isn’t a single thing, other countries use different dollars with different values. I understand that two-letter code may be what they use in their (private?) API, but if it’s this confusing it might be worth having a way to clear it up, like a note or table in the About section. This Workflow looks pretty useful for those who have a Switch. If picking a currency anyway, why not have it show directly in the initial list of results?

I’d prefer to find a solution which would work out of the box, even if it meant including a compiled binary which doesn’t seem simple with fswatch. My first thought was using a launch agent with WatchPaths, but that’s not recursive.

If I understood you correctly, what you want is a job for something like Karabiner-Elements.

Can’t say I agree that would make sense for Alfred. It’s a whole different paradigm and PopClip’s whole point. By design Alfred runs when it’s called and is otherwise invisible; adding a whole new automatic context seems neither simple nor consistent. You request would (literally) entail rewriting PopClip itself into Alfred. It would make more sense to have PopClip invoke Alfred Workflows, which you probably can do via AppleScript.

Not everyone is familiar with PopClip. It helps if you explain exactly how it’s feature works, with screenshots.

You’re looking for File Filters.

Not finding it now, but I know there’s a Workflow in this forum which uses GUI automation to do just that.

If that does work and Google doesn’t make a launchd daemon to work around the issue, maybe we can. That StackExchange answer is from July and already has a “not as permanent as I thought” edit so not jumping into that solution just yet. Either way, the Workflow has been ready for about a week with some changes, including support for multiple Google Drive paths. It also (tries to) uses the included SQLIte gem, so it might solve your issue @millerstevew. Pinging @alfredpanda because you asked to be notified of the release.

With recent versions of Google Drive, which switched to the macOS File Provider API, you may no longer need a workflow as Google Drive files may show up in regular Alfred searches. If you’re not seeing them, go into Alfred Preferences → Features → Default Results → Search Scope → Reset… (bottom right) and “Reset to Applications and Home”. If you’re not yet on a Google Drive/macOS combination which allows that, or you prefer using the workflow for its granularity and want to report a problem, run !gddiagnostic and paste the results in this thread or on GitHub. Note that to use the workflow you need to set up your Google Drive location in the Workflow’s Configuration. If you don’t know how to find your Google Drive, How-To Geek has the steps.

Setup Set your Google Drive’s location in the Workflow’s Configuration. Usage Search the contents of your Google Drive via the gd keyword. Filter for folders only with gdf. Fallback Searches are included. ↩: Open. ⌥↩: Reveal in Finder. ⇧↩: Search on Google Drive’s website. You’ll be asked to build the cache on the first run. A notification will show when it’s ready. The more files you have, the longer the wait. A macOS launchd agent will be loaded to do it daily. An immediate cache rebuild can be forced with ⌘⌥⌃↩. The Universal Actions make it straightforward to copy and move files to a Google Drive folder. To report a problem, run !gddiagnostic. ⤓ Install on the Alfred Gallery | Source

Yes, that is documented. Syncing—and any other setting—is unrelated to your license. You can sync one, none, both, to different locations or the same, it’s your choice. Alfred itself doesn’t do the syncing, it allows you to pick a custom Preferences location which you can then sync (e.g. Dropbox).