diff --git a/doc/design/workflow/Verwijlen/Froscon26Agenda.txt b/doc/design/workflow/Verwijlen/Froscon26Agenda.txt index c190fac6f..477cc81aa 100644 --- a/doc/design/workflow/Verwijlen/Froscon26Agenda.txt +++ b/doc/design/workflow/Verwijlen/Froscon26Agenda.txt @@ -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