RepeatRepeat — Proof of concept to make a script filter update itself without further user input

[vitor]

This workflow is officially deprecated in favour of Alfred’s native rerun in Script Filters, introduced in 3.2. You can find the old source on Github.

 

An experiment to answer a question.

 

Type repeatrepeat and the workflow will automatically start typing . (so it auto-runs again) repeatedly, once every two seconds. It’s a hack but it works well enough, with the only issue being it’ll still type . once after you dismiss it, which may lead to unpredictable results depending on what other apps you’re running.

 

Edited August 31, 2022 by vitor

[Tyler Eich]

This is pretty much a useless workflow. It’s meant as a proof of concept to answer a specific question. Are there any more use cases where this would be useful, other than a timer? Not with the way this has to work (it’s very much a hack), but if it was implemented as core functionality, maybe we’d see some workflow/dashboard results cropping up (if that would be desirable is another matter entirely).

I’ve built this mainly because in many of my workflows I had to work around Alfred’s limitations, which in the end influences their design, so why not take another challenge?

It ended up being smaller than I initially thought, but that does not mean it’s still not an ugly hack. Here’s a gif demonstration (I only pressed ↩ twice — to autocomplete the name, and to activate it the first time — all the other times you see Alfred appear is the workflow using applescript to call itself, with a one second delay each time).

Download

https://github.com/vitorgalvao/alfred-workflows/raw/master/bin/RepeatRepeat.alfredworkflow

Source

https://github.com/vitorgalvao/alfred-workflows/tree/master/RepeatRepeat

License

I don’t care, do whatever you want with this. If you make any changes that could benefit any of the scripts, I’d certainly appreciate if you’d share them (perhaps I could incorporate them), but it’s not at all required.

 

+1, I'd love to see this functionality

 

Two usage examples:

• Top Processes by zhaowu. Activity Monitor has live information; I rarely use the workflow because I want to know when the process in question starts to settle down as it happens
• Wolfram|Alpha by Tyler Eich. Many users have complained about how long it takes Wolfram|Alpha to respond as they type; if the workflow could let the user know that the script is still working as it provides the last set of results, it could save a few confused users.

 

There are many factors to consider with this behavior, though. What can be 'updated'? Everything (arg, title, subtitle, icon, autocomplete, valid)? Can order of results be changed? Maybe a manual 'disable' button for Alfred's intelligent sorting? Is selection maintained after the update?

[vitor]

+1, I'd love to see this functionality

 

Two usage examples:

• Top Processes by zhaowu. Activity Monitor has live information; I rarely use the workflow because I want to know when the process in question starts to settle down as it happens
• Wolfram|Alpha by Tyler Eich. Many users have complained about how long it takes Wolfram|Alpha to respond as they type; if the workflow could let the user know that the script is still working as it provides the last set of results, it could save a few confused users.

There are many factors to consider with this behavior, though. What can be 'updated'? Everything (arg, title, subtitle, icon, autocomplete, valid)? Can order of results be changed? Maybe a manual 'disable' button for Alfred's intelligent sorting? Is selection maintained after the update?

How could I have forgotten top? Same here, I use it way less than I’d like, simply because the information does not update on the fly. There’s actually another way to go about this. On this particular workflow, the first node could be changed to contain.

cat << EOF
<?xml version='1.0'?><items>
  <item uid='repeatrepeat' arg='{query}' valid='yes' autocomplete='repeatrepeat'>
    <title>$(date "+%H:%M:%S")</title>
    <subtitle></subtitle>
    <icon>icon.png</icon>
  </item>
</items>
EOF

and the second one

tell application "Alfred 2" to search "repeatrepeat  "

repeat {query} times
	delay 1

	tell application "Alfred 2"
		tell application "System Events"
			keystroke " "
			key code 51
		end tell
	end tell
end repeat

tell application "System Events"
	key code 53
end tell

What this would do is, instead of calling Alfred over and over again (making the window “flash”), you would pick a number beforehand and the workflow would type a space and delete it immediately once a second — since the script filter runs every time a key is entered, this would work visually better

Unfortunately, this has one huge drawback — if you leave Alfred (by pressing ⎋) before the repeat command finishes, it’ll effectively keep pressing those keys over and over, until it finishes (which could effectively leave you unable to use your computer for the allotted time).

Edited June 26, 2013 by Vítor

[hzlzh]

You can share your workflow on the List site below~

[vitor]

You can share your workflow on the List site below~

I know, I usually do, but this being a proof of concept, I don’t think it’d be useful to add it there.

[vitor]

Update.

It now uses OneUpdater, so this should be the last time you need to manually update.

 

Also updated with a new method.

[jeffsui]

So there is a better (different) way to do this Alfred 3.1  You can see the blog post I wrote ( https://medium.com/@Jeef/alfred-today-my-experience-writing-a-plugin-80cbd0fea9c1#.23jbamfye (scroll down to External Trigger and caching)

 

Basically you can fire off an apple script the triggers a hide alfred - then re-open aflred setup and maybe that is what you are looking for?

Edited October 16, 2016 by jeffsui

[vitor]

@jeffsui Not really. I had encountered your post before, but it does not do the same thing. You seem to be just updating a view once, which could have been done since version 2. What this proof of concept (that exists since version 2) does is refresh the same view over and over, until the user arbitrarily decides to stop it.

 

The goal here is to indefinitely refresh local information that is constantly updating, like a real-time Alfred status bar.

 

Your solution is also using way more nodes, and I’m not even sure all of them are needed. Why even hide Alfred if you’re going to call it again? Just call it again and the current view will be superseded.

[jeffsui]

On 10/11/2016 at 1:06 PM, vitor said:

@jeffsui Not really. I had encountered your post before, but it does not do the same thing. You seem to be just updating a view once, which could have been done since version 2. What this proof of concept (that exists since version 2) does is refresh the same view over and over, until the user arbitrarily decides to stop it.

 

The goal here is to indefinitely refresh local information that is constantly updating, like a real-time Alfred status bar.

 

Your solution is also using way more nodes, and I’m not even sure all of them are needed. Why even hide Alfred if you’re going to call it again? Just call it again and the current view will be superseded.

 

The reason I had to hide alfred was I needed to refresh the view for the same command.  In your case you are constructing new commands by adding a period to the input.

 

Have you found a way to keep the "timer" going while having the text on the screen say "repeatrepeat" without adding the periods?

 

[vitor]

8 minutes ago, jeffsui said:

The reason I had to hide alfred was I needed to refresh the view for the same command.  In your case you are constructing new commands by adding a period to the input.
 
Have you found a way to keep the "timer" going while having the text on the screen say "repeatrepeat" without adding the periods?

 

As I mentioned, you could’ve accomplished that in the past already by using Alfred to call itself (via AppleScript) or by using the previous method RepeatRepeat used, which was to add a space and then delete it (which is documented in this post). The way that works in Alfred has indeed changed recently as a single space is no longer enough to retrigger, but the point still stands as you could just as well add and remove a period or a letter. The single reason I changed that method in this recent version is that depending on when you cancel, ⌫ might still be pressed once after Alfred is dismissed, and that may have unintended consequences. Adding a period might have consequences as well, but those are likely less severe.

 

Either way, for my particular case I’m glad to say this particular proof-of-concept has done its job. It has cemented in my head how useful the feature was and that it is indeed impossible to fake it appropriately with the current feature set, allowing for a proper discussion of this as a native feature.