Skip to content

Releases: RustAudio/baseview

v0.2 - Window Handler overhaul (Release Candidate 1)

25 Jun 07:28

Choose a tag to compare

(Note this is a pre-release. It will only be published to crates.io after a period of extended testing, and may still be patched with important bug fixes if necessary.)

This is the first major baseview release, which contains some (long overdue!) updates and breaking changes. 🙂

Most of them pertain to the WindowHandler trait, here are a few highlights!

New WindowContext Type

The WindowHandler used to take a temporary Window<'a> argument in every single one of its methods.

These have been removed, and now your WindowHandler type receives a WindowContext at creation time, an internal handle to the window which can be stored and cheaply cloned around:

pub struct MyWindowHandler {
  window: WindowContext
}

Window::open_blocking(options, |window| MyWindowHandler { window });

The context can give you various information and ability, such as getting/setting the window size, getting its scale factor, accessing its WindowHandle and DisplayHandle, managing keyboard focus, and more in the future!

Baseview now embraces reentrancy

WindowHandler methods took exclusive, mutable references to the handler type (&mut self). And baseview tried its best to ensure these methods were not called re-entrantly in order to be able to safely produce that &mut reference.

However, this was only reliable on X11 (since it's a network protocol, all events and responses are already de facto buffered). Re-entrancy is a widely accepted design philosophy in both the Win32 and AppKit platform APIs, so in many cases, re-entrant event handler calls from those platform would cause "already borrowed" panics and crash everything.

This is especially tricky since that behavior entirely depends on what the WindowHandler implementation (and more likely users and other libraries on top of that) does while handling an event.

Well, no more! Now WindowHandler methods only take shared (&self) references, and can be called re-entrantly.
Moreover, all WindowContext methods (resize, focus, etc.) now send a request to the underlying platform immediately.

For instance, calling resize may now immediately send a Resized event to the WindowHandler, depending on the platform.

No more waiting for initial Resized event.

It used to be that at window creation time, WindowHandlers didn't know the actual size and scaling factor of the window. Baseview would then send an artificial Resized event to properly finish setup.

Thanks to the window context being available at creation time, implementers can now directly use it to query the window's size and scaling factor!
This is now the preferred way for initialization, therefore Baseview will not send that initial Resized event any longer.

Resized is no longer an event, but a separate callback instead.

Currently, almost everything baseview does triggers on_event, and expects a reply to know whether the event was captured or ignored.

While this makes sense for e.g. input events, other events need separate types of replies, or sometimes do not expect a resize at all.

The latter is the case for resized events, so it's been moved to its own handler method:

impl WindowHandler for MyWindowHandler {
    fn resized(&self, new_size: WindowSize) {
        let size = new_size.physical;
       // Do something with the new size
    }
}

New WindowSize type

As showcased above, this version introduces a new WindowSize type, which allows to get a window's size in either logical or physical pixels, without any extra conversions needed.

With Win32 and X11 providing window sizes in physical pixels, and AppKit providing them in logical pixels, it's always guaranteed that either the logical or physical size values produced by baseview comes directly from the underlying platform without any conversions (while the other is calculated using the window's scale factor).

This allows you to use the value that's best for your use case directly, while minimizing errors due to rounding or precision loss.

Removed WindowInfo, Size et al. in favor of types from the dpi crate

Baseview used to provide its custom implementation for those basic types, which were a bit clunky to use, and also had precision issues in some edge cases.

So instead, it has been migrated to the widely used types from the dpi crate, providing us with extra interoperability in the ecosystem, as well as quite a few Quality of Life improvements!

The biggest one is that the size setting in WindowOpenOptions and WindowContext::resize now take any impl Into<Size> type.
This allows you to pass a size in either physical or logical pixels, and let baseview handle any needed conversion for the current platform!

Update to raw-window-handle 0.6 and keyboard-types 0.8

This version updates those two dependencies for easier integration with the rest of the ecosystem.
While the keyboard-types update was more trivial, raw-window-handle changed its API to make it so that HasWindowHandle types give borrowed handles, instead of owned ones.

This is what motivated the switch to WindowContext, so that it works in line with the other HasWindowHandle types. All of these are now cheaply-clonable handles that any object can hold to ensure it can still access the window and display without fear of UB.

(Note however that holding these handles still does ensure the window will remain valid, only that no UB will occur. Platform APIs may still return errors if trying to use those after the window was destroyed)

New PlatformHandle for wgpu integration

