Jump to content

Workflow loses focus action


Recommended Posts

Hey Andrew and everyone else :-)


When workflows get complex, they often have some sort of post-processing involved to clean up, prepare for next launch, kill the last scripts... This gets very useful when you have multi threaded workflows. So of course, this isn't for everyone :)


But here it is: I think it would be useful to have a "workflow lost focus" action, where it would be possible to run a script after the workflow has gone, either because

  • the user closed alfred / alfred lost focus (for example with the escape key),
  • because the current query doesn't match anything from this workflow anymore,
  • because the user activated an item and alfred disappeared (well for this one, we can just actually run a script)

There is currently no way of knowing when a workflow loses focus, and we end up having to rely on timeouts, which might end up starting a process heavy / network heavy task right when the user needs it for the workflow.


Am I making myself clear? Has anyone found anything better than timeouts?


Cheers 8-)

Link to comment
Share on other sites

When I hear a question like this, my first feeling is you might consider refactoring the workflow as a standalone background server daemon with a workflow script as a client.


Alfred's workflow-execution model is based around short-running processes. Long-running workflows can cause problems, e.g. Alfred won't run your workflow again until the previous call has completed.


The way I'd do something like this is to have a server/client architecture, and the server cleans up and shuts itself down if no client has connected in the last X seconds. The client starts the background server process if the server isn't currently running. All the state is in the server process, and you have a very lightweight—and fast—client script in the workflow that communicates with it (via HTTP/REST, a UNIX pipe or whatever).


It's a much cleaner architecture and eliminates a lot of potential problems.


If it's important for Alfred to inform your process when its window has closed, a more standard solution would be for Alfred to send a signal to the process (if it's still running), such as SIGUSR1 or SIGHUP.


Sending and catching signals is a standard feature of most languages, and you wouldn't have to figure out some kind of interprocess communication between your tidy-up script and whatever other processes are running (which would probably end up being signals…)

Link to comment
Share on other sites

I'm not sure what it is you're doing exactly, but I quite like the server-hangs-around-for-a-bit model. It's still ready and waiting if you need to use it again straight away.


Obviously that's not so great if it's hammering the CPU.


I think it would definitely be handy if you could check a box in the workflow config that tells Alfred to send a signal to your workflow process if the user closes Alfred or otherwise aborts your workflow.

Link to comment
Share on other sites

Since most of us run script filters using bash to launch the workflow as a file, then this could be done by adding some more code into the script filter box. You can catch SIGHUP and SIG-anything with simple Bash Traps.


If a script starts to run in Alfred, then it will continue to run even if the user presses escape (I'm pretty sure this is true), but Alfred just won't be available to catch and display the results.

Link to comment
Share on other sites

But it should send a SIGTERM (I think that's the right one) when the script ends. Or you could actually code this into the workflow script box:

php myscript.php

So, you probably don't even need to use a trap.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...