overview
LabKit Documentation
LabKit documentation is organized by the question you are trying to answer. Start with a task guide, then open an API reference only when you need exact MATLAB call syntax or returned data shapes.
Choose A Starting Point
| I want to | Start here |
|---|---|
| Install, update, or open LabKit | Getting started |
| Understand every launcher action or call it from MATLAB | LabKit Launcher |
| Choose an app and understand its inputs and outputs | App guide |
Call a reusable labkit.* function | Public API reference |
| Understand ownership and package boundaries | Architecture |
| Create or modify an app | App development |
| Run tests or diagnose performance | Testing |
| Call packaging, profiling, codecheck, or documentation tools | Maintainer tools |
| Understand documentation sources and generated HTML | Documentation system |
| Maintain a private app workspace | Private apps |
| Prepare a release | Release process |
Documentation Layers
getting-started/ installation, launcher, updates, and first-run concepts
apps/ one directory per family and one subdirectory per app
including the LabKit Launcher under LabKit Core
framework/ UI runtime concepts, behavior, and app-authoring contracts
libraries/ one directory per reusable public MATLAB facade
reference/ generated-function reference landing page
development/ reader-task folders for app building, maintenance, and tools
history/ chronological change records and the project history index
Every Markdown file is published automatically. Its path owns navigation and its first level-one heading owns the page title. Public App manuals are matched to labkit_launcher("list"); App-owned function pages are discovered from complete public MATLAB help contracts.
Reference Conventions
Public function pages follow the MATLAB reference pattern:
- summary and syntax
- description and behavior
- input arguments and options
- output arguments and data shapes
- algorithms or scientific semantics where relevant
- errors and limitations
- executable examples
- version history, See Also, and related topics
Each app family has a landing page. Each concrete app owns a directory whose README.md is its Get Started and detailed behavior page; complex apps can add focused workflow, file-format, or algorithm topics beside it. App pages explain launch, task flow, interaction rules, inputs, outputs, persistence, scientific meaning, non-GUI APIs, errors, limitations, examples, related topics, and component history as applicable. They do not document internal callbacks.
Framework and library landing pages follow the Qt module pattern: overview and ownership first, followed by grouped concepts, supported public members, detailed behavior, examples, and related modules. Generated function pages are owned by MATLAB source help blocks. Handwritten HTML is never a source.
Project History And Support
- Project history lists all change records and connects them to the affected apps, framework, and libraries.
- Support explains how to report workflow problems.