Buttons 6 and 7 are for horizontal scrolling, just like buttons 4 and 5
are for vertical scrolling. I couldn't find a list of button numbers in
the X11 protocol specs, but this is what the buttons are bound to on my
Logitech G502 and
http://xahlee.info/linux/linux_x11_mouse_button_number.html also
confirms this.
The next frame's time stamp needs to be computed based on the last
frame's, not based on the current time, unless the last frame took too
long to process.
This would solve the most important use case for #116. Only the Linux
version has been tested, but the Windows should work perfectly fine, and
I don't know anything about macOS programming but that version also
compiles so it should be fine.
Since this isn't emitted anywhere, this can only lead to confusion for
library consumers. They'd need to implement their own click detection
with the button up and button down events.
The things remaining are all of the cursor things in the X11
implementation (there's _a lot_ of it, so there's probably a reason why
it's all still there but unused), and the super unsound immutable
reference to mutable reference cast in the macOS implementation that
Clippy automatically errors out on.
The main change is that all of these types are simplified, there are
more different OS-specific window handle types, and they are no longer
gated behind the respective targets which makes the library a bit easier
to use for applications.
* add ability to close window from user code, add HostWindowHandle
* fix manual close method for Mac, rename HostWindowHandle to ChildWindowHandle
* fix rustfmt.toml and run cargo format
* fix merge conflict mistake
* fix more merge conflict mistakes
* implement requested changes (with a non-broken commit this time)
* implement requested changes
* slight reordering of impls
* drain autorelease pools in Window::open_* methods
* fixes to NSView lifetime logic:
- in open_parented and open_blocking, release NSView after adding
it as a subview of the parent
- in open_blocking, don't call autorelease on NSWindow. previously
it was a no-op, but now that we are actually draining our
autorelease pools, it ends up prematurely releasing the window.
* fixes to NSView cleanup logic:
- Move retainCount check to before calling [super release].
If [super release] happens first, then in the final call to
release, [super release] deallocates the object and the call to
retainCount results in a segfault.
- Move objc_disposeClassPair to dealloc. Previously we were
calling it when retainCount == 1, but that's exactly when
dealloc is called, so this is cleaner. Also, we need to call
objc_disposeClassPair after [super dealloc].
NOTE: The circular-reference-breaking logic in release is
definitely broken. It's easy to thwart it by e.g. creating a
wgpu surface at some point after build() or dropping one at some
point before drop(). Need to come up with a better solution.
