matthunz / viewbuilder

Cross-platform user interface framework for Rust.

Viewbuilder

Examples

A cross-platform user interface framework for Rust.

Viewbuilder is a moduler GUI library that can be used as an entire framework, or with individual parts.

use viewbuilder::{
    view,
    web::{self, html, Web},
    ControlFlow, Model, View,
};

enum Message {
    Increment,
    Decrement,
}

#[derive(Default)]
struct App {
    count: i32,
}

impl Model<Message> for App {
    fn handle(&mut self, msg: Message) -> ControlFlow {
        match msg {
            Message::Decrement => self.count -= 1,
            Message::Increment => self.count += 1,
        }
        ControlFlow::Rebuild
    }
}

fn view(model: &App) -> impl View<Web, Message> {
    (
        format!("High five count: {}", model.count),
        view::once(html::button(
            html::on_click(|| Message::Increment),
            "Up high!",
        )),
        view::once(html::button(
            html::on_click(|| Message::Decrement),
            "Down low!",
        )),
    )
}

fn main() {
    web::run(App::default(), view)
}

Getting started

Instatllation is simple with:

cargo add viewbuilder --features full

viewbuilder's Issues

RSX view

We could wrap Dioxus' rsx! macro with our own that returns an Element

Map basic winit signals and slots to window

Difference between concoct and viewbuilder

The libraries concoct and viewbuilder look much the same from the outside, and none of the two seem to depend on the other. What is the difference between them?

Add `#[derive(Model)]`

Add Taffy support

Similar to xilem, I'd like to allow for multiple layout systems. Currently this is being tested with LinearLayout but a FlexLayout or TaffyLayout element should exist to add more layout options.

Impl `View` for `Vec<V>`

#[deny(missing_docs)]

Impl `View` for `Option<V>`

Add multi-window example

Create windows while the event loop is running

Currently running Window::new or etc will create the window using the currently stored event loop. However, if the event loop is currently running these functions will panic.

I believe it's possible to just add a queue of pending windows and have them created after the current element code is finished (e.g. a click handler call)

Roadmap to v0.6

This crate went through a major update since v0.5 with a new focus on dioxus support. I'm looking to have v0.6 be a stable foundation for the road ahead. To this end I'd like to:

• Implement tree updates
• Add basic accesskit integration
• Handle events (so far just looking at mouse inputs for clicks)
• Implement more mutations in the VirtualTree

This should be a solid foundation but if it fits I'd also like to explore

• Layered rendering with skia
• Quadtree mapping for the layout tree (for event handling)
• User-defined elements

Handle window resizing

Accesskit integration

The plan is to use accesskit for accessibility support. This should be fairly straightforward by adding the winit adapter and an Element::semantics or accessibility method.

Fix text layout

Currently Text will only request a size large enough for one line.

I'm not sure how to get the actual size of the rendered text from cosmic-text...