# Flor Website

## Flor

- [The Rambling Book](/website/guide/book-index.md): Translator's note: If you can read Chinese, please prioritize reading the Chinese version; this is the author's original manuscript, other language versions are primarily translated by AI models and are for reference only.
- [](/website/guide/startup.md)
- [Glossary](/website/guide/glossary.md): This page unifies terminology in Flor documentation. When Chinese/English or API naming is inconsistent, refer to this page.
- [AI](/website/guide/ai.md): Flor's Framework DSL has similarities with React's functional UI expression. This means when using AI to assist writing Flor interfaces, AI doesn't necessarily need prior training specifically for Flor. Since many large models have already formed strong understanding capabilities on React, JSX, functional components, declarative UI etc., Flor's DSL can to some extent reuse this expression habit. In other words, when you describe an interface structure to AI, it can leverage its understanding of React-style UI organization to quickly migrate to Flor's DSL, helping you complete rapid interface building, structure adjustment and style organization. For specific view encapsulation writing, see Framework DSL. This is another manifestation of Flor's "want everything, want more, want even more" philosophy: Want the clear structure of view-based development from traditional GUI frameworks, Want the expression efficiency of modern frontend declarative UI, Want to maximally utilize the functional UI thinking AI is already familiar with, making layout design easier to generate, modify and iterate. Of course, a quiet word: Flor's initial design wasn't deliberately created to fit AI usage scenarios. It just naturally evolved along DSL API design, and only later discovered that this design is naturally suitable for AI understanding and generation. Therefore, Flor's documentation site also chose a documentation framework with AI support capabilities for its own construction. Besides regular documentation for developers to read, this site also provides documentation entries for large language models, convenient for you to provide more model-readable materials when using AI-assisted development. If you want AI to help you write Flor interfaces, explain Flor's DSL, or quickly generate a layout from description, prioritize using the LLM documentation links provided below.
- [](/website/guide/use/init.md)
- [](/website/guide/use/window.md)
- [Flor Signal Reactive System](/website/guide/use/signal.md): Flor framework has a built-in lightweight reactive signal system. This signal system is inspired by Floem, referencing its API design, but completely independently implemented by us. Unlike Floem, because of Flor's design goals, Flor Signal naturally supports cross-thread use, signals can be safely read, written and passed in multi-threaded environments. This article mainly explains how to use Signal. For complete function signatures and trait lists, see Signal API Reference.
- [External Events](/website/guide/use/handler.md): External events are a way to append event logic to already existing views. You don't need to implement a new View just to handle one click, one mouse move, one shortcut. Create view then chain call on_* methods, hand closure to Flor. These on_* methods come from EventBuilder, import it before use: Complete signature see Handler API. This page first learns by usage process: start from one click, then gradually use mouse position, keyboard, focus, lifecycle and drag-drop.
- [View State](/website/guide/use/control-state.md): Flor framework has implemented a complete view state system to manage a view's state performance in different interaction scenarios.
- [Focus Builder](/website/guide/use/builder/focus.md): This page only introduces builder methods for configuring focus table. Complete explanation of focus mechanism see Focus Mechanism, runtime APIs for manipulating focus through ViewId see ViewId. Actually exposed trait is:
- [Event Builder](/website/guide/use/builder/event.md): Event Builder is used to attach external event handlers to views. It's suitable for application-side code: you don't need to write a new view type, nor implement View, just chain bind events when creating views. Complete method list, handler types and dispatch status see Handler API. This page only explains how to use.
- [Layout Builder](/website/guide/use/builder/layout.md): Layout Builder is used to configure display mode, size, spacing, positioning, Flex/Grid and other layout properties when creating views. Basic writing is calling .layout(|layout| { ... }) after view, continuously calling layout methods in closure, finally returning modified layout.
- [](/website/guide/use/builder/class.md)
- [Style Builder](/website/guide/use/builder/style.md): Style Builder's entry is .style(|style| { ... }). It's used for manually writing view style's chain configuration, suitable when you want to directly call view-provided strongly-typed style methods, instead of writing style as class string.
- [Disable Builder](/website/guide/use/builder/disable.md): Disable Builder is used to switch view to ControlState::Disabled. It's application-side configuration view state builder, not a method custom view authors need to override in View trait. Currently exposed interface is:
- [Z-Index Builder](/website/guide/use/builder/z-index.md): Z-Index Builder is used to set z_index for views. It only affects sibling node ordering under same parent view, not global stacking context.
- [Transform Builder](/website/guide/use/builder/transform.md): Transform Builder is used to set declarative Transform2D for views. It affects view itself and its child views' drawing and hit testing, but doesn't change position and size calculated by Taffy layout.
- [](/website/guide/use/resolver-layer.md)
- [Framework DSL](/website/guide/use/framework-dsl.md): Flor's interface code can be written as a set of normal Rust DSL: functions are responsible for composing views, parameters are responsible for passing in properties, signals and handlers, and the return value is an already configured view. This has similar usage feeling to JSX: page is not a large string template, but a set of view functions that can be split, reused, passed parameters. Difference is Flor doesn't need extra template language, composition itself is Rust's function calls and chain methods. If not yet familiar with how .class(...)、.layout(...)、.style(...) multiple calls merge, first see Resolver Layer Mechanism.
- [Focus Mechanism](/website/guide/use/focus.md): Flor's focus is an explicit mechanism. Views won't automatically enter the focus system just because they can be clicked, can display text, or bound keyboard events. A view only enters the focus table when explicitly registered, then it will be accessed by Tab, will become the dispatch target for view-level on_key_*, and will have on_focus and on_blur triggered by the focus manager. First look at a minimal example: Views without focus_index won't enter the focus table. They won't be selected by Tab; when clicking them, the framework can't set focus to that view; their view-level on_focus / on_blur won't be triggered by the focus manager; their view-level on_key_* won't be triggered because "this view got focus". For specific builder writing see Focus Builder. For API to manipulate focus at runtime through ViewId see ViewId.
- [Framework Capabilities](/website/guide/features/overview.md): Framework capabilities section specifically introduces flor's optional capabilities. They are mostly enabled through Cargo features, and after enabling they expose the corresponding API, event builder or platform behavior. If you just want to look up all feature names, first see Quick Overview. This section explains platform capabilities in detail: what you can do after enabling, where the entry point is, and which tutorials/APIs are related.
- [Clipboard](/website/guide/features/clipboard.md): clipboard feature is used to enable system clipboard read/write capability. It is suitable for implementing copy, paste, import/export of temporary text and similar functionality.
- [Drag-Drop](/website/guide/features/drag-drop.md): drag-drop feature is used to enable system drag-drop events. After enabling, views can receive drag enter, hover, leave and release through event builder.
- [System Tray](/website/guide/features/tray.md): tray feature is used to enable system tray icon capability. After enabling can add, update, delete tray icons, and receive mouse events on tray icons.
- [Theme Change](/website/guide/features/theme-change.md): theme-change feature is used to enable system theme change related types and event builder. It is suitable for when the system switches from light mode to dark mode, updating the application theme or rebuilding related styles.
- [Monitor Information](/website/guide/features/monitor.md): monitor feature is used to enable monitor query capability. It is suitable for initial window positioning, multi-screen adaptation, reading work area size, adjusting custom logic by monitor DPI, and similar tasks.
- [High DPI](/website/guide/features/hi-dpi.md): hi-dpi feature is used to enable process-level DPI awareness. It will let the application receive more accurate DPI information, and let Flor update rendering scaling and layout units when window DPI changes.
- [Cross-thread Window Creation](/website/guide/features/cross-thread-window-creation.md): cross-thread-window-creation feature allows calling WindowOption::open(...) outside event loop thread to create windows.
- [ViewId](/website/guide/control/view-id.md): ViewId is view's identifier and operation handle in Flor runtime. View tree, layout state, event handlers, focus table, scroll state, mouse capture and render resources are all associated to same view through it. This page targets two scenarios: operating current view in event callbacks, or accessing runtime capabilities through self.view_id in custom view implementation. When only want to configure focus order, prefer reading Focus Builder.
- [View Trait](/website/guide/control/view-trait.md): View is Flor's view implementation interface. A concrete view provides its ViewId through it, and optionally overrides measurement, drawing, hit test, focus, input events, tooltip, drag-drop and state update hooks. Application side usually uses views provided by independent view library (for example flor_lys) when composing interface, then configures with builder. Only when writing new views, encapsulating underlying drawing logic or implementing complex interaction, need to directly implement View. View authors should focus on on_* methods. Besides must-implement view_id(), and temporary debugging tag(), don't override call_*, bus_*, visual_rect() and other non-on_* dispatch methods; they are framework internal scheduling layer.
- [Style Unit](/website/guide/control/resolver/style-unit.md): Flor's layout system uses Unit and Length types to represent size units. All units are converted to pixel values before being passed to layout engine.
- [Resolver Struct](/website/guide/control/resolver/resolver-struct.md): This page doesn't need deliberate learning, just read to have an impression. When developing views, directly use Resolver Derive Macro is enough. Resolver is Flor framework's internal style/layout resolver, used to manage state variants, unit conversion and calculation cache. View authors usually don't need to directly operate Resolver, instead through Resolver Derive Macro automatically generate implementation.
- [Resolver Derive Macro](/website/guide/control/resolver/resolver-derive.md): #[derive(Resolver)] is Flor's style parsing derive macro. It automatically generates Resolver type, chain methods, state variant support and reactive update capability for style enums. This macro has built-in view state mechanism, mainly used for view style system. It can work with class system, parse class names in on_update_class and update styles. View authors only need to define style enum, derive macro will automatically generate all Resolver related code.
- [Class Name Resolution Helper Functions](/website/guide/control/resolver/class-resolve.md): flor::view::resolver::shared provides helper functions for class name resolution, used to parse state prefixes, colors, rounded corners, font weights and other common style class names.
- [Developing a Switch View from Scratch](/website/guide/control/create-view.md): This chapter will guide you through implementing a complete Switch view from scratch. Through this process, you will master all core aspects of view development: defining style enums, implementing the View trait, drawing, measuring, supporting atomic classes, and responding to mouse events. Switch is an ideal learning case: it has "on/off" states, requires drawing a track and thumb, needs to respond to clicks, and can be customized with atomic classes for colors and sizes. After completing this chapter, you can follow the same pattern to develop your own views.

## API

- [API Overview](/website/api/index.md): This section contains query-oriented API references. Class Syntax BasicsLayout Class SyntaxSignal APIView Conversion APIHandler API
- [Class Syntax Basics](/website/api/class-syntax.md): This page describes the general parsing rules for .class(...) strings. For usage instructions, see Atomic Class Support. For the complete list of layout classes, see Layout Class Syntax.
- [Layout Class Syntax](/website/api/layout-class.md): This page lists the current support scope of Flor's built-in layout classes. For .class(...) usage instructions, see Atomic Class Support. For general class string parsing rules, see Class Syntax Basics. Layout classes are uniformly parsed by Flor and available for all views. Flex, Grid, Block related classes are controlled by features.
- [Signal API](/website/api/signal.md): This page is for querying the main public APIs of flor::signal. For usage instructions, see Signal Reactive System.
- [View Conversion API](/website/api/view.md): This page documents the public APIs in flor::view related to view identity, generic view objects, and child-view sequences. For usage-oriented guidance, see Framework DSL.
- [Handler API](/website/api/handler.md): This page is for querying the main public APIs of flor::view::handler and flor::view::builder::EventBuilder. For usage instructions, see External Events.