Jump to content
ctwise

Throttle script filters

Recommended Posts

Script filters fire for every key press. That is fine for lightweight script filters that can respond quickly but is a problem for heavy script filters that take significant time to operate. It would be helpful to support script filter throttling. This might be as simple as a checkbox ("Throttle requests"). It would work by waiting a short time between key presses, if another key is pressed the timer resets, if the timer expires the script filter is run.

 

It's possible to emulate this in a script but it's such a common use case it would be helpful to have it in Alfred.

Share this post


Link to post
Share on other sites

Alfred always waits for a single script filter object to finish before calling it again, so if it calls on the first character you press and takes a few seconds to reply, it will only get called again with the current query at this point (e.g. if you have typed 6 further characters, the script gets called with these 6 characters, not all the separate times inbetween).

Share this post


Link to post
Share on other sites

Alfred always waits for a single script filter object to finish before calling it again, so if it calls on the first character you press and takes a few seconds to reply, it will only get called again with the current query at this point (e.g. if you have typed 6 further characters, the script gets called with these 6 characters, not all the separate times inbetween).

 

That's good to know but if a script takes five seconds to return results and I type the query 'avengers', then I get script results for 'a' and ten seconds later I get script results for 'avengers' as opposed to five and a half seconds later for a timeout of 500 milliseconds.

Share this post


Link to post
Share on other sites

The only issue with timeouts would be that even the last character typed would fall victim to this. So if it took a little longer than expected to show the last set of results, it could fail and you get nothing as well. 

Share this post


Link to post
Share on other sites

I wonder if Alfred could by taught to only fire off the script once a keypress timeout was met? So, instead of firing on immediate keypress, he waits for a very short time (30ms?) to see if another key has been pressed, only firing the script once no new keypress is registered. So, in the Avengers example, instead of firing on the press of 'a' it only fires once 'avengers' is fully typed, assuming you type 'avengers' quickly. Does that make sense?

 

I couldn't find conclusive data on how quickly users typically type but did come across Jakob Nielsen's findings that a 100ms response time is still perceived as instantaneous.

 

http://www.nngroup.com/articles/response-times-3-important-limits/

Share this post


Link to post
Share on other sites

I wonder if Alfred could by taught to only fire off the script once a keypress timeout was met? So, instead of firing on immediate keypress, he waits for a very short time (30ms?) to see if another key has been pressed, only firing the script once no new keypress is registered. So, in the Avengers example, instead of firing on the press of 'a' it only fires once 'avengers' is fully typed, assuming you type 'avengers' quickly. Does that make sense?

 

This is certainly a very interesting idea, and definitely something I'm willing to have a good think about after v2.0 is out. It might be worth reviving this topic and reminding me in the future :)

Share this post


Link to post
Share on other sites

This is certainly a very interesting idea, and definitely something I'm willing to have a good think about after v2.0 is out. It might be worth reviving this topic and reminding me in the future :)

 

As you requested, the thread has been revived and you are reminded ;-)

Share this post


Link to post
Share on other sites

This is a very cool idea. I think 30 ms is much too short of a delay, however (that's 30+ characters per second!).

 

The optimal delay would be very user and workflow dependent. Some users type much faster than others; some workflows take much longer to return results than others. And the response time of the same workflow can be highly variable, depending on the state of what the workflow is leveraging (other apps, the OS, the network).

 

I think a decent compromise would be for workflows to be able to indicate a suggested minimum query length/change in query length (i.e. don't query with less than 3 characters or if fewer than 2 characters have been added/deleted), which would be honoured by Alfred until a timeout has been exceeded. The timeout would be decided by Alfred based on observed user input speed (i.e. Alfred might call the workflow after 250 ms for a touch-typist like me or after 500 ms for a hunt-and-pecker like my dad), or a user-specified value.

Share this post


Link to post
Share on other sites

Bump! I think this would be a really useful feature to have. At the very least, I think Alfred should not show out of date results - e.g. if you type 'avengers' and the script returns results for 'a', Alfred just ignores those results and then reruns the script with 'avengers'.

Share this post


Link to post
Share on other sites

Alfred 2.6, January 2015. In your Script Filter, click the Run Behaviour button.

 

You can choose whether Alfred should wait for or kill an already running script, and you can choose how long it should wait for user input before executing the script.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...