Skip to content
This repository has been archived by the owner on Mar 27, 2024. It is now read-only.

GUI Development Progress

Jump to bottom
Charles Saracco edited this page May 2, 2019 · 1 revision

As discussed on the How VST2 GUIs work page, most of the current Rust GUI crates will not work for our purposes due to (at least one of):

  1. No API support for connecting our window to the parent window that the DAW creates.
  2. The assumption that we want our own event queue, event loop, and/or event handling thread.

Therefore, we have decided that the best course of action would be to not use any of the crates in the current Rust ecosystem, and create our own crate instead.

Design

We are opting to use the platform "native" APIs (winapi, xcb/x11, and cocoa) so that we have very fine-grained control over the two problems mentioned above (attaching to parent and the event queue), and then providing a platform-independent wrapper so that a given VST can use the library for any given platform.

In order to provide functionality to draw to the screen, we will need to provide a platform-independent rendering context -- this will probably either be a raw OpenGL context, or a raw Vulkan/Metal context (to be determined).

Also, in order to provide a platform-independent way to handle events, we will need to convert the platform-specific events to something that every OS can use. This will probably be something like defining our own enum, and then passing that to some event handler.

Any further details about the actual API of the crate might change too rapidly for a wiki document, so check out rtb-rs for more details.

Alternatives considered

Beyond our own rtb-rs crate, there are currently several options we've been considering.

Using an already-created Rust GUI crate

TODO: list crates we've already tried, and why they're difficult to work with.

Using an embedded browser library

This approach is probably the most controversial, given that current attempts at browser-embedded frameworks like Electron are clunky at best. However, they're also ubiquitous and fast to develop.

In general, this approach seems heavy handed for plugin development if done incorrectly.

Pros:

  • Rapid development (just create HTML and CSS) and no re-skilling involved.
  • Creating the plugin system is not too difficult, as it's mainly interfacing with a built-in library.
  • Hundreds of man-hours of high-level UI work is available for free. Things we take for granted such as:
    • file support
      • fonts
      • images (vectors, png/jpg/gif/etc)
    • fancy drawing types
      • vector shapes with canvas or svg
      • drop shadows
      • curves
      • gradients
    • animations
    • advanced type/font handling
    • positioning and layout system all taken care of (harder and more opinionated than it sounds!)
    • scripting for free
    • event callbacks
    • performance optimisations
      • culling
      • drawing management
    • DOM

Cons:

  • Every environment has different available libraries (MacOS has Webkit, windows has HTMLView, etc)
  • Increases the size of the plugin
  • Increases the memory use of the plugin
  • A good one second delay between loading the library and seeing anything on the window.

The current browser framework possibilities are:

(TODO)

Clone this wiki locally