-
Notifications
You must be signed in to change notification settings - Fork 96
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
Unsubscribed keybindings cause crash when used #444
Comments
As a really terrible workaround, I can overwrite all of the default keybindings with a junk action and this prevents the crash. However, these keys now become unusable for other purposes.
What this tells me is that the |
I am not a native If there are any devs who see this issue, I'd appreciate any input you can provide as to the intention of the |
This is just a common construct to separate contract from implementation. It helps decouple projects and it makes code more testable in general. In your case, you should be able to focus on As for the actual issue, I honestly have no idea what's going on here. Definitely sounds like a bug. The good news is that workspacer is fairly easy to just build and run locally, so you may be able to just load the source-code in Visual Studio, run it, and then reproduce in debug mode and just take it from there, |
In my config, I use the
UnsubsribeAll()
method from theIKeybindManager
class to get rid of any existing keybindings and apply my own. This works until I press a default keybinding. This causes Workspacer to crash. The log entry relating to the crash is below.Just simply invoking
UnsubscribeAll()
in the basic default config and then pressing one of the default keybindings causes a crash. I stripped down the config to just create 5 simple workspaces and not really do anything else. Still, the call toUnsubscribeAll()
followed by trying to use an unbound keybind causes the application to crash.The expected behavior that I'm anticipating is that keybindings that have been "unsubscribed" would be ignored by Workspacer. Somehow, this is not the case.
The text was updated successfully, but these errors were encountered: