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

Workflow: revised the discussion summary

Browse source 
I went through the entire digest extracted by Claude,
revalidated the central statements, reworded most summaries
to capture the meaning adequately and added quotes from
the original mails verbatim at several instances.

I consider this version now ready for review.
This commit is contained in:
Fischlurch 2026-07-29 20:48:38 +02:00
parent 89d2ceed4b
commit e219dcbb8c
2 changed files with 945 additions and 579 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1521
doc/design/workflow/Verwijlen/Discussion25Digest.txt
View file

File diff suppressed because it is too large Load diff

3
doc/design/workflow/Verwijlen/WorkflowProposals.txt
View file

@ -711,6 +711,7 @@ mode/tool system. FCP's Select and Position tools also change the behaviour of t
can therefore indeed also be considered modes, which gives us a hybrid design as well. Specialised can therefore indeed also be considered modes, which gives us a hybrid design as well. Specialised
views can be combined with tools or modes. views can be combined with tools or modes.
[[contextual_bar]]
To conclude: all methods have pros and cons. Tools, modes and views aren't mutually exclusive, so To conclude: all methods have pros and cons. Tools, modes and views aren't mutually exclusive, so
I think we should use whichever method or combination of methods is appropriate for different I think we should use whichever method or combination of methods is appropriate for different
actions in Lumiera. Whenever we can, we should try to avoid all three and design the app to be as actions in Lumiera. Whenever we can, we should try to avoid all three and design the app to be as
@ -721,7 +722,7 @@ side automatically enters trim mode. However, a user does still need to explicit
Regardless of the method, immediate visual differentiation of tools/modes/views is important and Regardless of the method, immediate visual differentiation of tools/modes/views is important and
I'd like this to extend to any timeline option that can be toggled on/off. Therefore I'd like to propose I'd like this to extend to any timeline option that can be toggled on/off. Therefore I'd like to propose
the use of a _contextual bar_ that appears over the bottom part of the timeline whenever a contextual the use of a *contextual bar* that appears over the bottom part of the timeline whenever a contextual
mode is active. mode is active.
.Contextual bar with options for the mode/tool .Contextual bar with options for the mode/tool