gingerbeardman

Understood, thanks!

Any plans to add support for Temp Mail? https://temp-mail.org/en/

Late reply, but I just asked this question again and then remembered I had asked it before...

I just set up a File Filter with a single character keyword and scoped to my Projects folder.

We'll see how I get on with it.

It's the first time this has ever happened.

Happy to ignore.

Features > Clipboard History > Advanced > Auto-paste on return

Stopped doing what it should all of a sudden in 5.5 [2257]

I restarted Alfred and it started working again.

This is a first for me.

This seems really useful.

Is there any chance we can add a custom directory? For decades now all my screenshots are sorted into daily folders in my downloads folder.

So, I would set it to search Downloads (and sub folders) instead of Desktop.

Here's my parallel version, execution time is 0.58s

https://gist.github.com/gingerbeardman/ff346ea8e2704c316682df4f6ea47237

Thanks! rq now takes 1.5 seconds on my machine.

I guess a parallelised version might be even quicker? Of course, it's not necessary at this point but perhaps would be a fun exercise to realise an approach that might be able to be applied to other workflows.

Cheers

Oh, good catch. I see /opt/homebrew/bin/xattr

And I have no idea why

I was almost done parallelising and the run time had reduced from 23 seconds to 3.5 seconds

Thanks so much!

I think there are some crossed wires in this, so let me summarise:

• workflow used to be very fast almost instant
• at some point it has become slow (Sonoma? I came straight from Monterey)
• I'm using only the option "Only show apps in /Applications"
• the mdfind part is instant (I mistakenly said mds earlier, sorry) ~1000 apps reported in a fraction of a second
• the slow part is the xattr call which is taking 0.023 seconds per app on my machine, which for 1000 apps is the ~23 seconds

So I'm going to look into parallel-ising the xattr loop.

That works, it took 27 seconds to find 57 of 986 apps. I'm not sure I ever gave the old version that long, as it used to take only a few seconds at most before something changed.

Logging grows by ~40 lines per second on my machine, which feels slow. Nothing untoward in there, apps listed are as expected.

I notice that when you close the alfred window the mds command keeps running. So if I invoke rq multiple times (for example when I think it's not working, oops) then there will be multiple scans happening at once. Can that be avoided?

The mdfind is aspect is pretty much instant, as confirmed on the command line. So the slow bit is the checking? Which is surprising. Maybe the use of osascript for the app_as_json function is slow?

[10:56:48.804] Logging Started...
[10:56:49.913] Remove Quarantine[Script Filter] Queuing argument '(null)'
[10:56:50.440] Remove Quarantine[Script Filter] Queuing argument '(null)'
[10:57:15.225] Remove Quarantine[Script Filter] Script with argv '(null)' finished
[10:57:15.232] Remove Quarantine[Script Filter] { "items": [{"title":"prima","subtitle":"/Applications/...

I mean that I only turned on "ignore" after things stopped working, no results shown, to see if it helped.

So I turned it off and there are still no results showing.

I know for certain I have some apps that should be found.

Sorry I totally missed the notification for this reply. No idea how.

I think the above download has expired.

I have both "only /Applications" (since you added it for me) and "Ignore signed/notarised" on (since the workflow stopped working).

I think maybe it stopped working when I upgraded from Monterey to Sonoma. I skipped Ventura.

Nothing showing in debug log of Alfred for the existing version.

Another link with more info on Settings deep URLs

https://gist.github.com/dvessel/2b6ad97b2da16d445671b39618221aab

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".

The workaround I've settled on for this is to make macOS treat the non-retina display as retina, by forcing the Scale to be 2x (rather than 1x).

There are pros and cons to this approach, but it solves many visual problems so I'd say "it works for me". YMMV

https://blog.gingerbeardman.com/2024/01/25/running-modern-macos-on-non-retina-displays/

This is really great.

One question: is it possible to give results from this workflow preference over all other results?

This is really useful, thanks!

Any chance to be able to configure so that HEX values are returned as 0xAB rather than AB?

There might be similar prefix for Octal, but I don't know it

I just upgraded to Sonoma and this is no longer working for me.

I have it set to only look in /Applications

But it just sits at "Finding qunarantined apps..."

Log says:

[21:53:18.717] Logging Started...
[21:53:19.702] Remove Quarantine[Script Filter] Queuing argument '(null)'
 

Any ideas?

I've also submitted feedback. via feedback link and feedback assistant. FB13536508

The reason I tried disabling is because on non-retina displays (i use an external display of 1920x1200 as my main display) the new cursor is twice as wide as it is on my laptop retina display. This means it's mistakable for a selected space character and it also obscures neighbouring text. 

@Hedgehog your genius hammerspoon workaround is fantastic - using it for Alfred and Ulysses. Cheers!

Since 2023.2 this is really slow to list results for me (~6 seconds every time).

It used to be pretty much instant.

It also now lists results that aren't really Mac apps.

Can I limit it to /Applications folder (and its subfolders)?

edit: I spent some time removing quarantine from all search results. now it's quicker, but i'd still like to limit to /Applications

I recently updated from 4.0.2 to 4.0.5 and also didn't get any error saying my API key was missing. I was previously using a key for the service that was removed. 
 

Anyway, it's easily solved but was very annoying to waste time fixing what was already working. 
 

I'll try to find time to file a PR to fix the issue. 
 

OK, it is a curious one!

A quick google of the exception in the crash report gives this:

https://developer.apple.com/forums/thread/696460

which has an answer from Quinn “The Eskimo!” that leads here: https://developer.apple.com/documentation/security/updating_mac_software

The crash report from Console is already at the pastebin link above  but i've emailed it just now.

Original filename was: Alfred-2023-09-28-133239.ips

I'll stay on this version to see if it happens again. No worries.