[pull] master from RustAudio:master #26
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
This should fix the inability to create OpenGL contexts with alpha channels in raw-gl-context, but it seems like that still needs a bit more work.
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.
Including @prokopyl's PR that adds more X11 error handling: glowcoil/raw-gl-context#15 Commit: prokopyl@raw-gl-context@98cd3cf1104ee254a67e3fed30e4e6b2ae2b6821 (with `cargo fmt`) Branch base: b68a05b
This only needed a couple changes for the raw-window-handle migration, and for the different module paths.
There are now three todo!()s when compiling with the OpenGL flag that need to be filled in, with the only nontrivial one being the X11 version.
This should in theory work! When requesting an OpenGL context, the window visual is determined based on the matched framebuffer config.
We're going to need this for the other platforms as well.
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.
b4a3d2b missed some immutable borrows, but these borrows need to be local anyways because of the way the closing is implemented.
So in the situation that multiple X11 clients are handling errors from different threads they don't see and interfere with each other's errors. As mentioned in glowcoil/raw-gl-context#15 (review).
Merge raw-gl-context into baseview to allow OpenGL contexts to be created during window creation
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.
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.
Add the active keyboard modifiers to the mouse events
macOS: scroll event handling
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.
RawWindowHandleWrapper is only necessary since GlContext::create takes an `impl HasRawWindowHandle` argument, but GlContext::create is an internal unsafe API and it is can just take a RawWindowHandle directly.
Forming mutable references to the WindowState is unsound given the possibility of reentrant calls to NSView methods. Instead, form only immutable references to the WindowState and wrap mutable fields in Cell and RefCell. Follow-up work should use try_borrow_mut instead of borrow_mut to avoid panicking in the case of reentrant calls.
The X11 backend has a full implementation of a `Window::set_mouse_cursor` method, but it isn't exposed via any public interface, which results in a lot of warnings for unused code. Add a public `set_mouse_cursor` method, along with stubbed-out versions in the Windows and macOS backends.
#163) These `PhantomData` fields are redundant, as the public `WindowHandle` struct already contains one.
The public Window struct holds a mutable reference to `platform::Window`, which is a pattern that doesn't make sense for all backends. On Windows, the `platform::Window` struct itself just holds another (immutable) reference, and on macOS the `platform::Window` struct has to be wrapped in a `RefCell` so that a mutable reference to it can be formed. Change the public `Window` struct to hold `platform::Window` directly, and change `platform::Window` in the macOS and X11 backends so that it simply holds a reference to another `WindowInner` struct similarly to the Windows backend. This allows us to remove the platform conditional in the declaration of the top-level `Window` struct. It also allows us to remove the `RefCell` wrapping `platform::Window` in the macOS backend and replace it with `Cell`s wrapping its individual fields.
Instead of trying to detect when to clean up the window based on the `NSView`'s retain count, require window cleanup to be initiated explicitly via `Window::close`, `WindowHandle::close`, or `[NSWindowDelegate windowShouldClose:]` (in non-parented mode; called when the user clicks the "X" button). This fixes the leaks and use-after-frees that can be caused by the inherent unreliability of the retain count logic. As discussed in #153, this change essentially means that the `NSView` created by Baseview will not be suitable as the top-level view for an Audio Unit, since the Baseview API now requires that child windows be cleaned up by an explicit call to `WindowHandle::close`, and the only reliable signal for cleaning up an Audio Unit view is a call to `[NSView dealloc]`. However, this does not mean that Baseview cannot be used in the context of an Audio Unit; it just means that plugin frameworks must implement a compatibility layer with a wrapper `NSView` (which is the approach taken by JUCE). In order to implement this change: - `WindowState` is stored in an `Rc` rather than a `Box`. - `WindowHandle` holds an `Rc<WindowState>` so that `WindowHandle::close` can directly invoke window cleanup logic. - Since the window can be closed during an event handler, `WindowState::from_view` now returns a clone of the `Rc<WindowState>` held by the `NSView` to ensure that it lives until the end of an event handler. - In the non-parented case, the `NSView` is set as the window delegate, which allows it to receive the `windowShouldClose:` call when the user clicks the "X" button, upon which it will dispatch the `WillClose` event and initiate window cleanup logic. - `Window::open_parented` and `open_blocking` no longer `release` the `NSView` immediately after attaching it. Instead, the `NSView` is released as part of the cleanup logic in `WindowInner::close`. - `Window::resize` now checks if the window is open to avoid using the `NSView` after releasing it. - The overridden `release` method, the `retain_count_after_build` field, the `ParentHandle` struct, and the `close_requested` flag have all been removed.
Add logic for CursorEntered/CursorLeft on Windows
This PR adds a simple example that allows to test and showcase the `Window::open_parented` method. That example first creates a parent window using `Window::open_blocking`, and then creates a smaller child window using `Window::open_parented`. Both window's handlers log all of their events to the console, in a similar fashion to the `open_window` example. Both windows actually do rendering (unlike the `open_window` example for now): the parent fills its window with a grey backround, and the child fills its window with a red background. This example also uses the `softbuffer` crate to perform the rendering, which allows testing it in a more portable manner and in the simplest use case possible, without having to involve OpenGL or any 3D rendering pipeline at all.
Replace the `xcb` and `xcb-util` crates with `x11rb`. We were using an old version of the `xcb` crate which had some soundness issue. `x11rb` doesn't have these issues and generally provides a safer and nicer to use API. It's possible to use `x11rb` without linking to xcb at all, using the `RustConnection` API, but unfortunately we have to use the `XCBConnection` API (which uses xcb under the hood) due to our use of the xlib GLX API for creating OpenGL contexts. In the future, it might be possible to avoid linking to xlib and xcb by replacing GLX with EGL. Getting the xlib-xcb integration to work also necessitated upgrading the version of the `x11` crate, since the version we were using was missing some necessary functionality that was previously being provided by the `xcb` crate.
trigger `WindowEvent::Focused` and `WindowEvent::Unfocused` events when the plugin window gains/loses focus. implemented by adding observers to `NSNotificationCenter::defaultCenter()` that listen to `NSWindowDidBecomeKeyNotification` and `NSWindowDidResignKeyNotification` notifications on the `NSViews`' window. tested and confirmed to work in Live, Bitwig, FL Studio, Reaper and AudioPluginHost.
* Implement input focus for Mac * Add stubs for Windows and Linux * Remove unnecessary call to window * Implement input focus for Windows * Add check for key window status * Rename to `has_focus` & `focus` * Use GetFocus * Fix incorrectly named var --------- Co-authored-by: Micah Johnston <[email protected]>
This PR adds code to render a basic gray background to the opened window in the `open_window` example. This also helps making the example a bit more useful, since most users will want to render to their window. And also it looks nicer. 🙂 This is done using the `softbuffer` crate, in the same manner of the `open_parented` introduced in #172.
Resizing should trigger a baseview resize event, but because we already set the new size here the `WM_SIZE` event was ignored. Co-authored-by: Micah Johnston <[email protected]>
This PR fixes a soundness issue inside the `XErrorHandler` utility function, which could use an xlib `Display` pointer that had no guarantee to be still valid. This could happen because the underlying `XErrorEvent` was stored directly inside the returned error type, and the `Display` pointer it contained was only called to extract the error message during in `Debug` implementation, which could happen long after the associated `Display` had been destroyed. This PR fixes this by extracting the error message upfront and storing it as a string as soon as the error happens. This PR also fixes the `handle` method that was not properly marked `unsafe`.
This adds the ability to change the cursor on Windows platforms. For some reason there are very few default cursors included in Windows so a lot of cursors available on other platforms aren't available yet, which is why many of the `MouseCursor` options just maps to `IDC_ARROW`. I'll look into adding custom cursors next. `LoadCursorW` is supposedly superseded by [LoadImageW](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadcursorw) but I couldn't find a way to do it with that one that doesn't crash. Tested with Vizia's cursor icon example [here](https://github.com/Fredemus/vizia/tree/baseview-window-events) and everything seems to work as it should. Also tested by hovering over some buttons on a plugin.
This PR splits off the X11 event loop logic into a separate module. It also changes the X11 implementation of the `Window` type to take only a shared reference to the inner type (`&WindowInner` instead of `&mut WindowInner`), bringing it in line with the other backends. This does not change any of the logic however, it only separates some of the window state from the event loop state, to make sure they don't step on each other's toes in the future (particularly around the WindowHandler). This is part of the effort to split up #174 into smaller pieces.
Co-authored-by: Micah Johnston <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )