Alfred is slow to notice external changes to workflow info.plist [Investigating]

[deanishe]

I wasn't sure whether to post this in here or in Feature Requests. Ultimately, I chose here because the workflow configuration sheet and workflow variables provide a very handy way to configure a workflow, but its utility as a settings store is significantly limited by the fact that Alfred doesn't notice when info.plist was altered by something other than itself.

 

Specifically, I'm thinking about scenarios like the one I outlined in the Workflow Variables HOWTO, where a workflow developer would like to offer a way to toggle a setting on/off or add an API key via the workflow's own UI, rather than asking users to crack open Alfred Preferences, hunt down the workflow and edit its configuration sheet.

It's a better user experience, allows the developer to validate the input, and knowledge of the existence of the configuration sheet is far from universal (a more obvious "settings in here!" icon might help).

The problem is that Alfred takes several seconds to notice that info.plist has been changed by something other than itself (possibly several minutes if the workflow is symlinked), so the setting doesn't immediately stick and the workflow displays incorrect info or straight-up doesn't work until Alfred notices.

Practically, this makes the variables in the configuration sheet read-only.

This is a great shame, as it means that if you want to provide the ability to alter a workflow's settings from within the workflow, you have to forget about the configuration sheet and implement the whole thing yourself  

Ideally, Alfred would either (a) check the modtime of info.plist every time it sets the workflow variables or (b) provide some official means for workflows to edit their own settings, e.g. /Applications/Alfred\ 3.app/Contents/MacOS/Alfred\ 3 --set "name" "value" (Alfred can grab the workflow's bundle ID from its own workflow variable! How cool is that?)

Edited December 5, 2017 by deanishe

[Andrew]

@deanishe I wonder why symlinked workflows take that long to update, I'd have to look into that. Alfred is fed filesystem notifications from macOS when there is an update Alfred should be aware of (this mechanism is also used for the syncing), and Alfred sets the grouping param to 5 seconds, so it shouldn't be any slower than this. I wonder if symlinked ones aren't even getting notifications at all, and it's an alternative mechanism (there are a few others) which is reloading the info plist at that time.

 

I'll add a ticket and have a bit of a think into this

 

Cheers,

Andrew

[deanishe]

27 minutes ago, Andrew said:

it shouldn't be any slower than this.

 

It isn't for "installed" workflows, but alas, 5 seconds is still 4.99 seconds too slow for a workflow that just toggled one of its settings and called its own External Trigger…

 

WRT symlinks, FSEvents treats the symlink as the file to watch, not (the contents of) what it points to. So I guess in that regard, Alfred would have to call realpath on it first and subscribe to that path instead.

 

Out of interest, does Alfred un--subscribe from the event stream when it moves to the background? I simply assumed you weren't using FSEvents to keep Alfred as idle as possible in the background.

 

For my part, I'd prefer an tiny official helper program for updating the values. It would pretty much eliminate the risk of a workflow screwing up its own info.plist, allow Alfred to be aware of any changes instantly, and allow you to change how/where settings are stored however you like. You could pass the path to the helper program as an environment variable, then I can just run "$alfred_variables_setter" API_KEY "ABC-DEF-XYZ".

Edited December 4, 2017 by deanishe
comma comma comma comma, comma chameleon

[Andrew]

@deanishe Alfred doesn't unsubscribe, but idles on the events, only acting on the grouped events when they become relevant (i.e. Alfred needs the changes). Alfred only subscribes to the top level Alfred Preferences file, not multiple paths, so this will be why there may be reload issues with symlinked workflows.

 

I can see that Alfred needs these things:

 

1. Setting a workflow configuration variable, which will write the variable to the info plist.

2. Forcing a reload of a workflow, which will get Alfred to reload a workflow e.g. if a symlinked info plist is externally updated via github

 

It pains me to say that, for now, this may be done through Alfred's AppleScript interface, as the framework for this already exists. I do have much bigger plans for the future for this area though.

[deanishe]

33 minutes ago, Andrew said:

this may be done through Alfred's AppleScript interface, as the framework for this already exists

 

That's cool, too. All that matters, imo, is that the workflow gets the new value on the next run. So as long as the call is synchronous, it's all good.

 

46 minutes ago, Andrew said:

Forcing a reload of a workflow, which will get Alfred to reload a workflow e.g. if a symlinked info plist is externally updated via github

 

I don't think this is such a biggie. Perhaps others have different experiences, but for me, this is just a much more extreme case of the same "workflow changes its own settings" issue, and would be resolved by the same means.

[deanishe]

Actually, I take my above comment back: it's a huge pain that Alfred doesn't notice changes to symlinked workflows.

I don't know whether it's a change between Alfred 2 and 3 or in macOS, but Alfred used to notice changes in symlinked workflows after 20–30s. Now it never does.

 

I find myself killing and restarting Alfred a lot while developing, in order to force a reload of info.plist.

Having just written a workflow that re-writes its own info.plist (i.e. not just setting variables), I'd love to see a reload command added to Alfred's AppleScript dictionary that tells it to re-read info.plist.

A setvar command to set a variable is good, especially as it would prevent workflow's borking their info.plist through sloppy coding, but a reload one would be broadly more useful.

Edited December 21, 2017 by deanishe

[Andrew]

@deanishe no worries, this will be sorted in the new year.

 

Out of interest, are all your symlinked workflows in folders dotted around the filesystem, or do they all exist from a single separate folder. One thing I've been mulling over for quite some time is the ability to add additional paths for workflows. For example, the Alfred.alfredpreferences workflows folder by default, then additionally ~/Alfred/Workflows. Alfred would load all workflows within the additional folder in the same way.

 

This would allow you to have synced and non-synced workflows etc.

 

Cheers,

Andrew

[deanishe]

1 minute ago, Andrew said:

do they all exist from a single separate folder

 

For me, no. I have two or three separate workflow folders. I use ~/Code/Alfred where possible, but many Go tools like your projects to be on $GOPATH, so my Go workflows are tucked away somewhere under ~/src.

I also don't keep the workflow code in the project/repo root directory, so Alfred treating ~/Code/Alfred as a second workflow directory wouldn't necessarily work for me.

 

This is pretty common. A lot of folks who publish workflows put a built version in the repo, and thus keep the actual source in a separate subdirectory to avoid having workflows within workflows. That is to say, our workflows directory often looks like this:

My Workflows/
    Workflow 1/
        Workflow 1.alfredworkflow
        source/
            info.plist
            ...
    Workflow 2/
        Workflow 2.alfredworkflow
        source/
            info.plist
            ...
    Workflow 3/
        Workflow 3.alfredworkflow
        source/
            info.plist
            ...