My gut feeling is that something happens while that method is executing that prevents AltTab from successfully exiting. Looking at the documentation of that method, it seems like a lot of things will be going on until the app will indeed stop, with multiple opportunities for the terminate sequence to be cancelled. Looking at App.shared signature, that should never return a null value, so – if the previous assumptions are correct – most likely it's the NsApplication.terminate(_ sender: Any?) that fails to stop the currently running instance. If we assume that the restart method doesn't fail in the first line, since it successfully start a new instance of AltTab, my guess would be that the second line somehow fails to stop the currently running app. break the execution flow between starting another instance and exiting the current one), that could explain this behavior. Still, if any of those two lines could fail (i.e. Unfortunately, I am not familiar at all with MacOS development. Not sure if it's good news or bad news, but seemingly there are only two lines to analyze. I'm using AltTab since Jul 15 2020, and this only happened a single time, today, about 3 weeks into using 6.13.0, so my guess would be that it's indeed related to the restart code which was changed in commit 56d47fc As it stands I don't know what to do next. How can it stay running after spawning the new instance?Īny hypothesis, steps to reproduce, etc are welcome. So even in a weird scenario, the app would quickly spawn and die, spawn and die, etc. The next line after open -n is to quit the current app. I can't picture how the code would result in 3 instances though. I guess something went wrong in your case. I didn't want to add a supervisor process that handles the restart because it's way more complexity to handle, so I used this open -n approach. I've spent a bunch of time looking online at how other people restart their app, and it's surprisingly a very complex problem. The code used to be just open + quit, and I thought it could lead to some data-races were the launch would happen while the app is still open, and trigger the preferences panel instead. The idea is that for a safer restart, it's better to first start a new instance, then quit the current one. That restart code use macOS open -n tool. The goal is to restart, run the launch sequence, realize the permission is missing, and show the user the window explaining that the permission is required to work. Oh, I found another edge-case: if you remove a required permission like Accessibility Permission in System Preferences, AltTab notices it, and restarts itself. Furthermore, on your ps output, we see that it's the same location/binary. Each would add their own login item, and multiple would thus launch after login.Īll these edge-cases have been handled. There was also a potential issue where someone could have various versions of AltTab that they downloaded to test them at some point. I made sure there that there can't be multiple AltTab. There was also an issue in the past where AltTab would start as a login item right after the user logs in their session. This way there is still a UX to open the preferences window. This is for people who hide the menubar icon. I have implemented the macOS API so that if the app is launched when it's already running, it shows the preferences window of the running app.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |