Why can't Alfred handle "losing focus"?

[matthew16]

AFAIK, If I have a search up and another app is activated, the current Alfred search is lost forever.

 

Is this true or am I missing something? 

 

It's really frustrating for me and making Alfred hard to use. But before I say any more, I want to make sure I'm correct that there's nothing I can do about this.

 

One thing I am aware of is that we can set a shortcut to go to the last path in a file search. But this doesn't help with workflows or anything else.

Edited April 16, 2017 by matthew16

[deanishe]

Use the UP and DOWN arrows to navigate through the last queries you entered into Alfred.

 

Unfortunately, it doesn't work with workflows that use External Triggers (i.e. when Alfred goes into a funky mode showing the workflow's icon top right, but no keyword). Which is one of the main reasons why External Triggers are rubbish…

[Andrew]

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.

[vitor]

I was under the impression we already had one or two threads on this subject, but I’m not finding them (the ones I remember). I think @Florian was in them, so perhaps he can find them.

 

I’m also interested in the matter of Alfred’s focus. I’d very much like an option to make Alfred’s focus unstealable — i.e. once I call Alfred, it only disappears after I (not the system or another app) dismiss it or action a result. Two cases where I miss it daily:

• I finish watching a video. While it’s in the credits I launch Alfred. If I’m not fast enough with my command, I lose it.
• I have a Workflow with a Script Filter that shows a bunch of URLs. Each one I action is opened in the browser. The “Don’t close the Alfred Window on actioning result” option is checked. However, the first one always closes Alfred, because it also launches my browser (which steals focus).
  

[deanishe]

17 hours ago, Andrew said:

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.

 

Personally, I think a separate hotkey that brings Alfred back up in its previous state would be a better idea for a few reasons.

1. It could also work in External Trigger mode. If your workflow benefits from Alfred's history, the fact that it ignores External Triggers and always drops you back at the workflow entry point, not where you actually were, is one of the biggest reasons to ignore External Triggers, and use delimited queries & AppleScript instead.
2. Some queries have side effects without the user actioning a result. For example, Alfred-Workflow has "magic arguments", whereby it assumes control from the workflow to perform common housekeeping tasks, like deleting the cache, data, and/or settings. You don't want Alfred putting workflow:reset in the query box for you, nor to have to sit and wait five seconds before re-opening Alfred to ensure it doesn't.
3. I don't speak for everyone, of course, but the majority of the time, I don't want to go back to where I just was when I open Alfred.

 

[Andrew]

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

[deanishe]

1 hour ago, Andrew said:

I'm more specifically talking about the one scenario when focus is unexpectedly pulled from Alfred

 

I'm pretty sure that (2) would lead to unwanted re-population of the query, for example, if someone uses one of AW's magic arguments that opens the log file or data/cache directory. (I don't think Alfred has any way of knowing that Console.app or Finder was launched from Python code and that it's supposed to lose focus.)

 

If Alfred auto-populates the query, and the user runs, say, workflow:opendata (which opens the workflow's data directory in Finder), I suspect they'd get stuck in a loop where Alfred keeps re-activating Finder and dismissing itself when opened.

 

Edited April 19, 2017 by deanishe
clarify what I mean

[Andrew]

@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)?

[deanishe]

It's a combination of design goals and something missing.

 

AW is aimed at beginners and should, as far as possible, just work.

 

Magic arguments were first added as development/debugging tools (which was a real pain before Alfred got a debugger).

 

They also make it very easy to implement updates in your workflow without adding your own UI.

 

They're implemented the way they are (they fire when the query matches, not when a result is actioned) because that's the only way AW can control the execution flow. 

 

Because Alfred doesn't offer any way to direct execution flow from code, but always requires it to pass through some workflow element in the UI, the only way to not require workflow authors to explicitly add a bunch of elements to their workflow to support these features is to not return control to Alfred in the first place.

 

We chatted about this at one point, but I never mentioned magic arguments, as that was a solved problem till you suggested re-opening Alfred with the previous query…

[Andrew]

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

[vitor]

Alfred’s stats say I call it 142 times a day on average. Many of those are in sequence and to do different things. It seems to me bringing the previous query automatically might be distracting to my usage.

Not wanting to derail the conversation, why isn’t making Alfred’s focus unstealable (even as an option) an option?

In the past I got the impression this was perhaps undoable (well), but it now seems to be completely a design choice. If it is, I strongly disagree with it. If I call Alfred, I want Alfred. I don’t want it to be closed because another application thinks it should get my attention now. Alfred is supposed to be a butler, that’s the analogy behind the name. A butler is supposed to come when we call, and only go away when we give them a task (action a result) or specifically dismiss them. If another person (app) comes in the room shouting and demanding our attention we tell it to wait a moment, finish giving our instructions to the butler, and then listen to this new character.

I doubt there has been a single time in my years of using Alfred where I called it, focus got stolen away and then I though “oh, well, I won’t call Alfred again then”. No. Every time I curse internally, ignore the app, call Alfred again to do what I wanted, and then pay attention to the new app.

For many of us, Alfred is the gateway to everything else. Alfred doesn’t exist to call other applications, other applications exist to be called by Alfred. Alright, alright, I’m kidding with this paragraph, but everything else is true!

Edited April 19, 2017 by vitor

[deanishe]

Is it possible to tell if your app lost focus because another window "randomly" took focus (e.g. popped up an "An Update is Available!" dialog) or because the user clicked on a different window?

[deanishe]

In any case, I think a separate hotkey to recall Alfred with its previous query/state (perhaps hitting the normal hotkey twice in succession) would be less prone to causing problems with existing workflows.

 

Even in less pathological cases than my above workflow:opendata loop, re-populating the query may lead to wasting limited (or paid-for) API calls.

 

[vitor]

1 hour ago, deanishe said:

Is it possible to tell if your app lost focus because another window "randomly" took focus (e.g. popped up an "An Update is Available!" dialog) or because the user clicked on a different window?

 

If an app requests focus right after a user clicks or presses a keyboard shortcut, we can assume it was triggered by the user and not an app. If that is easy for Alfred to detect or not, I do not know.

 

In any case, I’d gladly take the tradeoff and doubt I’d ever be affected. It’d certainly be less frustrating for me. Again, I’m fine for this behaviour to be an option, not the default. It was just before I was under the impression it couldn’t be done well (or at all), and now it seems that is not the case.

[Lucian Hodoboc]

On 4/19/2017 at 11:40 PM, vitor said:

Alfred is supposed to be a butler, that’s the analogy behind the name. A butler is supposed to come when we call, and only go away when we give them a task (action a result) or specifically dismiss them. If another person (app) comes in the room shouting and demanding our attention we tell it to wait a moment, finish giving our instructions to the butler, and then listen to this new character.

Well, that does makes sense! I was just about to start a thread to ask whether the name is related to Batman's butler. Good thing I did a search first. 😃