lumiera_documentation/doc/design/workflow/Verwijlen/Froscon26Agenda.txt
Ichthyostega d6df336f9b Workflow: integrate the digest into the menu and overview page
I have rather ambivalent feelings towards that Agenda text,
as generated by Claude; I perceive that as intrusive --
yet I want to share and discuss this aspect further...
2026-07-29 22:07:16 +02:00

338 lines
16 KiB
Text

Workflow Workshop at FrOSCon-26 -- working Agenda
=================================================
:Date: 2026-07-27
:Author: Hermann Voßeler (Compilation)
:toc:
//MENU: label Agenda draft
[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[Workflow Discussion Digest];
flag any point where the account misrepresents your position.
- _Wouter:_ current state of the editing *scenario catalogue* -- even a partial
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 -- 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
---------------------------------------------
_-- ready for decision --_
-> link:Discussion25Digest.html#moving[Moving, rearranging and ripple behaviour]
Individually small questions, each with wide consequences:
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.
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 -- 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]
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 the placement type per clip -- lines and borders rather than colour
- marking the *group leader* of an implicit group
- 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
[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 5 -- Nested clips, sections and vertical space
-----------------------------------------------------
_-- deep dive; flagged in the digest --_
-> link:Discussion25Digest.html#sections[Sections and the narrative structure] /
-> link:Discussion25Digest.html#layering[Tracks, layering and vertical space]
The least resolved cluster of the Grouping area, and the one the digest
itself marks for in-person discussion.
- 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 6 -- Trimming
-------------------
_-- deep dive --_
-> link:Discussion25Digest.html#trimming[Trimming]
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.
- 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 7 -- Routing groundwork
-----------------------------
_-- exploration: opening the quadrant --_
-> 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, 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 and sub-mixes -- and what replaces mute/solo per track,
once the global track order is given up
[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 8 -- Round-up
-------------------
_-- smaller items --_
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 9 -- Process
------------------
- 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