This release also brings a new PlatformHandle, a cheaply clonable handle that can be created from a WindowContext, and allows accessing the underlying platform window and display connection, via the HasWindowHandle and HasDisplayHandle traits.

The main difference with the WindowContext handle (which also implements HasWindowHandle and HasDisplayHandle) is that PlatformHandle is Send and Sync, allowing it to be sent to other threads. This allows it to be directly used with wgpu.

The trade-off is that it cannot perform any action on the window, or fetch any of the internal baseview state. Moreover, while the handle can be sent across threads, it may not be actually used off of the main thread on some platforms (most notably macOS).

See the PlatformHandle type's documentation for more information.

PRs merged in 0.2

  • Embrace reentrancy by @prokopyl in #267
  • Update to raw-window-handle 0.6, introduce new WindowContext type by @prokopyl in #273
  • Migrate custom size/position types to those from the dpi crate by @prokopyl in #275
  • Update to keyboard-types 0.8.3; migrate to NamedKey across platforms by @waywardmonkeys in #214
  • Add new PlatformHandle type and WGPU example by @prokopyl in #276
  • Update dependencies and MSRV to Rust 1.82 by @prokopyl in #278
  • Win32: Use the proper HInstance value by @prokopyl in #277
  • Make most public structs/enums non_exhaustive by @prokopyl in #279

New Contributors

Full Changelog: v0.1.4...v0.2

v0.1.4 - X11 Feature Parity & last non-breaking changes

17 Jun 18:17

Choose a tag to compare

This releases contains a few fixes, and brings X11 to feature parity by properly supporting window focus.

This is expected to be the last release of the 0.1.x (unless things happen). Work is now beginning on the 0.2 release with quite a few breaking improvements. 🙂

What's Changed

Full Changelog: v0.1.3...v0.1.4

v0.1.3 - Better Internals

15 Jun 13:34

Choose a tag to compare

This release brings a variety of fixes and improvements that needed major changes to the internals of baseview, all of which were facilitated by the previous releases!

What's Changed

New Contributors

Full Changelog: v0.1.2...v0.1.3

v0.1.2 - Safer Internals

11 Jun 20:05

Choose a tag to compare

This release is focused on reworking the internals of baseview, making them more stable, reliable and safe for future major changes.

However, there are also quite a few bug fixes, as well as a few API improvements!

What's Changed

  • Add builder-style methods to WindowOpenOptions by @prokopyl in #245
  • GLX cleanup & refactor by @prokopyl in #244
  • Introduce proper, safe Xlib/XCB wrapper by @prokopyl in #246
  • Implement HInstance, UUID, and WindowClass wrappers by @prokopyl in #247
  • Send WindowEvent::{Un}Focused on Windows, Linux (feature parity) by @AlexCharlton in #251
  • Windows: defer SetFocus tasks (bugfix) by @AlexCharlton in #252
  • Windows: Fix DND on non-parented windows (bugfix) by @AlexCharlton in #249
  • Windows: Ensure WindowEvent::Resized is sent when opening a SystemScaleFactor window (bugfix) by @AlexCharlton in #254
  • Win32: Introduce safe wrapper for window creation process and lifecycle by @prokopyl in #259
  • Win32: More safe wrappers by @prokopyl in #261
  • macOS: Refactor NSView subclass implementation by @prokopyl in #262

New Contributors

Full Changelog: v0.1.1...v0.1.2

v0.1.1 - Updated foundations

16 May 04:59

Choose a tag to compare

This version updates the foundational libraries baseview relies on with the more modern counterparts that were released over the last few years.

These bring less error-prone primitives, reduce some uses of unsafe, and allow for better maintainability.
This will allow us to go through deeper changes much more easily in the near future.

As a bonus, this version also now explicitly defines Rust 1.80 as the MSRV for baseview. This was already the case for previous versions, but it is now properly documented.

What's Changed

  • X11: Use x11-dl instead of x11 by @prokopyl in #241
  • macOS: move from objc and cocoa crates to the objc2 crates by @prokopyl in #240
  • macOS: Use CFUUID instead of the uuid crate for a random class name by @prokopyl in #243
  • Explicitly set MSRV to 1.80 by @prokopyl in #242
  • Replace winapi usage with windows by @damyanp in #218

New Contributors

Full Changelog: v0.1...v0.1.1

v0.1 - Initial release!

03 May 18:19

Choose a tag to compare

This is the first released version of Baseview! 🎉

This release means Baseview also now available on crates.io: https://crates.io/crates/baseview

This is also the first release to adhere to Semantic Versioning. Future releases of the v0.1.X branch will be semver-compatible with this one.