A data-first Rust-native UI design toolkit.

Related tags

GUI druid


A data-first Rust-native UI toolkit.

crates.io docs.rs license chat

Druid is an experimental Rust-native UI toolkit. Its main goal is to offer a polished user experience. There are many factors to this goal, including performance, a rich palette of interactions (hence a widget library to support them), and playing well with the native platform. See the goals section for more details.

Druid's current development is largely driven by its use in Runebender, a new font editor.

We have been doing periodic releases of Druid on crates.io, but it is under active development and its API might change. All changes are documented in the changelog.

For an overview of some key concepts, see the (work in progress) Druid book.


A very good place to ask questions and discuss development work is our Zulip chat instance, in the #druid-help and #druid channels, respectively.

We gladly accept contributions via GitHub pull requests. Please see CONTRIBUTING.md for more details.


Here's a simple counter example app.

use druid::widget::{Button, Flex, Label};
use druid::{AppLauncher, LocalizedString, PlatformError, Widget, WidgetExt, WindowDesc};

fn main() -> Result<(), PlatformError> {
    let main_window = WindowDesc::new(ui_builder());
    let data = 0_u32;

fn ui_builder() -> impl Widget<u32> {
    // The label text will be computed dynamically based on the current locale and count
    let text =
        LocalizedString::new("hello-counter").with_arg("count", |data: &u32, _env| (*data).into());
    let label = Label::new(text).padding(5.0).center();
    let button = Button::new("increment")
        .on_click(|_ctx, data, _env| *data += 1)


Check out the the examples folder for a more comprehensive demonstration of Druid's existing functionality and widgets.


calc.rs example flex.rs example custom_widget.rs example

Using Druid

An explicit goal of Druid is to be easy to build, so please open an issue if you run into any difficulties. Druid is available on crates.io and should work as a lone dependency (it re-exports all the parts of druid-shell, piet, and kurbo that you'll need):

druid = "0.7.0"

Since Druid is currently in fast-evolving state, you might prefer to drink from the firehose:

druid = { git = "https://github.com/linebender/druid.git" }

Platform notes


On Linux, Druid requires gtk+3; see GTK installation page. (On ubuntu-based distro, running sudo apt-get install libgtk-3-dev from the terminal will do the job.)

Alternatively, there is an X11 backend available, although it is currently missing quite a few features. You can try it out with --features=x11.


Druid's goal is to make it easy to write and deploy high quality desktop applications with a smooth and polished user experience on all common platforms. In order to achieve this we strive for a variety of things:

  • Make it easy to build and package on all supported platforms.
  • Implement abstractions to avoid platform specific quirks.
  • Respect platform conventions and expectations.
  • Handle display resolution and scaling reliably with little effort.
  • Enable easy, yet powerful internationalization.
  • Offer robust accessibility support.
  • Produce small and fast binaries with low memory usage.
  • Have a small dependency tree, a high quality code base and good organization.
  • Focus on powerful, desktop-grade applications.
  • Provide a flexible set of layouts and common widgets.
  • Ease creation of custom components and application logic as needed.


In order to fulfill those goals, we cannot support every use case. Luckily the Rust community is working on a variety of different libraries with different goals, so here are some of Druid's non-goals and possible alternatives that can offer those capabilities:

  • Use the the platform-native widgets or mimic them. (Relm)
  • Embed easily into custom render pipelines. (Conrod)
  • Adhere to a specific architectural style such as Elm. (Iced, Relm)
  • Support rendering to HTML when targeting the web. (Iced, Moxie)

Druid is just one of many ongoing Rust-native GUI experiments. If it doesn't suit your use case, perhaps one of the others will!



The Druid toolkit uses druid-shell for a platform-abstracting application shell. druid-shell is responsible for starting a native platform runloop, listening to events, converting them into a platform-agnostic representation, and calling a user-provided handler with them.

While druid-shell is being developed with the Druid toolkit in mind, it is intended to be general enough that it could be reused by other projects interested in experimenting with Rust GUI. The druid-shell crate includes a couple of non-druid examples.


Druid relies on the Piet library for drawing and text layout. Piet is a 2D graphics abstraction with multiple backends: piet-direct2d, piet-coregraphics, piet-cairo, piet-web, and piet-svg are currently available, and a GPU backend is planned. In terms of Druid platform support via Piet, macOS uses piet-coregraphics, Linux uses piet-cairo, Windows uses piet-direct2d, and web uses piet-web.

use druid::kurbo::{BezPath, Point, Rect};
use druid::piet::Color;

// Create an arbitrary bezier path
// (ctx.size() returns the size of the layout rect we're painting in)
let mut path = BezPath::new();
    (80.0, 90.0),
    (ctx.size().width, ctx.size().height),
// Create a color
let stroke_color = Color::rgb8(0x00, 0x80, 0x00);
// Stroke the path with thickness 1.0
ctx.stroke(path, &stroke_color, 1.0);

// Rectangles: the path for practical people
let rect = Rect::from_origin_size((10., 10.), (100., 100.));
// Note the Color:rgba8 which includes an alpha channel (7F in this case)
let fill_color = Color::rgba8(0x00, 0x00, 0x00, 0x7F);
ctx.fill(rect, &fill_color);


Widgets in Druid (text boxes, buttons, layout components, etc.) are objects which implement the Widget trait. The trait is parametrized by a type (T) for associated data. All trait methods (event, lifecycle, update, paint, and layout) are provided with access to this data, and in the case of event the reference is mutable, so that events can directly update the data.

Whenever the application data changes, the framework traverses the widget hierarchy with an update method.

All the widget trait methods are provided with a corresponding context (EventCtx, LifeCycleCtx, UpdateCtx, LayoutCtx, PaintCtx). The widget can request things and cause actions by calling methods on that context.

In addition, all trait methods are provided with an environment Env, which includes the current theme parameters (colors, dimensions, etc.).

impl<T: Data> Widget<T> for Button<T> {
    fn event(&mut self, ctx: &mut EventCtx, event: &Event, data: &mut T, env: &Env) {

    fn lifecycle(&mut self, ctx: &mut LifeCycleCtx, event: &LifeCycle, data: &T, env: &Env) {

    fn update(&mut self, ctx: &mut UpdateCtx, old_data: &T, data: &T, env: &Env) {

    fn layout(&mut self, ctx: &mut LayoutCtx, bc: &BoxConstraints, data: &T, env: &Env) -> Size {

    fn paint(&mut self, ctx: &mut PaintCtx, data: &T, env: &Env) {

Druid provides a number of basic utility and layout widgets and it's easy to implement your own. You can also compose widgets into new widgets:

fn build_widget() -> impl Widget<u32> {
    let mut col = Flex::column();
    for i in 0..30 {
        let button = Button::new(format!("Button {}", i).padding(5.0);


Druid's layout protocol is strongly inspired by Flutter's box layout model. In Druid, widgets are passed a BoxConstraint that provides them a minimum and maximum size for layout. Widgets are also responsible for computing appropriate constraints for their children if applicable.


Druid uses a Data trait to represent value types. These should be cheap to compare and cheap to clone.

In general, you can use derive to generate a Data impl for your types.

#[derive(Clone, Data)]
struct AppState {
    which: bool,
    value: f64,


The Lens datatype gives access to a part of a larger data structure. Like Data, this can be derived. Derived lenses are accessed as associated constants with the same name as the field.

#[derive(Clone, Data, Lens)]
struct AppState {
    which: bool,
    value: f64,

To use the lens, wrap your widget with LensWrap (note the conversion of CamelCase to snake_case):

LensWrap::new(WidgetThatExpectsf64::new(), AppState::value);

Alternatively, lenses for structs, tuples, and indexable containers can be constructed on-demand with the lens macro:

LensWrap::new(WidgetThatExpectsf64::new(), lens!(AppState, value));

This is particularly useful when working with types defined in another crate.


The main authors are Raph Levien and Colin Rofls, with much support from an active and friendly community.

  • Screen Module, window titlebar, position, size, DPI

    Screen Module, window titlebar, position, size, DPI


    All changes are only implemented on Windows (but have skeletons for other platforms)

    • Added Screen module, where you can get infomation about the screen and monitors.

    • Added setting window size, position, maximized and minimized state.

    • Added option to disable the default titlebar.

    • Added option to let windows handle a custom titlebar like the default one (move, double click to maximize, etc (based on win-settings)).

    • Changed window creation to use window's default window size if the user does not specify a window size.

    • Implemented a solution for re-entrancy on Windows. #1068

    • Improved DPI on windows (10), should now work correctly across monitors with different dpi settings

    This should close the Window's side of #1044, #778, #634, #427. And #626

    Some use-cases I could think of for this:

    • Restore window size/position on next launch, as they where when it was closed.
    • Create custom look for titlebar.
    • Layout multiple windows (I think GIMP does/used to do this: picture).
    • Create window(s) on a particular monitor.
    • Change size to fit content, or make content fit window size (This might require additional API).
    • Create window at a spesific point (For example an app that shows information about files when users hovers over them or pop up windows, like confirm dialogs/error messages etc)
    opened by rhzk 27
  • Wayland


    A wayland backend for druid-shell.

    Very much not ready for inclusion (might never be), but I'm opening the PR early so others can experiment if they like.

    Currently some of the size calculations are broken, and there's no use input handling at all. But wayland is fun to hack on (trust me) so feel free to have a play. :smile:


    You should be able to run the empty_window example without it crashing! It draws a gradient so we can check that the memory is all aligned nicely. I'm just beginning to work on input, currently incorporating xkb so I can translate scancodes to the nice things people expect. But its 11pm here so maybe tomorrow. I've pushed the current state.

    No region invalidation yet so the invalidate example might trigger epilepsy.


    I've got to start work next week, so I've done all I can for now. You can run druid examples directly on wayland and it works! (sort of). Definitely not ready for the prime time, but I'm going to try to get the branch ready for merging, so work can continue in-tree, when I (or someone else) next gets chance.


    I've done some more work. I've refactored out the buffer management code, in an attempt to make things more modular. I've also moved to individual fields having interior mutability rather than the whole struct. A lot of fields can be Cell rather than RefCell, potentially saving a few nanoseconds. :) I've also moved to holding weak references most places, which matches how other backends work. Most druid examples will run now, although many will exhibit incorrect behavior.

    enhancement discussion shell D-Hard 
    opened by derekdreery 26
  • Window white flash on init

    Window white flash on init

    Is it possible to prevent the white flash that happens before the GUI is initially drawn? Maybe just being able to choose black rather then a white flash is enough. Seeing it in the examples on Windows.

    opened by Adarma 24
  • wayland: rebased and merge into master

    wayland: rebased and merge into master

    pull all the changes from wayland into master since we're down to just a few missing pieces in wayland (mostly pieces also missing within the x11 backend) time to let it soak in master.

    opened by james-lawrence 23
  • Scroll behavior component

    Scroll behavior component

    This is the work I outlined in https://github.com/linebender/druid/issues/73#issuecomment-658316701

    Put simply this allows any widget to very easily support scrolling on its own while picking and choosing what behaviour to support yet remaining consistent with other scrolling widgets.

    • The original Scroll widget has been renamed to AbsoluteScroll to indicate that it provides bi-directional scrolling for a child which has an absolute size. It can no longer restrict scrolling to a specific axis.
    • List now manages its own scrolling instead of having to be wrapped in a Scroll. It has gained the ability to change the layout axis to horizontal with the .horizontal() builder fn. The layout code stretches children to full size on the non-primary axis like the Flutter ListView as this solves some issues specifically with inset scrollbars which will come after this patch.
    • The now public methods and such on the scroll_component have been documented, including making some things like scrollbar point hit tests more well defined

    There are more things I want to do (specifically inset scrollbars) and a few existing bugs I noticed I want to fix but this patch should be functionally identical to existing behaviour to avoid issues with reviewing and scope.

    As an example here is the list example after changing the .fix_height(50.0) to .fix_width(200.0) and adding .horizontal() to the second List construction image

    widget architecture S-needs-review 
    opened by ForLoveOfCats 23
  • Segmentation fault (core dumped) when using MenuDesc widget and svg feature

    Segmentation fault (core dumped) when using MenuDesc widget and svg feature

    I got Segmentation fault (core dumped) crash when I enabled svg feature and attaching menu to WindowDesc.

    • Using svg feature while NOT attaching a menu to window run just fine.
    • Attaching menu to window while NOT using svg will run just fine.

    Replicated in

    • 63e34fa2 ( latest master, when this issue is filed)
    • 93620d1

    To quickly replicate: Add svg to the default feature in druid's Cargo.toml

    default = ["gtk","svg"]

    then run the example which uses menu:

    cargo run --example multiwin
    DEBUG [druid::localization] available locales [], current en-US
    DEBUG [druid::localization] resolved: [en-US]
    INFO  [multiwin] Window added, id: WindowId(1)
    Segmentation fault (core dumped)

    OS used: Ubuntu 18.04.5 LTS x86_64 Kernel: 4.15.0-118-generic

    I wasn't able to replicate this in the published 0.6.0 crate.

    shell/gtk crash 
    opened by ivanceras 19
  • Problems with TextBox::fix_width()

    Problems with TextBox::fix_width()

    Whenever I change TextBoxs width, the textbox resizes, but debug_paint_layout shows it's CollisionBox still being original size. image I can click into CollisionBox, but I cannot click outside of it. The layouts work correctly though.

    EDIT: Flex still takes the original size and not the "fixed" one.

    bug widget 
    opened by MGlolenstine 19
  • Do we need `WindowHandle::set_level`?

    Do we need `WindowHandle::set_level`?

    Is it ever necessary to change the window level after it's already created? For windows that aren't yet created, we have WindowBuilder::set_level. There was some concern in #1785 whether WindowHandle::set_level will work on x11, but I don't know about any other platforms...

    opened by jneem 18
  • Implemented scaling for widgets

    Implemented scaling for widgets

    This adds scaling support to widgets

    One can control the scaling a widget recieves with the Scale widget "Scale::new(value, child)". The scale is then propagated down the tree unless overwritten again by a new Scale widget.

    I have updated Button, CheckBox, Label, Padding, ProgressBar, RadioGroup, Scroll, SizedBox, Slider, Spinner, Stepper, Switch and TextBox to support scaling.

    I did not update the image drawing widgets as I am unsure if they should be scaled, and in that case it needs to be done on the gpu-side?

    I did think about a few different ways to implement this but I wanted to avoid any breaking change and I wanted the widgets to have control over how they scale, but if anyone thinks of a better way feel free to suggest it.

    There is also a example showing dynamic and static scaling on most widgets.

    opened by rhzk 18
  • Add debug option to display widget ids

    Add debug option to display widget ids

    This will paint the id of each widget of some subtree in the bottom right of that widget's bounds; useful for debugging various bits of event flow and widget behaviour.

    Screen Shot 2020-04-24 at 1 32 24 PM

    opened by cmyr 18
  • Designing a unified multi-click API

    Designing a unified multi-click API

    While working on #843 I also started thinking about double-clicks and how to best do them. I think that the behavior should match across platforms so that druid users can just read the druid docs and not worry about platform specifics.

    Double-clicks are good, triple-clicks possibly worth it, but what about quadruple-clicks or even more? I'm not sure there's really much value in going beyond three. It's definitely more work.

    • Windows natively supports only up to double, so will need a custom implementation anyway.
    • GTK seems to support triple clicks, so we can probably piggyback on that for up to triple.
    • macOS supports up to triple on most buttons, but seems to be practically unbounded for left and right buttons. We can piggyback on the platform for up to triple, including unbounded_count % 3.
    • Web has some support via UIEvent.detail but I haven't tested how well it works.

    Custom implementations (which Windows will need anyway) will need to be careful to follow the user configured OS setting for double click timeout.

    Thus I propose the following unified API:

    • Support for up to triple-clicks.
    • Both MouseDown and MouseUp contain the click count.
    • No extra double or triple click events, it's merely an extra event property for those who care.
    discussion shell 
    opened by xStrom 18
  • Remove outdated documentation in LifeCycle events

    Remove outdated documentation in LifeCycle events

    The documentation previously included an outdated claim that users interested in automatic focus should call register_for_focus() in response to LifeCycle::WidgetAdded. This is no longer true since the addition of LifeCycle::BuildFocusChain, so the relevant section was deleted. Additionally, this commit fixes a minor spelling error in the documentation of the latter.

    Fixes #2318 .

    opened by sprocklem 1
  • Add a public constructor to StringCursor

    Add a public constructor to StringCursor

    StringCursor fields being private is the only thing preventing a user to define its own EditableText, unless it directly wraps an existing one.

    As an exemple, with this patch it is possible to wrap a RichText, implement few traits, and use it in a TextBox.

    opened by benoitryder 0
  • Fix documentation of automatic focus in LifeCycle events

    Fix documentation of automatic focus in LifeCycle events

    Currently, the documentation tells users to to call LifeCycleCtx::register_for_focus() in the documentation for both LifeCycle::WidgetAdded (as in version 0.7) and the new LifeCycle::BuildFocusChain. I believe that the relevant section in the former simply needs to be deleted.

    I can submit a pull request for this when I have time later today, if need be.

    opened by sprocklem 2
  • When I use Image Widget, I want to initialize the image when creating it. How can I get the variables in AppState

    When I use Image Widget, I want to initialize the image when creating it. How can I get the variables in AppState

    I have a question. When I use Image Widget, I want to initialize the image to get the variables in ImageList when creating it. Thank you for your answer `fn image_list() -> impl Widget{

    let image_buf = ImageBuf::from_file("E:/bizhi/00.jpg").unwrap();
    let image_show = Image::new(image_buf).fill_mode(FillStrat::Contain).controller(ImageController{});
    let size_box_image = SizedBox::new(image_show).height(50.).width(50.);

    }` Change the address E:/bizhi/00.jpg to the variable in ImageList Thank you for your answer

    opened by dream45678 0
  • L10n example and performance improvements

    L10n example and performance improvements

    Adds an example showing how to use fluent to translate text, including a more advanced plural selection. Fixes a couple unneeded String clones in the localization implementation by using a Cow, and prevents the bidi markers from being written by fluent so we don't need to remove them.

    opened by JasperDeSutter 0
Modular FFXIV data toolkit written in rust.

ironworks Modular FFXIV data toolkit written in rust. ironworks is pre-1.0, and as such its API should be considered unstable. Breaking API changes wi

Saxon Landers 10 Oct 21, 2022
The Rust UI-Toolkit.

The Orbital Widget Toolkit is a cross-platform (G)UI toolkit for building scalable user interfaces with the programming language Rust. It's based on t

Redox OS 3.7k Jan 1, 2023
SixtyFPS is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++ or JavaScript.

SixtyFPS is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++ or JavaScript.

SixtyFPS 5.5k Jan 1, 2023
Cross-platform GUI toolkit written in Rust

Tuix is a cross-platform GUI toolkit written in Rust. The driving principle behind tuix is to be a self-contained, small-as-possible, but still fast,

George Atkinson 166 Dec 13, 2022
A Rust binding of the wxWidgets cross platform toolkit.

wxRust master: / mac(0.10): This is a Rust binding for the wxWidgets cross platform toolkit. API wxRust API documentation How it works The wxRust libr

KENZ 129 Jan 4, 2023
A light windows GUI toolkit for rust

Native Windows GUI Welcome to Native Windows GUI (aka NWG). A rust library to develop native GUI applications on the desktop for Microsoft Windows. NW

Gabriel Dube 1.6k Jan 7, 2023
A cross-platform GUI toolkit in Rust

NXUI - Native X UI A cross-platform GUI toolkit in Rust NXUI is a GUI toolkit that calls OS native APIs as much as possible to achieve fast operation.

らて 11 Jun 3, 2022
A graphical user interface toolkit for audio plugins.

HexoTK - A graphic user interface toolkit for audio plugins State of Development Super early! Building cargo run --example demo TODO / Features Every

Weird Constructor 14 Oct 20, 2022
Truly cross platform, truly native. multiple backend GUI for rust

WIP: Sauron-native a rust UI library that conquers all platforms ranging from desktop to mobile devices. An attempt to create a truly native, truly cr

Jovansonlee Cesar 627 Jan 5, 2023
Cross-platform native Rust menu library

A cross-platform Rust library for managing the native operating system menus.

Mads Marquart 16 Jan 6, 2023
Native Rust library for FastCGI

The FastCGI Rust implementation. Description gfcgi is a native Rust library for FastCGI. This library supports multithreaded socket listeners and HTTP

Andrey Gridchin 9 Aug 7, 2022
Winsafe-examples - Examples of native Windows applications written in Rust with WinSafe.

WinSafe examples This repo contains several examples of native Win32 applications written in Rust with WinSafe. All examples follow the same program s

Rodrigo 40 Dec 14, 2022
Example for Rust Android Native Development

Android console application example project based on rust & cargo-xdk

Zhuo Zhang 4 Mar 17, 2022
Windows Native Undocumented API for Rust Language 🔥

Windows Native   The Windows-Native Rust library provides a convenient and safe way to access the native Windows undocumented APIs using the Rust prog

null 3 Aug 22, 2023
Crate for simple implementation of Component for Native API 1C:Enterprise written in rust

Гайд по использованию на русском языке можно посмотреть здесь и задать вопросы по использованию, но не оставляйте там комментарии об ошибках, т.к. там

Maxim Kozlov 40 Sep 30, 2023
Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.

libui: a portable GUI library for C This README is being written. Status It has come to my attention that I have not been particularly clear about how

Pietro Gagliardi 10.4k Dec 31, 2022
OS-native file dialogs on Linux, OS X and Windows

nfd-rs nfd-rs is a Rust binding to the library nativefiledialog, that provides a convenient cross-platform interface to opening file dialogs on Linux,

Saurav Sachidanand 152 Nov 9, 2022
A tiny, neat C library that portably invokes native file open and save dialogs.

Native File Dialog A tiny, neat C library that portably invokes native file open, folder select and save dialogs. Write dialog code once and have it p

Michael Labbe 1.5k Dec 28, 2022
OS native dialogs for Windows, MacOS, and Linux

?? nfd2 nfd2 is a Rust binding to the nativefiledialog library, that provides a convenient cross-platform interface to opening file dialogs on Windows

Embark 33 May 15, 2022