-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
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
upgrade/reinstall induce time-dependent dock and launchpad behavior #102721
Comments
Interesting. It seems that after an app has been uninstalled for a few seconds, it will be auto-removed from the Dock. That’s good smart behaviour, which happens to clash with our way of doing things. I agree this is something that should be fixed, but I also have no immediate solution. Whatever we do is bound to require changes to the I’m surprised we didn’t bump into this before. Pinging @Homebrew/brew for ideas. |
@vitorgalvao I’ve been experiencing this pretty consistently since we introduced the move-install-delete dance for I never bothered to bring it up because I ultimately don’t really use Launchpad very often. One possible approach to tackle this:
|
@claui's proposed solution makes sense to me. |
In #89497 (comment) @reitermarkus proposed to use |
As well as having to put things back in the Dock, there is the issue of a system dialog to click through before being allowed to use any of the apps displaying this beaviour: "Homebrew Cask downloaded this app on [date], etc." Could this be solved in the same way, or is this just macOS doing what macOS does now? |
That’s a macOS security feature we go to great lengths to support.
As such, there’s nothing to “solve”. You can either complain about the process to Apple via Feedback Assistant or install casks with |
Don't do that |
wait no |
Unsure if this is related but I've noticed updates also may reset/remove notification settings. For example, I have Slack installed and configured to have a notification dot on the dock icon when receiving messages. After installing updates that notification no longer works (no dot) and I have to re-configure it through system preferences. |
To add to the last comment: Big Sur asks to give the recently upgraded app permission to display notifications, even though permissions were granted for the previously installed version. |
Can we prioritise the issue? This does cases inconvenience when use you brew to have the same reproducible environment. |
You can definitely prioritize this, let us know when you have a pull request to review. |
A brute force but simple approach that works: defaults export com.apple.dock "/path/to/temporary/file"
# Do the upgrade/reinstall as usual
defaults import com.apple.dock "/path/to/temporary/file"
killall Dock It makes the Dock “flash” by being killed and reopened, but at least it the result at the end is the desired one. |
until @Homebrew preserves Dock applications Homebrew/homebrew-cask#102721 Signed-off-by: Lucas Larson <[email protected]>
@vitorgalvao Is it possible to automize this with hooks or something? |
@Phlogi, it's been some time since the last post so I'm not 100% if this will be relevant, but you can indeed make a custom shell function that automates the process @vitorgalvao described for keeping the dock consistent with # I like to simplify the upgrade process of both formulae and casks with just
# 'brew upgrade', however, you can also modify this so that the automation only
# runs when the '--greedy' flag is passed.
#
# The 'if' statement checks whether the user ran 'upgrade' with 'brew', AND if
# there are any outdated casks - where it performs the necessary commands to
# preserve the dock icon positions (including flashing when restarting 'Dock'),
# otherwise it just runs the 'brew' command as normal.
if [[ $1 == "upgrade" && `$HOMEBREW_PREFIX/bin/brew outdated --cask --greedy` ]]
then
defaults export com.apple.dock "/tmp/dock-layout.plist"
$HOMEBREW_PREFIX/bin/brew upgrade --greedy
defaults import com.apple.dock "/tmp/dock-layout.plist"
killall Dock
else
$HOMEBREW_PREFIX/bin/brew $@
fi As an optional extra, you can add the Pop the above script as a function in Zsh's Hope that someone may at least find this useful to them :). |
Thanks, as i'm using fish and i don't like the wrapping approach too much, i use the following pragmatic explicit alias:
Then just call: |
Homebrew/homebrew-cask#102721 (comment) Signed-off-by: Lucas Larson <[email protected]>
What is Zsh's |
Things going missing from the Dock is manageable, but the problems with Notifications is more frustrating (it isn't obvious in this case). I appreciate there is a brute force workaround for one part of this problem (thanks to @vitorgalvao), lets hope someone with better knowledge of LaunchServices can help with the pointers @claui provided above for a more complete potential fix. |
I agree, it's just incredibly aggravating when apps get:
It's fine to deal with these minor things on their own, but it destroys any hopes of any actual auto-upgrade in the background because I'll come back and see some app reset to defaults. |
Locking this because this has turned into "post my specific reasons why I too find this annoying" which doesn't help anyone get to the actual solution: someone caring enough to submit pull request to fix it. |
--force
.brew update-reset && brew update
and retried my command.brew doctor
, fixed as many issues as possible and retried my command.Description of issue
brew upgrade
andbrew reinstall
use the same basic logic for handling Artifacts (Apps) so this applies to both. The issue is that since upgrading to macOS 11 from Mojave, I have noticed that some apps are being removed from Dock duringbrew upgrade
. They also remove themselves from Launchpad and are then restored to the end position, but this has been the 'expected' behavior sincebrew cask upgrade
came around. A messy Launchpad I can live with, begrudgingly; a dock that loses apps is far from desirable behavior.Here is how you can reproduce this behavior. I will be using the
headset
cask as an example because it is a small and simple app that installs quickly and does not readily produce the bad behavior on my old macbook. I will also use thestress-ng
formula to slow down the upgrade/reinstall process.brew install stress-ng
brew install headset
brew reinstall headset
should work as expected without removing the app from Dock or moving it in Launchpad.stress-ng --cpu 8 --timeout 30s
.brew reinstall headset
now during the stress test causes the app to disappear from Dock and Launchpad, and then reappear in Launchpad at the end position. The degree of stress required will likely depend on your system so play with the arguments if this is not sufficient on a more recent device.I do not propose a solution here. There already exists ample discussion on this behavior elsewhere e.g. in past stale/locked issues. Related issue: #89497
Command that failed
I use the
headset
cask here as an example. Other casks where I have seen this behavior without intentionally inducing it are generally larger apps with bin linking and other complications, e.g.libreoffice
andcalibre
.Output of command with
--verbose --debug
Click to expand
Output of
brew doctor --verbose
Click to expand
Output of
brew tap
The text was updated successfully, but these errors were encountered: