Hover "+" on nested tree widget rows to create child objects

WHAT DO YOU RECOMMEND?

In tree-view widgets, show the “+” (create object) button on hover for every row, not only the widget’s root object. Clicking it creates a new object and links it inside the hovered object’s body — identical to the existing root-row behavior, applied recursively.

HOW COULD IT BE DONE?

The mechanism already exists for the root row: create object → append link block to source object → row appears as child in tree. Extend the same hover affordance and action to child rows, with the hovered row’s object as the link target. New object type could follow the same default rules as the root-row “+” (space default type, or a long-press/secondary menu for type selection).

REAL WORLD USE CASES

Building page hierarchies, e.g. a Project with sub-documents (specs, test logs, meeting notes), each of which has its own children. Today, creating a grandchild requires opening the intermediate object, typing /link, and creating the object from the editor — three steps and a context switch away from the sidebar. With a “+” on every tree row, the entire hierarchy can be grown from the sidebar in single clicks. This mirrors Confluence’s “create child page” from the page tree and Notion’s “+” on every sidebar page row — the interaction users coming from those tools immediately reach for. It also makes tree widgets a complete navigation surface: currently they support reading hierarchy but not extending it.

RECOMMENDED ALTERNATIVES

  • Current workflow: open object → /link → create. Works, but slow and breaks flow for rapid structure building.

  • Pinning each intermediate object as its own widget to get a root-row “+” — technically works, defeats the purpose of a tree.

ADDITIONAL CONTEXT

Related to the general theme of tree widgets as hierarchy UI:

Just to add on after thinking about certain things like the fact that images and other types show in widget hierarchy view:

The “+” should only appear on rows whose object layout supports body content (page, note, task, etc.). File-layout objects (images, video, audio, PDF) have no editable body to link into, so the button is hidden on those rows — consistent with how the app already varies widget options by layout.

Feature Request added on GitHub: