WindowRequestApi
WindowRequestApi 是 flor::windows 里的窗口延迟命令接口。它为 WindowId 提供一组 request_* 方法,把窗口操作加入 Flor 事件循环队列,而不是在当前调用栈里直接调用平台窗口 API。
设计目的
request_* 方法用于避免窗口操作在错误的时机直接重入平台层。
典型风险包括:
- 窗口消息处理过程中直接改窗口,导致平台消息重入。
- 响应式更新、布局刷新或绘制过程中直接
set_size/destroy,导致事件循环嵌套执行。 - 跨线程回调直接控制窗口,造成 UI 线程限制、等待顺序问题、死锁或死循环。
WindowRequestApi 会把操作延后到 Flor 事件循环的统一 flush 点:先结束当前派发,再按 FIFO 顺序执行已入队的窗口命令。
Trait
当前实现为 WindowId 实现这个 trait。
命令清单
返回值
所有 request_* 方法都会返回 WindowCommandRequest:
它用于给已入队命令挂接执行结果回调:
回调类型是:
回调会在 flush_window_commands() 执行命令后调用,不会从 result(...) 里立即调用。
result 的时机
WindowCommandRequest 是单次使用句柄。需要结果时,应在创建请求后立刻调用 .result(...):
不要先保存请求,再在很久以后挂回调。事件循环可能已经执行并移除了该命令;如果回调注册晚于命令执行,Flor 会用错误结果调用这个回调。
如果不关心结果,可以直接丢弃返回值:
跨线程行为
request_* 方法本身始终可用。是否启用 cross-thread-window-commands,影响的是跨线程提交后的事件循环唤醒行为。
cross-thread-window-commands 会自动启用 event-loop-wakeup。完整使用场景见 跨线程窗口命令。
执行顺序
命令按 FIFO 顺序执行。flush_window_commands() 每次只处理当前批次:执行过程中新增的命令会留到后续批次处理,避免递归命令不断扩展当前 flush。
执行完成后,如果命令带有 result(...) 回调,Flor 会把回调排入完成队列,再统一调用。

