benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Workflow: update the "Agenda" text -- processed by Claude

Browse source 
After the manual revision of the digest document `Discussion25Digest.txt`,
Claude-code was tasked to look at the differences and perform whatever
modifications were deemed necessary to the "Agenda" text.

__Note__: I have not touched anything in this Agenda yet, it is generated text altogether
This commit is contained in:
Fischlurch 2026-07-29 21:38:21 +02:00
parent 651a463566
commit 717babbd5e
1 changed files with 286 additions and 146 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

432
doc/design/workflow/Verwijlen/Froscon26Agenda.txt
View file

@ -1,198 +1,338 @@
Workflow Workshop at FrOSCon 2026 -- working Agenda
===================================================
Workflow Workshop at FrOSCon-26 -- working Agenda
=================================================
:Date: 2026-07-27
:Author: Hermann Voßeler
:Author: Hermann Voßeler (Compilation)
:toc:
//MENU: label FrOSCon-26 Agenda
************************************************************************
Working agenda for the planned in-person meeting at FrOSCon 2026
(St.Augustin), continuing the workflow design discussion between
Wouter Verwijlen and the Lumiera team. The items below are derived
from the link:Discussion25Digest.html[Discussion Digest 2025]: every
“open” point recorded there is a candidate; this page arranges them
into workable blocks and marks the intended outcome for each.
************************************************************************
// NOTE: draft compiled from the digest -- ordering, timeboxes and
// priorities to be adjusted by the participants.
[abstract]
Working agenda for the planned in-person meeting at FrOSCon-2026 in St.Augustin,
continuing the workflow design discussion between _Wouter Verwijlen_ and the
Lumiera team. The items collected here are derived from the status summaries of
the -> link:Discussion25Digest.html[Workflow Discussion Digest]: every point
marked as _open_ there is a candidate; this page arranges those points into
workable blocks and indicates the intended outcome for each.
CAUTION: Ordering, weighting and the time budget are to be decided by the
participants -- this is a menu to choose from, not a schedule.
The compilation was assisted by Knowledge-Technology (»AI«),
drawing on the status summaries of the discussion digest.
Orientation
-----------
Three topics stand out as _ripe for decision,_ since the discussion has already
circled them from several sides and merely stops short of a conclusion:
the *attachment gesture* (block 1), the *moving semantics* (block 2) and the
cluster around *nested clips and vertical space* (block 5) -- the latter being
the only topic that the digest itself flags as _``a prime candidate for the
next in-person discussion''._
The remaining blocks are exploratory: they open ground that the eMail discussion
either never reached (*Routing*), never treated systematically (*Trimming*),
or left at the level of principles without tangible form (*tools and modes*).
Whenever a proposal is weighed during the meeting, the working principles
distilled in the digest provide the yardstick:
- minimise the number of design elements
- map down / simplify down to known software behaviour
- the Gimp modifier pattern
- modifiers as limited resource
- power of defaults
And three standing checks apply to any concrete design considered here,
each of them an open point carried along since FrOSCon-25:
- can the gesture be mapped coherently onto _all_ control systems --
mouse, keyboard, pen, hardware controller?
- does it avoid ``surprising or non-deterministic (suddenly jumping)
behaviour'' -- the risk inherent in the placement concept?
- how does it play out for each of the
-> link:Discussion25Digest.html#personas[personas]?
Preparation
-----------
- Read (or skim) the link:Discussion25Digest.html[Discussion Digest 2025];
flag any point where the digest misrepresents your position.
- Read (or skim) the -> link:Discussion25Digest.html[Workflow Discussion Digest];
flag any point where the account misrepresents your position.
- _Wouter:_ current state of the editing *scenario catalogue* -- even a partial
collection helps as test material for blocks 1--3.
- _Hermann:_ check which parts of the timeline UI can serve for hands-on
demonstration (even in mock-up form), especially for the attachment
gesture question (block 1).
- Collect any mockups / sketches produced since December (connection
visualisation, placement adjustment popups).
collection provides test material for the blocks 1, 2 and 6.
- _Hermann:_ check which parts of the timeline UI could serve for demonstration,
even in rudimentary or mock-up form.
- Collect any mockups and sketches produced since December 2025
(connection visualisation, placement adjustment, palette layout).
Block 1 -- The attachment gesture (decision)
Block 1 -- Attaching clips: the decisive gesture
------------------------------------------------
_-- ready for decision --_
The point where the discussion paused in December 2025. Three status summaries
converge onto this single question, which is a good indication of its weight:
- how the placement prototype is established when
-> link:Discussion25Digest.html#adding[adding clips]
- the ``UI mechanics'' ensuring that clips added to the timeline indeed
get connected into clusters, whenever applicable
(-> link:Discussion25Digest.html#grouping-devices[grouping devices])
- how to establish the prototype in the first place
(-> link:Discussion25Digest.html#prototypes[placement prototypes])
Three candidate designs are on the table:
1. *context rule at drop location* -- proximity decides;
correction afterwards through the tool palette
2. *the hooking gesture* -- a marked change of drag direction over the target;
plus insertion by dropping onto the seam between two clips
3. *arrow connect* -- drop onto a clip, then position in a second step
Regarding the hooking gesture, Wouter stated he ``would like to try this,
to see how that would feel'' -- so if anything tangible can be shown at the
meeting, this is where it pays off. Otherwise a walk-through on paper,
against situations from the scenario catalogue.
Decisions to take along the way:
- how far the automatic mode reaches: magnetic only, or content-anchoring
as well (Wouter argued content-anchoring should require a deliberate act)
- the drop-location rules and their tuning: _how close is close?_
[role="summary"]
**********************************************************************
Aim:: settle on one primary design (or a definite combination), spelled
out precisely enough to be built; record the fallback option and the
criterion that would prompt a revision.
**********************************************************************
Block 2 -- Moving, rearranging and collisions
---------------------------------------------
_The point where the discussion paused in December 2025_
(-> link:Discussion25Digest.html#adding[Adding clips and automatic placement setup]).
Three candidate designs for how a clip acquires its placement connections:
1. context rule at drop location (proximity: magnetic yes / content-anchor?)
2. the “hooking gesture” (change of drag direction over a target; seam-drop
for magnetic insertion)
3. arrow-connect (two-step: drop onto clip, then position via arrow)
Wouter explicitly wanted to _try_ the hooking gesture. If any form of
interactive mock-up is possible at the meeting, this is the block to use it;
otherwise paper walkthrough against scenarios from the catalogue.
Intended outcome::
Pick one primary design (or a concrete combination), well-defined enough
to be prototyped; note the fallback and the criteria for revisiting.
Related decisions to take along the way:
- how far the automatic mode reaches (magnetic only, or content-anchor with
explicit target selection)
- the exact drop-location rules and their tuning parameters (“how close is
close”)
Block 2 -- Moving semantics (decision)
---------------------------------------
_-- ready for decision --_
-> link:Discussion25Digest.html#moving[Moving, rearranging and ripple behaviour]
Open points, each small but consequential:
Individually small questions, each with wide consequences:
- *Collision default*: block (with push-through resistance) vs. never-block /
make-way (Resolve model). Homework reference: Kdenlive's default mode as a
specimen of blocking.
- *Make-way side effects*: when clips move out of the way, may magnetic
connections break? Which reactions are shown during the gesture?
- *Reordering*: the mechanism for FCP-style drag reordering under magnetic
placement -- “dragging while respecting all placements” vs. “dragging while
ignoring the selected clip's children”; which is default?
- *Modifier budget*: confirm the table -- Shift = add to selection,
Alt = duplicate, Ctrl = the common “alternative behaviour” modifier
(Gimp pattern); snapping as toggle.
Collision default:: blocking (with a push-through resistance) versus
never-blocking / making way, as DaVinci Resolve does. Wouter suggested
Kdenlive's default mode as a specimen of blocking behaviour to try out.
Making way:: if clips move aside, may their magnetic connections break?
And what is shown while the gesture is still in progress?
Reordering:: the mechanism for drag-and-drop reordering under magnetic
placement -- ``dragging while respecting all placements'' versus
``dragging while ignoring the selected clip's children''. Which is default?
Direction:: identical connection semantics for horizontal and vertical
dragging were proposed; the reaction to overlaps remains to be defined.
Modifier budget:: confirm the table -- Shift = add to selection,
Alt = duplicate, Ctrl = the common ``alternative behaviour'' modifier
following the Gimp pattern; snapping as a toggle rather than a modifier.
Intended outcome::
Defaults fixed for collision behaviour and reordering; modifier table
confirmed; open corner cases delegated to the scenario catalogue.
The discussion regarding a general *ripple-trim function* is parked; it need
only be reopened should the decisions here or in block 1 change the premise
-- namely, that most clips end up connected by placements anyway.
[role="summary"]
**********************************************************************
Aim:: fix the defaults for collision behaviour and for reordering;
confirm the modifier table; hand the remaining corner cases over to
the scenario catalogue.
**********************************************************************
Block 3 -- Visual language (exploration / mockups)
Block 3 -- Tools, modes and the contextual palette
---------------------------------------------------
_-- design work --_
-> link:Discussion25Digest.html#tools-modes[Tools, modes, views and the contextual tool palette]
The principles are agreed -- tools as primary system, a default navigation tool,
contextual modes with fluid entry and exit, the palette as central device with
the Gimp modifier pattern -- while _most aspects of the tangible manifestation_
are still open. Notably:
- which modes are actually to be provided, and how they mesh up:
an inventory, together with the transitions between them
- how effect parameters and mixer strips can be reached under an overarching
navigation tool -- explicitly unresolved since FrOSCon-25
- and more generally: how far the navigation of the selection focus can
span the whole UI, beyond the timeline
- palette layout, and avoiding occlusion of the timeline content beneath it
This block underpins several others: the palette is the agreed place for
correcting placement prototypes (block 1), for the trim sub-modes (block 6),
and possibly for the gear switch (block 8).
[role="summary"]
**********************************************************************
Aim:: a first inventory of the modes and tools intended, with their
entry and exit conditions; agreement on what the palette must be able
to display.
**********************************************************************
Block 4 -- Visual language
--------------------------
_-- exploration, mockups --_
-> link:Discussion25Digest.html#grouping-devices[Grouping devices] /
link:Discussion25Digest.html#prototypes[Placement prototypes]
-> link:Discussion25Digest.html#prototypes[Placement prototypes]
No existing NLE offers a model for displaying clip connections; colour is
largely reserved for the editor's own clip colourisation. To work on:
No existing NLE provides a model to copy for displaying clip connections;
and colour as a cue is largely spent already, since clip colourisation is a
vital organisational tool for the editor. To be worked on:
- indicating placement type per clip (lines/borders rather than colours)
- indicating the placement type per clip -- lines and borders rather than colour
- marking the *group leader* of an implicit group
- collision and diagnostic indicators (“why is this clip here?” --
the derivation display)
- gesture feedback overlays: locked-clip indication, direction arrows
(the Priority-2 cues from
link:Discussion25Digest.html#gesture-concept[the gesture concept])
- indicators for collisions, and the _derivation_ display
answering ``why does this clip sit here?''
- the interplay of implicit groups with explicit multi-selection
- the Priority-2 gesture cues: which of the interacting clips stay locked
in place, which will move and in which direction
(-> link:Discussion25Digest.html#gesture-concept[the gesture concept]) --
noting that their feasibility depends on connectivity hints being pushed
into the GUI beforehand, which is yet to be sounded out
Intended outcome::
A shortlist of visual candidates worth drawing up properly after the
meeting; agreement on what the minimum indicator set must convey.
[role="summary"]
**********************************************************************
Aim:: a shortlist of visual candidates worth elaborating after the
meeting; agreement on the minimum set of indicators and what each
of them must convey.
**********************************************************************
Block 4 -- Nested clips, sections, vertical space (deep dive)
--------------------------------------------------------------
Block 5 -- Nested clips, sections and vertical space
-----------------------------------------------------
_-- deep dive; flagged in the digest --_
_The least-resolved cluster of the Grouping area_
(-> link:Discussion25Digest.html#sections[Sections and the narrative structure] /
link:Discussion25Digest.html#layering[Tracks, layering and vertical space]).
-> link:Discussion25Digest.html#sections[Sections and the narrative structure] /
-> link:Discussion25Digest.html#layering[Tracks, layering and vertical space]
- Can nested sequences deliver the lightweight, always-visible quality of
Wouter's *sections* proposal (named headers, drag-to-reorder scenes,
per-section versioning)? What exactly is missing?
- Vertical screen real estate: inline rendering of nested content sharing
track space (Hermann's sketches from April 2025 as starting point);
stepwise expand/collapse; condensed previews; the popup-portal idea
and its misclick problem.
- The layering-order override (content fixed above a reference clip):
define the practical test that FrOSCon-25 called for.
The least resolved cluster of the Grouping area, and the one the digest
itself marks for in-person discussion.
Intended outcome::
A shared picture of how a nested clip appears in each state
(collapsed / condensed / expanded / opened), concrete enough to mock up;
decision whether sections need any dedicated support beyond nested
sequences + placements.
- can nested sequences actually deliver the lightweight, always-visible
quality of Wouter's *sections* proposal -- drag-to-reorder of scenes,
section headers in the ruler, per-section versioning? What is missing?
- vertical screen real estate: inline rendering of nested content sharing
the surrounding track space, taking the sketches from April 2025 as
starting point (now reproduced in the digest)
- a precise definition of the gradual *expand / collapse* steps, so that the
overall timeline stays balanced and excess complexity can remain hidden
- the *popup portal* idea needs elaboration -- including the misclick problem
Wouter raised himself
- the layering-order override (content fixed above a reference clip):
define the practical test that FrOSCon-25 called for
[role="summary"]
**********************************************************************
Aim:: a shared picture of how a nested clip appears in each of its states
-- collapsed, condensed, expanded, opened -- concrete enough to be drawn
up; and a decision whether sections require any dedicated support beyond
nested sequences plus placements.
**********************************************************************
Block 5 -- Trimming deep dive (exploration)
--------------------------------------------
Block 6 -- Trimming
-------------------
_-- deep dive --_
_Never had its dedicated round in the mail discussion_
(-> link:Discussion25Digest.html#trimming[Trimming]).
-> link:Discussion25Digest.html#trimming[Trimming]
- walk through Wouter's document proposal (clip-based trim-side selection,
three commands, contextual trim mode, no sync locks) as a whole
- interplay with placement connections: what exactly ripples when trimming
magnetic / content-anchored neighbours (behaviour matrix as reference)
- clip selection vs. trim-side selection: mutually exclusive?
toggling? how does this respect sticky selections?
- keyboard bindings for trim operations; dynamic trimming via playback
Trimming was touched frequently, yet never received a dedicated round;
together with Routing it is the least covered core area -- while both
participants consider it the very heart of the editor's work.
Intended outcome::
Confirm or amend the document proposal as the working trimming design;
produce the list of trim scenarios for the catalogue.
- walk through Wouter's document proposal as a whole: clip-based trim-side
selection, the three commands, trim mode as a contextual mode, no sync locks
- the interplay with placement connections in detail: what exactly ripples
when trimming magnetic or content-anchored neighbours
(the prototype behaviour matrix serves as reference)
- clip selection versus trim-side selection: mutually exclusive, or toggled?
And how does either respect a sticky selection, without introducing yet
another mode?
- keyboard bindings for the trim operations; dynamic trimming during playback
[role="summary"]
**********************************************************************
Aim:: confirm or amend the document proposal as the working design for
trimming; compile the list of trim situations to be added to the
scenario catalogue.
**********************************************************************
Block 6 -- Routing groundwork (open the quadrant)
--------------------------------------------------
Block 7 -- Routing groundwork
-----------------------------
_-- exploration: opening the quadrant --_
_The one area of the 2025-08-24 topic plan that was never discussed_
(-> link:Discussion25Digest.html#tagging[Organising footage] /
link:Discussion25Digest.html#layering[Layering]).
-> link:Discussion25Digest.html#tagging[Organising footage] /
-> link:Discussion25Digest.html#layering[Layering]
The one area of the 2025 topic plan that was never entered. A caveat applies
throughout: everything concerning the organisation of material within the
session is to be treated as an indication of _``features we would like to
have''_ -- the handling of »assets« in Lumiera is still at a very early,
conceptual stage.
- default routing rules: what happens without any user intervention
- tag-based routing in detail: tag taxonomy, tagging effort, auto-detection,
relation to bins/project view
- explicit wiring (“plugs”): which user-visible form, if any, in the first
- tag-based routing in detail: tag taxonomy, the manual effort involved,
automatic detection, and the relation to bins and the project view
- explicit wiring (»plugs«): which user-visible form, if any, in a first
iteration
- mixing groups, sub-mixes, and what replaces track mute/solo
- mixing groups and sub-mixes -- and what replaces mute/solo per track,
once the global track order is given up
Intended outcome::
Not decisions -- a structured map of the routing questions, so this area
can be worked through by mail like Grouping was.
[role="summary"]
**********************************************************************
Aim:: not decisions, but a structured map of the routing questions, so
that this area can be worked through by eMail the way Grouping was --
separating what can be settled now from what has to wait until the
handling of assets has matured.
**********************************************************************
Block 7 -- Smaller items (round-up)
------------------------------------
Block 8 -- Round-up
-------------------
_-- smaller items --_
- *Gear switch activation*: sub-mode of tools vs. always active for keyboard
users; dedicated per-gear bindings in parallel?
(-> link:Discussion25Digest.html#gear[The gear switch])
- *Navigation tool scope*: reaching effect parameters and mixer strips under
the overarching navigation tool -- unresolved since FrOSCon-25
(-> link:Discussion25Digest.html#tools-modes[Tools, modes, views]).
- *Placement edge cases* from Wouter's catalogue: swapping clips of different
placement types, offset inheritance, anchor deletion
(-> link:Discussion25Digest.html#prototypes[Placement prototypes]).
Gear switch:: -> link:Discussion25Digest.html#gear[The gear switch] +
Open: the activation model (sub-mode of tools versus always available for
keyboard users); whether dedicated per-gear bindings should exist in
parallel; to what degree and in which scope a gear setting is remembered;
and the actual gear scales per context. Since feasibility presumably has
to be determined by prototyping, the aim here is to scope such an
experiment rather than to decide the design.
Placement edge cases:: -> link:Discussion25Digest.html#prototypes[Placement prototypes] +
From Wouter's catalogue: swapping clips of differing placement types,
the inheritance of offsets, and the deletion of an anchor.
Placement selection by keyboard:: -> link:Discussion25Digest.html#keybindings[Keybindings] +
Cycling through the prototypes versus Blender-style key-popup menus --
a choice that hinges on the number of prototypes remaining at three.
Default keybindings:: -> link:Discussion25Digest.html#keybindings[Keybindings] +
Still open, yet presumably premature: the concrete default bindings can
only settle once the gesture vocabulary from the blocks 1, 3 and 6 has
taken shape. Worth a brief decision whether to open this at all.
Block 8 -- Process
Block 9 -- Process
------------------
- publication path for the *scenario catalogue* (PDF -> Asciidoc, as with the
Proposals document)
- Wouter's offer to work directly in Asciidoc / git for future document
updates
- roadmap towards the actual *design document*: which digest topics are ripe
to be rewritten as specification
- applying the *personas* to prioritise: a first pass ordering the agreed
features (-> link:Discussion25Digest.html#personas[Target audience])
- rhythm and channel for the continued discussion after the meeting
- publication path for the *scenario catalogue* (PDF -> Asciidoc, as was
done with the Proposals document)
- Wouter's offer to work directly in Asciidoc and Git for future updates
of the »Workflow Proposals«
- the road towards an actual *design document*
(-> link:Discussion25Digest.html#method[working method]):
which of the digest topics are ripe to be rewritten as specification,
and in which order
- applying the -> link:Discussion25Digest.html#personas[personas]:
a first pass at ordering the agreed features by priority
- the toolkit question (-> link:Discussion25Digest.html#scope[scope and priorities]):
no decision is pending and no change of course intended, yet Wouter's
concern is on record and the direction of GTK development is being
watched -- a brief status exchange, if desired
- rhythm and channel for continuing the discussion after the meeting