Andrew

@thegriffinwells Not by clicking the hat in the menu, but if you drag Alfred to the dock, a single click on this will bring up Alfred's main search window. Having said that, Alfred really does work fastest when using the hotkey (alt+space) by default, as this way, your hands don't need to leave the keyboard to use the mouse. Cheers, Andrew

@Dilapidus You'll need to delete the metadata cache from the location listed above for Alfred to look further and find the 1Password 6 data. Cheers, Andrew

@thedave Is this happening with every Alfred theme, or just specific ones? If it's just a specific one, could you share this with me to take a look?

@PavelDohnal This will be down to Alfred not having the required permissions in macOS Mojave. Take a look at Alfred's Mojave getting started guide: https://www.alfredapp.com/help/getting-started/macos-mojave/ Specifically the Accessibility section. Cheers, Andrew

@Druboi Could you please clarify what you mean as this could relate to more than one feature within Alfred? Some [annotated] screenshots would be perfect. Also, are you using the latest version of Alfred (3.7 b938)?

@wwvuillemot I've just tested this on the latest macOS Mojave and it works as expected. Could you check that Alfred has been granted accessibility access, as this is required to dispatch key events: https://www.alfredapp.com/help/getting-started/macos-mojave/ Cheers, Andrew

@deanishe I've made a note to have a think about this - but that would then make the behaviour different if you were to migrate an internal to an external script. I do agree that with an external script, it makes sense to differentiate between no argument and empty argument.

Looking back through my notes, I think the original reason it's like that is because argv came after {query} (which is just string replaced in the script) - An empty argument for {query} was always represented as empty string as there was no obvious or predictable way to string replace "not set" for {query}. I'll probably leave this as is.

@deanishe interesting - I can see why this is behaviour (and predictable)... I'm not sure it would be wise to change this behaviour to not pass an argument as this may cause regression issues.

That's correct, I was going to say they essentially launch in order but run in parallel but that's with caveats and can be misleading! Thanks for correcting me.

There are a couple of issues with your workflow which which is why it's not working as you intend: 1. Having 3 separate streams coming out of a hotkey means these three streams are running independently of each other, the top one first, then the second, then third one down. I.e. in your example workflow, the file will be written 3 times. To run as a single flow, you need to chain the items in series. 2. Setting a variable in osascript is local to the script itself... so for example, "theTitle" will never be passed back into the Alfred workflow. For data to be passed back into Alfred, it has to be output from the script - you can then set the variable using the Arg / Var as you have done. (More advanced scripting allows you to pass JSON out of a script to directly set variables.) Add a Utilities > Debug workflow object connected to outputs of objects then use the little bug icon top right of the workflow editor to see what data is being passed around your workflow. This will help you work out where things are going wrong! Cheers, Andrew

Ah yeah, my bad! I'll fix this in the next release. Alfred checks for permission once on startup and once when starting the snippet expansion. I'll be sure to check if the request is already visible to prevent the second one. Do you have an old version of Alfred hanging around somewhere? Alfred doesn't remove Alfred Text Service from the Accessibility area himself, it's the absence of the Alfred Text Service.app binary which causes this to happen automatically, and it's not included in the latest 3.7 pre-release. Cheers, Andrew

@deanishe this is now fixed in the 3.7 pre-release. Let me know if it behaves as you would expect!

@Gary King if you update to the Alfred 3.7 b931 pre-release, this should now be fixed

@psifertex Eject All will only eject the items which match the eject scope. If there are no matching items to eject, Eject All won't show.

@psifertex Your backup drive isn't going to be treated as "Removable Media", so try switching the scope from "Removable Media" to "Local Mounted Volumes" and you'll likely see the drives you want to eject [moved to Discussion & Help]

There are a few things you can do in Alfred's workflows which help with this. Firstly, you could have two separate Open URL actions configured as appropriate, then use modifiers on the connections... e.g. return on the result will open the first Open URL object in the default browser, alt+return will open in the second Open URL object with a specified browser. A simple workflow could be: Keyword to take a URL as argument -> two Open URL actions, one with a modifier. Another option is to dynamically configure the Open URL object. This is a more advanced workflow technique, but allows for significant flexibility using the JSON utility: https://www.alfredapp.com/help/workflows/utilities/json/ It's probably best to take the simple approach first.

Right, I've slept on this and I'm gonna keep minimal disruption here and treat mod override results at the same inheritance level as the result itself... so if you have variables set on a mod, it will fully replace the item variables. I accept that this gives the maximum flexibility of allowing separate variables for an item and a mod. Conveniently, you can also just set variables": {} on a mod if you don't want it to take the item variables by default. Cheers, Andrew

@Gary King It actually came about after a fix I made to work around a High Sierra bug to do with how Alfred dealt with the max / min number of file search results to process. Thanks for spotting this!

This behaviour is currently broken too though - If you set item variables and don't set any mod variables, the mod gets the item variables anyway (which is synonymous with the inheritance approach). On the flip side of this, if the mod variables inherit from the item variables, then you can set one variable for the result shared by the item and all the mods, then either override that variable in the mod, or set a separate variable so you know which mod has been used down stream. This feels like the correct behaviour. Is losing the ability to set a variable on an item but not the mods really an issue in practice?

Hm, I've tested this fix both ways - It feels more predictable / correct to take the inheritance approach, so if you set variables on a mod, then they are merged in with the item variables (and above), and are overridden where appropriate. If you didn't want a mod to inherit the item variable, it could always be set to empty... or for dynamic inheritance in your library, skip the item variables altogether and just set them on the mods (once the bug is fixed).

@deanishe I'm currently fixing this for 3.7 and this is a tricky decision. The current behaviour (wether right or wrong) passes the item variables if no variables are set for a mod. As this has only just come up, I think to have the least amount of regression issues would be to do keep the current behaviour, but do as you suggest and the mod variables completely replace item variables (but correctly fixed to override upstream vars etc). I'll also update the documentation to reflect this, as it states: Which isn't correctly working anyway.

@Gary King I've identified why this could happen, and will have it fixed in the next pre-release

@bmazin Alfred shouldn't include ~/Library by default, even with folders in home selected. If you haven't manually added this folder to the scope, it might be worth rebuilding your macOS index as there may be an internal macOS metadata issue. There is a shortcut for this in Alfred's Advanced preferences. Cheers, Andrew [Moving to discussion and help]

@tmutimer this is actually a known issue which I've talked to Apple technical about. Alfred, by design, yields focus to other apps. The issue here is that Alfred isn't told where that event comes from. If Alfred had more information fed to him in the event, he could differentiate between which focus events could be ignored. I still have an internal ticket for this, but for now, I'm going to move this to noted. Cheers, Andrew