• Content count

  • Joined

  • Last visited

  • Days Won


Andrew last won the day on April 13

Andrew had the most liked content!

1 Follower

About Andrew

  • Rank
    Alfred's Dad

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

5,097 profile views
  1. @deanishe I'll msg you at some point to pick the conversation up again. I'd rather properly solve the underlying things such as direct execution etc leaving Alfred's main UI to be predictably consistent if I end up changing the focus behaviour.
  2. @deanishe An option could be to use the "Hide Alfred" workflow object after performing something behind the scenes which you know may pull focus from Alfred. Having said that, these magic arguments sound a bit hacky / cludgy - is there a reason it's done like this? (i.e. is there something missing in Alfred Workflows which would allow what you are trying to achieve without needing them)?
  3. @deanishe I'm more specifically talking about the one scenario when focus is unexpectedly pulled from Alfred, and Alfred disappears. In all other scenarios, Alfred would open in the default state as he has done since the start. If I made it such that if Alfred disappeared outside of the user's expectation, then you have a few seconds window to bring the Alfred window back and carry on. This means that any time that you action a result, or simply hide Alfred manually (e.g. by using the hotkey, or pressing Esc), then things would be as they are now. I suspect that (2) above would also be included in this depending on how Alfred is being dismissed from the screen.
  4. Alfred yielding focus to macOS is essentially by design and intrinsic to Alfred's behaviour. Having said that, I've raised a ticket to have a bit of a re-think about this. I can see that it could be very useful for Alfred to keep full state for a short period of time after having the focus pulled from him, making him hide. e.g. if you were to use the main Alfred hotkey within a few seconds of focus being pulled, it would put Alfred back on the screen it its previous state.
  5. 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
  6. @Beery It sounds like something else is happening outside of Alfred's control for cmd-c-c to trigger within Alfred. Do you have a non Apple keyboard, or any other apps in the macOS Accessibility preferences (Security & Privacy > Privacy > Accessibility)? Could you also try cmd+c using the opposite cmd key just in case there is an unexpected hardware issue causing a double trigger? Cheers, Andrew
  7. @mrchow19910319 It's hard to say what could be causing this as Alfred is essentially idle when you aren't using him. One explanation could be a workflow, or perhaps macOS reindexing. Could you open Activity Monitor and see if you get anything more granular in the CPU tab. Also, in Activity Monitor, select the Alfred process and sample the process (from the cog in the toolbar). This will tell me where this is likely happening Cheers, Andrew
  8. @Beery In this case, Alfred will be adhering to the macOS standard key delay before a key repeat. If you set the "Delay Until Repeat" in the macOS System Preferences > Keyboard preferences to the "Long" end of the scale, this will no longer be triggering repeat keys. Cheers, Andrew [moving to help sub-forum]
  9. Alfred only applies fuzzy matching to Apps, everything else is keyword or word based throughout the rest of Alfred which is why the actions panel doesn't employ fuzzy matching. This has been by design in Alfred since the start (at a framework level), so is unlikely to change any time soon, but I'll make a note of this thread for possible considerations in the future. Cheers, Andrew
  10. @dgbeecher which version of Alfred are you running? 3.3.1 should have addressed the full fuzzy match from word boundary when using "open with" and searching for applications.
  11. @dfay it's unlikely I'll add this to Alfred as it would involve quite a bit of fudging to be compatible. When you use a hotkey to select some text in Alfred, the source app still has focus so it's easy to generically get that app to copy the selection to the clipboard. Once Alfred has focus (i.e. you are typing a keyword into Alfred), this context has gone so it would involve using e.g. Accessibility access which the main Alfred app doesn't want, or AppleScript which is very much app specific. I do have some things planned for Alfred in the future which will make getting a text selecting into an Alfred Workflow more generic, but no details as of yet. Cheers, Andrew
  12. @matthew16 I agree about turning off unintelligent search. The best way to find files in Alfred is to use the file search mode: More specifically, prefixing your search with [spacebar] which is the shortcut for the open keyword. Once you've followed @Vero's advice on reindexing, this file search mode should work great alongside default searches which will include applications etc. Cheers, Andrew
  13. @dgbeecher you can actually do this without any configuration using the file selection hotkey under Features > File Search > Actions > File Selection. I have set this to alt+f. I select a file in Finder, hit alt+f which shows Alfred's action panel. You can select "Open With" from there Cheers, Andrew
  14. @user01 the searches you are referring to are the default fallback searches. You can leave all the web searches enabled (as these will only show when you use their keywords). To change the default fallback searches, use the "Setup fallback results" button under the Features > Default Results tab. If you set duckduckgo as your top default result, then you can type bang searches directly into Alfred Cheers, Andrew
  15. It seems like the app is fettling the key events or clipboard outside of Alfred's control, which would naturally get in the way of Alfred working as expected. Have you tried disabling that app and things work as expected?