Jump to content


  • Posts

  • Joined

  • Last visited

jandubois's Achievements

Helping Hand

Helping Hand (3/5)



  1. Yes, that is a good point. I think one possible solution would be for Alfred to provide 2 environment variables to all scripts it executes: $ALFRED_CACHE and $ALFRED_CONFIG. They would be set up to point to the volatile and non-volatile app data directories (including the bundle id). By default $ALFRED_CONFIG would point to the regular ~/Library/Application Support/... folder, but if the user sets a Sync Folder, then these config directories will be moved to a subdirectory of the sync folder. The $ALFRED_CACHE setting however would continue to point to ~/Library/Caches/... It should be the responsibility of the workflow to create the actual cache and/or config directories because not every workflow needs them; Alfred would just provide the paths, but the workflow has to execute `mkdir -p "$ALFRED_CONFIG"` before creating any files in them. I don't have an opinion (yet) what should happen if the workflow doesn't have a bundle id. Maybe the $ALFRED_* variables should then not be set at all? A side benefit of this scheme is that workflow code doesn't need to embed the bundle id to create these directory paths themselves; changing the bundle id via the Alfred GUI would be enough to change them.
  2. I've just tried out the syncing feature, and find it inconvenient that persistent workflow settings are not being synced as well. E.g. for the tz workflow it would be nice if any changes to the list of configured cities would sync. Or for the WolframAlpha workflow it would be useful if the API key would sync. I understand and agree that volatile/cached data should be kept on the local machine, but I wonder why it is recommended to keep user configuration out of the workflow directory? I can see that it may be desirable to keep personal configuration data out of exported workflows. But that could be achieved by using a convention to put all such data into a Config subdirectory of the workflow folder, and the Export function could just ignore the content of that subdirectory.
  3. I actually spent several minutes trying to figure out how to display the context menu to delete various objects in workflows, or file/directory names in search scopes until I realized that I the delete key works. So it would definitely help to be more consistent in the UI: some lists have little "+" and "-" tabs to add/remove items (e.g. Themes), some only have the "+" (e.g. Search Scope), and some have neither (e.g. user defined file types). And some have context menus (e.g. Themes, but it doesn't include the Delete action), but most don't. Not a big deal, more a "polish" kind of thing...
  • Create New...