An extremely powerful new feature in Alfred 3 is its workflow variables.
You can set and manipulate these not only in Alfred’s own UI elements, but also via script output or Script Filter results.
The Alfred 3-only
Workflow3 class provides an
API for getting and setting workflow variables via Script Filter feedback
Variables can be set at the Workflow, Item or Modifier level using their
setvar(name, value) methods.
Items and Modifiers inherit any variables set on their parent Workflow or Item objects at the time of their creation.
This way, you can have some variables inherited and others not.
Alfred-Workflow does not automatically import any variables. All getters only consider variables you have set, not those passed to your script by Alfred.
As Alfred passes workflow variables to scripts as environment variables,
var=1 style flags with a command-line library that can
map environment variables to command-line options (such as Click) is
a clean and powerful idiom.
Click allows you to set a prefix, e.g.
WF_, and it will then automatically
map matching environment variables to corresponding command-line options, e.g.
WF_USERNAME=deanishe is equivalent to
WF_DEBUG=1 is equivalent to
Let’s say we’re using a client program for some imaginary social whatnot that works like this:
prog [--username=<name>] (profile|pages|friends) (--view|--edit|--share)
You could control this program from a Script Filter as follows. This assumes
you would connect the Script Filter to three Run Script Actions, one for
friends, and with a Filter Utility
before each Run Script that checks for
pages == 1,
profile == 1 etc.
The Run Script action behind the
pages == 1 Filter Utility might then
The other options (
--share) are set via the
corresponding environment variables (
The salient part of the Script Filter driving the workflow might look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
from workflow import Workflow3 wf = Workflow3() # Username will be needed in every case. Set at the workflow level # to ensure all items inherit it wf.setvar('WF_USERNAME', 'deanishe') # Some example actions. We've set username above as the main # identifier. We'll set flags on feedback items that subsequent workflow # Filter Utilities can use and WF_* variables to pass arguments # directly to the program # Profile it = wf.add_item('Profile', 'View profile', arg='profile', valid=True) # Inherited by all modifiers it.setvar('profile', '1') mod = it.add_modifier('cmd', 'Edit profile') # Set only on mod. Equivalent to option --edit mod.setvar('WF_EDIT', '1') mod = it.add_modifier('alt', 'Share profile') # Set only on mod. Equivalent to option --share mod.setvar('WF_SHARE', '1') # Set after modifier creation, so only set on item, and is thus the default # Equivalent to option --view it.setvar('WF_VIEW', '1') # Pages it = wf.add_item('Pages', 'View pages', arg='pages', valid=True) # Inherited by all modifiers it.setvar('pages', '1') mod = it.add_modifier('cmd', 'Edit pages') # Set only on mod. Equivalent to option --edit mod.setvar('WF_EDIT', '1') mod = it.add_modifier('alt', 'Share pages') # Set only on mod. Equivalent to option --share mod.setvar('WF_SHARE', '1') # Set after modifier creation, so only set on item, and is thus the default # Equivalent to option --view it.setvar('WF_VIEW', '1') # Repeat for Friends # ... # ...
While you could also replace the
(view|edit|friends) commands with
--command (view|edit|friends) option and drive the whole workflow
via environment/workflow variables, I’d advise against going too far in
that direction (e.g. having a single Script Filter connected to a single
Run Action containing an option-less command), as it could make your
workflow very hard to follow for people wanting to hack on it.