Andrew

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

@natebeaty @deanishe thanks! this is some indispensable info which should help me get to a solution

@deanishe sent you a PM.

@deanishe which part is timing out? Seeing the change log in the update tab, or the actual update? The first part is hosted on our website, the second on cachefly - both should be lightening fast. If it's the download, what do you see for this: http://cachefly.alfredapp.com/testcdn.txt

@deanishe thanks for spotting - just fixed this if you update to b849 pre-release

@vitor I used the comma is because the middle of that sentence is optional... i.e. "To run a command without Terminal, use a Run Script action.". Anywhoooo, not spending any more time on this (well, apart from fixing the pre-release broken resizing of that config sheet)

Here we go:

@deanishe it does say that in the very last subtext - I'll break that out to a separate paragraph.

@vitor I'm reluctant to add niche features to Alfred, keeping him away from bloat. I'll keep this as a note for future consideration, but it may come in the form of adding a tick box in the Open File action, which means you'd still need to create a workflow of sorts.

Good idea...

I'll tweak that a little for clarity before release

@deanishe My script filter was just hard code returning {"items": []}

@deanishe one of my notes in the ticket is for more granular logging levels. I specifically wrote to make the Script Filter JSON/XML output as finest (i.e. least important), as while messing about with the screenshot above, I ended up making the output empty so I could actually see if things were going on

@deanishe I've added in a few extra bits of debugger output to the script filter for the next release, so now you see the argument being queued (which can stack up depending on the selected queue mode), and the argument used with relation to the script output (the actual argument used when running the script). I've also added a ticket to look at improving the debugger generally, increased info etc. Cheers, Andrew