Andrew

Just to add to this, the Browse in Alfred object is able to veto the automatic closing of the File Filter action if it is directly connected, but when there are objects between, you need to specify the behaviour in the connection configuration.

It stacks on the currently visible window, so you need to make sure the Alfred window is visible. To do this, edit the connection after the filter and set it to not close the window after actioning. You'll get a square instead of a circle on the connection. The above is an example with a 1 second delay object added just to test the stacking works ok.

Fair point, I'm gonna have a bit of a play with this to see what's possible without it feeling janky

I'd be extremely surprised if there were any of knowing that macOS is about to show a permissions dialog, as this thing is usually completely opaque in macOS. The built-in copy/move/delete actions are telling Finder to move these files, so one option could be to make Finder active before doing this, but that is possibly not desired for when the elevations of permissions isn't required as it'll defocus the current app. This is a interesting conundrum to fix robustly, with future proofing, and not fudging. I'll have a think about what can be done.

@ahecht this sounds like a hotkey conflict, usually caused with ⌘Space. If you're using ⌘Space, you'll need to disable all the related items on this page: https://www.alfredapp.com/help/troubleshooting/cmd-space/

Thanks for the feedback, I sometimes add options into workflows first to see how well they are received, and how well they work. I already have a note to bring this same option from the Browse in Alfred to the default navigation options, but at this point, it will likely remain a simple checkbox to keep this complexity of understanding this feature low. Cheers, Andrew

Thanks for the samples, in every case, it appears that the underlying macOS Contacts API has failed. It was also reported by email that launching the Contacts or Email apps also caused them to hang. While this method shouldn't block Alfred, I am going to look into moving this contacts access check off of the main thread at startup so even if the underlying API does break or hang, it shouldn't hold you up from using Alfred, even if contacts won't be visible. Cheers, Andrew

I'm on Big Sur 11.2.1 and things are working fine, so I'm not sure what could be happening on your Mac. Could you please open Activity Monitor, select Alfred and then Sample Process as I'd like to see what's holding Alfred up. If you could email that to our info@ address and I'll take a look tomorrow morning (it's 23:30 here right now). You can grab Alfred 4.3.1 b1214 here: https://cachefly.alfredapp.com/Alfred_4.3.1_1214.dmg Thanks, Andrew

If you select some text in Alfred's input box (e.g some of your calculation) it will copy that text rather than the selected results in Alfred, which is causing the close. Alternatively you could get Alfred to re-show the last typed history, so your calculation will still be in Alfred when you re-show him: https://www.alfredapp.com/blog/tips-and-tricks/quick-tip-view-your-recent-query-history/

Hmm, you're probably right actually. @rxstuve Also try using Alfred's built-in file troubleshooter which may give more indication into what's going on: https://www.alfredapp.com/help/troubleshooting/indexing/

The external drive still needs to be indexed by macOS if you'd like file search results on this drive. Make sure this drive isn't listed in Spotlight's Privacy prefs, then in Terminal, check the indexing status of this drive by typing the following: mdutil -s /Volumes/name-of-your-external-volume If indexing is enabled on this drive, adding the volume to Alfred's default search scope should be all you need to do. Alternatively, if it's just apps you'd like to launch from this drive without indexing enabled, there are a few ways you could achieve this. The most

@vitor should /usr/local/Cellar remain, or be removed too?

Alfred is primarily designed with keyboard and type-ahead filtering in mind, the input focus is always in the search / filter field, and the expectation is that you can always type a few characters to filter down the list of results to just the relevant items. Even in your example animated image in the original post, it looks really inefficient scrolling to find something - if this workflow has been correctly designed, typing a few more characters will present you with the most relevant results, negating the need to scroll. That's why this is an indicator rather than a functional s

I'm moving this to feature suggestions as this isn't a macOS scroll bar, it's a non-interactive theme-able scroll indicator. If you want it wider, you can make it wider in the theme editor. The indicator has actually been like this for the past decade, so I'm not going to treat it as a bug. Having said that, there is an argument for giving it a minimum vertical size cap, even though this reduces the actual usefulness (as it currently shows quite how many results there are).

@obadiahcruz take a look at the following forum post. In Big Sur, you'll need to either select one of the visual effect views (which will give a native background), or remove the blur from your theme to avoid the types of corners you're experiencing. The issue is discussed in more details here: