Why I built Core Terminal.

I like the way Terminal works on my Mac. I use Linux too, and I wanted to bring that workflow with me: profiles, tabs, and saved window groups I could reopen without setting everything up again.

So I started building Core Terminal.

It was originally called Replica Terminal, and it’s my first Linux desktop application. The goal is a native Linux terminal built around that familiar workflow, with support for both Wayland and X11.

Reopening a useful setup

Profiles were a big part of what I wanted. Fonts and colors matter, but a profile also needs to remember how the shell should behave, which keyboard mappings to use, and the terminal’s starting size. Those settings belong together when they’re part of the same setup.

Window groups let me save an ordered set of tabs with their profiles, working directories, and dimensions. I can reopen the group without recreating each tab individually. It restores the terminal setup, not the programs that were running inside it.

core-terminal — saved workspace● restored

$ core-terminal --open-group daily

restored 03 tabs · profiles and directories loaded

build ~/core-terminalnotes ~/writinglogs ~/tmp

$ _

Core Terminal can also import and export supported settings in macOS .terminal profile files, so some of an existing setup can come across. It won’t reproduce every Mac-specific option, and the project documents what GTK, VTE, and Linux can support.

Then there’s the keyboard behavior. Ctrl+C copies selected text, but still interrupts a command when nothing is selected. Ctrl+V pastes. I want those everyday interactions to work the way I expect, too.

What happens when you close a tab

I’m building Core Terminal with Rust, GTK4, and VTE. GTK4 provides the desktop interface, while VTE handles terminal emulation, including shell output, selection, and scrollback. That lets me concentrate on the application around it.

Closing a tab has been one of the less visible parts of that work. The window disappearing also means dealing with its shell and any commands still running inside it, including background jobs.

A shell can look idle while background jobs are still running. A command can exit while a confirmation dialog is open. By the time someone confirms the close, the situation may have changed. The application has to check again and make sure it’s acting on the right processes.

Flatpak adds another complication: the application is inside a sandbox, but it needs to run the user’s shell and commands on the host. Cleanup has to reach those host processes. Seeing a helper inside the sandbox exit doesn’t prove that the commands outside it stopped, so the tests have to check both sides.

There’s a surprising amount involved in something that looks like a window with text in it.

Where it stands

Testing so far includes automated tests and process-cleanup checks, along with interface testing under X11 and in a nested Wayland session. There’s more desktop testing ahead. The nested session is useful, but it isn’t a replacement for running the application on the desktops people use.

Some differences from macOS are unavoidable. Under Wayland, the compositor controls top-level window placement. Core Terminal can save the tabs and their settings, but it can’t guarantee exact macOS-style screen positions when restoring a group.

I’m working on Core Terminal in my spare time, and there are still things to improve. I want to keep using it, finding what needs attention, and making it better. I hope it’s the first of more Linux applications I build.

The code, build instructions, and project documentation are on GitHub.

Back to all field notes←