-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat(linux): expose XSetErrorHandler #12
feat(linux): expose XSetErrorHandler #12
Conversation
124fe8d
to
725f57c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I appreciate that this is an attempt of resolving #11, but adding a global error channel is clearly not the solution we want. Especially the added Err API does not tell which hotkey registration was failed, which makes returned Event completely useless.
cf377d3
to
16e8db4
Compare
I've taken another approach. Making the XSetErrorHandler an opt-in for Linux implementation only. |
@changkun any feedback here? Do you have something against the new approach? |
Thanks for contributing another workaround. The approach might solve the Linux problem, but introducing a platform-specific API is not the goal of simplicity. The issue should be resolved with the absence of public APIs regarding explicit error handling. We either stick to the runtime panic that effectively warns the user or solve the problem entirely by knowing the registration error immediately at the Register call. I do not have a chance to work on this before the end of next week, if this is needed urgently, you may switch back to a forked version that applies this patch. According to the previous discussion, I'd like to close this for the clarification of rejecting any platform-specific workarounds. Any other actual solutions that match the previously described expectations remain kindly welcome and appreciated. |
I see. Will be great if you manage to solve it properly. But I disagree that runtime panic is acceptable. IMO panic should happen only on startup and not based on user configuration that may change at runtime. On another note regarding API consistency and simplicity. There currently are platform specific variables which will be better to be handled in a single wrapper in the hotkey package.
I've currently added per platform wrappers for these: |
The key variables are different. The actual unification is
without being bothered by those convenient name shortcuts. |
Using |
If you find the package confusing then please leave it. Thanks. |
I like the package, just giving my two cents about improving it. Didn't mean to offend you or the package in any way. I apologise I sounded like that. |
Resolves: #11