WhackyTech Workbench

I kept coming back to an awkward desktop question: why did I have to reopen several applications before I could resume one activity? For WhackyTech Workbench, I wanted Build, Research, Write, Play, and Recover to be working contexts with visible history, rather than merely names for groups of windows. The first design stretched toward building a whole environment. I pulled it back to a minimal Debian VM so I could test the interaction without first making an operating system.

The proposed stack—Xorg, xinit, FVWM3, xterm, and a command palette—was deliberately modest. The important work was assigning identity to an activity and deciding what it should restore after interruption or failure. Reviews kept returning to recovery and the boundary between the window manager and Workbench itself. The plan reached a concrete set of small contexts and a build sequence, while the VM implementation and reliable session restoration remained to be demonstrated.

The command boundary

The design centered on a shell command called wt. Both keyboard menus and direct terminal use would go through it:

wt open build
wt open research
wt show status
wt show timeline
wt log <message>
wt menu

In the supplied draft, wt open selected an activity script, recorded the current activity, appended a timeline event, and launched that script. The palette offered the same actions as a list. This meant the interaction model could be exercised from the command line before it needed a more elaborate interface.

State was intentionally plain. A current-activity file held the selected name, while a timeline log recorded timestamped events. The status view gathered basic system information, memory, and mounts. There was no custom desktop database in the plan.

Seven small working contexts

The activity scripts were deliberately uncomplicated:

Recover mattered because it was part of the normal model, not an emergency procedure hidden elsewhere. Its first version displayed information; it did not automatically run repair commands.

The proposed bindings put the palette on Super+Space, a terminal on Super+Enter, and the seven activities on Super+F1 through Super+F7. A root-window menu provided another route to the same actions.

Keeping the experiment reversible

The session flow was manual: log in at a TTY, run startx, enter the Workbench, and return to the TTY on logout. The plan called for VM snapshots before major phases and preserved that terminal login route. It avoided a display manager, autologin, bootloader changes, and automatic recovery actions.

The intention was to test activities, command routing, visible state, and recovery without also inventing a compositor, widget toolkit, or package manager. Wayland, animations, plugins, and automatic session restoration were outside the initial scope.

The unresolved part was activity ownership

The review exposed a useful weakness: the 0.1 scripts launched applications, but they did not yet define the lifetime of an activity. If Build opens two terminals, what makes Build active, closed, or failed? Can two Build activities exist? Does switching activity imply changing workspace? What happens if one child process exits?

The assistant proposed a later model with a name, workspace, start time, status, and tracked processes. It also suggested structured timeline events such as activity opening and process spawning. Those were recommendations for a subsequent version, not features proved by the shell draft.

One concrete implementation concern was the broad process-name-based logout command. A later version would need to own and terminate its specific session process rather than assume every matching window-manager process belonged to it.

The build plan had a small Debian environment and a set of activity views to try. Its unresolved question was whether Build, Research, or Write could retain enough identity and history to resume usefully after interruption. This record ends before a completed VM proves that experience.