Menu
Layouts and shortcuts
Three customisation mechanisms, all backed by the registry: named layouts, which record the arrangement of the docks and create a command; the keybinding table, kept separate from commands so that remapping acts on the binding; and the widget registry, which turns the dashboard into a surface fed by contributions.
Named layouts
A layout is a snapshot of the workbench: open panels, active panel per dock, sizes, and the effective zones of panels that were moved. It does not contain the panels' internal state: applying a layout repositions panels, it does not replay what they contained.
var L = window.IsoFindLayouts;
L.liste(); // ['Audit', 'Traceability']
L.enregistrer('Traceability'); // K.shell.snapshot(), then registers a command
L.appliquer('Audit'); // K.shell.restore(...)
L.renommer('Audit', 'Control');
L.supprimer('Control');
L.gerer(); // manager, command core.layouts.manage
| Behaviour | Detail |
|---|---|
| Saving creates a command | The layout appears in the palette and the Actions panel, and can be given a shortcut. |
| Dedicated widget | Layouts can be applied in one click from the dashboard. |
| Renaming | Renames the command. Deleting disposes its token. |
| Reset | K.shell.reset() closes everything and returns each panel to its declared zone, without deleting saved layouts. |
Keyboard shortcuts
The keybinding table maps a combination to a command identifier. Remapping acts on the binding, never on the command: a plugin therefore cannot impose a key the user has reassigned.
Shipped defaults
| Combination | Command |
|---|---|
| Ctrl+Shift+P | core.palette.open |
| Ctrl+Shift+E | core.fichiers.toggle |
| Ctrl+Shift+J | core.journal.toggle |
| Ctrl+Shift+H | core.historique.toggle |
| Ctrl+Shift+D | core.db.toggle |
| Ctrl+Shift+A | core.actions.toggle |
| Ctrl+Shift+M | core.problemes.toggle |
| Ctrl+Shift+L | core.layouts.manage |
| Ctrl+Shift+K | core.keys.manage |
| Ctrl+I | app.outils.isofImport |
| Ctrl+E | app.outils.isofExport |
| Ctrl+Shift+I | app.donnees.importCSV |
| Ctrl+Shift+S | app.donnees.backupDatabase |
The defaults are deliberately few. Binding all ninety-six domain actions would produce ninety-six combinations, of which nobody would remember the tenth, and which would collide inside editors. The shipped combinations cover everyday actions; the rest goes through the palette.
Three resolution rules
| Rule | Consequence |
|---|---|
| A binding is only installed if its command exists on the page. | A key that did nothing would look like a broken shortcut. The number of active shortcuts therefore varies from page to page. |
| On a given combination, candidates are walked from most recently bound to oldest, and the first available command wins. | Conflicts are not refused: forbidding duplicates would stop a plugin from claiming a key the user never reserved for it. They are shown, and the user decides. |
| A combination without a modifier does not fire inside an input field. | Otherwise binding "n" to a command would make it impossible to type the letter n, and the symptom would be blamed on the keyboard. With a modifier the key always passes through: Ctrl+F inside an editor must reach the application. |
Help
›
Keyboard shortcuts
›
core.keys.manage
The screen lists the installed shortcuts, flags conflicts and allows remapping. This screen is as much for discovering shortcuts as for changing them: without a list to consult, a shortcut is only used by those who already knew it existed.
// Low-level API, in the kernel
var token = K.keybindings.bind('ctrl+alt+p', 'phreeqc.simulation.lancer');
K.keybindings.list(); // [{ combo, commands: [...] }, ...]
K.keybindings.unbindAll('ctrl+alt+p');
token.dispose();
Dashboard widgets
The dashboard is a widget host fed by the registry. A plugin that declares a widget sees it appear without any page being modified, including if it loads after the mount: the mount listens to dashboard.changed.
K.dashboard.registerWidget({
id: 'phreeqc.dernieres',
source: 'phreeqc',
order: 60,
title: { fr: 'Dernières simulations', en: 'Recent simulations' },
factory: function (ctx) {
// ctx.root : the card element. May be filled asynchronously.
}
});
var mounted = K.dashboard.mount(host); // { rafraichir, dispose }
K.dashboard.widgets(); // the list, sorted by order
K.dashboard.remonter(); // redraws wherever the dashboard is mounted
Kernel widgets
Four widgets, each tied to a question that comes up when the software is opened.
| Widget | Question | On click |
|---|---|---|
| Resume | What was I doing last time? | Reopens the object. |
| Modifications | What changed in my data? | Emits historique.ouvrir, which loads the History panel on that sample. |
| Favourite actions | What do I do every day? | Runs the command. |
| Layouts | How do I get set up again? | Applies the layout. |
Two more are added: Workflows (saved chains, runnable in one click) and Notebooks (recent notebooks, opened in the Notebook panel).
No widget shows a counter such as "224 samples". The figure is accurate but leads to no action, and it would take the most visible area of the screen. Every shipped widget opens an object that was already being worked on.
Visibility
The modifications widget reads the signed registry through the user's visibility clause, applied on the backend. The dashboard is displayed on every start, often in front of people who do not have access to every sample. If the clause fails, the route returns an error rather than an unfiltered list.
Dashboard profiles
A profile is applied on first open, without overwriting later customisations. The researcher profile favours multi-family descriptive statistics and makes the science-watch widget conditional on air-gap mode being off. Available profiles follow the modules opened by the licence.