Andrew

@nikivi touch will update the last used timestamp: https://ss64.com/osx/touch.html To get the built-in troubleshooting to work, temporarily add the AddressBook/Sources/ folder to your default search scope.

@nikivi the metadata tool is no longer used, it was superseded by the built-in file troubleshooting within Alfred's help preferences. The metadata tool itself has no intrinsic link to Alfred, it's a completely independent app, and I suspect just the act of opening the file is causing macOS to update the last used metadata flag, which is fixing the single metadata record in your broken index. You might find that creating a script to touch, open, or mdls each of those files will have exactly the same effect.

I'm moving this out of the bug forum

@nikivi Alfred is given the type to add by macOS, he doesn't make it up himself. Whatever type is given to Alfred by macOS is added to that File Types: field, so if your metadata is broken, and macOS is giving Alfred nothing, or something bogus, Alfred has no way of determining that this is correct or incorrect.

What would you consider a bug? I don't see anything wrong in the screenshots you've posted.

@chris this should now be fixed in the Alfred 4.3 b1195 pre-release

[Original reply from when this was posted as a Bug Report] @nikivi If you've been messing with your metadata and it's gone from working to not working, without any changes in Alfred, there is unlikely to be a bug in Alfred. For due-diligence, I have taken the time to create a workflow to reproduce the bug you've reported, and everything is working as expected in macOS 11.0.1. Contacts are indeed parsed correctly.

@chris the borders is something I'm aware of and something I'll have to _simulate_ in the theme editor. Up until now, Alfred uses the same renderer for the theme editor as the actual window, but macOS adds those window borders when you set a visual effect view as the content view of an NSWindow. In the theme editor, I'm using the visual effects view, but as a view, so macOS doesn't render the borders. I'm in two minds whether to either simulate it, or just add a note saying that macOS may add a border depending on configuration. I'll add a note about the roundness on th

Hey Chris - I noticed this too. Looks like there is a bug in macOS Big Sur when in non-retina which resizes images without interpolation too. I'm going to see if there is a workaround in the standard components, otherwise I'll create a small custom component which draws these images properly. Cheers, Andrew

If you update to the 4.3 b1193 pre-release, this should now be fixed

I'll update the pre-release later today with a fix for this, it's caused by essentially what I described above.

Note, if you haven't seen the upcoming 4.3 changes on theming, take a look here:

I haven't looked into this deeply yet, but I imagine what is happening (due to the enhancements in Alfred's window config in 4.3 pre-release) is Alfred is internally getting the "current theme" before it's dark mode internal helper is setup. As such, Alfred might have been showing you e.g. the selected light mode theme for your current dark mode. Out of interest, are you both in dark mode?

@vitor interesting spot, this is actually something which I can very easily fix with the new URL helper methods I'm working on. I'll have this fixed in the next build, thanks!

Just to let you know, I'm working on new theming options which will allow for rounded corners and also to use the native macOS Visual Effect view (the blur effect you get in Spotlight and various windows around macOS). A side effect of the using this native view type is getting proper window surround, and no fuzzy corners. Here is an example: