Type index: https://quickshell.org/docs/v<version>/types/
Changelog: https://quickshell.org/changelog/
2. Inspect each type used
For every Quickshell type, verify:
import module
creatable versus singleton status
properties and their units
signals and handler parameters
invokable methods
platform or protocol restrictions
Do not infer one service's shape from another service.
Do not preserve a guessed fallback API for older versions.
Target the installed version unless the user explicitly requests multiple versions.
3. Resolve local and web disagreement
The installed module describes what the local binary exposes.
On a typical Qt 6 Linux installation, inspect:
Use the equivalent QML import directory on other systems.
*.qmltypes establishes names, properties, signals, methods, and enums,
but prose docs remain necessary for semantics such as units and lifecycle.
4. Cross-check official examples
Use the official examples repository only when the guide and type pages are insufficient.
Call the git_clone_safe tool with URL https://github.com/quickshell-mirror/quickshell-examples and an isolated destination.
Do not invoke it as a shell command.
Read the example nearest to the requested component.
Do not treat community configuration files as API documentation because they may target another Quickshell revision.
5. Record evidence honestly
qmllint provides static evidence only.
An offscreen Quickshell load provides load evidence only.
Neither proves mapped surfaces, input, compositor behavior, or service integration.
Runtime service checks require an isolated D-Bus and service environment.
Visual and interaction acceptance require a nested compositor or an explicitly approved target session.
# Getting fresh Quickshell documentation
Quickshell APIs change between releases.
Resolve the installed version before designing or changing a component.
## 1. Identify the installed version
```sh
qs --version
```
Use the exact reported version in official URLs:
- Guide: `https://quickshell.org/docs/v<version>/guide/`
- Type index: `https://quickshell.org/docs/v<version>/types/`
- Changelog: `https://quickshell.org/changelog/`
## 2. Inspect each type used
For every Quickshell type, verify:
- import module
- creatable versus singleton status
- properties and their units
- signals and handler parameters
- invokable methods
- platform or protocol restrictions
Do not infer one service's shape from another service.
Do not preserve a guessed fallback API for older versions.
Target the installed version unless the user explicitly requests multiple versions.
## 3. Resolve local and web disagreement
The installed module describes what the local binary exposes.
On a typical Qt 6 Linux installation, inspect:
```text
/usr/lib/qt6/qml/Quickshell/**/qmldir
/usr/lib/qt6/qml/Quickshell/**/*.qmltypes
```
Use the equivalent QML import directory on other systems.
`*.qmltypes` establishes names, properties, signals, methods, and enums,
but prose docs remain necessary for semantics such as units and lifecycle.
## 4. Cross-check official examples
Use the official examples repository only when the guide and type pages are insufficient.
Call the `git_clone_safe` tool with URL `https://github.com/quickshell-mirror/quickshell-examples` and an isolated destination.
Do not invoke it as a shell command.
Read the example nearest to the requested component.
Do not treat community configuration files as API documentation because they may target another Quickshell revision.
## 5. Record evidence honestly
`qmllint` provides static evidence only.
An offscreen Quickshell load provides load evidence only.
Neither proves mapped surfaces, input, compositor behavior, or service integration.
Runtime service checks require an isolated D-Bus and service environment.
Visual and interaction acceptance require a nested compositor or an explicitly approved target session.