search

v-yarotsky / dawg

Fancy link expander for Alfred
MIT License
2 stars 1 forks source link

Need a better way to update (preserving the config) #1

Open v-yarotsky opened 8 years ago

v-yarotsky commented 8 years ago

@deanishe mentioned that the config can be stored ~/Library/Application Support/Alfred 2/Workflow Data/<bundle id>

deanishe commented 8 years ago

There are de facto data and cache directories for each workflow.

Alfred passes their paths in the alfred_workflow_data and alfred_workflow_cache environment vars when you run your workflow, but it doesn't create the directories for you.

v-yarotsky commented 8 years ago

I just realized that neither of these folders are going to be synced between computers. How about having explicit backup/restore commands that would make use of alfred_workflow_cache? The update process would still be quite clunky, but probably not nearly as much as it is today (run dawg edit, copy contents, update, run dawg edit, paste contents).

deanishe commented 8 years ago

If I wanted to sync data between machines, I'd probably use a sibling directory to the workflow's own, e.g. ../my.bundle.id.sync-data/ or just ../my.bundle.id.data.json. It'll get synced along with all the workflows and Alfred won't overwrite or delete it.

deanishe commented 8 years ago

The smoothest solution for a situation like this (a workflow rewriting its own info.plist), imo, would be to install a Launch Agent that watches the configuration file and info.plist for changes and calls dawg -update.

That would pick up on most things that can happen, like a user editing the configuration via File > Open Recent instead of dawg edit, or all the user's Script Filters getting deleted on update. You could also drop the -n -W editing method, with its unusual application behaviour.

dawg would have to be careful to avoid an infinite loop when rewriting info.plist itself.

v-yarotsky commented 8 years ago

Moving the configuration file out of the workflow has one other downside, though – users won't be able to share the workflow with the configuration by just exporting it. For example, I'd like to share my pre-configured dawg workflow with my team so that they can just double-click to get started. With that said, I have one more solution in mind, although it can be quite tricky – code auto-update; i.e. dawg could check with github every so often to see if the new version is available, and if it is – it could just download a new binary.

deanishe commented 8 years ago

Presumably, you'd include a sample configuration with the workflow that gets copied to the proper location on install if no configuration file exists in any case. For your team, replace that with the one from your settings.

My Python workflow library has supported updates via GitHub releases for a good while. It's a super-handy feature, but it doesn't do anything complicated. It just downloads the .alfredworkflow file and tells Alfred to install it via open.