giannissc

There are four user levels to using a GUI framework:

1. View composition
2. Custom interactions
3. Custom widgets
4. Framework Development

View composition

giannissc

General

• Event and Lifecycle are propagated down the entire tree but if every single events was processed by every widget that would cause performance issues.
• The mechanism which decides which events and lifecycles will be propagated to which parts of the tree is the Pod
• Some events are global (e.g. WindowSize) and are handled directly by the Pod and some are local and targeted to specific subset of widgets in the tree (e.g.MouseMove).
• Targeted events are controlled by the IS_DISABLED, IS_HANDLED, HAS_ACTIVE, IS_HOT, and HAS_FOCUS flags.

Event Handling Infrastructure

• The IS_HANDLED flag is set to false at the root of the tree by the Pod
• The widget that processes the event must set the IS_HANDLED flag through its context.
• The IS_HANDLED flag applies to keyboard and mouse events.

giannissc

UX Notes:

General Visuals

• The current state/value of a widget should be obvious/visible.
• If the value doesn't fit the last digit should be faded to indicate that the value shown is only partial. A good heuristic would be to choose a size that is large enough to fit 3 digit numbers (e.g. selecting a value between 0-100)
• Expand the label when the user is interacting with the widget.
• The the widget's state/value should always be visible, move the location of the label if necessary (e.g. when pointer is interacting with the widget)
• A widget should optionally provide an indication of the min/max boundaries, where relevant.
• The slider should optionally provide an indication of intermediate values (e.g. axis ticks) between the min/max boundaries, where relevant.
• UI elements that are used for fine control (e.g. knobs) should be big enough to make them easy to grab.
• For widgets with a single functionality the entire widget's area should optionally be wired to trigger the widget's action.

giannissc

Types of State

• Global Scope State = Application Data or Model
• Local Scope State = UI State / Empemeral State (e.g. animation progress)
• Inherited Scope State = Shared UI State / Ambient State (e.g. month selection in calendar element)
• Distributed State (e.g. tab selection shared by tab bar and a tab grid that live in different parts of the view tree)
• Transient State/Impulse Response (e.g. a button is pressed and a side bar is revealed)

Generic State Access Patterns (aka Global State)

• Subset: Callback or Adapt
• Descendent: Lens or Adapt

giannissc

Buffer<uint> Input;
RWBuffer<uint> Output;

//returns the index that this value should be moved to to sort the array
uint CuteSort(uint value, uint laneIndex)
{
    uint smallerValuesMask = 0;
    uint equalValuesMask = ~0;
    
    //don't need to test every bit if your value is constrained to a smaller range

giannissc

UI and Declarative Programming in Rust

The graphical user interface (GUI) is the cornerstone of most modern applications. It is often the main interface to use a computer program, providing a bridge from your software to someone out there in the world. Therefore, to best represent our hard-earned application logic, a GUI should be responsive, robust, and accessible.

So let's use Rust, a modern language for efficient and robust software! Well...

Why are user interfaces so hard for Rust?

I've been working on open-source Rust projects for about 8 years now,

giannissc

[unstable]
codegen-backend = true

[profile]
incremental = true

[profile.dev]
codegen-backend = "cranelift"
# If you want to attach a debugger, set this to true
debug = "line-tables-only"