Developers¶

Three pages for the two things people arrive wanting: to understand what happens under an app, and to add something to the library.

How it works — the map. Which module is which, how many lines each is, and the frame from run(app) through the escape-sequence parser to the row-diffing painter. Read this before proposing a change to view.py or runtime.py.

Writing a component — a radio set built end to end, then the conventions it demonstrates and the mistakes it avoids. A component here is a function that takes ui, takes what it should display, and returns a View; there is no base class to inherit and no state to own.

Contributing — the toolchain, the test pyramid, the house rules, and what a change has to pass before it lands. Five type checkers, because they disagree and the disagreements are where the bugs are.

Before you add to the core¶

The bar for view.py and runtime.py is higher than the bar for a widget, and deliberately so. Check whether an application can do it first, and prefer letting it until a second application wants the same thing — that rule is why there is ui.open_modal and no Screen class.

What is stable says which names are frozen at 1.0 and which are still collecting the callers that will settle their shape.