Workflow Discussion 2025 — a Digest

The material is arranged by topic, not chronologically — although within each topic thread, the argument is presented in the order it actually developed, through quotes attributed with author and date. Each topic thread closes with a status box stating what was agreed, what remains open, and what was postponed deliberately. Topics touch upon each other in many places; such connections are given as cross-references.

Quotes from eMails and chat have been lightly edited (typos, punctuation) for readability; the substance has been preserved verbatim. Some agreements were reached in unrecorded meetings and are marked as such.

In August 2025, Hermann proposed to organise the topic field into four areas, which also form the structure of this overview — preceded here by a section that explains the fundamentals and addresses overarching topics.

Measured against this fourfold organisation, the discussion so far covered Grouping and Editing substantially, Control in one extended pass — while Routing was barely touched. This asymmetry originates from the way in which the discussion unfolded, and provides natural starting points for a follow-up.

· 🙞 🙜 ·

​ 

​ 

The very first exchange already established a remarkable convergence regarding the aims.

Both participants share the desire to get away from conventional track management — the constant enabling, disabling and locking of tracks — whilst maintaining flexibility regarding the choice of method:

A terminological note from Wouter also underpins this aspiration:

In other words: Wouter tends to use the term “tracks”, to imply not only the layering, but also the UI feature with buttons to enable/disable them, and further track controls.

Another shared conviction concerns the level of abstraction. Lumiera aims neither at a “magical” high-level feature set, nor at exposing raw building blocks:

This “medium level of abstraction” is a foundational principle from the Lumiera vision document; and it connects to a deliberate strategic choice: Lumiera is explicitly not conceived as a clone of existing commercial applications, and does not attempt to compete with industry-backed development on their terms:

Wouter accepted this reasoning explicitly for the case discussed there (immediate live-update in response to UI, see → gestures), while insisting that immediacy of feedback is not mere polish but a genuine time-saver — a tension both participants agreed to resolve by clever design rather than raw computing power.

The notion of »Flow« became the central yardstick of the whole discussion: UI concepts are judged by whether they sustain or interrupt the editor’s flow. Wouter formulated this pointedly:

Hermann’s corresponding formulation approaches a similar idea from the side of perception and spatial cognition:

The flow criterion recurs throughout: expand/collapse cycles are interruptions (see → timeline sections); modes must be entered and exited fluidly (see → tools and modes); and a coherent gesture vocabulary should let the work become “similar to kind of a dance” (Hermann, eMail 2025-04-23; see → keybindings).

In the »Workflow Proposals«, Wouter identified six groups of users who would most likely be attracted to Lumiera and its goals. This topic carried considerable weight in the discussion at the FrOSCon-25 conference, even while agreement was reached quickly:

At FrOSCon, Benny proposed to order these groups by expected affinity; the discussion identified the first group (the specialist in an industrial work environment) and the social media creators as the more challenging audiences, since both require rather specialised tools. The groupings are understood as provisional — a working instrument to focus feature discussions and eventually order the feature list by priority.

The personas actually do work within the discussion: for instance, the → keybinding debate explicitly distinguishes the specialist, who commands a rich vocabulary of shortcuts, from the returning casual user, who will have forgotten anything that is not obvious — and the free-flowing editor is the natural constituency for the → sections proposal.

Right at the beginning, Hermann proposed to conduct the exchange as a kind of workshop: “to set aside a limited time budget […] and try to discuss some of the aspects and proposals you raise and attempt to create a kind of design document, or at least in some way document the ensuing discussion” (eMail 2025-03-31). Wouter later underlined the documentation aspect from his side:

The method of the discussion itself was made explicit at one point:

Complementing this inductive method, Wouter considers to contributes empirical findings: a growing catalogue of editing scenarios, that might be collected as screenshots from his actual work, documenting typical situations which tend to be challenging — to check any proposed mechanics against real-world usage. Hermann encouraged this explicitly: descriptions can be terse, need not be encyclopedic, and need not come with solutions; what matters is “the special twist that makes it difficult to handle” (eMail 2025-10-05). Both agree on the limits of armchair reasoning:

Early in the discussion, Hermann gave a series of explanations of Lumiera’s foundational concepts, which the later topic threads constantly build upon. They are collected here as reference.

Several discussions probed the boundaries of what Lumiera should attempt.

Wouter took a clear position against node-based compositing inside the NLE:

Hermann’s answer: “I agree and I disagree at the same time, because that indicates a dilemma” (eMail 2025-04-07) — if a project starts simple and pragmatic, it runs danger of getting locked into a fixed model; yet a small project cannot cover the whole ground. Lumiera’s resolution is a two-layered approach: form a core model that can cover the larger ground, while structuring it such that plain editing-and-rendering functionality can be finished first. Interestingly, both participants share the assessment that “nodes as-we-know-them” do not work well in larger editing projects — but draw different conclusions: Wouter wants the topic out of scope, Hermann wants to re-think what is good about nodes, so that traditional editing can be smoothly extended into compositing territory when and where needed (eMail 2025-04-06). In the Lumiera model, node-like wiring exists as a capability of Placements (»plug« qualifications), without a node-graph UI.

Discussed at FrOSCon-25 and sharpened afterwards: the UI language is English; translations are welcome, but there are no plans to support languages requiring a re-ordering of UI elements (right-to-left). When Wouter suggested softening the wording, Hermann made the underlying decision explicit — as a matter of priorities: bidirectional support would cause a complexity explosion precisely in the massive custom-drawing code of a video editor (does time run right-to-left? the track heads, the tool palettes, the timecode formats…?), effort a small team cannot shoulder (eMail 2025-08-29). He also flagged the meta-question — whether it is honest to “give the impression that you’re open towards an idea when in fact you have made up your mind otherwise” — and enumerated similar priority questions likely to come up: MS Windows portability, tablet platforms, GPU-based realtime previews, beginner-friendliness, AI assistance.

This discussion started “in the garden at FrOSCon-25”: Wouter pointed out Qt’s track record for big timeline applications (DaVinci Resolve, Ableton Live), the poor Mac situation of GTK, and easier availability of Qt developers; he observed sluggishness in several GTK-3/4 applications (eMail 2025-08-26). Hermann laid out the other side: any project doing non-standard custom drawing is effectively “married” to its toolkit; the GTK choice was historical (Joel Holdsworth), yet meanwhile rests on deep inside knowledge and a way of using GTK-3’s toolkit aspects while pushing aside the framework aspects; Qt in turn is a massive application framework whose abstraction layers carry their own price tag, and pushing those aside is equally not the intended usage. “Since we intend to do very specific things that are certainly not mainstream, we need to walk a thin line here.” (eMail 2025-08-29)

The single most load-bearing concept to emerge from the Control discussion is the Gesture. The crispest definition was given in the IRC chat, starting from the question how a trim edit should be performed:

A gesture is thus an abstract interaction, which can be bound to different control systems (mouse, keyboard, pen, hardware controllers) — the vision being that all control systems are supported on an equal footing. Concrete gesture designs are discussed within their functional topics (e.g. the hooking gesture for → adding clips, navigation gestures in the → keybinding discussion, trim gestures in → trimming edits); so this thread here records the underlying machinery and the question of immediate feedback.

On the technical level, dragging and its visual feedback happen entirely within the UI, handled by a gesture controller with pre-canned, quick-response logic. Once the gesture completes (e.g. the mouse is released), the controller assembles a command sentence — a symbolic representation of the kind “this Subject with ID 12345 was moved by GUI-coordinates of Δ −205 and hit another Subject with ID 9876 in constellation III”. This sentence, encoded as a symbolic term, is sent through the UI-Bus down into the Session, where it is processed asynchronously and with much more flexibility: placements are queried, clips re-arranged, knockout conditions checked. The outcome is placed as an event into the global session log, broadcast, and “projected”: the GUI receives a diff message and re-arranges the visible widgets (Hermann, eMail 2025-10-04; see also → Event Sourcing).

Wouter raised the obvious concern: Final Cut, Resolve and to some degree Avid show the result of an action while you are performing it — “That’s a fantastic way to see what kind of impact your action is having” (eMail 2025-10-04). Hermann’s analysis: UI event streams deliver several events per millisecond, while resolving a network of placement constraints can take between a tenth of a second and seconds; full live resolution would require the kind of GPU-backed engineering that only industry can sustain (see also → vision section). Wouter conceded the strategic point — “it might be better to not even try; Adobe Premiere doesn’t have this either” — but insisted that immediacy is a genuine timesaver, and that Lumiera’s placement concept makes outcomes harder to predict, so the user needs guidance all the more (eMail 2025-10-06).

The agreed middle ground was formulated as two priorities:

Priority-2 requires the GUI to receive “a little help” from the session model beforehand: connectivity hints attached to the elements (e.g. a clip carrying an index-hint naming the later clip that attaches to it magnetically), so the gesture controller can draw connection lines as a simple overlay without latency. Wouter spelled out what the cues should convey:

This topic opened the first deep dive, with Hermann’s critique of the “almost universal pattern” of key bindings in contemporary applications: a flat mapping space, scopes that are obvious to the programmer but opaque to the user and do not mesh with the workflow, bewildering function names, and de-facto un-documentability caused by the very configurability of the bindings. The opposite pole — the “opinionated GUI” — surprisingly yields a small, well structured, well documentable set of bindings, plus the ability to give active cues. And overshadowing both: “we can only recall and associate a very small number of things at any instant […] even while the software gives you hundreds of keybindings, most people will only ever be able to use one hand full” (eMail 2025-04-02).

Wouter countered with the professional editor’s reality:

…and later supplied the ergonomic argument why no default can fit everyone: his own most efficient layout clustered essential functions around the ASD keys for the left hand — until a (left-handed) switch to a Wacom tablet changed the entire configuration. “It will be impossible to come up with ergonomic defaults as we will never know the specific setup of a user” (eMail 2025-04-25). At the same time he confirmed Hermann’s core observation from his own experience: flat bindings only stick when used identically across applications and daily — with the notable exception of Blender, whose keys survive years of disuse because its gesture patterns are so well structured and plausible so that they tend to build muscle memory quickly.

Incidentally, both agree to reject the “opinionated” style, the »Gnome style« of user interface design — as Hermann put it (eMail 2025-04-02): “we know best what you want and need and we give you exactly that and will not confuse you with any configurability”…

Hermann drew the two approaches together with an observation about what actually succeeds:

He would thus prefer to put only 20% of development effort into a conventional generic keybinding framework, while allocate 80% towards development of broad generic handling patterns, that can be controlled by a small set of common gestures. Notable examples would be navigation, controlling playback, or an attempt to connect editing actions like trimming/rolling to navigation gestures.

The synthesis both sides subscribed to: build the coherent structure, but let it map down to common expectations — or more precisely, let it be simplified down, while the more elaborate structure remains underneath (unlike conventional applications, where no such elaborate backing structure exists). A newcomer would get the expected “click-and-drag” behaviour; the expert configuration might use explicit triggers Blender-style (g/m), which would also lead to making selections sticky.

The same principle was formulated memorably in the IRC chat: “if we want to do something unconventional, there must be a path leading to it from known terrain” (Hermann); with Wouter adding the reason: “people carry their knowledge of other apps into new apps, expecting them to respect certain conventions — when a program does things wildly different, people will be very uncomfortable, and this becomes an obstacle for them to invest time into learning it” (IRC 2025-04-16).

Wouter’s »Lumiera Workflow Proposals« document analyses how existing NLEs switch timeline interactions: tool-based (Premiere, FCP), mode-based (Avid, Lightworks, Resolve), or view-based (FCP’s precision editor) — and finds that no NLE uses one method exclusively; hybrids are the norm. His conclusion sets the direction (»Tools + modes + views«): use whichever combination is appropriate, avoid all three whenever a simple, direct and obvious interaction is possible — and where a mode is used, design it as a contextual mode that is entered and exited fluidly, without dedicated user actions.

The centrepiece of his proposal is the »contextual bar« (also termed the »contextual tool palette«): an overlay appearing over the bottom part of the timeline whenever a contextual mode is active, offering exactly the options of that mode — e.g. for clip selection (group, cut, duplicate, nudge, ripple- and snap-toggles), for trimming (trim/roll/slip/slide/ripple toggle), and for adding clips (insert, overwrite, replace…). Colours can indicate which contextual mode is active.

In the mail discussion, the question of modes first appeared as a point of friction — “in textbook UI design, modes are frowned upon […] however, in our domain, I am convinced that modes, when used well, are a valuable tool” (Hermann, eMail 2025-04-07); Wouter concurred, listing the many modes hiding in every serious NLE (eMail 2025-04-08). At FrOSCon-25 the direction was then settled: tools (tool-modes) are the preferable system — provided a handling mechanism can be found that works naturally across all control systems. Hermann proposed, taking inspiration from Blender, to extend tool usage to the entire UI, with a top-level navigation tool as default; moving of clips would become a sub-mode of this navigation tool rather than a separate tool. Wouter’s contextual palette integrates naturally: tools can have sub-modes, presented on the palette — switching between trim, roll, slide and slip after activating the edit tool.

The pattern for handling sub-modes found its blueprint late in the discussion:

A further insight, prompted by the question which behaviour should be default: the editor’s workflow is not homogeneous but goes through phases — the buildup phase of an edit may need a different configuration than the tweaking phase; a switchable sub-mode which can also be overlaid temporarily by a modifier can serve both (Hermann, eMail 2025-10-04).

A proposal by Hermann addressing a pervasive annoyance: parameters and movements in media work span several orders of magnitude, and every level matters at times.

The point of reference is the mouse acceleration feature of most desktop environments. This is in fact a hidden, built-in gear switch nobody can control; media applications tend to add ad-hoc fine-tuning modifiers for a few “especially relevant” knobs. Instead, one uniform set of handles and a gesture should be usable whenever some value or setting must be adjusted.

Wouter found the idea clear and worth considering, but contributed two concerns from hardware usage experience

At FrOSCon-25 the gear switch was integrated into the tool concept as a sub-mode entered when manipulating any setting value; Wouter afterwards questioned exactly this point: “I’m not entirely sure about the gear switch being a sub-mode. Maybe it’s something we would like to always work for whoever uses keyboard shortcuts.” (eMail 2025-08-26)

This topic connects Wouter’s chapter 1 (source material) with the routing question. The pivotal idea arose from combining two observations. Hermann, drawing from his audio work experience: music, ambience, foleys will be integrated from distinct sources anyway, so routing to sub-mixes can be established automatically if the material is tagged (eMail 2025-04-07). Wouter then took that to an even more radical conclusion:

Organising and routing thus collapse into one act — so this yet again connects to the recurring theme of using a “consistent scheme solving additional problems en passant”, that resurfaced time and again during that discussion.

From the Workflow Proposals document, chapter 1 contributes further conclusions and proposals, which have been woven into the discussion thereafter: support most organising systems side by side, since they don’t interfere (source timelines, rating, tagging, marking); metadata-based search and filtering as must-haves; a native 1…5 star rating working on clip sections as well as whole clips; bins-in-bins rather than bins-in-folders; automatic source reels based on user-defined rules (“show me all clips from the second day of the shoot from camera A”); watch-folder auto-import; a built-in metadata browser for sound libraries; and timeline versioning — snapshots without manual duplicate-and-rename archaeology, which would directly tie into Lumiera’s →event-log based architecture.

In conventional NLEs, the vertical order of tracks determines the layering (compositing) order — which forces the editor to arrange content by technical necessity rather than by workflow convenience. Lumiera decouples the two:

Tracks in Lumiera form a tree (»the Fork«), and each sequence carries its own local track tree — which rules out one homogeneous global track order, but turns tracks into a cheap, flexible resource. Sub-tracks then become “a fluid local working space”: if moving a clip creates an overlap, a rule can resolve it by moving the clip to an adjacent sub-track; sub-tracks carry no meaning by default, unless a placement explicitly ties to them (eMail 2025-04-07). In the same spirit, a collision while dragging could shear a clip aside: two sibling sub-tracks are created on the fly, each overlapping clip put on one of them, inheriting the original track’s placement settings such as panning or fading (eMail 2025-10-04, → moving clips). The track head, incidentally, is understood as the visual representation of the fork’s placement — common settings like fade levels or mixing mode live there.

What is lost by giving up global tracks: the ability to toggle or mute whole groups of content by track. The replacement follows an audio-workflow insight — routing by → tagging the material.

At FrOSCon-25, a concrete mechanism for controlled layering was discussed: allow the user to configure, per track, that all content stays fixed above a reference clip — promising greater freedom of track arrangement, with the caveat recorded in the meeting summary that practical tests are needed to determine feasibility.

The question how to group and encapsulate parts of an edit was identified early as the pivotal decision — “the choices made here will very much influence all other aspects of working in the timeline” (Wouter, eMail 2025-04-02) — and its treatment shows the discussion at its most productive: two independently developed models converged step by step.

In his document and in the ensuing discussion in April 2025, Wouter proposed grouping as a first-class citizen of the timeline: every clip is part of a group.

Hermann recognised his own plans in the proposal — “what you describe as a ‘group’ would be modelled in Lumiera as a Sequence, with its own track tree, but bound as virtual medium within a clip” (eMail 2025-04-05) — but challenged the fixed three-level hierarchy:

Wouter defended the fixed structure as roles rather than kinds — “on a technical level, all three of these could be sequences […] it keeps things simple enough that many actions can be performed fast” — while acknowledging the appeal: “I’m intrigued by your quest for everything to be flexible, but I also wonder if it comes at a cost to the user.” (eMail 2025-04-08)

Two weeks later, Wouter proposed a resolution — groups and nested sequences are different things serving different purposes:

The second half of the convergence arose from exploring the consequences of the placement concept: once clips are → connected by placements, grouping emerges from these relations — clips with relative placement act as “group leaders”, and an implicit grouping scheme arises from the direct relationships of neighbouring clips (Hermann, eMail 2025-08-29). Wouter, initially wary of unintended automatic connections, arrived at the same point:

The discussion ensuing after FrOSCon-25 consolidated this line of thought: rather than introducing a dedicated light-weight grouping device, placements can achieve the same effect; what remains unresolved is the visual representation. On that front the discussion has concrete warnings and leads: no NLE offers a model to copy — “we need to write down several ideas and just create mockups” — and colour as visual cue is largely spent already, since clip colourisation is a vital organisational tool for editors; thus lines and borders between or around clips are the more promising direction (Wouter, eMail 2025-08-26).

To make placements workable in the UI, the discussion (from FrOSCon-25 onward) settled on offering a small set of placement prototypes — pre-configured placement setups, chosen per clip, adjustable through the contextual tool palette. Hermann prefers the term “prototype” over “archetype”, referencing the prototype-based type systems of JavaScript and Python: a new instance is created by cloning the prototype (eMail 2025-08-29).

The set was worked out in Hermann’s mail of 2025-08-29 and condensed by Wouter (eMail 2025-10-21) to three:

Wouter’s design maxim was accepted as guiding principle: “the fewer, the better. Few prototypes will make it easier to understand what is going on, and we’ll need fewer visual cues on the timeline. […] The prototypes you proposed seem sufficient to me, and if not, we can always expand later.” (eMail 2025-10-01)

The mail of 2025-08-29 analysed systematically what happens to attached clips when their anchor is edited:

The content-anchored case has a remarkable edge: if the anchor point is edited outside the visible part of the anchor clip, it remains mathematically well defined --

The chat session settled ground rules that held throughout:

Early on, Hermann outlined a list of requirements for the representation of placements in the UI, that were elaborated further and confirmed at the FrOSCon-25 meeting:

Wouter’s catalogue of problematic situations (eMail 2025-10-01) stands largely unresolved:

In the chapter titled »Organising the timeline: sections«, Wouter’s document proposes to divide the timeline into named sections: mark their headers in the ruler, use background colours for orientation, keyboard navigation between sections — and, crucially, encapsulation for the sake of sync safety: working inside one section cannot throw other sections out of sync; sections can be time-locked (e.g. when cut to music); their order can be changed by drag and drop, so scenes can be rearranged freely — a feature squarely aimed at the free-flowing editor persona; sections could even carry version alternatives of a scene. This proposal carries particular weight for Wouter, and its motivation — a top-level handle on the narrative structure — was emphasised repeatedly throughout the discussion.

At and after the FrOSCon-25 meeting, the alternative approach was explored: implementing sections as a dedicated timeline feature would require considerable effort while not fitting the Lumiera core design as a homogeneous building block. Hermann thus proposed nested sequences as the implementing mechanism — these are already planned for the session model: every such nested sequence has its own track tree; a transition can be built between adjacent chapters while retaining the ability to reshuffle them — “we can thus solve two problems with the same feature”. Since each nested sequence is self-contained, the sync-safety aspect of sections would be achieved as a by-product, while each such nested sequence could again be connected through a suitable placement to some overall global music track.

The cost of encapsulation, however, is opacity — and this is where Wouter’s gravest reservations live:

Incidentally, Wouter mentions two exceptions: compositing stacks that are meant to be seen as one clip, and grouped music stems.

The elements of an answer, collected across the discussion:

If placements are to carry the editing experience, the decisive moment is when a clip enters the timeline: which placement prototype will it select, and how much does the user have to do about it? This question dominated the last months of the 2025 discussion, and is the point where that discussion eventually paused.

Wouter framed the option space (eMail 2025-10-06): setup by context (the surroundings determine the new clip’s placement), last-used setting, or a fixed default — his least favourite, “because it encourages users to stick with one type as much as possible”. All agree on the goal: “we want whichever option results in the least amount of user actions to get a desired result.”

Hermann invoked the mainstream UI guideline — avoid explicit options if an automatic rule covers most cases and can be adjusted after the fact — and sketched the automatic rule via proximity (eMail 2025-10-08): close to a clip on the left ⇒ magnetic; close to a clip above/below ⇒ content-anchored; else parent-relative. The tuning spectrum ranges from “engage whenever any clip lies in that direction” (which would be acceptable only if the auto mode itself is _gated by a gesture — like switching on a magnet toggle icon and letting things fall into place) to “engage only when really close” — a hooking feature.

Wouter accepted proximity for the magnetic case but drew a line for content-anchoring:

His fallback suggestion — make “parent-relative” the global default, giving near-traditional NLE behaviour for everyone — provoked Hermann’s power-of-defaults argument:

The B-Roll build-up scenario served as recurring proof of concept: the first B-Roll clip becomes a group anchor; further B-Roll material snaps magnetically to its end; sound effects and subtitles are content-anchored on neighbouring tracks; the whole compound can then be dragged as a single entity (eMail 2025-08-29).

Hermann’s summarised the interaction mechanics discussed thus far, and integrated their use into a state model:

And those stages will mesh up: a clip lifted out of the timeline is again an isolated clip in hand, “as if we’d picked it from the media bins” (eMail 2025-12-07).

Both agree that plain hovering cannot trigger anchoring — “it must be a distinctive gesture” (Hermann, eMail 2025-12-07). Three candidate designs are on the table:

Given connected clips, what happens when you drag one? Hermann initially framed three variants — (a) only the dragged clip moves, adjusting its offset; (b) the whole magnetically linked compound moves; (c) additionally, content- anchoring anchors move along, so that relative-placed clips act as group leaders of implicit bundles — and proposed modifier-selected sub-modes with (c) as default: grab a bundle anywhere, and it moves as a whole, within its wiggle room (eMails 2025-08-29, 2025-10-04).

Wouter’s counter-model proved to be the breakthrough:

Hermann adopted it on the spot: “Hey, that’s brilliant, I didn’t see this as a possible concept […] Hierarchical is more generic and encompasses that case, you just need to grab the right thing.” What remains from the modifier idea is the temporary detach: a modifier (or toggle) to move a clip or selection as an isolated case, ignoring its connections — analogous to Final Cut’s tilde key and the classic “linked selection” toggle (Wouter, eMails 2025-10-01, 2025-10-04).

Enumerating the logical possibilities for one clip moved into another — block; push aside; overlap above/below; shear aside into adjacent track space; repel and flip order — Hermann proposed “no magic” as default: move within free space, block on obstacles, and never reconfigure things or create chains of secondary ripple effects without an explicit indication by the user (snapping-resistance and tear-away being the familiar analogy). Wouter pushed back hard:

Hermann acknowledged the concern without conceding the default (“A very valid point. I do not know if I agree to it, really. Could be!”); Wouter suggested trying Kdenlive’s default mode as a specimen of blocking behaviour. The question — and the related one whether clips move out of the way during a drag (risking broken magnetic connections when they do) — remains open.

A load-bearing workflow requirement still lacks its mechanism: easy reordering of clips, FCP’s signature move (drag a clip elsewhere; the rest makes space; the gap closes). Under pure placement semantics, dragging a magnetic clip moves everything attached behind it — useful for trimming, but not what reordering wants: “While a user might want magnetic placement for trimming, they might not want it for moving clips. So we need to distinguish: dragging while respecting all placements — and dragging while ignoring the selected clip’s children.” (Wouter, eMail 2025-11-25) His earlier question marks the same spot: if moving the anchor moves the attached clips, “wouldn’t moving them reorder their positions? […] If not done by moving magnetic clips, how else could we reorder?” (eMail 2025-10-01)

Modes and modifiers are “a very limited resource” (Hermann, eMail 2025-10-04); Wouter began the bookkeeping (eMail 2025-12-11): keep Shift ≙ add to selection and Alt ≙ duplicate for convention’s sake; Ctrl becomes “the common modifier” switching to the alternative behaviour shown on the contextual palette (the Gimp pattern, → tools and modes); Avid-style snapping can be a toggle instead; Premiere’s Ctrl-box-select-of-cuts is probably dispensable.

Some terms were explained and settled (Wouter, eMail 2025-12-11):

— with Wouter defending the usefulness of lift-with-gap in track-based contexts (protecting timings until the gap is closed deliberately).

Also settled en passant: dropping a clip from the bin onto an existing timeline clip will replace the target, taking over position and connections, with the length adjusting to the new clip (eMails 2025-10-05/06).

Furthermore: no brick wall at timecode zero — Lumiera is not based on timecode internally (rather on an opaque 64-bit µs-granularity time — timecode is mere presentation), so negative positions are unproblematic and the user can relocate the zero point on the time ruler when required.

Wouter repeatedly noted that a general ripple-trim function would be “handy in any case”, to serve users replicating traditional behaviour. Hermann sees classic ripple trim as a workaround “for lack of a better alternative, since the user needs a way to keep sync between adjacent tracks, without having proper means to define the relationship between these tracks” — and thus implementing ripple-trim would introduce a duplicated behaviour pattern, yet subtly deviating from what placements provide (eMail 2025-11-09). Outcome: “I understand your reasoning for not wanting a ripple function, so let’s park that for now.” (Wouter, eMail 2025-11-25)

“Trimming is a topic in itself, one of the most complex indeed” (Wouter) — “yes, but it is the very heart of an editor’s work. Thus for me it is the litmus test.” (Hermann, IRC 2025-04-16). Both also agree on its systematic priority:

The IRC chat explored the mechanics of trim-side selection: most NLEs select a cut (nearest the playhead) and pick its A or B side; only Lightworks selects the side of an underlying clip.

Wouter prefers the clip-based approach — “since we already have a mechanism for navigating clips, we should probably not add another mechanism just for navigating cuts” — and his document turns this into a concrete proposal: three commands on the selected clip (select in point / out point as trim side; select in point for a roll edit, toggling to the out point on second press), with repeated presses switching between ripple and non-ripple trims. Trimming itself “doesn’t need to be reinvented”: frame-wise, by fixed amounts, or dynamically through playback. Since the trim keys collide with clip-nudge keys, a trim mode is accepted — yet would be designed as a contextual mode (→ tools and modes): entered by selecting a trim side, exited by clicking empty timeline space or the mode key; playback in trim mode always previews the selected cut, Avid-style. At FrOSCon-25 the sub-mode arrangement was agreed upon: switching between trim, roll, slide and slip happens on the tool palette after activating the edit tool.

Two connections to the placement concept deserve emphasis:

In the mail discussion proper, trimming was touched frequently, but never given its own deep dive — Wouter’s mutually-exclusive-selections question is still standing: should clip selection and trim-side selection exclude each other (saving precious keys), and how does that interact with sticky selections without introducing yet another mode? (eMail 2025-04-25)