Mixed-host tabs: tabs and splits from several daemons in one layout (M4 option a) #17

New issue

Open

opened 2026-10-02 00:50:25 +00:00 by jhgaylor · 0 comments

jhgaylor commented

2026-10-02 00:50:25 +00:00

Owner

PLAN.md's deferred options:

(a) home layout, remote panes. geek's tree holds blocks whose host names another daemon. The client connects to each host directly for terminal bytes (the home daemon is still never a relay), and the tree has to cope with panes it can't reach (host down, sandbox asleep).
(b) Superlogical's model. Daemons own terminals only, and clients arrange tabs and splits. That gives up M1's "same layout live on every device".

(a) is the expected choice, since it keeps M1. The protocol was kept open for it: every block has a host (M3b), and nothing in core or the protocol may assume a pane's terminal lives on the daemon that owns the layout.

To decide

What geek's tree stores for a remote pane, and what is shown while that host is unreachable.
Creating a remote pane: geek asks the other daemon to spawn it, then records it.
Who owns size, restart policy and history for a remote pane (its own daemon, presumably).
How closing works across both trees, and what happens when the remote daemon closes it first.
CLI: illogical run --host mac --tab into the home layout.

Done when

One tab bar shows a geek tab and a Mac tab; a split in a geek tab can hold a Mac shell.
Moving such a pane by drag works the same as a local one, live on every device.
With the Mac offline, its panes show as unreachable and come back on their own when it returns.

Today a tab doesn't mix hosts (PLAN.md, M4: "Layout is per host; a tab doesn't mix hosts", decided 2026-10-01). Each daemon owns its own layout and the page switches between hosts. This milestone lets one screen hold tabs (and splits) whose terminals live on different daemons, for example a geek tab and a Mac tab side by side in one tab bar. PLAN.md's deferred options: - **(a) home layout, remote panes.** geek's tree holds blocks whose `host` names another daemon. The client connects to each host directly for terminal bytes (the home daemon is still never a relay), and the tree has to cope with panes it can't reach (host down, sandbox asleep). - **(b) Superlogical's model.** Daemons own terminals only, and clients arrange tabs and splits. That gives up M1's "same layout live on every device". (a) is the expected choice, since it keeps M1. The protocol was kept open for it: every block has a `host` (M3b), and nothing in `core` or the protocol may assume a pane's terminal lives on the daemon that owns the layout. ### To decide - What geek's tree stores for a remote pane, and what is shown while that host is unreachable. - Creating a remote pane: geek asks the other daemon to spawn it, then records it. - Who owns size, restart policy and history for a remote pane (its own daemon, presumably). - How closing works across both trees, and what happens when the remote daemon closes it first. - CLI: `illogical run --host mac --tab` into the home layout. ### Done when - One tab bar shows a geek tab and a Mac tab; a split in a geek tab can hold a Mac shell. - Moving such a pane by drag works the same as a local one, live on every device. - With the Mac offline, its panes show as unreachable and come back on their own when it returns.

jhgaylor added the

milestone

label

2026-10-02 00:50:25 +00:00