Skip to content

Latest commit

 

History

History
88 lines (63 loc) · 3.9 KB

ECOSYSTEM.md

File metadata and controls

88 lines (63 loc) · 3.9 KB
Raw

Ecosystem

This document describes the Iced ecosystem.

It quickly lists the different audiences of the library and explains how the different crates relate to each other.

Users

Iced is meant to be used by 2 different types of users:

  • End-users. They should be able to:
    • get started quickly,
    • have many widgets available,
    • keep things simple,
    • and build applications that are maintainable and performant.
  • GUI toolkit developers / Ecosystem contributors. They should be able to:
    • build new kinds of widgets,
    • implement custom runtimes,
    • integrate existing runtimes in their own system (like game engines),
    • and create their own custom renderers.

Crates

Iced consists of different crates which offer different layers of abstractions for our users. This modular architecture helps us keep implementation details hidden and decoupled, which should allow us to rewrite or change strategies in the future.

Ecosystem graph

iced_core

iced_core holds basic reusable types of the public API. For instance, basic data types like Point, Rectangle, Length, etc.

This crate is meant to be a starting point for an Iced runtime.

iced_native

iced_native takes iced_core and builds a native runtime on top of it, featuring:

  • A custom layout engine, greatly inspired by druid
  • Event handling for all the built-in widgets
  • A renderer-agnostic API

To achieve this, it introduces a bunch of reusable interfaces:

  • A Widget trait, which is used to implement new widgets: from layout requirements to event and drawing logic.
  • A bunch of Renderer traits, meant to keep the crate renderer-agnostic.
  • A Backend trait, leveraging raw-window-handle, which can be implemented by graphical renderers that target windows. Window-based shells (like iced_winit) can use this trait to stay renderer-agnostic.

iced_web

iced_web takes iced_core and builds a WebAssembly runtime on top. It achieves this by introducing a Widget trait that can be used to produce VDOM nodes.

The crate is currently a simple abstraction layer over dodrio.

iced_wgpu

iced_wgpu is a wgpu renderer for iced_native. For now, it is the default renderer of Iced in native platforms.

wgpu supports most modern graphics backends: Vulkan, Metal, DX11, and DX12 (OpenGL and WebGL are still WIP). Additionally, it will support the incoming WebGPU API.

Currently, iced_wgpu supports the following primitives:

  • Text, which is rendered using wgpu_glyph. No shaping at all.
  • Quads or rectangles, with rounded borders and a solid background color.
  • Clip areas, useful to implement scrollables or hide overflowing content.
  • Images and SVG, loaded from memory or the file system.
  • Meshes of triangles, useful to draw geometry freely.

iced_winit

iced_winit offers some convenient abstractions on top of iced_native to quickstart development when using winit.

It exposes a renderer-agnostic Application trait that can be implemented and then run with a simple call. The use of this trait is optional. A conversion module is provided for users that decide to implement a custom event loop.

iced

Finally, iced unifies everything into a simple abstraction to create cross-platform applications:

This is the crate meant to be used by end-users.