- widget tree
- a render widget to test render tree?
- a combination widget to test widget tree?
- render tree
- rebuild sub tree (1 week)
- react widget change (1 week)
- ci & workflow
- perform layout on render tree (2 weeks)
- layout flow
- base layout widget
- Row
- Column
- Center
- Flex
-
Widget Derive
-
paint
- which 2d graphic library to use?
- paint flow.
-
Theme data.
-
event
- window event
- application event, block on multi main window support
- event loop
- bubbling framework
- common events
- point event ?
- keyboard event
- wheel event
- focus event
-
include_svg.
-
widgets for todo demo
-
base widget
- Button
- Text
- ListView
- Scrollable
- Checkbox
-
input widget.
-
animations
-
A derive macro for state impl
-
refactor stateful
- into_sateful should not depend on
BuildCtx
- into_sateful should not depend on
-
auto implement declare macro to build widget.
-## we need readable & learnable documents.
-
readme
-
contributing
-
tutorial
-
api docs cover
-
how framework work
-
compose trait accept stateless/stateful enum so we not always convert a widget to stateful.
- osx
- linux, already add a test in ci.
- windows
- android
- ios
- web / WebAssembly
For now, we have Widget
as an abstract node to hold everything user declare, and then construct a tree from it. When user declare tree convert to Widget
information have be erased.
if we omit this pre box and build widget tree directly one by one, so we can keep all type information when build the tree, and can do many optimistic across the type information.
- all compose widget have be consumed.
- stateless parent and son render widget can be merged until not only sized by parent.
- some stateless render sibling can be merged.
provided declare!
macro.
a. compose widget can support directly update its subtree by compile time analyze
- block by d b. compose widget not exist in widget tree
- block by d c. compose widget should be concrete type
- after c & b finished, compose widget should be zero cost.
- block by b & i.
d. we can remove
Attribute
concept and use compose widget to implement it. - compose widget can be zero cost after b & c
- block by i.
e. we can use compose widget to implement animate, should it not depends on
BuildCtx
in dsl f. we can use compose widget as DeclareBuilder so it can not depends onBuildCtx
in dsl g.widget!
macro should not depends onBuildCtx
- block by e & f
h.
widget!
macro can use anywhere, and not depends on any context. - should add a reactive blocks to track outside widget change.
- block by e & f & g
- remove
#[widget]
attr i. addQueryType
trait to find type information