#40 : Support for Google Chrome Profile

[yomybaby]

This PR fixs #40.
Now you can add your profile of Google Chrome Profile
Just add you Chrome profile directory name like this:

// without profile
browser: 'Google Chrome'

// with profile
// On Mac OS X, the directories are located in ~/Library/Application Support/Google/Chrome
browser: 'Google Chrome#Profile 1'

// with Default profile
browser: 'Google Chrome#Default'

# is separator.

It uses --profile-directory option.

I just want to share something about this issue.
With the --profile-directory option

• open command with bundle id doesn't open that profile
• Run Chrome using /Applications/Google Chrome.app/Contents/MacOS/Google Chrome opens that profile properly.

I try to find the way to use profile directory name. But I couldn't.

[johnste]

Thank you!

When I previously tried adding this feature I ran into a limitation in the Chrome browser where it would only open the supplied profile if Chrome wasn't already running. That is, if you had it running with Profile 1, triggering a rule that would open it in Profile 2 would instead open it in the existing Profile 1 issue.

I haven't tried your approach yeah so I'm interested to hear if it has the same issue.

[yomybaby]

I just tried some cases.

• Case 1: Open Chrome manually before Finicky try to run 😄
  • everything is ok. It follow all rule using chrome with porilfe 1, profile2, default.
• Case 2: Close Chrome completely, only first time works. 😢

I'll try to find a solution this weekend.

[yomybaby]

I found an open source project it work properly.
But it written by Go.

https://github.com/ShogunPanda/alfred-chrome/blob/master/alfred-chrome.go

[NicolaVerbeeck]

From what I can gather from that Go project, your changes to the same thing (https://github.com/ShogunPanda/alfred-chrome/blob/e472fc66a7c2cffda85d452ccca289d2dfd762b3/alfred-chrome.go#L127)

With 2 exceptions: they quote the profile name and put the URL as the first argument instead of the --profile-directory

[yomybaby]

I just found a solution.

If I remove task.waitUntilExit() from shell function. Everything is fine.
https://github.com/johnste/finicky/blob/master/Finicky/Finicky/Utilities.swift#L9

@johnste , Is there any reason to use waitUntilExit? If not, I'll change the code and push 😉

[johnste]

If there was a reason I don't remember it. If it solves the problem it's definitely an option to remove it.

It'll take me a few days/a week or so to be able to test this and review it,

[johnste]

Seems like it's working! That's awesome!

It would be great to refer to the profile by the profile name instead of folder name. Seems like the profile name is stored in a json file called Preferences under path profile.name. Would you be able to make that work too? To make it work really well finicky should probably tell you if a profile couldn't be found (and maybe log a list of existing profiles?)

[yomybaby]

Thank for letting me know about proifle.name. Ok, I'll try to make some changes for using that name instead of folder name.

I'll check this function first :
https://github.com/ShogunPanda/alfred-chrome/blob/master/alfred-chrome.go#L92-L117

[vendruscolo]

This is good, thanks! What do you think about using a separate key in the config file to pass the option down to the open command? I was thinking about having something similar to this:

browser: "Google Chrome",
profileName: "Work"

Or even something else entirely:

browser: "Google Chrome"
customArgs: "--profile-directory=Work"

The former is self explanatory and it would make everything explicit, with the advantage that we could easily bring that to other browsers that support profiles. And as you suggest, we can easily validate it.

The latter opens up a world for advanced users that might want to pass some other configuration that we can't think of at this time. For this specific scenario though, makes things hard to discover and validate. (I prefer the first myself)

[johnste]

@vendruscolo I like the idea of using a separate property for the profile name, the first option.

There are request to be able to run a script instead of starting an application #89 which fits pretty well with the second option. I'm not against bringing in custom arguments or arbitrary scripts, but as you mention they can't be validated and have to be an obvious "power feature" that can be scary.

[vendruscolo]

Awesome. Let me know if I can help in any way :)

[johnste]

Closing this in favor of this pull request
Thank you all!

[yomybaby]

Oh great! Thank you.