Duplicate a session #8

New issue

Open

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

dusan commented

2026-08-19 23:55:19 +00:00

Owner

Context

A session is a set of GSettings keys under
/me/dusansimic/terminalko/sessions/<uuid>/, described by a relocatable schema
(data/me.dusansimic.terminalko.session.gschema.xml) and wrapped by
terminalko_config::Session. There are around twenty keys: name, colour, type,
command, cwd, env, login-shell, autostart, persistent, restart, confirm-close,
the ssh trio, the container trio, the escalation pair, and the font, palette and
scrollback overrides.

Store::create_session(folder, name) makes a new one with defaults.

The gap

There is no way to copy a session. Setting up a second session that differs from
an existing one in one field means re-entering every field. The original plan
listed Duplicate in the session context menu; it was never implemented.

Approach

Add Store::duplicate_session(&self, id: &str) -> Session in
crates/terminalko-config/src/session.rs:

create a new session in the same folder, immediately after the original, so it
appears next to what it was copied from (create_session then move_session,
or a create_session_at);
copy every key rather than a hand-written list. SettingsSchema::list_keys
gives the names — the same approach reset_all already uses for deletion — so a
key added later is copied without anyone remembering to update this;
give the copy a distinguishable name: "<name> copy" is enough, and the user
is about to rename it anyway;
do not copy anything that must be unique. Today nothing is: the id is the path,
not a key. If that ever changes, this is where it matters.

Then a win.session-duplicate action and a menu entry beside Rename….

Acceptance criteria

Duplicating a session produces one with every setting identical except the
name, verified by a test that sets a non-default value for each key, copies,
and compares — not a spot check.
The copy lands next to the original, in the same folder, and survives a
restart.
Duplicating a running session does not touch the running one, and the copy is
not started automatically.
Adding a key to the schema does not require touching the duplication code; the
test above should fail if that stops being true.
./build-aux/ci.sh passes.

Notes

Tests go in crates/terminalko-config/src/session.rs, which runs headless with
GSETTINGS_BACKEND=memory — see the with_store helper.
BSD-2 rules in CONTRIBUTING.md apply.

## Context A session is a set of GSettings keys under `/me/dusansimic/terminalko/sessions/<uuid>/`, described by a relocatable schema (`data/me.dusansimic.terminalko.session.gschema.xml`) and wrapped by `terminalko_config::Session`. There are around twenty keys: name, colour, type, command, cwd, env, login-shell, autostart, persistent, restart, confirm-close, the ssh trio, the container trio, the escalation pair, and the font, palette and scrollback overrides. `Store::create_session(folder, name)` makes a new one with defaults. ## The gap There is no way to copy a session. Setting up a second session that differs from an existing one in one field means re-entering every field. The original plan listed **Duplicate** in the session context menu; it was never implemented. ## Approach Add `Store::duplicate_session(&self, id: &str) -> Session` in `crates/terminalko-config/src/session.rs`: * create a new session in the same folder, immediately after the original, so it appears next to what it was copied from (`create_session` then `move_session`, or a `create_session_at`); * copy **every** key rather than a hand-written list. `SettingsSchema::list_keys` gives the names — the same approach `reset_all` already uses for deletion — so a key added later is copied without anyone remembering to update this; * give the copy a distinguishable name: `"<name> copy"` is enough, and the user is about to rename it anyway; * do not copy anything that must be unique. Today nothing is: the id is the path, not a key. If that ever changes, this is where it matters. Then a `win.session-duplicate` action and a menu entry beside *Rename…*. ## Acceptance criteria - Duplicating a session produces one with every setting identical except the name, verified by a test that sets a non-default value for **each** key, copies, and compares — not a spot check. - The copy lands next to the original, in the same folder, and survives a restart. - Duplicating a running session does not touch the running one, and the copy is not started automatically. - Adding a key to the schema does not require touching the duplication code; the test above should fail if that stops being true. - `./build-aux/ci.sh` passes. ## Notes - Tests go in `crates/terminalko-config/src/session.rs`, which runs headless with `GSETTINGS_BACKEND=memory` — see the `with_store` helper. - BSD-2 rules in `CONTRIBUTING.md` apply.

dusan referenced this issue

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

Per-session icon: decide whether it is wanted #10

dusan referenced this issue

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

Session templates with variables #11

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#8

No description provided.

Rows
Columns