- 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
Static initialisation and shutdown can be intricate; but in fact they
work quite precise and deterministic, once you understand the rules
of the game.
In the actual case at hand the ClassLock was already destroyed, and
it must be destroyed at that point, according to the standard. Simply
because it is created on-demand, *after* the initialisation of the
static DependencyFactory, which uses this lock, and so its destructor
must be called befor the dtor of DependencyFactory -- which is precisely
what happens.
So there is no need to establish a special secure "base runtime system",
and this whole idea is ill-guided. I'll thus close ticket #1133 as wontfix
Conflicts:
src/lib/dependable-base.hpp
all these tests are ported by drop-in replacement
and should work afterwards exactly as before (and they do indeed)
A minor twist was spotted though (nice to have more unit tests indeed!):
Sometimes we want to pass a custom constructor *not* as modern-style lambda,
but rather as direct function reference, function pointer or even member
function pointer. However, we can not store those types into the closure
for later lazy invocation. This is basically the same twist I run into
yesterday, when modernising the thread-wrapper. And the solution is
similar. Our traits class _Fun<FUN> has a new typedef Functor
with a suitable functor type to be instantiated and copied. In case of
the Lambda this is the (anonymous) lamda class itself, but in case of
a function reference or pointer it is a std::function.
- polish the text in the TiddlyWiki
- integrate some new pages in the published documentation
Still mostly placeholder text with some indications
- fill in the relevant sections in the overview document
- adjust, expand and update the Doxygen comments
TODO: could convert the TiddlyWiki page to Asciidoc and
publish it mostly as-is. Especially the nice benchmarks
from yesterday :-D
..this collection of ideas, terms and conclusions has been shaped
since some time within the TiddlyWiki. Since I've now started even
some supporting implementation regarding these concepts, its time
to publish them in the design documentation section of the Website
This page gives the rationale for the way our diff framework is built.
This reasoning might *reduce* the relevance of any decisions
regarding the implementation data structure and thus lead to
far reaching consequences for the whole architecture.
Introduce the new term "Fork" at various relevant places
within the documentation. We do not entirely purge the
term "track" though; rather we
- make clear that "Fork" is the entity to build tracks
- use "fork" also synonymous to the "tree of tracks"
a long standing TODO to document the actual start-up sequence, which
is implemented this way since a long time now. There was an unwritten
section in the "Linking and Application Structure", which seems the
apropriate place for this kind of intricate techincal details.
Last week, Benny Lyons was here on visit in munich and he was pondering
the idea of an experimental secondary build system, as a way to learn
more about the source structure of Lumiera. This reminded me to fill
some missing parts of the documentation. Possibly this is also the
right moment to land the GTK-3 transition?
