Workflow: update the "Agenda" text -- processed by Claude
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:
parent
651a463566
commit
717babbd5e
1 changed files with 286 additions and 146 deletions
|
|
@ -1,198 +1,338 @@
|
||||||
Workflow Workshop at FrOSCon 2026 -- working Agenda
|
Workflow Workshop at FrOSCon-26 -- working Agenda
|
||||||
===================================================
|
=================================================
|
||||||
:Date: 2026-07-27
|
:Date: 2026-07-27
|
||||||
:Author: Hermann Voßeler
|
:Author: Hermann Voßeler (Compilation)
|
||||||
:toc:
|
:toc:
|
||||||
|
|
||||||
//MENU: label FrOSCon-26 Agenda
|
//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
|
[abstract]
|
||||||
// priorities to be adjusted by the participants.
|
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
|
Preparation
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
- Read (or skim) the link:Discussion25Digest.html[Discussion Digest 2025];
|
- Read (or skim) the -> link:Discussion25Digest.html[Workflow Discussion Digest];
|
||||||
flag any point where the digest misrepresents your position.
|
flag any point where the account misrepresents your position.
|
||||||
- _Wouter:_ current state of the editing *scenario catalogue* -- even a partial
|
- _Wouter:_ current state of the editing *scenario catalogue* -- even a partial
|
||||||
collection helps as test material for blocks 1--3.
|
collection provides test material for the blocks 1, 2 and 6.
|
||||||
- _Hermann:_ check which parts of the timeline UI can serve for hands-on
|
- _Hermann:_ check which parts of the timeline UI could serve for demonstration,
|
||||||
demonstration (even in mock-up form), especially for the attachment
|
even in rudimentary or mock-up form.
|
||||||
gesture question (block 1).
|
- Collect any mockups and sketches produced since December 2025
|
||||||
- Collect any mockups / sketches produced since December (connection
|
(connection visualisation, placement adjustment, palette layout).
|
||||||
visualisation, placement adjustment popups).
|
|
||||||
|
|
||||||
|
|
||||||
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
|
||||||
---------------------------------------------
|
---------------------------------------------
|
||||||
|
_-- ready for decision --_
|
||||||
_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)
|
|
||||||
---------------------------------------
|
|
||||||
|
|
||||||
-> link:Discussion25Digest.html#moving[Moving, rearranging and ripple behaviour]
|
-> 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 /
|
Collision default:: blocking (with a push-through resistance) versus
|
||||||
make-way (Resolve model). Homework reference: Kdenlive's default mode as a
|
never-blocking / making way, as DaVinci Resolve does. Wouter suggested
|
||||||
specimen of blocking.
|
Kdenlive's default mode as a specimen of blocking behaviour to try out.
|
||||||
- *Make-way side effects*: when clips move out of the way, may magnetic
|
Making way:: if clips move aside, may their magnetic connections break?
|
||||||
connections break? Which reactions are shown during the gesture?
|
And what is shown while the gesture is still in progress?
|
||||||
- *Reordering*: the mechanism for FCP-style drag reordering under magnetic
|
Reordering:: the mechanism for drag-and-drop reordering under magnetic
|
||||||
placement -- “dragging while respecting all placements” vs. “dragging while
|
placement -- ``dragging while respecting all placements'' versus
|
||||||
ignoring the selected clip's children”; which is default?
|
``dragging while ignoring the selected clip's children''. Which is default?
|
||||||
- *Modifier budget*: confirm the table -- Shift = add to selection,
|
Direction:: identical connection semantics for horizontal and vertical
|
||||||
Alt = duplicate, Ctrl = the common “alternative behaviour” modifier
|
dragging were proposed; the reaction to overlaps remains to be defined.
|
||||||
(Gimp pattern); snapping as toggle.
|
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::
|
The discussion regarding a general *ripple-trim function* is parked; it need
|
||||||
Defaults fixed for collision behaviour and reordering; modifier table
|
only be reopened should the decisions here or in block 1 change the premise
|
||||||
confirmed; open corner cases delegated to the scenario catalogue.
|
-- 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#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
|
No existing NLE provides a model to copy for displaying clip connections;
|
||||||
largely reserved for the editor's own clip colourisation. To work on:
|
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
|
- marking the *group leader* of an implicit group
|
||||||
- collision and diagnostic indicators (“why is this clip here?” --
|
- indicators for collisions, and the _derivation_ display
|
||||||
the derivation display)
|
answering ``why does this clip sit here?''
|
||||||
- gesture feedback overlays: locked-clip indication, direction arrows
|
- the interplay of implicit groups with explicit multi-selection
|
||||||
(the Priority-2 cues from
|
- the Priority-2 gesture cues: which of the interacting clips stay locked
|
||||||
link:Discussion25Digest.html#gesture-concept[the gesture concept])
|
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::
|
[role="summary"]
|
||||||
A shortlist of visual candidates worth drawing up properly after the
|
**********************************************************************
|
||||||
meeting; agreement on what the minimum indicator set must convey.
|
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#sections[Sections and the narrative structure] /
|
-> link:Discussion25Digest.html#layering[Tracks, layering and vertical space]
|
||||||
link:Discussion25Digest.html#layering[Tracks, layering and vertical space]).
|
|
||||||
|
|
||||||
- Can nested sequences deliver the lightweight, always-visible quality of
|
The least resolved cluster of the Grouping area, and the one the digest
|
||||||
Wouter's *sections* proposal (named headers, drag-to-reorder scenes,
|
itself marks for in-person discussion.
|
||||||
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.
|
|
||||||
|
|
||||||
Intended outcome::
|
- can nested sequences actually deliver the lightweight, always-visible
|
||||||
A shared picture of how a nested clip appears in each state
|
quality of Wouter's *sections* proposal -- drag-to-reorder of scenes,
|
||||||
(collapsed / condensed / expanded / opened), concrete enough to mock up;
|
section headers in the ruler, per-section versioning? What is missing?
|
||||||
decision whether sections need any dedicated support beyond nested
|
- vertical screen real estate: inline rendering of nested content sharing
|
||||||
sequences + placements.
|
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,
|
Trimming was touched frequently, yet never received a dedicated round;
|
||||||
three commands, contextual trim mode, no sync locks) as a whole
|
together with Routing it is the least covered core area -- while both
|
||||||
- interplay with placement connections: what exactly ripples when trimming
|
participants consider it the very heart of the editor's work.
|
||||||
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
|
|
||||||
|
|
||||||
Intended outcome::
|
- walk through Wouter's document proposal as a whole: clip-based trim-side
|
||||||
Confirm or amend the document proposal as the working trimming design;
|
selection, the three commands, trim mode as a contextual mode, no sync locks
|
||||||
produce the list of trim scenarios for the catalogue.
|
- 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#tagging[Organising footage] /
|
-> link:Discussion25Digest.html#layering[Layering]
|
||||||
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
|
- default routing rules: what happens without any user intervention
|
||||||
- tag-based routing in detail: tag taxonomy, tagging effort, auto-detection,
|
- tag-based routing in detail: tag taxonomy, the manual effort involved,
|
||||||
relation to bins/project view
|
automatic detection, and the relation to bins and the project view
|
||||||
- explicit wiring (“plugs”): which user-visible form, if any, in the first
|
- explicit wiring (»plugs«): which user-visible form, if any, in a first
|
||||||
iteration
|
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::
|
[role="summary"]
|
||||||
Not decisions -- a structured map of the routing questions, so this area
|
**********************************************************************
|
||||||
can be worked through by mail like Grouping was.
|
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
|
Gear switch:: -> link:Discussion25Digest.html#gear[The gear switch] +
|
||||||
users; dedicated per-gear bindings in parallel?
|
Open: the activation model (sub-mode of tools versus always available for
|
||||||
(-> link:Discussion25Digest.html#gear[The gear switch])
|
keyboard users); whether dedicated per-gear bindings should exist in
|
||||||
- *Navigation tool scope*: reaching effect parameters and mixer strips under
|
parallel; to what degree and in which scope a gear setting is remembered;
|
||||||
the overarching navigation tool -- unresolved since FrOSCon-25
|
and the actual gear scales per context. Since feasibility presumably has
|
||||||
(-> link:Discussion25Digest.html#tools-modes[Tools, modes, views]).
|
to be determined by prototyping, the aim here is to scope such an
|
||||||
- *Placement edge cases* from Wouter's catalogue: swapping clips of different
|
experiment rather than to decide the design.
|
||||||
placement types, offset inheritance, anchor deletion
|
Placement edge cases:: -> link:Discussion25Digest.html#prototypes[Placement prototypes] +
|
||||||
(-> 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
|
- publication path for the *scenario catalogue* (PDF -> Asciidoc, as was
|
||||||
Proposals document)
|
done with the Proposals document)
|
||||||
- Wouter's offer to work directly in Asciidoc / git for future document
|
- Wouter's offer to work directly in Asciidoc and Git for future updates
|
||||||
updates
|
of the »Workflow Proposals«
|
||||||
- roadmap towards the actual *design document*: which digest topics are ripe
|
- the road towards an actual *design document*
|
||||||
to be rewritten as specification
|
(-> link:Discussion25Digest.html#method[working method]):
|
||||||
- applying the *personas* to prioritise: a first pass ordering the agreed
|
which of the digest topics are ripe to be rewritten as specification,
|
||||||
features (-> link:Discussion25Digest.html#personas[Target audience])
|
and in which order
|
||||||
- rhythm and channel for the continued discussion after the meeting
|
- 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
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue