Andrew

@Obbut perfect thanks, I'll tweak the default themes to take that into account so less people experience this issue.

@marlabs The Script Filter is for populating results into Alfred, and as such, a specific JSON output is expected. https://www.alfredapp.com/help/workflows/inputs/script-filter/ You can get an example to get you started from the + button bottom left of the workflow preferences, select "Getting Started > Script Filter" which will give you a working example. Cheers, Andrew

@Obbut any help with this is appreciated... Could you let me know if there is a threshold of theme blur which this is introduced? Or wether any (tiny) level of theme blur also has an issue. Also, if you switch to the high performance graphics card on your MBP (untick automatic graphics switching in energy saver prefs), do you still see the issue? Cheers, Andrew

@runelind I'd be interested in finding out if a PRAM reset fixes the issues too, seeing as people are complaining about the Iris 6100 performance here and people say PRAM reset fixes it in some cases: https://forums.macrumors.com/threads/2015-macbook-pros-intel-iris-6100-is-so-choppy-in-yosemite.1857649/

Yeah this is bizarre, and almost certainly a macOS graphics driver bug relating to newer MacBook Pros. Alfred uses native blurring on the main window, and there is faultless performance with any blur level on my old test Mac Mini mid-2010 with macOS 10.13 beta installed. If this isn't fixed by Apple, I'll possibly remove blurring from the default themes to prevent confusion.

At this point, my macOS 10.13 test machine isn't indexing Safari bookmarks at all (i.e. Spotlight isn't seeing them). If macOS were to be indexing bookmarks, I suspect they may just be in a different location which needs to be added to Alfred's default search scope.

This is now sorted in the 3.4.1 b858 pre-release

This is now sorted in the 3.4.1 b858 pre-release

@Jasondm007 You should just be able to use F5 and F6. As the Apple Keyboard doesn't have additional functions assigned to these keys, don't hold the fn key, just use the F5 or F6 key by itself.

The icon staying in the dock (for the first time you setup Text Expansion) was a quirk introduced in a previous build. I've actually fixed this for 3.4.1. If you disable and re-enabled text expansion after it's setup, it won't be in the dock. Cheers, Andrew

@BrianGilbert_ Doh sorry, I didn't see that you offered the new path (as I had just replied to a couple of identical emails for ScreenSaver). I'll get this fixed in the next pre-release Andrew

@BrianGilbert_ I'm currently looking to see if there is a new way to start the screensaver, if I can't find one, I'll raise an Apple DTS

@samdale67 Are you seeing the bookmarks in Spotlight? There is a good chance they have just not been indexed yet.

@xavdid Further to this, I've just installed macOS High Sierra 10.13 Beta on my very old Mac Mini (Intel c2d mid 2010) and blur is working extremely smoothly. This suggests that it could be a driver bug for your Mac spec, OR that macOS High Sierra has significantly improved graphics performance.

@xavdid As it's a new laptop model, it may very well be a driver bug in macOS for your integrated graphics card. The blur works fine on my MacBook and my 2012 development iMac. I'm sure if you switched to the non-integrated graphics on your MBP, it would also be smooth.

@mescalito This issue has come about since this report: I'm going to add in an option next to the Ignore Types for including or excluding concealed types in the history, enabled by default. This will allow you to return to the previous behaviour Cheers, Andrew

@deanishe Alfred's result view architecturally has no concept of workflows or where actual results have come from. When you perform a cmd+c, add to the buffer, or navigate into a folder for the selected result etc, Alfred understands that a result arg has been marked as a file (from any source, not just script filters), and file interactions are made available. When, in your script filter, you mark the result arg as a file, you are telling Alfred's result view that the argument you have provided is a file, and thus make the file interactions available. Results shown in Alfred are unprocessed, the arg is just a dumb string. This is where the high performance comes in, as Alfred doesn't need to process any of the args BECAUSE of the 'type' defining a result arg as a file. Don't forget that the JSON you are setting in the arg is {"alfredworkflow":...}. It is specifically processed when a result is actioned for the connected outputs in for the workflow, which is why you are seeing it unprocessed when using non-workflow file interactions from Alfred's default results. I can totally appreciate your point of view, but as I've said, the 'type' was added to define the type of the 'arg', and this is a strict relationship to allow Alfred's result view (unaware of workflows), to process the provided arg appropriately. There are a few ways for this to be fixed: 1. I'll almost certainly be adding variables for each item in the JSON, which is the correct way to address this issue. 2. Adding a new item 'type' which is something like 'JSON containing a File arg'. This would allow the Script Filter to identify and pre-process items into Results differently. It's unlikely that this would be prioritised above other features. Remember that there is a holistic aspect to look at when it comes to Alfred, where performance is absolute key and a huge priority for me. You've spotted a limitation of the JSON / XML which is the result of an absolute design decision which has just come up for the first time. I'd rather fix this properly than alter architectural design for a less than 1% workflow specific use case.

@deanishe this isn't a bug as you are setting the arg type as file, and then passing JSON as the arg. This is a strict mapping as knowing that a result is a file has a number of behavioural differences for a specific result row (display, navigation, actions, accessibility). Alfred doesn't process any result arguments until they are selected and passed out of the workflow object, at which point, the workflow framework takes care of recognising and processing the output. This is important from a performance standpoint and it also ensures that outputs from all object types are processed in the same way. The fact that you can't set the type as file, AND dynamically set variables by passing JSON out of the argument is a limitation of the Script Filter JSON/XML design. I've raised a ticket to have a look at this, but it will likely be by adding in variables for each item. I've also joined it to my other improvements tickets in this area which will likely be dealt with at the same time (e.g. different icons for mods). Cheers, Andrew

@deanishe if you set type as file, then Alfred expects a file in the arg and will check if that file exists before treating it as a file. It's interesting seeing how you are setting variables per item there by essentially passing JSON as the arg. Makes me think that there is a case to have a "variables" field per item so that you can continue to use the arg for the actual argument, making this scenario work as expected. (Assuming you specifically want vars only set for this one result, and not globally for the script output, which would be done in the variables field). You can actually set the type to "file:skipcheck" to get Alfred to skip the existence check, but I'm not sure the file actions panel will work with JSON as the arg (not currently at my Mac to check this). Cheers, Andrew

@DanJ if you do manage to reproduce this, please do let me know as this hasn't come up before.

@DanJ hm very strange - the results are only ever updated on the event thread which would avoid race conditions, and symbolicating this stack gives me very little information as to why this is happening. I'll add some additional debugging in to see if there is ever a situation where something is being updated asynchronously when it shouldn't be. Cheers, Andrew

@nikivi Hmm odd - But I'm not able to reproduce this. Would it be possible for you to share a super simple workflow with just the list filter in it exhibiting this issue so I can see it happening here? Cheers, Andrew

@vitor the clipboard history can ONLY search by content as you don't assign keywords or titles to items like you do with snippets. When searching the clipboard history, snippets are shown before clipboard history items. When playing with this and making snippets match much wider, you got snippets almost always showing above clipboard history items when you didn't want them to be there.

When this was first highlighted a while back, I did some basic research around performance and noise, and found it made the clipboard viewer quite a bit less useful for getting to your clipboard history results as you regularly saw unwanted snippets placed above history items. This is essentially why I kept snippets to keyword and title (think of the title as a kind of metadata or tags field which is also searched), which keeps the history search much more useful. While I'll unlikely change the clipboard viewer behaviour, I do have two new workflow objects planned - a Snippet Filter and Clipboard Filter, both of which will be decently configurable and will allow for both getting to snippets via their content, and also workflow based processing of these items. Cheers, Andrew

@Keven the .alfredpreferences package within the Alfred 3 application support folder will be one left there at the point of setting up sync. Alfred doesn't delete this in case the initial relocation of the preferences goes horribly wrong. It's fine for you to delete this file if you have your sync folder set elsewhere.