Session templates with variables #11

New issue

Closed

opened 2026-08-19 23:56:03 +00:00 by dusan · 0 comments

dusan commented

2026-08-19 23:56:03 +00:00

Owner

Context

A session is fully described by its GSettings keys (docs/spec/session-model.md),
and Duplicate (issue #8) covers "another one like that". The original plan's M7
listed session templates with variables as a further step.

What it would mean

A template is a session shape with holes in it: ssh to ${host} as ${user},
or podman exec into ${container} running ${command}. Creating a session from
one asks for the holes and fills them in.

This is speculative — nobody has asked for it, and the two things it competes with
already exist:

Duplicate covers repetition of a concrete session;
discovery already fills in the common variables by itself: the New menu
lists ssh hosts from ~/.ssh/config and containers from the installed runtimes
(docs/spec/session-types.md), so ssh to a host needs no template.

Before building it, write down a case that neither of those covers. If none
exists, close this.

If it is built

templates live beside sessions in GSettings, as their own relocatable schema —
do not overload the session schema with an "is a template" flag, or every query
has to remember to exclude them;
variables: ${name} in any string field, with a declared list of variable names
and prompts so the dialog can be built from the template rather than by scanning
for ${...};
substitution happens once, when the session is created; a session is not
re-derived from its template afterwards. Live templates mean deciding what
happens to sessions when the template changes, and that is a much larger
feature;
the created session must be a normal session in every respect — no hidden link
back — so nothing else in the codebase needs to know templates exist.

Acceptance criteria

A template can be created, listed, used to create a session, and deleted.
Creating a session from a template asks for exactly the declared variables, and
the result is indistinguishable from a hand-made session.
Changing a template afterwards does not affect sessions already made from it.
Templates never appear where sessions are expected: not in the sidebar, not in
terminalkoctl list, not in the agent's autostart set.
docs/spec/ gains a spec for it, written before the code as
CONTRIBUTING.md requires.

Notes

Lower priority than anything in issues #6–#8, which close gaps in features that
already exist.

## Context A session is fully described by its GSettings keys (`docs/spec/session-model.md`), and *Duplicate* (issue #8) covers "another one like that". The original plan's M7 listed **session templates with variables** as a further step. ## What it would mean A template is a session shape with holes in it: *ssh to `${host}` as `${user}`*, or *podman exec into `${container}` running `${command}`*. Creating a session from one asks for the holes and fills them in. This is speculative — nobody has asked for it, and the two things it competes with already exist: * **Duplicate** covers repetition of a concrete session; * **discovery** already fills in the common variables by itself: the New menu lists ssh hosts from `~/.ssh/config` and containers from the installed runtimes (`docs/spec/session-types.md`), so *ssh to a host* needs no template. Before building it, write down a case that neither of those covers. If none exists, close this. ## If it is built * templates live beside sessions in GSettings, as their own relocatable schema — do not overload the session schema with an "is a template" flag, or every query has to remember to exclude them; * variables: `${name}` in any string field, with a declared list of variable names and prompts so the dialog can be built from the template rather than by scanning for `${...}`; * substitution happens **once**, when the session is created; a session is not re-derived from its template afterwards. Live templates mean deciding what happens to sessions when the template changes, and that is a much larger feature; * the created session must be a normal session in every respect — no hidden link back — so nothing else in the codebase needs to know templates exist. ## Acceptance criteria - A template can be created, listed, used to create a session, and deleted. - Creating a session from a template asks for exactly the declared variables, and the result is indistinguishable from a hand-made session. - Changing a template afterwards does not affect sessions already made from it. - Templates never appear where sessions are expected: not in the sidebar, not in `terminalkoctl list`, not in the agent's autostart set. - `docs/spec/` gains a spec for it, written before the code as `CONTRIBUTING.md` requires. ## Notes - Lower priority than anything in issues #6–#8, which close gaps in features that already exist.

dusan closed this issue

2026-08-20 04:58:11 +00:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

dusan/terminalko#11

No description provided.

Rows
Columns