-
-
Notifications
You must be signed in to change notification settings - Fork 165
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
Crash resume functionality #152
Comments
It doesn't crash for me. When it crashes it opens up Terminal window with crash log. Please report the crash log. If the Terminal window doesn't open up for some reason, the latest crash log is stored in |
I've been messing around a bit and now it's no longer in the tray.
So no crash log. |
Then it means that you encountered a severe native crash The crash log should be in |
I managed to pull this:
|
Thanks for the report! It looks like it fails somewhere here https://github.com/nikitabobko/AeroSpace/blob/0ce757b/src/mouse/moveWithMouse.swift#L77 when you move the window with your mouse But I don't understand yet why it fails. The code under the question looks safe to me 🤔 |
I am encountering the same issue: crashing a few times a day depending on use. No terminal window and no folder /tmp/bobko.aerospace/ Here is an example crash log:
|
Save/restore state automatically would be great. Crashes at least once a day for me. Here are 3 more crashes https://pastebin.com/T4zRL1J6 |
oh man, wish there is a restore functionality as well, or a snapshot features similar to tmux-resurrect. But i guess that would require a background process continously record the layout every 10s interval so aerospace can use the latest one to restore the windows/app in each workspace. Looks like the layout feature is being tracked here: #57 |
I love it when I have stuff setup nicely but Aerospace will still regularly crash for me.
Is there crash tracking?
Could there be a quick and dirty way to restore the workspace state after restarting the app?
I guess this requires some checkpointing of the window state but I imagine something like: if the app starts and finds a saved state with the exact same windows (and ids) as are currently present, probably worth trying to put them all back where the saved state says they should go.
The text was updated successfully, but these errors were encountered: