Named profiles for the home directory a box is given

[kacperpaczos]

Creating a box already takes a custom home directory - create_box passes it to --home - but it is a bare path field labelled "Home Directory (Leave blank for default)". Nothing says what it changes, and using it for more than one box means remembering paths and retyping them.

This puts a name on that directory and calls it a profile.

What it does

• Profiles in the primary menu: a window listing profiles, each showing the directory it points at, with Browse (opens it in the file manager) and Remove. Adding one takes a name and puts the directory under ~/boxes/<name>.
• New-box form: the home directory is now decided by one row. Profile lists Host (shared home), then the profiles, then Custom folder… which opens the same folder chooser the form had before; the chosen directory shows as the row's subtitle. The separate "Home Directory" entry and its button are gone - they were a second control for the same setting, with nothing to say which of the two won. Cancelling the chooser falls back to Host rather than leaving the row claiming a folder nobody picked. What this costs is typing a path by hand; in a graphical form a chooser seemed the better way to name a directory, but say the word and the entry comes back.
• The value handed to distrobox is unchanged, so this is a way of choosing the option that already exists, not a new mechanism. Every existing box keeps using the host's home.

Profiles are stored in GSettings as a name-to-path map (a{ss}), the same shape and helper style as the terminal preference. No new dependencies, no new files.

Why it is useful

A box whose home is its own keeps that home's dotfiles to itself, so an application running in it has its own settings and logins while the rest of the host's files stay reachable - /home/you/projects is still there, just not under ~. Exports are unaffected: distrobox-export resolves the host home from DISTROBOX_HOST_HOME, so applications added to the menu and commands added to the terminal still land on the host. That makes a box a usable profile for a tool you sign into, without a second user account.

The directory is created when it is first needed - by distrobox when a box is built, or by Browse when someone looks at it - rather than at the moment the profile is named.

Screenshots

Testing

cargo test: 7 pass, including new ones pinning the name rules (accepts work, Personal 2, a_b-c; rejects empty, whitespace, over-long, and anything with /, " or $).

End to end on a virtual display with an isolated $HOME, an isolated GSettings keyfile backend and a scratch schema: adding a profile writes profiles={'praca': '…/boxes/praca'} and the row appears with both buttons; Browse creates the directory that was not there before. With a stub distrobox logging its arguments, creating a box gives:

# Host (shared home)
create -n test-host -i docker.io/library/fedora:40 -Y
# profile "praca"
create -n test-praca -i docker.io/library/fedora:40 -Y --home /…/boxes/praca

so nothing changes unless a profile is chosen.

Two things worth a decision

• Two boxes pointing at one profile share that home, and therefore share the applications' settings. That is the point of naming it - "my work home" - but it does mean two boxes running the same application under one profile share its login. Happy to make a profile single-box if you would rather.
• Removing a profile only forgets the setting; it does not touch the directory or any box built on it. That felt like the safe default for something that owns a user's data, but it does leave the directory behind.

Not included here, deliberately: changing an existing box's profile. A container's home is fixed when it is created, so that would mean recreating it. The safe shape is to offer the profile choice in the existing Clone Box flow, so the original is untouched until the copy is known to work - a follow-up if you like the direction.