Alfred 3 compatibility

I'm running Alfred 3, and can confirm this workflow seems to be in good order.

Only thing I'd note is that the settings.json file is saved in ~/Library/Application\ Support/Alfred\ 2/Workflow\ Data/hue-alfred-workflow/settings.json. Not sure what kind of advice they have for that.

EDIT: Looks to be hard-coded here:

hue-alfred-workflow/logic/packages/alp/core.py

Line 73 in 2988e37

    
           nvPath = os.path.expanduser(os.path.join("~/Library/Application Support/Alfred 2/Workflow Data/", bundleID))

@stephenyeargin thanks for reporting! Can you explain what the issue is with the settings.json file?

It's writing the file to a folder that, ostensibly, should no longer be in use -- I've upgraded to Alfred 3 and removed Alfred 2. However, this workflow's configuration files are always stored in the Alfred 2 path. While nothing is broken in my testing, users that have only used Alfred 3 may not have the same success.

See the heading "Be Aware" in this blog post. The good news is that they made it backwards compatible. 😄

Some more reading on a potential solution (wouldn't be backwards compatible) - http://www.alfredforum.com/topic/9070-how-to-workflowenvironment-variables/

I agree Alfred 3 compatibility should be a priority. I don't plan on upgrading to 3 since it's a paid upgrade and I don't see any strong incentives to do it. PRs to fix this issue are welcome!

It looks like there should be no issues. Yes the alp package references an old "Alfred 2" directory, but you can see in the code that it creates it if it doesn't already exist. So without having actually tested yet, I don't anticipate any compatibility issues. Waiting on my new license key to be able to actually test.

I've updated alp's core (PR'd to original repo here: phyllisstein/alp#23) in this commit: e6135e5

However this is more of a "cosmetic" fix so that it technically refers to the correct storage/cache directories. In either case (either migration to 3 or starting at Alfred 3), the workflow as it currently is would have referred to the "Alfred 2" storage/cache dirs and silently create them if they didn't exist. Still, might as well leverage the script environment variables that Alfred provides.

I've tested this on Alfred 3.

Reopening as I've realized the "color picker" php script still has a direct reference to Alfred 2:

return `osascript -e 'tell application "Alfred 2" to search "hue lights:$lid:color:$hex"'`;

This is something that actually straight up won't work in Alfred 3.

Reopening as I've realized the "color picker" php script still has a direct reference to Alfred 2

May not be a big loss if this feature is dropped (alternatively, could create a branch that maintains support for folks using Alfred 2). In my use cases, I've only asked for specific colors by name (red, blue, white).