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...
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
Asciidoc (deliberately) does not provide direct layout controls;
however, since we are publishing directly from Asciidoc markup,
at times ''we do require such controls''
A recurring pain point is that sometimes additional (vertical) whitespace
is required for better structuring a body of text; in the past I used various
tricks that turned out to be not reliable... And through exprimentation I have
now worked out a ''canonical solution''
* Asciidoc provides a pre-defined page attribute `{nbsp}`
* when used in a separate Paragraph, this generates an ''empty paragraph'' as spacer
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 digest was generated by Claude(faible) under my supervision.
The goal of this effort is to produce a persistent record of the
Workflow discussion between Wouter and myself during the last year.
- I had work notes, taken during the ongoing discussions and eMail threads
- the raw eMail messages were collected into a MBox file for Claude to digest
- a general framing was provided, and the ''Lumiera Workflow Proposals'' + Froscon-25 discussion defined as context
- Claude was then first tasked to identify topics and structure of the discussion
- the resulting list was cross-checked and reconciled with my own understanding
- this led so some rearrangement and the need to place focus onto some aspects;
adjustments and discrepancies were pointed out and discussed with Claude, leading to some refinement
- after providing also the IRC discussion and instructing Claude to work in the proposals section from Wouter's document,
text generation was started; Claude was also instructed to synthesise a discussion agenda based on identified conclusions
Images were extracted form the PDF provided by Wouter with the command
pdfimages -png -j wouter260316v4.pdf wouter/v4
As usual, I have added the images separately, into the Website-repository,
in order to save storage space in the main Lumiera repo (since storage in
a Git-repository is permanent and can not be shrinked later without
rewriting the history)
Furthermore, I have changed the naming scheme of the images,
adding a prefix with the version number where some image was added.
...added new chapter 1: working with source material
===========================================================
Remark from Ichthyo(committer):
Converted from PDF to raw text with
pdftotext wouter260316v4.pdf WorkflowProposals.txt
Images extracted with:
pdfimages -png -j wouter260316v4.pdf wouter/v4
Again adding the images separately to the Website-repository,
in order to save storage space in the main repository....
During the last months, a lot of gradual changes to policies and guidelines
had been finalised and documented. Moreover, recent clarifications regarding
memory management in the render engine will lead to a clearer definition
of the »Vault« Layer's role, with some ''engine code'' expected to move down.
On this occasion, I reworked relevant sections in the documentation to
confirm the role that now falls to central parts of the overall architecture.
Notably I decided to rename those parts related to the application backbone
as »Vessel« — to underpin the more active and defining role they assumed.
- comb through the Website, starting at the frontpage
- add a **news** entry to confirm this major upgrade step (C++23)
- improve the wording in various overview pages
- adapt the ''release checklist'' to align it with **git-flow**
- reorganise the image folder(s) on the website
- the animated beating heart is back ;-)
...and split-out the description of preview-releases,
since that rather belongs into some kind of changelog (NEWS).
Furthermore, check the links to the build dependencies
The RfC documents were written to complement discussions of the Lumiera developers;
yet since the time where ''Ichthyo'' is working basically alone on the project,
this kind of discussions have ceased. During the following years, some ideas
promoted by the existing RfC documents became rather detached from the
actual state of development in the code base.
Many of the existing RfC documents require some commentary to place them
into context, and some of the decisions taken in the early stage of the
project should be **re-assessed**. This includes the decision to reject
some proposals, which initially might have seemed desirable, yet could not
be reconciled with the understanding of the matter and topic in question,
as was gained through the ongoing analysis and development.
Some sections of the Lumiera website document meeting minutes,
discussion protocols and design proposals from the early days
of the project; these pages were initially authored in the
»Moin Moin Wiki« operated by Cehteh on pipapo.org at that time;
this wiki backed the first publications of the »Cinelerra-3«
initiative, which turned into the Lumiera project eventually.
Some years later, those pages were transliterated into Asciidoc
semi-automatically, resulting in a lot of broken markup and links.
This is a long standing maintenance problem problem plaguing the
Lumiera website, since those breakages cause a lot of warnings
and flood the logs of any linkchecker run.
- indicate clearly that a ''past discussion'' is documented here
- point out what is the primary focus for UI design ''currently''
- arrange some links better
- use cross-links / Linkfarm; especially cross-link to
the discussion regarding Wouter's Workflow proposals (2025)
Create a new subcategory "design/architecture/time"
and rearrange several pages related to time handling and time codes.
NOTE: starting with this changeset, a ''Link-Farm'' is required for cross-links;
since we don't have an automatic solution for this task yet, I have created
the necessary forwarding pages manually in the website repository.
...fine-tuned a few small bits here and there in the
current chapter of the workflow document
===========================================================
Remark from Ichthyo(committer):
Converted from PDF to raw text with
pdftotext wouter250819v3.pdf WorkflowProposals.txt
Images extracted with:
pdfimages -png -j wouter250819v3.pdf wouter/wouter250819v3
Again adding the images separately to the Website-repository,
in order to save storage space in the main repository....
- add markup to match formatting from PDF
- link to the images extracted into the website Git-repository
- adjust image sizes to fit into the text
- add some cross references
(incidentally: TimelineDiscussion.txt -- store image locally)
Chapter 2 (about the timeline) is now complete.
- extend discussion regarding trackless
- add section about Tools / Modes / Views
- section: Adding clips to the timeline
- section: Selecting clips
- section: Arranging clips
- section: Trimming clips
- section: Splitting and merging clips
- section: Removing clips
- add subchapter regarding sections of the timeline
- Adding and editing transitions
- Changing timeline clip properties
===========================================================
Remark from Ichthyo(committer):
Converted from PDF to raw text with
pdftotext wouter250629v2.pdf WorkflowProposals.txt
Images extracted with
pdfimages -png -j wouter250629v2.pdf wouter/wouter250629v2
Images required no cropping;
the white background images were omitted.
Again adding the images separately to the Website-repository,
in order to save storage space in the main repository....
This is the version from 4.Apr
- add a subchapter about the current NLE landscape
- add a subchapter on tracks vs. trackless
- add a bit more information in the navigation subchapter.
===========================================================
Remark from Ichthyo(committer):
Converted from PDF to raw text with
pdftotext wouter250404v1.pdf WorkflowProposals.txt
Images extracted with
pdfimages -png wouter250404v1.pdf
...and then cropped in Gimp ("crop to content");
images 06 and 11 needed to be split in two parts
cropped in Gimp ("crop to content")
NOTE: Adding the images separately to the Website-repository,
in order to save storage space in the main repository,
because content, once added, can not be removed from Git....
- included the list of "Personas", quoting from Wouter's document
- add some details from the ensuing discussion
- close the document with a section "Conclusions" to list the
most relevant open points
Topic: proposals for Lumiera Workflow
Present:
- Wouter Verweijlen
- Benny Lyons
- Hermann Voßeler
Note: This commit creates a new subsection
for the discussion related to Wouter's »Lumiera Workflow Proposals«....
At various places, concepts and drafts from the early stage of the
Lumiera Project are still reflected in the online documentation pages.
During the last months, development focussed on the Render Engine,
causing a shift in some parts of the design, and obsoleting other
parts altogether (notably we consider to use IO_URING for async IO)
Complete the investigation and turn the solution into a generic
mix-in-template, which can be used in flexible ways to support
this qualifier notation.
Moreover, recapitulate requirements for the ElementBoxWidget
No new information added, rather removed lots of technical details,
which do not belong into design documentation. And try to present
the existing information more comprehensively
..at that time, that page was hastily written do document an
somewhat controversial implementation draft, which later on evolved
into the Application-main object Lumiera relied on since then.
Recently, a dedicated page dealing with subsystems and lifecycle
has been added to the Architecture section; so this page here
should be rewritten to focus on the "Application realm" as such.
- most notably the NOBUG logging flags have been renamed now
- but for the configuration, I'll stick to "GUI" for now,
since "Stage" would be bewildering for an occasional user
- in a similar vein, most documentation continues to refer to the GUI
