The Editing Interface

This page goes through the default editor's interface block by block: how the screen divides, what each of the buttons on a node does, how parameters get edited, where abstract nodes live, what the sidebar holds, and finally the two floating panels together with the container you have to place yourself.

How the screen divides

The default editor splits the rectangle it is given into left and right. About nine tenths of the width on the left is the paper, the document content itself; the narrow strip that remains on the right is the sidebar, holding buttons that act on the document as a whole.

Beyond that there are the two floating panels, Insert Concept and Edit Parameters. They take no part in the left-right division; they float above the interface and can be dragged and resized. Which region they float over is up to you, which is the subject of the last section on this page.

Nodes on the paper

Every concept node on the paper carries its own row of buttons. There are two arrangements: spread across an appbar at the top of the node, or collected into a strip on the right and folded behind a chevron. Which one a concept gets is decided by the renderer factory it uses, covered in Editor Renderer Factories.

Either way the buttons themselves are the same eight:

The chaining switch corresponds to the relation property from tutorial chapter 1. Two adjacent nodes of the same kind are numbered independently and spaced apart when separated; when chained, the second sits flush against the first and the two read as one run. A list of items usually wants chaining, two unrelated theorems want separation.

The two "add paragraph" buttons solve a problem peculiar to tree-shaped documents: when two block nodes are direct neighbours there is no position between them where a cursor could go, and therefore no way to insert anything in between. These buttons create such a position out of nothing.

Unwrap is the other kind of deletion: it removes the fact that something is a theorem while leaving the content where it was, as ordinary paragraphs.

The parameter drawer

The Edit parameters button unfolds a drawer from the node listing all of its parameters.

The control each parameter gets is decided by its type and its extra fields:

Note the order: choices takes precedence over type. A parameter typed string that carries choices renders as a dropdown rather than a text field. The Proposition concept in tutorial chapter 7 relies on this to turn category into a choice between Theorem, Lemma and Corollary.

Parameters pinned by a second-class concept through fixed_override do not appear here, since authors are not meant to change them in the first place. This is where the practical difference between fixed and default parameters shows: the former are part of the concept, the latter merely a starting point.

Abstract nodes

Abstract nodes attached to a node (footnotes, for instance) appear as a row of small chips below it. Clicking one opens a floating window to edit it. That window is an independent editor component sharing the main editor's core, so the concepts available inside a footnote are exactly those available in the body.

They get a window of their own because an abstract node is a complete little document, with its own paragraphs and possibly its own theorems, and there is no room for that between two lines of text.

The sidebar

The sidebar carries four fixed buttons, all of which act on the whole document or the whole interface rather than on one node:

The last one governs whether shortcut hints appear at all. It is on by default, so holding Alt by itself for a moment makes each button show the key that reaches it; with it off, holding Alt produces nothing. Turning it off once the shortcuts are familiar makes for a quieter screen. The hint mechanism is covered in detail on the Keyboard Operation page.

Buttons you add yourself come after these four, separated by a divider; see Customizing the Default Editor for how.

The two floating panels

The Insert Concept panel lists every second-class concept currently available, grouped by node kind; clicking one inserts it at the cursor. The Edit Parameters panel shows the parameters of the concept node the cursor is in, applied when you press save. Both can be dragged around and resized from the bottom right corner, and both remember position and size in the browser's local storage, so they come back where you left them.

Two of the sidebar buttons show and hide these panels.

AreaContainer: the one part you must place yourself

Both panels are rendered by the editor component internally, but their positioning depends on an external container: a panel places itself within that container's coordinate system and cannot be dragged outside it. That container is AreaContainer, and you have to render it.

AreaContainer renders as an absolutely positioned empty box filling its parent, with no appearance of its own. You are using it to mark out a rectangle and tell the panels they may move around inside it. Where you put it depends on which region you want them to float over. If the editor and the printed output sit side by side, the printer side is a good choice, so the panels float over the output and never cover the text being edited:

import { AreaContainer, DefaultEditorComponent, DefaultPrinterComponent } from "@project-callio/calliotext"

<Box sx={{position: "relative", width: "100%", height: "100%"}}>
    <Box sx={{position: "absolute", left: 0, width: "50%", height: "100%"}}>
        <DefaultEditorComponent editorcore={editor_core} />
    </Box>

    <Box sx={{position: "absolute", left: "50%", width: "50%", height: "100%"}}>
        {/* The container fills the printer column, so that is where the panels may move. */}
        <Box sx={{position: "absolute", top: 0, left: 0, width: "100%", height: "100%"}}>
            <AreaContainer />
        </Box>
        <DefaultPrinterComponent printer={printer} root={tree} />
    </Box>
</Box>