vitor

What you’re doing is not a workaround; it’s the proper way to do it. A trigger connected to an output is as simple as it gets.

Moving to Feature Suggestions.

You need to share it for us to be able to help. In practice what does it mean that your Workflow lets you look at your recent screenshots? It’s a big difference it they are saved as files or to the clipboard. That would mean Workflows would be able to supplant Alfred features, which isn’t a good idea and would lead to bug reports to Alfred which could not be fixed by the team. Again, it depends on how your Workflow is implemented. It’s the Copy to Clipboard Output, or use a Dispatch Key Combo Output with ⌘V.

Moving this to Feature Requests.

In a decade of building Workflows and frequenting this forum, I don’t recall ever facing the need or seeing another request for that. Most Workflow actions are fast enough you wouldn’t get to abort them in time anyway. How would that work, even? You add a kill utility to a Workflow, and then what? You connect it to a Keyword or Hotkey and when those are invoked they kill everything in the Workflow? With which signal? Does it force a quit? What about if you have queued actions ready to trigger? Are those cancelled to? You’re asking for a big internal change to support a minor feature which so far only one person would get occasional use out of. It seems unlikely to happen.

AppleScript is a subpar, atypical, underdocumented language with a small community. Taking long to learn it in no way reflects your ability to learn to program.

I don’t use Discord and it wouldn’t be a good use of our time to diagnose four hundred individual pages when you can do the way simpler and faster solution of trying it with fewer tabs. Timeouts should happen per event, which would mean one or more of the pages could be the problem as they are not letting the necessary JavaScript run or it’s taking too long to finish for another reason. Try this version, which will output to the debugger the URL it’s trying to pause before it does it. It might give a clue.

You seem to be under the impression that it would be simple to read your browser history and replicate its search behaviour. That’s an incorrect assumption. A Workflow with its own search history is far more realistic, but even that takes effort. It might certainly exist, but it’s far from a foregone conclusion that it does.

Welcome! There aren’t really “coding programs”. You use either a text editor with niceties thrown in for coding (VSCode is popular and free) or an IDE, which is a slower text editor with further niceties. What matters right now is choosing a language. That depends on the types of Workflows you want to start with, but in general Ruby or Python are good choices. Ruby is my pick for reasons I won’t go into (this isn’t the place for a flamewar), but Python has a larger community at the moment. Just make sure to use Python 3, not 2 (a can of worms not worth going into right now) if you go that route. That, however, will make it harder to share your Workflows right now because Python 3 does not ship with macOS. Ruby isn’t yet affected. Either way, the worse thing you can do is get analysis paralysis. Start with either, you can always switch later. Concepts you learn in one language will translate to others, even if you write or apply them differently, meaning you won’t waste time if you start with something decent (Ruby or Python). I won’t recommend a particular source for learning either because there are tons of good ones, from books to lectures to courses; spend a few minutes researching what resonates with you. Consider it part of the learning process: to be a good programmer you’ll need to be comfortable with looking things up.

Unlikely. I also used it to test and all Chromium browsers have similar AppleScript. I wonder what different about your setup; you seem to still be the only one to experience that and this has more users now.

Found it.

It’s not possible yet but there’s a Feature Request open for it already on the forum. Hard to find the link now on a phone, but I opened it.

Again, what you want to automate is Kali and your VM software. Can you already do that? If you can, Alfred can help. Again, it depends entirely on the VM software and the best OS. It does not matter which commands you want to run, only if the tools are automatable. Not all are. You can’t install Workflows without the PowerPack. Examples wouldn’t help at this point.

Again: This is not an Alfred problem, it’s a Spotlight problem. That’s were you need to concentrate your efforts. If it’s still indexing, then wait for it to finish. The first one can take a long while.

Make a Keyword, connect it to the Run Script, connect it to the File Filter. You then call the Keyword, never the File Filter.

Yes. Can you already do that without Alfred? If so, Alfred can streamline that. But it seems like you’re wanting to automate your VM software and the guest OS, and that depends entirely on them.

Welcome @thirstylizard, Making a duplicate post lowers the chance of fixing your issue because the people going through it might not see it. Please keep posts focused. I’ll merge the threads.

Welcome @mkhsv, Simply connect the Open URL to a Copy to Clipboard Output to copy the link. Then connect it to a Run Script Action with Language set to /usr/bin/osascript (JavaScript) and Script Application('System Events').keyCode(48, { using: ['command down'] }). That will fake a ⌘⇥ which is the fastest way to get back to the previous app; there are more proper ways to do it (save the current app and then go back to it), but they are slower and require more code and more changes to the Workflow.

Alfred has excellent documentation. For your daily sites Workflow, you’d connect a List Filter Input to an Open URL Action. To open apps should be similar, depending on exactly what you need.

Welcome @juanfal, That’s a very specific feature to fill a very specific need which seldom arises. Each of the connections you want takes seconds to create. You can further speed it up by copy and pasting Workflow objects and editing the parts you need. Tip: don’t create multiple Workflows for it, keep them in the same one.

I see the usefulness in muting your microphone from a Hotkey, as it’s a way that should work universally across apps. I’d be wary of calling it a way to take control of one’s privacy, though. Just like the Workflow can unmute the microphone programmatically, so can anyone else, which means muting it doesn’t offer any protection against those who are shady.

Update. It now also works on embedded YouTube players. Download the latest version.

Then please continue the conversation in that thread, because it’s the one tracking that issue. Remember to reference what you did exactly so it can be followed up; the thread has multiple solutions which worked for different people.

If you’ve used Migration Assistant, follow the link I posted above.

Apple certainly means to scare you when you enable the option: Which is true. And it’s why I don’t provide warnings in the Workflow, since the browsers do it themselves. Activating the option means your browser can be controlled programatically, which is the only way this Workflow can work but it also means it opens the gates to other tools. I never heard of malware which did anything via this route, which isn’t to say it couldn’t be built. Standard care about which tools you tend to run apply.