vitor

This is simple enough and looks quite ready to go in the Gallery, but I have a few suggestions:
You don’t need the Run Script, you can and should instead use the Run Shortcut automation. That would make it use no code and be a good candidate for the “Good for Learning” category. Would be useful to add a Hotkey Trigger too. I can imagine someone using e.g. ⌘⇧6 to take the screenshot and get the text. By the way: nice use of the Automation Task.

Thank you for the kind words.
 
Updated to 2023.6.
Tweaked icon. Show dialog when requiring screen recording permissions. Ignore extra windows created by Stage Manager.

The last point should fix your case, @jr5.

This is simple enough and looks quite ready to go in the Gallery, but I have a few suggestions:
You don’t need the Run Script, you can and should instead use the Run Shortcut automation. That would make it use no code and be a good candidate for the “Good for Learning” category. Would be useful to add a Hotkey Trigger too. I can imagine someone using e.g. ⌘⇧6 to take the screenshot and get the text. By the way: nice use of the Automation Task.

Signature looks correct, but you also need to notarise it otherwise there’s going to be a dialog about how Apple wasn’t able to scan it for malicious software and it won’t run.
 
First set up your credentials:
 
/usr/bin/xcrun notarytool store-credentials --apple-id 'YOUR EMAIL' --team-id 'YOUR TEAM ID'  
To notarise a raw binary, first zip it then use notarytool on the zip:
 
/usr/bin/xcrun notarytool submit '/PATH/TO/THE/ZIP' --keychain-profile 'PROFILE NAME SET WITH store-screndials' --wait  
After it returns successfully you can trash the zip, it’s only necessary to send it over. From then on, the first time a user runs your binary it’ll contact Apple’s servers to verify the notarisation then keep the information locally.
 
If you use Xcode, there should be a flow for notarising without having to leave it.

Welcome @Patrick Graf,
 
Seems like you’re looking for the Script Filter Input. You’ll be able to take whatever is input in Alfred, then do your calculations and return some JSON which will show up in Alfred.

I don’t know the exact timeline, but at least some of the options have been available at least since Monterey.

I didn't realize that. I learn something new everyday! And even just a few years ago I don't think I would have been able to build something like this thanks in part to this forum.
 
 
Not for the screen shot, but I like to be able to see the entire flow at a glance if possible. I have 2 x 27" displays and I like to see it all on one. If don't have to scroll, I choose not to scroll!!!!
 

you can also drag and drop from alfred into the dialog box

It is a little slow as I have some delays from debugging that I want to play with removing but this is the back end if you are curious:



 

 
na is the CLI tool that brett terpstra wrote to write to taskpaper files but i also mirrored it in plain text files using alfred's write to text file -- which is also useful

That was fun to watch, thank you for sharing the result!

@vitor look at the fruits of your labor:

Performance doesn’t just mean speed. You cannot fairly compare the resource usage of apps which are continually running in the background and gathering information to a single binary that must launch, execute, and exit in a fraction of a second. It’s different tradeoffs (like almost everything in computing) and Window Switcher is designed to be fast and consume effectively nothing, especially when you’re not using it.
 
In addition, you’re focusing on one third of the given reasons and not the right one. That post does not say hidden windows specifically cause performance issues. Every one of the tools we’re talking about has a different interface and objectives.
 
It’s worth noting the code is open-source, which allows anyone to pick it up and tweak it to their needs. There are also other window changing workflows which may behave in other ways. Different people have different preferences and value different things. There is a strong core of users who like the workflow exactly as it is, and it’s important to not ignore that.

Quick note: If you want the full path, you don’t even need the Automation Task, you can connect the Universal Action directly to the Copy to Clipboard.

Considering your last post, you might want a File Filter instead of a Universal Action.

I highly recommend you go through the interactive guide, as linked above. It’ll teach you the basics and help you to figure out how to figure out these details.

Thanks, that's fine, they have started rising to the top as I've been using them.
 
This is a great source of these deep urls: https://gist.github.com/rmcdongit/f66ff91e0dad78d4d6346a75ded4b751 just in case there are any "missing".

Sorry for the delayed response.
This sounds like your Mac has problems executing the Swift script.

Have you installed the Workflow from the Gallery (https://alfred.app/workflows/tobiasmende/audio-switcher/) or from the forum?

I thought the requirements are pre-installed in the modern Mac versions, but maybe some requirement is missing. This might be solved by running `xcode-select --install` on the command line.

This is vey much untested (I have neither Pro Tools nor a keyboard with numpad), but what I was suggesting was something like:
 
const systemEvents = Application("System Events") const keycodeNumpadMap = { "0": 82, "1": 83, "2": 84, "3": 85, "4": 86, "5": 87, "6": 88, "7": 89, "8": 91, "9": 92, ".": 65 } function run(argv) { argv[0].split("").forEach(character => { systemEvents.keyCode(keycodeNumpadMap[character]) }) systemEvents.keyCode(76) }  
This is using /usr/bin/osascript (JavaScript).

Should also be worth considering joining both workflows together for the next version, so people only have to install one. Or (I just thought of this while writing the previous sentence) even having a Script Filter that both shows the battery and allows for connecting and disconnecting (you shouldn’t be able to know battery levels anyway when AirPods are disconnected, I’d guess).

If you have an alternative icon, that would be helpful to further differentiate from the other AirPods workflow too. It surprised me a bit when I downloaded the Connector yesterday, as the icon in the notification was different from the one in the workflow.

Thanks and apologies - I’m new here and didn’t know that there was such a thing.

good point. and very fair. thanks for the info.
 
 
well that was making sense for me to bundle it in the Workflow when it was only available from me and through GitHub, so that users had nothing to think about. but with the Gallery uniforming the Workflows installs, maybe users will get used to those notice about having to install the dependencies or that some dependencies are already bundled. so that changes things a bit and i'll have to rethink what's the best now. will depend on what i plan for the future, but my first feel is that the Gallery is the first place to go for Workflows, so that will influence my choice quite strongly. thank you! those notices are super welcomed.
 
 
ha excellent, thank you again! haven't touched those Workflows for a while and moved quickly onto other things. so great new knowledge. will digest, and most probably end up updating the Workflow. thank you again Vitor!

Not exactly, as the workflow already used Python 3, only the path changed so everyone’s on the same version. That break sometimes happens after a macOS update.

@vitor looks like it was fixed in the latest version of Orion RC. Sorry for the trouble!

Not exactly, as the workflow already used Python 3, only the path changed so everyone’s on the same version. That break sometimes happens after a macOS update.

just wanted to say that Alfred is amazing! super quality build, precisely customizable, and my absolute daily driver for everything. amazing app, thank you!

@Tee Elem See how to use the debugger.

Also @rdjfraser, make sure you’re using the fork by @giovanni and not the original by Dean. Same for the other thread.
 
Use the versions in the Gallery for both.