#Window Creation and Control

Windows are created by WindowOption, returning the current window's WindowId after successful creation.

use flor::windows::WindowOption;
use flor_lys::label::label;

let window_id = WindowOption {
    title: "Hello Flor".to_string(),
    width: 800,
    height: 600,
    ..WindowOption::default()
}
.open(move |_window_id| {
    label("hello flor ~")
})?;

WindowOption handles window's initial configuration:

pub struct WindowOption {
    pub title: String,
    pub width: u32,
    pub height: u32,
    pub rem_px: f32,
    pub wait_v_sync: bool,
    pub show_fps: bool,
    pub continuous_rendering: bool,
    pub background_color: Color,
    pub tooltip_delay: Duration,
}

Default values:

continuous_rendering only controls whether event loop continuously triggers redraw, doesn't change Flor's interface model. Regular GUI applications keep default value; animation, real-time preview, game loop etc. scenarios needing per-frame refresh set to true.

#open's View Function

open signature is:

pub fn open<F, V>(self, view_fn: F) -> Result<WindowId, Error>
where
    F: Fn(WindowId) -> V + Send + Sync + 'static,
    V: IntoViewIter,

view_fn is the window root view's build function. After Flor creates platform window, renderer and window entry, it passes current window's WindowId to it, and converts return value to window root view tree.

use flor::platform::WindowId;
use flor::view::View;
use flor_lys::label::label;

fn build_view(_window_id: WindowId) -> impl View {
    label("hello flor ~")
}

WindowOption::default().open(build_view)?;

If you don't need to use window ID, write it as _window_id.

#How to Use WindowId in open Parameter

It is not recommended to directly call window control methods using the window_id in open(move |window_id| { ... }) during the root view build phase. At this time the window is completing initialization, Flor is still mounting the root view, registering the renderer, initializing focus and refreshing layout; directly calling set_size, set_window_mode, request_redraw, destroy etc. in this closure easily makes the initialization order unexpected, producing extra redraw, layout state inconsistency or platform layer behavior issues.

This WindowId is more suitable for being captured into view events, used to control current window in subsequent events:

use flor::platform::base::WindowApi;
use flor::view::builder::EventBuilder;
use flor_lys::button::button;

WindowOption::default().open(move |window_id| {
    button("Close Window").on_click(move || {
        let _ = window_id.destroy();
    })
})?;

If just setting initial title, size, background color, refresh mode, should prioritize writing in WindowOption fields, not changing in open's closure.

#WindowId

WindowId is platform window's handle wrapper. In current Windows platform implementation it's:

#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
pub struct WindowId(pub isize);

It implements WindowApi and WindowOperations. Need to import trait when calling these methods:

use flor::platform::base::{WindowApi, WindowOperations};
use flor::platform::WindowId;

#Creation and Lifecycle

#Display and Window Mode

WindowMode includes Normal, Minimized, Maximized, Fullscreen. In current Windows implementation, Fullscreen is temporarily treated as maximized.

#Position and Size

Position uses i32, allowing negative coordinates in multi-monitor environments; size uses u32.

#DPI, IME and Mouse

#Redraw

Regular view state changes are automatically requested for redraw by Flor. Only when you directly change external state through window or platform capabilities that framework can't detect, you need to manually call request_redraw().