Suppress the annoying "Move to /Applications?" prompt #544
Conversation
|
Bartender and Alfred both also exhibit this behavior. Is there a third party library that they're maybe all leveraging that can be handled as such? It all looks very cookie-cutter. |
|
Yes, there is, and there’s actually a compelling argument for it (even if we could argue that this would not apply to homebrew-cask users). Ultimately, since you can effectively dismiss that option on launch, I think maintaining casks “clean” would be preferable, unless we eventually come up with a better system to implement these one-off actions directly. |
|
I like the idea of Casks capturing tweaks that a user might want to implement on install. As it stands, this code executes at Class eval time (and so would write the default for every user who lists the cask). This sort of makes me things of homebrew's I wonder if it makes sense for us to look into providing something like this? I do see this as being in-line with my project goal of having Casks capture, document, and automate the complexity of mac software installation, so I think this path is worth exploring! |
I’m all for it.
And so are you. |
Whoops! Should've better learned my Ruby ;)
Definitely! Since OS X has great tools for working with the defaults system, something like my naive call to system() (without the class eval problem of course ;) should suffice as a first implementation, e.g. let the cask author add any commands that will be run. |
|
Just wanted to leave a note here that the GitHub program/cask could use this fix, too. |
|
Same with f.lux |
|
Same with Hands Off |
|
Things also presents this warning, FWIW. |
|
If F.lux is symlinked in |
@sheerun - see #30 for relevant historical discussion Currently you can change the app symlink dir with an option. If you're proposing to change the default target to |
this allows us to experiment with behavior that we may not want to promote to an official feature just yet. i'm thinking about stuff like #544, and other things i can't foresee we'll have to be careful to not let this get out of hand, but i think it could be helpful for cask authors to be able to try and problem solve locally.
|
Okay the latest release has a hook to support this, and I pulled in a modified version of the commit that uses it. It looks good from here - can folks test f-lux and submit more PRs for the other mentioned apps? 🍔 |
this allows us to experiment with behavior that we may not want to promote to an official feature just yet. i'm thinking about stuff like Homebrew#544, and other things i can't foresee we'll have to be careful to not let this get out of hand, but i think it could be helpful for cask authors to be able to try and problem solve locally.
…rompt. closes Homebrew#544 Signed-off-by: Paul Hinze <paul.t.hinze@gmail.com>
Just noticed that f.lux wants to move itself to /Applications if it is not there on launch. Figured out the default value that f.lux uses to remember the user doesn't want this behaviour and added it to the cask.
Usually, I wouldn't want any casks to touch my defaults, but in this case I think that it is in every cask user's interest to leave the app bundle where it is installed to by brew-cask and have it not moved anywhere else.