Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dterm: add caveat and uninstall #7801

Closed
wants to merge 1 commit into from
Closed

dterm: add caveat and uninstall #7801

wants to merge 1 commit into from

Conversation

L2G
Copy link
Contributor

@L2G L2G commented Dec 4, 2014

This adds a caveats stanza to highlight the need for accessibility permissions and an uninstall stanza to quit the app upon removal.

@vitorgalvao
Copy link
Member

Pinging @rolandwalker, @ndr-qef, and @claui (since you’ve expressed interested in UX).

Bringing this up since it looks like @L2G might be submitting more PRs of this form (apologies for hijacking your PR for this discussion). uninstall :quit isn’t required here, but it does make sense and can go a long way towards user perception of our care towards casks (“wow, they’ve even closed it for me”). I definitely like it, and while I’m not suggesting it should become mandatory, I’d like to know if you’d agree with encouraging it in the documentation.

@rolandwalker
Copy link
Contributor

We've had the ability to do uninstall :quit there since #4865, and it was intentionally added, so we might as well play with it to see what end-users think.

However, now that we have the app stanza, we can add app-specific logic on the backend that finds the bundle ID at runtime and operates on it implicitly as in #7854. So, at this point we could make all app Casks consistently (and implicitly) quit the app if running at uninstall time, if that was desired.

Running in the opposite direction, we are adding uninstall :trash, which is only a stub, but which when implemented would allow most app bundles to safely continue running after uninstall.

@L2G you've caught me right in the middle of removing the assistive_devices method (#7855), which will become a renamed toplevel stanza in the next release per #7854. The best way to roll with the transition is to write out the caveats literally and leave a todo comment as in plover.rb

@vitorgalvao
Copy link
Member

Thank you for the contribution, @L2G. It will be merged in a different pull request due to some simple recommended alterations. Your contribution is still included (and still credited to you), with the appropriate modifications, when applicable.

Changes:

  • Mentioned accessibility_access change.

@L2G
Copy link
Contributor Author

L2G commented Jan 8, 2015

Sounds good.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants