The shortcut schema of one ShortcutRegistry, stored in app::Settings. More...
| Header: | #include <ShortcutSettings> |
| Inherits: | QObject |
A shortcut is a setting (config-ui §CFGC-6). The schema has one `KeySequence` row per registered shortcut: the shortcut id is the row id, its name is the label, its details are the description, and its context is the section. The registered sequence is the default, read from the registry each time, so a reset returns to what the app declares now.
A write to a row is stored under `shortcuts/<id>` in app::Settings, and the row's value goes back into the registry with ShortcutRegistry::setBinding(). libshortcut stays free of libconfig. Every consumer that matches through the registry, ShortcutHelper and ShortcutDispatcher included, follows a rebind at once. A QShortcut that an app makes for a registered id follows it through follow().
An app registers its shortcuts at any time, often after this object exists. The registry tells this object about each registration, and this object adds the row and applies the stored rebind at once. So a rebind survives a restart whatever the order of the two (paint-tools §SI-5).
Two shortcuts on one sequence conflict when they share a context, or when one of them is in `global`, because ShortcutRegistry::match() tries the context and then `global`. The same holds for a context and its parents (ShortcutRegistry::setParentContext()): a key of `bahn` works in `pattern_editor`. Two contexts that never have the keyboard together, for example `bahn` and `trove.lane` in the hub, do not conflict. The schema's check across rows marks both rows invalid, and the tooltip names the other one. The write is accepted (config-ui §CFGM-5), so the operator can swap two keys in two steps.
Modifier holds and wheel chords are `Status` rows in their own sections. A chord is not a QKeySequence, so they are shown, not rebound (config-ui §CFGP-12).