Andrew

@saor47 I've seen a few cases of this over the past 6 months (after years of no problems). As part of the performance and efficiency improvements in the future 5.1 release, I've already preempted this as an issue and moved discovering the ejectable drives off of the main thread.

I'll actually be adding the ability to sort workflows by Gallery Updates in the next release  

This is in the plan

Depends on what you mean with “external”. If you mean external to the workflow itself, stored somewhere else on your hard drive, then that complicates sharing because you’ll need to make sure users also have that.
 
But if you just mean external to the Script box and ship the script inside the workflow’s folder, then it’ll work fine. Speed-wise it may technically be even a bit faster, though in practical terms the difference is so small you’ll never notice. When exporting it’ll just be the extra file inside the Workflow’s folder, which is good in the sense that it’s easier to edit and version control. It’s mostly a preference thing.
 
Combining both gives you extra flexibility, like doing a check for certain things in the Script box which then calls the correct script or the correct arguments.

Before I provide a bit more info, please trust that in creating Alfred, I have an intimate understanding of macOS performance, and the focus areas to prevent load on your system. There is only so much of this I can impart casually on a forum.
 
 
In asking this, I request you re-read my paragraph on raw vs promised data.
 
Internally, the Screenshot app will be dealing with raw TIFF data. It provides TIFF data and PNG data types in the clipboard, but to prevent load on your system, the PNG type will be promised. This means that the conversion to PNG happens when an app requests to USE the data, not at the point of capturing. This deferment is a magical feature of macOS which helps with the snappy nature and lower load.
 
When you paste the screenshot into e.g. Messages, messages will prefer the PNG data (as that's better to send over a network), so it asks the pasteboard for the PNG promised data, and internally, this conversion happens at that point in time.
 
If Alfred were to ask for every PNG promise when it sees it in the clipboard (from any app), then this conversion to PNG is forced for every single image copied to the clipboard, essentially undoing the magic work Apple put in place with promised data in the first place, and ultimately leading to a higher load on your system.
 
TLDR: By making Alfred work with the raw TIFF data, this is zero load on your system. Adding the option to convert to PNG on use means you'll get the conversion happening at the point of use, just like the Screenshot app will be doing.
 
Cheers,
Andrew

Before I provide a bit more info, please trust that in creating Alfred, I have an intimate understanding of macOS performance, and the focus areas to prevent load on your system. There is only so much of this I can impart casually on a forum.
 
 
In asking this, I request you re-read my paragraph on raw vs promised data.
 
Internally, the Screenshot app will be dealing with raw TIFF data. It provides TIFF data and PNG data types in the clipboard, but to prevent load on your system, the PNG type will be promised. This means that the conversion to PNG happens when an app requests to USE the data, not at the point of capturing. This deferment is a magical feature of macOS which helps with the snappy nature and lower load.
 
When you paste the screenshot into e.g. Messages, messages will prefer the PNG data (as that's better to send over a network), so it asks the pasteboard for the PNG promised data, and internally, this conversion happens at that point in time.
 
If Alfred were to ask for every PNG promise when it sees it in the clipboard (from any app), then this conversion to PNG is forced for every single image copied to the clipboard, essentially undoing the magic work Apple put in place with promised data in the first place, and ultimately leading to a higher load on your system.
 
TLDR: By making Alfred work with the raw TIFF data, this is zero load on your system. Adding the option to convert to PNG on use means you'll get the conversion happening at the point of use, just like the Screenshot app will be doing.
 
Cheers,
Andrew

Alfred using tiff is for historic compatibility reasons (as this is raw image data which is given to Alfred in the clipboard).
 
I'll add an internal ticket to investigate if improvements can be made in this area

@Karl87 I had slowed it down a little, and now it's pretty similar to double clicking the mouse.
 
For merging, are you holding the cmd key, then tapping C twice? You have to be quite slow to not get a merge.
 
Cheers,
Andrew

Blanket syncing your clipboard doesn't fit within Alfred's lightweight and secure ethos. While the reasons are numerous, I'll outline the main 2 here.
You use copy and paste much more than you may think. This means that every single time you use ⌘C, that block of text, image, or file would be sent over the network to wherever your sync is set to. This would not only use lots of network bandwidth, but significantly increase Alfred's "idle" CPU usage. The security implications are quite significant. You will, on more than one occasion, copy some private information. This means that the synced clipboard data would need to be made secure, as it's not ok to rely on the syncing service's encryption to keep this safe (non-end-to-end syncing services, even if "encrypting", maintain the private keys to your data). By Alfred encrypting the clipboard data, this makes general use significantly more bloated and slower. Alfred's Snippets can be synced because this is a user instigated action. You can choose what to store as a snippet and you can decide to sync snippets. This means you won't accidentally copy your most valuable password into the cloud.
 
Cheers,
Andrew

This is along the lines of the fix we are going to make in the short term  

@Afoan This is the Universal Actions panel you're seeing. You can disable the shortcut keys to activate this (including what I think you're referring to - the Tab key) in Alfred Preferences's Features > Universal Actions > Show Actions.

@juanra Alfred already has this in Alfred 4. Simply select a different Alfred theme when macOS is in Light / Dark modes and Alfred will remember.

@xilopaint yep

@xilopaint Vitor coordinated the updates over the weekend, and I just rolled them out, so you should see 1.4.1 now.

Yep, this is the intention. You can currently share themes to our main site, but I wanted to create a new system instead of migrating over the legacy system. I can't give timescales on when this will happen though.

The start of this process is happening here:
https://www.alfredforum.com/topic/19058-submitting-workflows-for-the-alfred-gallery/
 
It's also worth noting that when workflows are submitted for inclusion in the gallery, we help developers tweak and fix things like this with either simple guidance, or Github PRs.
 
 
All workflows you download from the gallery are hosted by us. Self-hosted workflows (e.g. a Github release) are automatically picked up by our backend system for review, then signed and re-hosted by us. Once the Gallery is out of Early Access, you should always see nice clean readmes.

The start of this process is happening here:
https://www.alfredforum.com/topic/19058-submitting-workflows-for-the-alfred-gallery/
 
It's also worth noting that when workflows are submitted for inclusion in the gallery, we help developers tweak and fix things like this with either simple guidance, or Github PRs.
 
 
All workflows you download from the gallery are hosted by us. Self-hosted workflows (e.g. a Github release) are automatically picked up by our backend system for review, then signed and re-hosted by us. Once the Gallery is out of Early Access, you should always see nice clean readmes.

The start of this process is happening here:
https://www.alfredforum.com/topic/19058-submitting-workflows-for-the-alfred-gallery/
 
It's also worth noting that when workflows are submitted for inclusion in the gallery, we help developers tweak and fix things like this with either simple guidance, or Github PRs.
 
 
All workflows you download from the gallery are hosted by us. Self-hosted workflows (e.g. a Github release) are automatically picked up by our backend system for review, then signed and re-hosted by us. Once the Gallery is out of Early Access, you should always see nice clean readmes.

Yep, this is the intention. You can currently share themes to our main site, but I wanted to create a new system instead of migrating over the legacy system. I can't give timescales on when this will happen though.

Oh gosh! Honestly. You guys have really really outdone yourselves with Alfred Gallery. This thing utterly rocks. The integration with the workflow GUI is just stellar. Old workflows that are available show an upgrade, existing ones that are up-to-date with that cool little comet icon. One place to check for update. Resolve dependencies. 😍
 
I am just ever so slightly missing some filtered lists on the web page like "New" / "Updated" / "Popular, but I expect they will come with time. 
 
A huge, stellar enthusiastic thumbs up 👍

Thanks for spotting this Chris, easy to reproduce and surprised it hasn't been spotted sooner!
 
I'll have this fixed in the next build
 
Cheers,
Andrew

@giovanni This is an interesting spot and something @vitor and I have been discussing in the past month. I have an internal ticket to look into what is a workable solution for this.

@Andrew In 5.0.5 [2096] this issue is fixed. Thank you so much!

I just wanted to drop in a note of thanks in here. I’ve been using Alfred since v1 and I can’t imagine not having this software in my day to day at this point. It has been exciting to see the energy here after the release of v5. @vitor @Veroand other folks here have helped me solve workflow puzzles and helped walk me through some basic scripting. Thanks to Alfred, I’ve learned a ton.
 
Thanks for continuing to make and wonderful piece of software that I'm currently using 59.4 times a day since 2018. Bummed I lost my pre 2018 stats in a computer migration:
 

This is actually a bug in the Spotlight window not correctly releasing the keyboard input focus when a floating panel is shown over it. Alfred is a floating panel instead of a traditional window, and this confuses Spotlight.
 
One workaround is to set Alfred's Appearance > Options > Focusing to compatibility mode, which makes the Alfred window act more like a traditional window, and this doesn't seem to "break" Spotlight.
 
Having said that, I'd recommend leaving Alfred in the floating panel mode as this is the least intrusive overlay for other apps and their focus behaviour. Just disable the Spotlight hotkey in the System Preferences > Keyboard > Shortcuts, or set it to a very obscure key if you're coming across this issue.