Jump to content
deanishe

Alfred is slow to notice external changes to workflow info.plist

Recommended Posts

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 by deanishe

Share this post


Link to post

@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

Share this post


Link to post
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 by deanishe
comma comma comma comma, comma chameleon

Share this post


Link to post

@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.

Share this post


Link to post
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.

Share this post


Link to post

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
×