Andrew

@deanishe related apps isn't part of the designated migration, but I can see that this could be useful to be migrated. I'll add a ticket to look into this as this will be the first non-keyword, non-hotkey item migrated. Off the top of my head, I can't think of any reason this can't be included in the migration though Cheers, Andrew

@GuiB thanks for the workflow, I'll take a look into this once I finish what I'm working on and get back to you

@deanishe the behaviour in Alfred's default results won't change (and therefore the AppleScript behaviour for "search" won't change). The new "browse" AppleScript command will open the navigation window and just use string you pass, so you'll be able to add a trailing slash or not depending on what you want.

@deanishe this is by design, and the behaviour is consistent with pasting a path into Alfred. It allows you to copy a path from e.g. pwd in terminal (which doesn't have a trailing space), paste it into Alfred and it will browse the same folder as your terminal session. If you paste ~/Desktop or ~/Desktop/ into Alfred, it will browse both, as these are treated as actual paths (the path is interpreted and resolved before the filtering within the file system navigation view). It is in fact just a side effect of Alfred recognising the search term as a path and navigating into it which is why the navigation is happening from AppleScript. The AppleScript search command is showing Alfred's default window with the specified search term (which happens to be a path), this search term is passed to the framework which is interpreting it as a path and then replacing the view out with the file system navigation view (you can actually see it flicker as the views change if you look closely). A tidier solution could be to add additional new AppleScript: tell application "Alfred 3" to browse "~/Desktop" This would open the navigation view directly, skipping the path recognition and processing via Alfred's default results view. Cheers, Andrew

@Empyreal I wonder if this is an Atom (electron) save dialog issue as it seems to work fine in the macOS native save dialog. Does it work fine for you in the TextEdit Save dialog?

It surprises me that this isn't easier to do by default... I'll add an additional AppleScript command for the next release which will be something like: tell application "Alfred 3" to action "~/Desktop" Cheers, Andrew

@deanishe is correct. Unbelievably, the Apple Contacts API doesn't support diacritic insensitive search... so Alfred offers using this which is slightly more reliable when spotlight is acting up, or switching to spotlight which has diacritic insensitive matching.

@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

@NickNY I've also replied to your Facebook messages earlier today, did you also try turning off Optimised Storage for iCloud as per this article: https://support.apple.com/en-us/HT207236 This may also bring your files back from iCloud. I take on board that iCloud Drive is getting more unreliable (especially for Pro apps), and I have raised an internal ticket to provide more warning when trying to use it to store Alfred's preferences. Cheers, Andrew

If it helps, Alfred's 'Replace' workflow utility object can actually accept new lines if you alt-enter in the right field. It's likely at some point I'll take a fresh look at all of the utility objects to see how they can be improved 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.

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

@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

@cbowns not sure if you spotted in that thread, but you can remove the quarantine flag with xattr after the mv, and then the app won't be translocated by macOS.

@Adrianthomas In the Script Filter's configuration, set the keyword argument to "Argument Optional". This way, the Script Filter will be run as soon as the keyword matches, before the user types any argument. Hope this helps Cheers, Andrew

@rossbennett interesting, thanks for posting! @HRD I still don't think there is anything for me to do right now other than keep an eye on this. I don't want to engineer a solution to work around a beta "work in progress" in High Sierra.

@Jasondm007 the workflow I created was a simple file filter (using macOS metadata). Modifying this to look for specifics within Notes.app (such as note folders) would be rather more involving, and I suspect, a bit more scripting. Somebody here may be able to prove me wrong on that though!

@Damoeire the difference between those two keywords is that open will open the item, find will reveal it in finder. For most other types of files, the consequence is more obvious, but with folders, both will end up in Finder. The open command will open Finder to within the selected folder, the find command will select that folder in Finder. I haven't experienced any issues with either of these keywords and folders, and the actual behaviour of this is controlled by macOS itself (Alfred doesn't do anything differently when asking to open a file or a folder, just passes off to macOS). Have you tried just restarting your Mac in case macOS is having a funny moment? Cheers, Andrew

@Jasondm007 You can't override Apple's key behaviour. If a key has an alternative (Apple) function, you need to hold the fn key to turn that key into an actual function key to use it in Alfred. You can turn all keys into standard function keys in Apple's Keyboard prefs, then you could assign custom functions to every key. Cheers, Andrew

@Acidham If you just want to list items in Alfred's results without any scripting, remember you can also use the List Filter.

@RodgerWW I've been using text expansion on my testing Mac for a while and it has been working as expected. Have you tried rebooting?

Yep, @deanishe is correct, Script Filter XML output will still be interpreted by Alfred for the foreseeable future, it just won't be getting feature updates like the JSON output. Cheers, Andrew

@Obbut thanks for checking! I decided to leave the frosty teal as-is.

@Obbut I've now updated the "Alfred" and "Alfred Dark" default themes to be less than 50% blur, and more opaque. They look practically the same, but should be higher performance. Would you mind updating to the 3.4.1 pre-release from Alfred's update prefs and check this for me? Cheers, Andrew