Reference content must match the actual code
A professional reference needs more than a list of feature names. Each documented component should map to an implementation in the released SDK or IDE, identify its public API, and describe what works in the designer, runtime, and published app.
Component index
Discover controls, nonvisual components, and subsystem capabilities.
Public Python names
Published import paths, classes, functions, methods, and properties.
Behavior contracts
Event arguments, callbacks and lifecycle assumptions.
Release evidence
Supported environments and sample validation associated with a specific version.
Guide, coding reference, and book serve different purposes
The user guide explains how to operate the IDE. The coding reference documents APIs accurately. The companion book teaches programming by projects. They will be maintained as distinct editorial streams, with links between related topics.
Why you don't see a giant generated API list yet
The development repository's registry and source audit provide a foundation. This public site will only expose completed, checked entries after their names and behavior are matched to a public release.
This material explains the workflow and current development direction. Exact menu labels, Python APIs and compatibility details will be checked against the public release and identified by version.
← All documentation