Folders, Order & Batches
Organizing happens in the same Library view described in The Library View — its left column is where you manage structure. Two live-disk foundations run underneath everything below: the library is a folder tree on disk, so moving something in the UI moves the actual file(s); and both list panels — expressions on the right, or pseudo rigs when a pseudo folder is scoped — are flat, showing what's directly in a folder rather than a nested tree of items.
Folder management
Create, rename, or delete a folder — on either root — with its row actions, or un-nest an expression folder one level. Hovering a folder row also reveals an Export action that writes just that folder to its own .exlib archive file, the same format and icon as the full-library export in Settings.
Drag-and-drop re-parents a folder: the drag projects an absolute indent depth from your cursor with a live highlighted drop-target, guards against into-self and no-op moves, and persists collapse state per-path across sessions (deep folders start collapsed on first run).
Custom order, not forced alphabetical
Folders sort alphabetically when they're first added, but you can drag any folder into any order after that — on both roots. Nesting, un-nesting, and inserting a folder between two others are the same drag gesture: the middle band of a row nests inside it, the top/bottom edge bands insert before or after it.
That order lives beside the folders, in a hand-editable sidecar file: _meta/folder-order.json, namespaced across both roots ({ schemaVersion, expressions, pseudo }). A folder with no recorded position — new, or created by hand outside the app — lands at its alphabetical spot among its siblings and is only written down the next time you explicitly reorder something. A scan never rewrites the file on its own, and stale entries are tolerated on read and pruned on write.
Tag rows also support custom order: drag a tag by its grip. Their order is saved together, and the tag or pack row’s context menu exposes its editing actions. See Packs & Tags for color and naming controls.
Moving expressions and rigs
Drag one or several rows onto any folder on the matching root to move them. A multi-selection drags as a single stacked card showing the count, with the other selected rows hidden during the drag. Moving a pseudo rig relocates its saved pair together, the same as moving an expression.
Batch operations
Shift-click for range select, Cmd/Ctrl-click to toggle. Once two or more rows are selected, a batch bar lets you move the whole selection to a folder, add a tag to everyone missing it, or back-up-then-delete with a typed confirm.
These screenshots were captured in an earlier beta. Toolbar and Library layouts have since changed; the written instructions on this page describe v0.145.4. See A Tour of the Panel for the current controls.
Inline metadata editing
The pencil action on a row opens an in-place editor for title, description, icon (a searchable Phosphor-icon grid, plus a custom-path fallback), and tags — with an existing-tag suggestion dropdown so your tag vocabulary stays discoverable rather than drifting into near-duplicates.
Deleting safely — and why the two roots differ
Every delete routes through an in-panel confirm dialog, never a native browser confirm. Expression deletes run a backup first. Before either kind of folder delete, eXLib enumerates the real disk tree: the dialog gives exact managed, subfolder, and unmanaged-file counts, names a bounded sample of unmanaged files, and the store refuses if that target set changes while the dialog is open.
The two roots are deliberately asymmetric here:
- On the expression root, deleting removes the expressions from the live library after writing a backup, but moves the complete folder into recoverable
_meta/trash/. This cannot be undone inside the panel. - On the All Pseudo Rigs root, every managed rig inside the folder and its subfolders moves up to the parent folder. The leftover tree—including files eXLib does not manage—moves into
_meta/trash/.
That asymmetry is intentional. A pseudo-folder delete does not write the expression-delete backup because it relocates managed rigs and quarantines the leftover tree instead; restoring its organization and recovering its user files are separate steps.
An expression-folder delete has two recovery layers: the automatic pre-delete backup and the complete folder in _meta/trash/. A pseudo-folder delete has relocated rigs plus a separate leftover trash folder. Follow Library Recovery before restoring either root.