raui 0.5.0

Renderer Agnostic User Interface
Documentation

RAUI Crates.ioDocs.rs

Renderer Agnostic User Interface

Table of contents

  1. About
  2. Architecture
    1. Application
    2. Widget
    3. Component Function
  3. Installation
  4. TODO

About

RAUI is heavely inspired by React declarative UI composition and UE4 Slate widget components system.

The main idea behind RAUI architecture is to treat UI as another data that you transform into target renderable data format used by your rendering engine of choice.

Architecture

Application

It is the central point of user interrest. It performs whole UI processing logic. There you apply widget tree that wil be processed, send messages from host application to widgets and receive signals sent from widgets to host application.

let mut application = Application::new();
let tree = widget! {
    (app {
        title = (title_bar: {"Hello".to_owned()})
        content = (vertical_box [
            (#{"hi"} button: {"Say hi!".to_owned()})
            (#{"exit"} button: {"Close".to_owned()})
        ])
    })
};
let mut renderer = HtmlRenderer::default();
application.apply(tree);
if let Ok(output) = application.render(&mut renderer) {
    println!("{}", output);
}

Widget

Widgets are divided into two categories:

  • Widget Node - used as source UI trees (variant that can be either a component, unit or none)
    widget! {
        (app {
            title = (title_bar: {"Hello".to_owned()})
            content = (vertical_box [
                (#{"hi"} button: {"Say hi!".to_owned()})
                (#{"exit"} button: {"Close".to_owned()})
            ])
        })
    }
    
  • Widget Component - you can think of them as Virtual DOM nodes, they store:
    • pointer to component function (that process their data)
    • unique key (that is a part of widget ID and will be used to tell the system if it should carry its state to next processing run)
    • boxed cloneable properties data (if component is a function, then properties are function arguments)
    • listed slots (simply: widget children)
    • named slots (similar to listed slots: widget children, but these ones have names assigned to them, so you can access them by name instead of by index)
  • Widget Unit - an atomic element that renderers use to convert into target renderable data format for rendering engine of choice.
    widget!{{{
        TextBox {
            text: "Hello World".to_owned(),
            ..Default::default()
        }
    }}}
    

Component Function

Component functions are static functions that transforms input data (properties, state or neither of them) into output widget tree (usually used to simply wrap another components tree under one simple component, where at some point the simplest components returns final widget units). They work together as a chain of transforms - root component applies some properties into children components using data from its own properties or state.

#[derive(Debug, Default, Copy, Clone)]
struct AppProps {
    pub index: usize,
}
implement_props_data!(AppProps);

widget_component! {
    app(props, named_slots) {
        unpack_named_slots!(named_slots => { title, content });
        let index = props.read::<AppProps>().map(|p| p.index).unwrap_or(0);

        widget! {
            (#{index} vertical_box [
                {title}
                {content}
            ])
        }
    }
}

widget_component! {
    vertical_box(key, listed_slots) {
        let items = listed_slots
            .into_iter()
            .map(|slot| ListBoxItem {
                slot: slot.try_into().expect("Cannot convert slot to WidgetUnit!"),
                ..Default::default()
            })
            .collect::<Vec<_>>();

        widget! {{{
            ListBox {
                items,
                ..Default::default()
            }
        }}}
    }
}

This may bring up a question: "If i use only functions and no objects to tell how to visualize UI, how do i keep some data between each render run?". For that you use states. State is a data that is stored between each processing call as long as given widget is alive (that means: as long as widget id stays the same between two processing calls, to make sure your widget stays the same, you use keys - if no key is assigned, system will generate one for your widget but that will make it possible to die at any time if for example number of widget children changes in your common parent, your widget will change its id when key wasn't assigned). Some additional notes: While you use properties to send information down the tree and states to store widget data between processing cals, you can communicate with another widgets and host application using messages and signals! More than that, you can assign a closure that will be called when your widget gets unmounted from the tree.

#[derive(Debug, Default, Copy, Clone)]
struct ButtonState {
    pub pressed: bool,
}

#[derive(Debug, Copy, Clone, PartialEq, Eq)]
enum ButtonAction {
    Pressed,
    Released,
}

widget_component! {
    // here we tell what data we want to unpack from
    // WidgetContext object passed to this function.
    button(key, props, unmounter, phase, state, messenger) {
        let label = props.read_cloned_or_default::<String>();

        if phase == WidgetPhase::Mount {
            drop(state.write(ButtonState { pressed: false }));
        }

        while let Some(msg) = messenger.read() {
            if let Some(msg) = msg.downcast_ref::<ButtonAction>() {
                let pressed = match msg {
                    ButtonAction::Pressed => true,
                    ButtonAction::Released => false,
                };
                println!("=== BUTTON ACTION: {:?}", msg);
                drop(state.write(ButtonState { pressed }));
                drop(signals.write(Box::new(*msg)));
            }
        }

        unmounter.listen(move |id, _state, _messages, _signals| {
            println!("=== BUTTON UNMOUNTED: {}", id.to_string());
        });

        widget!{
            (#{key} text: {label})
        }
    }
}

Installation

There is a main raui crate that contains all of the project sub-crates to allow easy access to all features needed at any time, each enabled using Cargo feature flags (by default only raui-core subcrate is enabled).

[dependencies]
raui = { version = "0.5", features = ["all"] }
  • raui-core - Core module that contains all RAUI essential logic.
    [dependencies]
    raui-core = "0.5"
    
  • raui-binary-renderer - Renders RAUI widget tree into binary format.
    [dependencies]
    raui-binary-renderer = "0.5"
    
  • raui-html-renderer - Renders RAUI widget tree into simple HTML format.
    [dependencies]
    raui-html-renderer = "0.5"
    
  • raui-json-renderer - Renders RAUI widget tree into JSON format.
    [dependencies]
    raui-json-renderer = "0.5"
    
  • raui-ron-renderer - Renders RAUI widget tree into RON format.
    [dependencies]
    raui-ron-renderer = "0.5"
    
  • raui-yaml-renderer - Renders RAUI widget tree into YAML format.
    [dependencies]
    raui-yaml-renderer = "0.5"
    

TODO

RAUI is still in early development phase, so prepare for these changes until v1.0:

  • Reduce unnecessary allocations in processing pipeline.
  • Find a solution (or make it a feature) for moving from trait objects data into strongly typed data for properties and states.
  • Create renderer for at least one popular Rust graphics engine.
  • Make C API bindings.