The Editor Is a Coordination Problem, Not Just a Canvas
OpenCut's earlier editor, and the rewrite's emerging desktop shell, point to the same underlying question: how can one media scene remain coherent when a user finds an asset, moves it in a preview, edits an exact value, and places it in time? This chapter focuses on the relationship among the browser, preview, inspector, and timeline. Understanding that relationship gives readers a way to see why OpenCut's later ambitions require shared state rather than a collection of attractive panels.
Four views of one editing scene
A video editor can look like a canvas with a play button, especially when judged from a screenshot. OpenCut's release history describes something more demanding. The former editor had an assets panel for finding media, a preview panel for seeing and manipulating the scene, a properties panel for precise values, and a timeline for arranging content over time. These are not four independent destinations. They are different views of one evolving scene.
Consider a simple action: placing a video into a project. The assets surface answers “what can I use?” The timeline answers “when does it exist, and on which layer?” The preview answers “what does the composition look like at this moment?” The inspector answers “what are the exact position, scale, rotation, typography, or blending values?” If each surface keeps its own interpretation, a clip can appear in one place in the timeline, another place in the preview, and a third place in the property fields. The visible disagreement is a UI bug; the underlying problem is that the system lacks a clear owner for the scene's meaning.
The current desktop rewrite preserves this four-part mental model in its shell. It creates browser, preview, inspector, and timeline panels once and keeps them as persistent parts of the window. The arrangement places the three visual-and-control regions above a lower timeline region. That is meaningful scaffolding: the project is deciding which responsibilities belong together before it has implemented media behavior. But each current panel is still a placeholder that displays its name. The shell demonstrates composition and state-preserving UI structure, not a functioning editing loop.
The distinction matters because a panel can be present without owning anything important. A preview that only displays pixels cannot tell the timeline that a selected element moved. An inspector that only edits local form values cannot guarantee that a drag in the preview updates the same property. A timeline that draws rectangles without a shared scene model cannot know whether a trim should move neighboring content. The useful unit is not the panel; it is the information that crosses between panels.
The arrows in this diagram are not meant to describe the current rewrite as already complete. They express the contract implied by the former editor's behavior and by the desktop shell's chosen regions. An asset selection has to become scene content. A preview gesture has to become a property change. An inspector edit has to be visible at the correct time. A timeline operation has to alter what the preview and inspector report. The shared state is the place where those meanings meet.
That model also gives each surface a distinct job. The browser is about source material and discoverability. The preview is about spatial and visual feedback. The inspector is about explicit values and fine control. The timeline is about temporal relationships, order, duration, and layers. The jobs overlap in their effects, but not in their purpose. A strong editor lets a user move between them without learning four different definitions of the same element.
The distinction between a job and an authority is useful here. The browser can introduce an asset, but it should not decide the asset's duration. The preview can report what is visible at the current time, but it should not quietly maintain a separate position from the inspector. The inspector can accept an exact scale value, but it should not have to know how every timeline track is drawn. The timeline can establish when an element participates in the scene, but it should not become the only place where selection exists. Each surface can own its presentation while a shared scene state owns the meaning that must survive a change of view.
That is also why the desktop shell's choice to create its four panels once is more than a layout preference. The code comments explain that persistent panel entities keep their state across renders instead of being torn down and rebuilt on every frame. This does not mean the rewrite already has selection or media state; the panels are still placeholders. It does show that the project recognizes a basic condition of interactive software: transient interaction state must have a stable home if a redraw is not allowed to erase it.
Gestures, values, and feature growth
OpenCut's historical improvements show why coordination becomes harder as soon as editing moves beyond simple placement. The first release rebuilt the properties panel into sections for transform, blending, typography, spacing, and background. Number inputs could accept mathematical expressions and support click-drag scrubbing. Users could move, scale, and rotate elements directly in the preview, adjust color with an eyedropper and opacity controls, and temporarily disable snapping while holding Shift. These choices serve different speeds of work: a gesture is quick and spatial, while a value is exact and inspectable.
Neither mode is sufficient on its own. Dragging an element toward the center is faster than typing coordinates, but it may not land on the exact position a user needs. Typing a value is precise, but it is a poor way to explore a composition. Snapping helps a user find alignment, but sometimes the desired position is deliberately off-grid. The editor therefore has to preserve the same underlying property while accepting different ways of changing it. It also has to show the result consistently: the handle in the preview, the number in the inspector, and the element's position relative to other clips must agree.
Selection is part of that contract, not decoration around it. The release notes describe fixes for selected elements losing their selection after resizing or moving, selection outlines becoming unclear when clips touched, and drag-selection accidentally reaching a neighboring track. Later improvements let Shift or Ctrl add to an existing timeline selection, highlighted rows when they contained a selected element, and allowed multiple selected clips to move and resize together. These cases reveal a hidden question: what exactly is selected, and which surface is responsible for preserving that fact while an operation is in progress?
If selection belongs only to the preview, a timeline drag may lose it. If it belongs only to a timeline rectangle, a direct manipulation handle may not know which properties to change. A user does not care which internal object owns the flag; they care that a deliberate selection survives the gesture and that a command affects the intended elements. OpenCut's fixes are historical evidence of this pressure. They show the former product negotiating the boundary between input events, scene state, rendering feedback, and undo behavior.
Feature growth makes the same problem larger. A static image can be positioned and scaled. Add keyframes, and its properties become functions of time rather than single values. Add an effect, and the rendered result depends on an additional operation that may apply to one clip or occupy its own place on the timeline. Add a mask, and visibility depends on a shape, position, rotation, feathering, and stroke. Add audio speed and volume, and playback and export must respect both a changed rate and the user's expectation that pitch can be maintained. Add captions, and text becomes tied to speech or an imported transcript as well as to visual layout.
The point is not that every feature must be implemented by one giant object. It is that every feature changes what the editor means by an element. The preview needs to render it, the timeline needs to place or expose it, the inspector needs to edit it, and persistence and export need to preserve it. The more composable the media model becomes, the less safe it is to let each panel invent a private representation.
The release history offers a useful example in keyframe editing. OpenCut added graph editing for the curves between keyframes, independent animation of position axes, copying and pasting keyframes between elements, and expanded timeline lanes for individual animated properties. Those controls are valuable precisely because they expose one temporal model in several forms. A curve in a graph, a property lane in the timeline, a value in the inspector, and a moving object in the preview all describe related changes. If they drift apart, the editor becomes difficult to trust even when each individual control looks polished.
The same reasoning applies to effects and audio. A blur applied to a clip is not just a button state; it changes the pixels that the compositor must produce at a particular time. A speed change is not just a number in the inspector; it changes duration, playback scheduling, waveform interpretation, and export. The former release notes mention playback stutter, timing slips that could cut out audio, inaccurate waveforms, and browser-specific MP4 export failures. These were not peripheral annoyances. They were symptoms of different parts of the scene failing to agree about time, selection, or output.
Undo makes the coordination requirement especially visible. A user experiences a trim as one intention, even if the application must update a clip's visible range, selection outline, neighboring boundaries, playback position, and perhaps audio. If undo records only the last mouse movement or only the field that happened to receive focus, it can restore one surface while leaving the scene inconsistent elsewhere. The former release notes repeatedly mention undo behavior around drag-and-drop, trimming, and track creation. Those fixes do not reveal the complete implementation, but they identify the right test: after an operation is reversed, do all views again describe the same scene?
Playback supplies a second test. The timeline may be structurally correct while the scheduler falls behind, the audio cuts out, or the preview stutters when an element is manipulated during playback. A user sees one failure, but several owners may be involved: the clock, the renderer, audio processing, and the interaction layer. This is why a feature can appear complete in a static screenshot and still be unreliable in use. OpenCut's history makes the system boundary visible by documenting failures at the joins between surfaces.
This is why the editor cannot be evaluated only by asking whether a feature exists. A more revealing question is whether the feature participates in the same scene model as the existing surfaces. Can a user discover an asset, place it, adjust it, animate it, preview it, and undo the result without crossing an invisible semantic boundary? The answer depends on ownership and transitions beneath the interface.
The current rewrite gives only an early answer. Its desktop code includes reusable buttons, badges, labels, separators, context menus, and a resizable-panel primitive. Its shell deliberately creates the panels once so their state can persist across renders. Those are sensible foundations for an interactive application. Yet the panel bodies currently say only “Browser,” “Preview,” “Inspector,” and “Timeline.” There is no visible media model, selection model, timeline command, or persistence layer to connect them. The right conclusion is not that the design has failed; it is that the repository has reached the shell stage, and the difficult coordination work remains to be demonstrated.
OpenCut's shared-foundation proposal becomes concrete at exactly this point. A common core would need to define the scene and the transitions that change it, while each surface would translate user input into those transitions and display the resulting state. The browser could remain a discovery surface, the preview a visual surface, and the inspector a precision surface, but none could be the sole authority over the scene. The next question is what common representation keeps those authorities aligned when the scene changes from frame to frame.