vitor

Welcome @ryan1233, Yes, all Workflows require the PowerPack, as do features like the Clipboard History and Snippets.

The way Alfred’s hotkey works is by registering it with macOS, which then handles it. But an app with Accessibility permissions (check under System Preferences → Security & Privacy → Privacy → Accessibility; maybe Slack is there) could override that. Seeing as the shortcut is disabled when Slack is in front, that’s a strong possibility. But seeing as there’re no other know cases, it may be caused by a particular integration you have installed or something to that effect.

Welcome @dav444, Check Troubleshooting File Indexing Issues. Built-in Troubleshooting and 2. Set the Search Scope correctly may be particularly relevant.

Depends on your sync directory. .alfredworkflow are zip files which unpack themselves on installation. Once one is installed, you can discard the downloaded file. That post is from 2014. For up-to-date instructions, see the documentation instead.

With so many relatively popular and several having gotten recent updates, that seems unlikely. It’s more probable you’re not doing some required setup, but it’s impossible to tell without more information. I don’t use JetBrains’ tools so can’t test. As mentioned above, to get proper help for a Workflow you should ask the developer directly on GitHub.

Tip when debugging: never say “latest” but always the exact version. With “latest” no one knows if you mean the latest beta or stable version, nor do we know if you’re really on the newest version. You may think you’re up to date but be mistaken, or might be a version behind because the auto-update hasn’t kicked yet, or we may be on what we think is the latest version but isn’t, or a multitude of other reasons. “Latest” also makes it impossible for people who face the same issue later on and find the conversation, as they’ll have no idea if their version matches the one in the report.

Checked BetterTouchTool, and its solution is pretty much the same as the AppleScript from the linked Stack Overflow (acts the same).

I can’t reproduce. Even with the same shortcuts, it works fine for me. You haven’t specified your versions of Alfred, 1Password, and macOS. Those are important for debugging. For reference, the way Alfred’s shortcut works is by registering it with macOS which then handles it. Check if anything else is interfering with the shortcut. Shortcut Detective (scroll down) may help.

Those are wildly different things. Are you referring to spaces? If so, there’s no programatic way to do what you ask. Closest you can get is GUI automation, faking keypresses and clicks to create a new space. But launching apps there is a whole different matter. To use the code in that post, copy the bottom block (“For other languages”) in a Run Script Action with /usr/bin/osascript (AppleScript) as the Language. Try it in the Script Editor app first to see how it works. For better ways than that, you’ll need to open the Feedback Assistant app and make a request to Apple.

There’s no answer to that. The bigger the number, the likelier more people have looked at it and use it. No. There was never the need, and every time I’ve inspected a Workflow (many) it did what it said.

@wrjlewis Consider a library which does the heavy lifting for you. Perhaps notion-py?

This forum is the current official place. Here’re also two “awesome-lists” of Alfred Workflows which may serve you nicely: https://github.com/learn-anything/alfred-workflows https://github.com/alfred-workflows/awesome-alfred-workflows Reddit may also be a good source. As I said, there’s never been a case of a nefarious Workflow. As with all software, including macOS itself, you should define your own level of trust. In general, start with the Workflows of users you recognise (e.g. from the forums) as making high quality Workflows. Looking at the numbers of watchers/forks/stars on GitHub (top right) can be a fair indicator of a Workflow’s popularity and how many eyeballs it has had. To analyse a Workflow yourself, reading the code is the best way. You can also use tools like Lulu or LittleSnitch to check the connections a Workflow makes while using it. Keep in mind there are many legitimate reasons for connections to the web: checking for updates and accessing an API (when relevant) are expected and beneficial. I’ve never seen a Workflow collect analytics, let alone something else.

Any error you should ask about in the repo. The developer will be in the best position to know what’s wrong and help. But you have at least 10 choices from which to pick from. I looked at the code of the VS Code Workflow and it doesn’t send any data out or do anything shady. Haven’t checked the node one, but there’s never been a nefarious Workflow. Because it uses node/npm and pulls some dependencies from there, it will depend on your trust in that ecosystem. Since you’re already using VS Code (made with Electron) and a proprietary JetBrains editor, it seems you trust that. But as linked above, there are several alternatives. Another may fit your needs better and/or not have the issue you’re facing.

Right-click an object and pick Edit Note…. Is that what you’re looking for?

Welcome @akame, Yes, there are several. Searching for the editor’s name plus “Alfred” should yield more results, but here’s two (one for each): Visual Studio Code; JetBrains.

That’s the important bit. Executables always run slower the first time because macOS does checks when that happens. Those are outside of Alfred’s (or any app’s) control. Speed-wise, it makes no difference to run the script from the dropdown or a previously saved file. The dropdown method is essentially saving the script and running it. It is possible for your Python 3 code to be slower than the Python 2 counterpart. Even by official benchmarks, Python 3 started off slower. Not sure what’s the current state, but remember /usr/bin/python3 is itself behind the current release by a few years. Thing is, it hasn’t and still isn’t. If you have it you won’t notice, but run /usr/bin/python3 on a fresh macOS install and instead of the code running you’ll be greeted by macOS asking you to install the developer tools. Just like /usr/bin/swift, /usr/bin/python3 is a shim. That’s why many Python Workflow developers—despite not using the dropdown to invoke Python—still chose to go with Python 2; it was a better experience to the user and many were expecting Apple to eventually make Python 3 available, not to remove languages. This isn’t to say /usr/bin/python3 shouldn’t or won’t be available in the dropdown, it just means simply throwing it in haphazardly wouldn’t have been a good approach. With Apple finally removing languages, the dropdown itself has improved: historically it only included languages which were really there, installed on the system by default, but it now detects Homebrew installs of the previously-included languages and is thus in better shape to support more. That doesn’t mean it makes sense to include any and all languages, though. Languages like node and lua would be tougher sells, because you can’t expect any user to have ready access to them when sharing your Workflow.

Welcome @schwerd, That means you’re selecting the 1Password app in the results, not the Workflow. What you’re looking for should say “Sign in and update items”. Alternatively, run :1pextras followed by Force update items.

What exactly do you mean? Alfred takes any shortcut as long as it has a modifier. Slack is incredibly popular yet you’re the only report of this issue. Everything indicates the cause is on your side, it’s now a matter of figuring out what exactly about your setup is responsible. Try ShortcutDetective (scroll down a bit to find it) to see if you can find which app is capturing the shortcut.

Welcome @JPR, See Making Python 2 Workflows work on macOS Monterey 12.3 and above for an explanation of what’s happening, and fixes. Or, in this case, download the updated version by @giovanni. For future problems, check the post linked above. When asking for help, strive to include the debugger output because it helps identify where the issue lies.

That is the name of the Workflow’s directory. If you change that, so does the UID. You can get it easily by navigating to it however is most convenient to you. Or you can make Workflow UIDs (locally) predictable by renaming the directories in a consistent pattern (install with brew install vitorgalvao/tiny-scripts/alfred-workflows-renamer or manually rename them how you see fit) which will make UIDs resilient even if you uninstall and reinstall the Workflow.

Again, you can’t use dynamic placeholders inside scripts, there would be no way to distinguish them from code. Those are passed in as environment variables, so you read them like: import os os.environ['str0'] To read the argument instead of the variable, follow the placeholder example: import sys sys.argv[1]

Then use an Argument and Variables Utility to send your dynamic placeholder to the next object.

It’s not the purview of the Workflow to unlock the 1Password app, nor does the app give external tools the ability to ask for that. Once the URL is sent to the browser, it’s out of the Workflow’s control and the 1Password extension is responsible for continuing the process. And you can unlock the 1Password app from inside the browser: You could argue that the extension should offer to be unlocked when it detects a possible login, but 1Password must have their reasons to do it this way (either to increase security or as a technical limitation). Either way, everything is working as designed. If you want the behaviour to change, it would need to happen on 1Password’s side.

The code can’t be working as the comments suggest, because {clipboard} and other dynamic placeholders do not expand inside Run Scripts (that could interfere with the code itself). You’ll need to tell Python to get the clipboard. Examples: With pbpaste.With Tkinter.