Andrew

@nikivi I've also been unable to reproduce this - is Alfred correctly learning in other features?

@GuiB I have actually addressed this recently after this thread:
 
https://www.alfredforum.com/topic/10427-typefile-is-ignored-when-variables-are-also-set-changes-made-for-341-b858-pre-release/
 
You can now simply add variables per item, for example (using your workflow):
 
Second item in your list: { 'title': "Desktop", 'subtitle': "By setting env var = file action doesn't work", 'type': "file", 'arg': "~/Desktop", 'variables': { 'varName': "varValue" }, 'icon': { "type": "fileicon", "path": "~/Desktop" } } I did update the documentation, but didn't make a big deal about highlighting it:
 
https://www.alfredapp.com/help/workflows/inputs/script-filter/json/#variables
 
Let me know if you have any problems with this
 
Cheers,
Andrew

@kballard the sheet from that cog only used to contain preferences relating to auto expansion, but it's now outgrown this. It's likely this cog will be replace with something more obvious in a future release.

@cbowns try doing an xattr -rc /path/to/app to remove all extended attributes before copying it to /Applications. This should work absolutely fine, and something I've been doing for quite some time with various things.

Interestingly, a while back, I started deploying Alfred in a signed dmg instead of a zip, as recommended by Apple - Apps packaged inside a signed dmg are not translocated by macOS.
 
It's unlikely Alfred's move command will remove the extended attributes, as it would sidestep a default feature added by Apple.
 
Cheers,
Andrew

... it's also worth noting that it would be super simple to create a workflow which adds a File Action for "Move to Applications", set for type Applications only. This could be a super simple script which removes xattrs and moves to /Applications/
 
Cheers,
Andrew

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

This workflow is officially deprecated if favour of Alfred’s Automation Tasks. You can find the old source on Github.
 
The open command gives us extra control when opening apps, such as making new instances or relegating to the background.

This Workflow emulates those options with File Actions.

@Danny Nemer You can actually remove individual items from the clipboard history from within Alfred's history viewer. Select the item you want to remove and use fn+backspace.
 
Cheers,
Andrew

Alfred is amazing. ?
 
 

Just throwing together a quick workflow this morning and did the pre-release update to check out the feature. Just wanted to hop back in and say great job! It makes so much easier to make everything look the way you want!
 
Much appreciated, @Andrew!

Good idea...
 

Ah thanks, typo, should be "was was was"

If you update to the latest pre-release, the snippet trigger is now in - and yep, it means type some text in any app and away you go

@derBingle If you update to the b837 pre-release, you can now enable this by right clicking in the canvas and selecting in the Options sub-menu

Hi @Andrew, thanks for the update ! At first try this is working great! So thanks a lot  ! Also, I saw the new snippet workflow trigger, this would be a very great addition! Thanks for your work

@kballard hmm, I had (wrongly?) assumed that this would have either been wrapped in a single pasteboard "transaction", or clearContents would have adjusted the clipboard change count (i.e. clipboard changed to empty), then writeObjects would have adjusted it too (i.e. changed to contents).
 
I've had a bit of a play with this and I can comfortably ignore clip counter changes until there are types available.
 
Thanks for highlighting this - I'll have this fixed in the next 3.4 pre-release
 
Cheers,
Andrew

Well that's about as quick of a response as you could possibly expect from a developer! ??
 
Thanks @Andrew!

@vitor these are now available in the 3.4 b832 pre-release

This can be enabled in Alfred's Appearance > Options preferences... "Save position when dragging Alfred main window"

@vitor Ah sorry, I thought you were talking about the "Call External" output. Yep, I can see that there is no errors being output when the External Trigger AppleScript is run on Alfred.
 
I've added the following errors into the External Trigger AppleScript for the next release:
Unknown Error: -1 Workflow Not Found: -2 Trigger Not Found: -3 Workflow Disabled: -4 Cheers,
Andrew

This is actually pretty easy, here is my safari search with sh for history and sb for bookmarks:
 
https://dl.dropboxusercontent.com/u/6749767/Alfred/Workflows/Search%20Safari.alfredworkflow
 
You could attach a hotkey to the beginning of one of these if you'd like to access one of these searches directly without a keyword.
 
Cheers,
Andrew

@deanishe these have content type 'com.netscape.javascript-source'.
 
This is why I try to suggest creating file filters which have the file types you are looking for such as images, plain text etc (even replacing out the default file filters with ones with multiple types for general search). Then the node_modules folder doesn't need to be excluded.
 
I've just spent the last few hours looking at the MDQuery API again, to find if there is a graceful way to exclude the e.g. node_modules folder, and there is still nothing I can do without loading tonnes of files first and subsequently filtering.
 
One possibility could be that I provide an extremely open ended "advanced" file filter object which has e.g. the following fields:
A raw metadata query with {query} placeholders. A regex to subsequently filter by path, allowing path matches to be rejected. A "Stop looking when x results have been found". It would have the caveat that with great power comes great uhhh potential slowness.
 
Cheers,
Andrew
 

I've never suggested this - I'm just trying to suggest solutions which work within the bounds and limitations of macOS and its metadata index which Alfred's file search and file filtering is built on.
 
This is also why I suggested a possible alternative workflow object.

To view Alfred on the currently visible screen, set the "Show Alfred on mouse screen" option in Alfred's Appearance > Options.
 
When it comes to files, Alfred simply asks OS X to open files and documents, so this behaviour is essentially controlled by OS X. Once Mavericks is settled, I am going to do a full usability run through and see if there are any quirks I need to work around, but for now, you may need to configure certain applications to be more compliant, or play with OS X options such as Mission Control's "When switching to an application" option.
 
[moving to the help forum]

Nothing more than I finally got around to updating the Mac Mini Alfred build server to macOS Sierra and Xcode 8 with a fresh reinstall. It was running El Capitan and Xcode 7 before this
 
Cheers,
Andrew