Status: Release published -- now again in Development Phase

Hereby I introduce a ''Development Status'' page, where the
current phase of the release cycle can be marked and similar
status information is published. This page also includes
the Changelog (from the file NEWS). Since updates must
be checked into Git and then pushed to our website,
such status marks are documented in the history.

Some notes regarding the phases of the Release cycle
were also added to the Release checklist.

+ some additional links resources and documentation tweaks

NEWS

@@ -1,6 +1,6 @@
 Lumiera -- Significant Changes
 ==============================
-Version: 0.pre.04
+Version: 0.pre.05~dev
 :Date: 11/2025
 
 *************************************************************
@@ -16,7 +16,7 @@ from `git://git.lumiera.org/LUMIERA`
 
 
 
-In the current stage of development, the focus is primarily on the
+At the current stage of development, the focus is primarily on the
 overall integration of fundamental functionality at all levels of
 the code base.
 
@@ -36,13 +36,13 @@ is yet unfinished.
 
 As of _11/2015_ (0.pre.03)::
 A lot of long standing maintenance work has been done.
-The Project upgraded to C++14 and Debian/Jessie as reference platform,
+The codebase has been upgraded to C++14 and Debian/Jessie as reference platform,
-followed by clean-up of workarounds now obsoleted. On the GUI side, we largely
+followed by clean-up of several workarounds now obsoleted. On the GUI side,
-made the transition to GTK-3, which leads to a rework of our timeline widget,
+the transition to GTK-3 was accomplished, which however necessitates a rework
-which is in progress but not finished yet. This work also spurred an effort
+of our timeline widget, which is in progress but not finished yet. This work
-to reorder the connection and communication between core and the UI, which
+also spurred an effort to reorder the connection and communication between
-is expected to be asynchronous. Due to the limited developer resources,
+the core and the UI, which is expected to be asynchronous. Due to the limited
-work on the Engine and Player part is stalled.
+developer resources, work on the Engine and Player part is stalled.
 
 As of _10/2013_ (0.pre.02)::
 The data models have been elaborated and some significant parts of the session

README

@@ -1,6 +1,6 @@
 Lumiera -- the video NLE for Linux
 ==================================
-Version: 0.pre.04
+Version: 0.pre.05~dev
 :Date: 11/2025
 
 *************************************************************

admin/scons/Setup.py

@@ -22,7 +22,7 @@ import Options
 
 #-------------------------------------------------------Configuration
 TARGDIR      = 'target'
-VERSION      = '0.pre.04'
+VERSION      = '0.pre.05~dev'
 TOOLDIR      = './admin/scons'    # SCons plugins
 OPTCACHE     = 'optcache'
 CUSTOPTFILE  = 'custom-options'

data/config/setup.ini

@@ -12,7 +12,7 @@ gui          = gtk_gui.lum
 modulepath   = $ORIGIN/modules
 configpath   = $ORIGIN/../../share/lumiera/config:$ORIGIN/config:~/.lumiera   # currently unused (2/2011)
 title        = Lumiera
-version      = 0.pre.04
+version      = 0.pre.05~dev
 website      = http://www.lumiera.org
 authors      = Joel Holdsworth|Christian Thäter|Hermann Voßeler|Stefan Kangas|Michael Fisher|Michael Ploujnikov|and others...
 copyright    = 2007 - 2025

doc/devel/Changelog

@@ -0,0 +1 @@
+../../NEWS

doc/devel/Doxyfile

@@ -5,7 +5,7 @@
 #---------------------------------------------------------------------------
 DOXYFILE_ENCODING      = UTF-8
 PROJECT_NAME           = Lumiera
-PROJECT_NUMBER         = 0.pre.04
+PROJECT_NUMBER         = 0.pre.05~dev
 PROJECT_BRIEF          = "»edit your freedom«"
 PROJECT_LOGO           = draw/rendered/LumiLogo-small.png
 OUTPUT_DIRECTORY       =

doc/devel/Doxyfile.browse

@@ -14,10 +14,12 @@
 #---------------------------------------------------------------------------
 DOXYFILE_ENCODING      = UTF-8
 PROJECT_NAME           = Lumiera
-PROJECT_NUMBER         = 0.pre.04
+PROJECT_NUMBER         = 0.pre.05~dev
+PROJECT_BRIEF          = "»edit your freedom«"
 PROJECT_LOGO           = draw/rendered/LumiLogo-small.png
 OUTPUT_DIRECTORY       =
 CREATE_SUBDIRS         = NO
+ALLOW_UNICODE_NAMES    = NO
 OUTPUT_LANGUAGE        = English
 BRIEF_MEMBER_DESC      = YES
 REPEAT_BRIEF           = YES
@@ -37,62 +39,87 @@ INLINE_INHERITED_MEMB  = YES
 FULL_PATH_NAMES        = YES
 STRIP_FROM_PATH        = ../../src/ \
                          ../../tests/
-STRIP_FROM_INC_PATH    = 
+STRIP_FROM_INC_PATH    = ../../src/
 SHORT_NAMES            = NO
 JAVADOC_AUTOBRIEF      = YES
 QT_AUTOBRIEF           = NO
 MULTILINE_CPP_IS_BRIEF = NO
+PYTHON_DOCSTRING       = NO
 INHERIT_DOCS           = YES
 SEPARATE_MEMBER_PAGES  = NO
 TAB_SIZE               = 4
+ALIASES                =
 OPTIMIZE_OUTPUT_FOR_C  = NO
+OPTIMIZE_OUTPUT_JAVA   = NO
+EXTENSION_MAPPING      =
+MARKDOWN_SUPPORT       = YES
+MARKDOWN_ID_STYLE      = GITHUB
+TOC_INCLUDE_HEADINGS   = 2
+AUTOLINK_SUPPORT       = YES
 BUILTIN_STL_SUPPORT    = YES
 CPP_CLI_SUPPORT        = NO
-IDL_PROPERTY_SUPPORT   = YES
+IDL_PROPERTY_SUPPORT   = NO
 DISTRIBUTE_GROUP_DOC   = NO
+GROUP_NESTED_COMPOUNDS = NO
 SUBGROUPING            = YES
-TYPEDEF_HIDES_STRUCT   = NO
+INLINE_GROUPED_CLASSES = NO
+INLINE_SIMPLE_STRUCTS  = YES
+TYPEDEF_HIDES_STRUCT   = YES
+LOOKUP_CACHE_SIZE      = 2
+NUM_PROC_THREADS       = 0
+TIMESTAMP              = DATE
 
 #---------------------------------------------------------------------------
 # Build related configuration options
 #---------------------------------------------------------------------------
 EXTRACT_ALL            = YES
-EXTRACT_PRIVATE        = YES
+EXTRACT_PRIVATE        = NO
+EXTRACT_PACKAGE        = NO
 EXTRACT_STATIC         = YES
 EXTRACT_LOCAL_CLASSES  = YES
 EXTRACT_LOCAL_METHODS  = NO
 EXTRACT_ANON_NSPACES   = NO
-HIDE_UNDOC_MEMBERS     = NO
+RESOLVE_UNNAMED_PARAMS = YES
+HIDE_UNDOC_MEMBERS     = YES
 HIDE_UNDOC_CLASSES     = NO
 HIDE_FRIEND_COMPOUNDS  = NO
 HIDE_IN_BODY_DOCS      = NO
-INTERNAL_DOCS          = YES
+INTERNAL_DOCS          = NO
 CASE_SENSE_NAMES       = YES
 HIDE_SCOPE_NAMES       = NO
+SHOW_HEADERFILE        = YES
 SHOW_INCLUDE_FILES     = YES
+SHOW_GROUPED_MEMB_INC  = NO
+FORCE_LOCAL_INCLUDES   = YES
 INLINE_INFO            = YES
 SORT_MEMBER_DOCS       = NO
-SORT_BRIEF_DOCS        = YES
+SORT_BRIEF_DOCS        = NO
+SORT_MEMBERS_CTORS_1ST = YES
 SORT_GROUP_NAMES       = NO
 SORT_BY_SCOPE_NAME     = NO
+STRICT_PROTO_MATCHING  = NO
 GENERATE_TODOLIST      = NO
 GENERATE_TESTLIST      = NO
-GENERATE_BUGLIST       = YES
+GENERATE_BUGLIST       = NO
 GENERATE_DEPRECATEDLIST= NO
-MAX_INITIALIZER_LINES  = 10
+ENABLED_SECTIONS       =
+MAX_INITIALIZER_LINES  = 50
 SHOW_USED_FILES        = YES
-SHOW_DIRECTORIES       = NO
 SHOW_FILES             = YES
 SHOW_NAMESPACES        = YES
+FILE_VERSION_FILTER    =
+LAYOUT_FILE            =
+CITE_BIB_FILES         =
 
 #---------------------------------------------------------------------------
 # Configuration options related to warning and progress messages
 #---------------------------------------------------------------------------
 QUIET                  = NO
 WARNINGS               = YES
-WARN_IF_UNDOCUMENTED   = YES
+WARN_IF_UNDOCUMENTED   = NO
 WARN_IF_DOC_ERROR      = YES
-WARN_NO_PARAMDOC       = YES
+WARN_NO_PARAMDOC       = NO
+WARN_AS_ERROR          = NO
 WARN_FORMAT            = "$file:$line: $text"
 WARN_LOGFILE           = doxygen-warnings-browse.txt
 
@@ -101,34 +128,31 @@ WARN_LOGFILE           = doxygen-warnings-browse.txt
 #---------------------------------------------------------------------------
 INPUT_ENCODING         = UTF-8
 INPUT                  = ../../src/ \
+                         ../../tests \
+                         ../../admin/scons
 FILE_PATTERNS          = *.c \
                          *.cc \
-                         *.cxx \
                          *.cpp \
-                         *.ii \
-                         *.ixx \
-                         *.ipp \
-                         *.i++ \
-                         *.inl \
                          *.h \
                          *.hh \
-                         *.hxx \
                          *.hpp \
-                         *.h++ \
                          *.inc \
                          *.dox \
-                         *.C \
-                         *.CC \
-                         *.C++ \
-                         *.H \
-                         *.HH \
-                         *.H++ \
-                         *.PY \
                          *.py
 RECURSIVE              = YES
+EXCLUDE                =
 EXCLUDE_SYMLINKS       = YES
+EXCLUDE_PATTERNS       =
+EXCLUDE_SYMBOLS        =
+EXAMPLE_PATH           =
+EXAMPLE_PATTERNS       =
 EXAMPLE_RECURSIVE      = NO
+IMAGE_PATH             =
+INPUT_FILTER           =
+FILTER_PATTERNS        =
 FILTER_SOURCE_FILES    = NO
+FILTER_SOURCE_PATTERNS =
+USE_MDFILE_AS_MAINPAGE =
 
 #---------------------------------------------------------------------------
 # Configuration options related to source browsing
@@ -139,14 +163,15 @@ STRIP_CODE_COMMENTS    = YES
 REFERENCED_BY_RELATION = YES
 REFERENCES_RELATION    = YES
 REFERENCES_LINK_SOURCE = YES
+SOURCE_TOOLTIPS        = YES
 USE_HTAGS              = NO
-VERBATIM_HEADERS       = YES
+VERBATIM_HEADERS       = NO
+CLANG_ASSISTED_PARSING = NO
 
 #---------------------------------------------------------------------------
 # Configuration options related to the alphabetical class index
 #---------------------------------------------------------------------------
 ALPHABETICAL_INDEX     = YES
-COLS_IN_ALPHA_INDEX    = 5
 IGNORE_PREFIX          = lumiera:: \
                          lumiera_ \
                          lumi_ \
@@ -161,23 +186,55 @@ HTML_FILE_EXTENSION    = .html
 HTML_HEADER            =
 HTML_FOOTER            =
 HTML_STYLESHEET        =
-HTML_ALIGN_MEMBERS     = YES
+HTML_EXTRA_STYLESHEET  =
-GENERATE_HTMLHELP      = NO
+HTML_EXTRA_FILES       =
+HTML_COLORSTYLE        = LIGHT
+HTML_DYNAMIC_MENUS     = YES
+HTML_DYNAMIC_SECTIONS  = NO
+HTML_CODE_FOLDING      = NO
+HTML_PROJECT_COOKIE    = DoxyLumiBrow
+HTML_INDEX_NUM_ENTRIES = 500
 GENERATE_DOCSET        = NO
+GENERATE_HTMLHELP      = NO
+GENERATE_ECLIPSEHELP   = NO
+TOC_EXPAND             = NO
 DISABLE_INDEX          = NO
-ENUM_VALUES_PER_LINE   = 4
 GENERATE_TREEVIEW      = YES
 TREEVIEW_WIDTH         = 250
-FORMULA_FONTSIZE       = 10
+ENUM_VALUES_PER_LINE   = 4
+EXT_LINKS_IN_WINDOW    = NO
+HTML_FORMULA_FORMAT    = svg
+FORMULA_FONTSIZE       = 9
+USE_MATHJAX            = NO
 SEARCHENGINE           = NO
 
 #---------------------------------------------------------------------------
-# Configuration options for other output formats
+# Configuration options related to the LaTeX output
 #---------------------------------------------------------------------------
 GENERATE_LATEX         = NO
+LATEX_OUTPUT           = latex
+LATEX_CMD_NAME         = latex
+MAKEINDEX_CMD_NAME     = makeindex
+COMPACT_LATEX          = YES
+PAPER_TYPE             = a4wide
+EXTRA_PACKAGES         =
+LATEX_HEADER           =
+LATEX_FOOTER           =
+LATEX_EXTRA_STYLESHEET =
+LATEX_EXTRA_FILES      =
+PDF_HYPERLINKS         = YES
+USE_PDFLATEX           = YES
+LATEX_BATCHMODE        = YES
+LATEX_HIDE_INDICES     = NO
+LATEX_BIB_STYLE        = plain
+
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
 GENERATE_RTF           = NO
 GENERATE_MAN           = NO
 GENERATE_XML           = NO
+GENERATE_DOCBOOK       = NO
 GENERATE_AUTOGEN_DEF   = NO
 GENERATE_PERLMOD       = NO
 
@@ -190,7 +247,7 @@ EXPAND_ONLY_PREDEF     = NO
 SEARCH_INCLUDES        = YES
 INCLUDE_PATH           =
 INCLUDE_FILE_PATTERNS  =
-PREDEFINED             = 
+PREDEFINED             = __cplusplus DEBUG EBUG_ALPHA
 EXPAND_AS_DEFINED      =
 SKIP_FUNCTION_MACROS   = YES
 
@@ -202,33 +259,29 @@ GENERATE_TAGFILE       =
 ALLEXTERNALS           = NO
 EXTERNAL_GROUPS        = YES
 EXTERNAL_PAGES         = NO
-PERL_PATH              = /usr/bin/perl
 
 #---------------------------------------------------------------------------
 # Configuration options related to the dot tool
 #---------------------------------------------------------------------------
-CLASS_DIAGRAMS         = NO
-HIDE_UNDOC_RELATIONS   = YES
 HAVE_DOT               = YES
-DOT_FONTNAME           = FreeSans
+DOT_NUM_THREADS        = 0     # use all cores
-DOT_FONTPATH           = 
 CLASS_GRAPH            = NO
 COLLABORATION_GRAPH    = NO
-GROUP_GRAPHS           = NO
+GROUP_GRAPHS           = YES
+HIDE_UNDOC_RELATIONS   = YES
 UML_LOOK               = YES
-TEMPLATE_RELATIONS     = NO
+UML_LIMIT_NUM_FIELDS   = 12
+TEMPLATE_RELATIONS     = YES
 INCLUDE_GRAPH          = NO
 INCLUDED_BY_GRAPH      = NO
 CALL_GRAPH             = NO
 CALLER_GRAPH           = NO
-GRAPHICAL_HIERARCHY    = NO
 DIRECTORY_GRAPH        = NO
-DOT_IMAGE_FORMAT       = png
+GRAPHICAL_HIERARCHY    = NO
-DOT_PATH               = 
+DOT_IMAGE_FORMAT       = svg
-DOTFILE_DIRS           = 
+INTERACTIVE_SVG        = NO
 DOT_GRAPH_MAX_NODES    = 50
 MAX_DOT_GRAPH_DEPTH    = 10
-DOT_TRANSPARENT        = NO
 DOT_MULTI_TARGETS      = NO
 GENERATE_LEGEND        = NO
 DOT_CLEANUP            = YES

doc/devel/Doxyfile.pdf

@@ -1,4 +1,4 @@
-# Doxyfile 1.5.6
+# Doxyfile 1.8.13
 
 # Variation of the Lumiera Doxygen configuration for PDF output
 #
@@ -12,12 +12,15 @@
 #---------------------------------------------------------------------------
 DOXYFILE_ENCODING      = UTF-8
 PROJECT_NAME           = Lumiera
-PROJECT_NUMBER         = 0.pre.03
+PROJECT_NUMBER         = 0.pre.05~dev
+PROJECT_BRIEF          = "»edit your freedom«"
+PROJECT_LOGO           = draw/rendered/LumiLogo-small.png
 OUTPUT_DIRECTORY       =
 CREATE_SUBDIRS         = YES
+ALLOW_UNICODE_NAMES    = NO
 OUTPUT_LANGUAGE        = English
 BRIEF_MEMBER_DESC      = YES
-REPEAT_BRIEF           = NO
+REPEAT_BRIEF           = YES
 ABBREVIATE_BRIEF       = "The $name class" \
                          "The $name widget" \
                          "The $name file" \
@@ -33,28 +36,48 @@ ALWAYS_DETAILED_SEC    = NO
 INLINE_INHERITED_MEMB  = NO
 FULL_PATH_NAMES        = YES
 STRIP_FROM_PATH        = ../../src/ \
-STRIP_FROM_INC_PATH    = 
+                         ../../tests/
+STRIP_FROM_INC_PATH    = ../../src/
 SHORT_NAMES            = NO
 JAVADOC_AUTOBRIEF      = YES
 QT_AUTOBRIEF           = NO
 MULTILINE_CPP_IS_BRIEF = NO
-DETAILS_AT_TOP         = NO
+PYTHON_DOCSTRING       = NO
 INHERIT_DOCS           = YES
 SEPARATE_MEMBER_PAGES  = NO
 TAB_SIZE               = 4
+ALIASES                =
 OPTIMIZE_OUTPUT_FOR_C  = NO
+OPTIMIZE_OUTPUT_JAVA   = NO
+EXTENSION_MAPPING      =
+MARKDOWN_SUPPORT       = YES
+MARKDOWN_ID_STYLE      = GITHUB
+TOC_INCLUDE_HEADINGS   = 2
+AUTOLINK_SUPPORT       = YES
 BUILTIN_STL_SUPPORT    = YES
-TYPEDEF_HIDES_STRUCT   = NO
+CPP_CLI_SUPPORT        = NO
+IDL_PROPERTY_SUPPORT   = NO
+DISTRIBUTE_GROUP_DOC   = NO
+GROUP_NESTED_COMPOUNDS = NO
+SUBGROUPING            = YES
+INLINE_GROUPED_CLASSES = NO
+INLINE_SIMPLE_STRUCTS  = YES
+TYPEDEF_HIDES_STRUCT   = YES
+LOOKUP_CACHE_SIZE      = 2
+NUM_PROC_THREADS       = 0
+TIMESTAMP              = DATE
 
 #---------------------------------------------------------------------------
 # Build related configuration options
 #---------------------------------------------------------------------------
 EXTRACT_ALL            = NO
 EXTRACT_PRIVATE        = NO
+EXTRACT_PACKAGE        = NO
 EXTRACT_STATIC         = YES
 EXTRACT_LOCAL_CLASSES  = YES
 EXTRACT_LOCAL_METHODS  = NO
 EXTRACT_ANON_NSPACES   = NO
+RESOLVE_UNNAMED_PARAMS = YES
 HIDE_UNDOC_MEMBERS     = YES
 HIDE_UNDOC_CLASSES     = YES
 HIDE_FRIEND_COMPOUNDS  = NO
@@ -62,21 +85,29 @@ HIDE_IN_BODY_DOCS      = YES
 INTERNAL_DOCS          = NO
 CASE_SENSE_NAMES       = YES
 HIDE_SCOPE_NAMES       = NO
+SHOW_HEADERFILE        = NO
 SHOW_INCLUDE_FILES     = NO
+SHOW_GROUPED_MEMB_INC  = NO
+FORCE_LOCAL_INCLUDES   = YES
 INLINE_INFO            = YES
 SORT_MEMBER_DOCS       = YES
 SORT_BRIEF_DOCS        = YES
+SORT_MEMBERS_CTORS_1ST = YES
 SORT_GROUP_NAMES       = NO
 SORT_BY_SCOPE_NAME     = NO
+STRICT_PROTO_MATCHING  = NO
 GENERATE_TODOLIST      = NO
-GENERATE_TESTLIST      = NO
+GENERATE_TESTLIST      = YES
 GENERATE_BUGLIST       = NO
 GENERATE_DEPRECATEDLIST= NO
-MAX_INITIALIZER_LINES  = 10
+ENABLED_SECTIONS       =
+MAX_INITIALIZER_LINES  = 50
 SHOW_USED_FILES        = NO
-SHOW_DIRECTORIES       = NO
 SHOW_FILES             = YES
 SHOW_NAMESPACES        = YES
+FILE_VERSION_FILTER    =
+LAYOUT_FILE            =
+CITE_BIB_FILES         =
 
 #---------------------------------------------------------------------------
 # Configuration options related to warning and progress messages
@@ -86,6 +117,7 @@ WARNINGS               = YES
 WARN_IF_UNDOCUMENTED   = NO
 WARN_IF_DOC_ERROR      = YES
 WARN_NO_PARAMDOC       = NO
+WARN_AS_ERROR          = NO
 WARN_FORMAT            = "$file:$line: $text"
 WARN_LOGFILE           = doxygen-warnings-pdf.txt
 
@@ -93,35 +125,32 @@ WARN_LOGFILE           = doxygen-warnings-pdf.txt
 # Configuration options related to the input files
 #---------------------------------------------------------------------------
 INPUT_ENCODING         = UTF-8
-INPUT                  = ../../src/
+INPUT                  = ../../src/ \
+                         ../../tests \
+                         ../../admin/scons
 FILE_PATTERNS          = *.c \
                          *.cc \
-                         *.cxx \
                          *.cpp \
-                         *.ii \
-                         *.ixx \
-                         *.ipp \
-                         *.i++ \
-                         *.inl \
                          *.h \
                          *.hh \
-                         *.hxx \
                          *.hpp \
-                         *.h++ \
                          *.inc \
                          *.dox \
-                         *.C \
-                         *.CC \
-                         *.C++ \
-                         *.H \
-                         *.HH \
-                         *.H++ \
-                         *.PY \
                          *.py
 RECURSIVE              = YES
+EXCLUDE                =
 EXCLUDE_SYMLINKS       = YES
+EXCLUDE_PATTERNS       =
+EXCLUDE_SYMBOLS        =
+EXAMPLE_PATH           =
+EXAMPLE_PATTERNS       =
 EXAMPLE_RECURSIVE      = NO
+IMAGE_PATH             =
+INPUT_FILTER           =
+FILTER_PATTERNS        =
 FILTER_SOURCE_FILES    = NO
+FILTER_SOURCE_PATTERNS =
+USE_MDFILE_AS_MAINPAGE =
 
 #---------------------------------------------------------------------------
 # Configuration options related to source browsing
@@ -132,14 +161,15 @@ STRIP_CODE_COMMENTS    = YES
 REFERENCED_BY_RELATION = YES
 REFERENCES_RELATION    = YES
 REFERENCES_LINK_SOURCE = YES
+SOURCE_TOOLTIPS        = NO
 USE_HTAGS              = NO
 VERBATIM_HEADERS       = NO
+CLANG_ASSISTED_PARSING = NO
 
 #---------------------------------------------------------------------------
 # Configuration options related to the alphabetical class index
 #---------------------------------------------------------------------------
 ALPHABETICAL_INDEX     = YES
-COLS_IN_ALPHA_INDEX    = 5
 IGNORE_PREFIX          = lumiera:: \
                          lumiera_ \
                          lumi_ \
@@ -149,11 +179,31 @@ IGNORE_PREFIX          = lumiera:: \
 # Configuration options related to the HTML output
 #---------------------------------------------------------------------------
 GENERATE_HTML          = NO
+HTML_OUTPUT            = html_browse
+HTML_FILE_EXTENSION    = .html
+HTML_HEADER            =
+HTML_FOOTER            =
+HTML_STYLESHEET        =
+HTML_EXTRA_STYLESHEET  =
+HTML_EXTRA_FILES       =
+HTML_COLORSTYLE        = LIGHT
+HTML_DYNAMIC_MENUS     = YES
+HTML_DYNAMIC_SECTIONS  = NO
+HTML_CODE_FOLDING      = NO
+HTML_PROJECT_COOKIE    = DoxyLumiBrow
+HTML_INDEX_NUM_ENTRIES = 500
+GENERATE_DOCSET        = NO
+GENERATE_HTMLHELP      = NO
+GENERATE_ECLIPSEHELP   = NO
+TOC_EXPAND             = NO
 DISABLE_INDEX          = NO
-ENUM_VALUES_PER_LINE   = 4
 GENERATE_TREEVIEW      = YES
 TREEVIEW_WIDTH         = 250
-FORMULA_FONTSIZE       = 10
+ENUM_VALUES_PER_LINE   = 4
+EXT_LINKS_IN_WINDOW    = NO
+HTML_FORMULA_FORMAT    = svg
+FORMULA_FONTSIZE       = 9
+USE_MATHJAX            = NO
 SEARCHENGINE           = NO
 
 #---------------------------------------------------------------------------
@@ -167,14 +217,22 @@ COMPACT_LATEX          = YES
 PAPER_TYPE             = a4wide
 EXTRA_PACKAGES         =
 LATEX_HEADER           =
+LATEX_FOOTER           =
+LATEX_EXTRA_STYLESHEET =
+LATEX_EXTRA_FILES      =
 PDF_HYPERLINKS         = YES
 USE_PDFLATEX           = YES
 LATEX_BATCHMODE        = YES
 LATEX_HIDE_INDICES     = NO
+LATEX_BIB_STYLE        = plain
 
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
 GENERATE_RTF           = NO
 GENERATE_MAN           = NO
 GENERATE_XML           = NO
+GENERATE_DOCBOOK       = NO
 GENERATE_AUTOGEN_DEF   = NO
 GENERATE_PERLMOD       = NO
 
@@ -187,7 +245,7 @@ EXPAND_ONLY_PREDEF     = NO
 SEARCH_INCLUDES        = YES
 INCLUDE_PATH           =
 INCLUDE_FILE_PATTERNS  =
-PREDEFINED             = 
+PREDEFINED             = __cplusplus DEBUG EBUG_ALPHA
 EXPAND_AS_DEFINED      =
 SKIP_FUNCTION_MACROS   = YES
 
@@ -198,33 +256,30 @@ TAGFILES               =
 GENERATE_TAGFILE       =
 ALLEXTERNALS           = NO
 EXTERNAL_GROUPS        = NO
-PERL_PATH              = /usr/bin/perl
+EXTERNAL_PAGES         = NO
 
 #---------------------------------------------------------------------------
 # Configuration options related to the dot tool
 #---------------------------------------------------------------------------
-CLASS_DIAGRAMS         = NO
-HIDE_UNDOC_RELATIONS   = YES
 HAVE_DOT               = YES
-DOT_FONTNAME           = FreeSans
+DOT_NUM_THREADS        = 0     # use all cores
-DOT_FONTPATH           = 
 CLASS_GRAPH            = NO
 COLLABORATION_GRAPH    = NO
-GROUP_GRAPHS           = NO
+GROUP_GRAPHS           = YES
-UML_LOOK               = NO
+HIDE_UNDOC_RELATIONS   = YES
-TEMPLATE_RELATIONS     = NO
+UML_LOOK               = YES
+UML_LIMIT_NUM_FIELDS   = 12
+TEMPLATE_RELATIONS     = YES
 INCLUDE_GRAPH          = NO
 INCLUDED_BY_GRAPH      = NO
 CALL_GRAPH             = NO
 CALLER_GRAPH           = NO
-GRAPHICAL_HIERARCHY    = NO
 DIRECTORY_GRAPH        = NO
+GRAPHICAL_HIERARCHY    = NO
 DOT_IMAGE_FORMAT       = png
-DOT_PATH               = 
+INTERACTIVE_SVG        = NO
-DOTFILE_DIRS           = 
 DOT_GRAPH_MAX_NODES    = 50
 MAX_DOT_GRAPH_DEPTH    = 10
-DOT_TRANSPARENT        = NO
+DOT_MULTI_TARGETS      = NO
-DOT_MULTI_TARGETS      = YES
 GENERATE_LEGEND        = NO
 DOT_CLEANUP            = YES

doc/devel/Status.txt

@@ -0,0 +1,64 @@
+Development Status
+==================
+:Date: {localdate}
+
+Current Phase::
+    [big green                   ]#Development#
+//  [big purple yellow-background]#Convergence#
+//  [big navy   aqua-background  ]#Release preparation#
+
+-> link:{ldoc}/technical/code/GitBranching.html[Git-flow] +
+-> link:{ldoc}/technical/infra/Release.html[Release]
+
+
+
+
+Objectives
+----------
+At the current stage of development, the focus is primarily on the
+overall integration of fundamental functionality at all levels of
+the code base. A sequence of
+link:{ldoc}/design/governance/integration.html[Integration steps]
+has been defined, each driven by some pivotal functionality,
+to be implemented as a »Vertical Slice«.
+
+Our Goal is to integrate an ongoing render process, with a render
+pipeline in the engine and video output in the UI.
+
+- A network of Render Nodes can now be built and invoked [green]#✔#
+- 🗘 The provisional buffer memory manager needs to be improved next,
+  to resolve a mismatch between the _Buffer Protocol_ and the
+  _Output Sink Protocol_, so that the target buffer of an output
+  sink can be used seamlessly within the Render Node network.
+- Another point to be resolved next is to decide upon the design
+  of the _Vierwer Output Connection_, which shall be used as an
+  anchor point for the running playback process.
+- Next we need a solution how to integrate some _Video Output_ solution
+  into the Lumiera UI (-> see the link:/research/videoDisplay/[recent research]),
+  so that it can be represented as an _Output{nbsp}Slot_.
+- After that, we could look into the integration of _Job Planning_
+  this _Output Slot_ with the _Scheduler_.
+- Once this has been accomplished, it should be possible to fill in
+  the remaining parts into the _Play Process_ implementation.
+- Furthermore we still need some provisional solution how to
+  trigger all this new functionality from the UI.
+
+
+
+
+Current Release
+---------------
+[red]#Lumiera is not usable yet#.
+
+- A »Preview Release« was
+  https://git.lumiera.org/?p=LUMIERA;a=tag;h=refs/tags/v0.pre.04[published at Dec 2, 2025]
+
+- link:/debian[DEB packages]
+  were built for »Trixie« and »Noble«
+
+
+Changelog
+~~~~~~~~~
+
+include::Changelog[lines="26..10000"]
+

doc/devel/design_process.txt

@@ -11,8 +11,17 @@ Design Process
 //Menu: attach child 'rfc'
 
 
-How it Works
+.Formalized discussions within a group of developers
-------------
+The purpose of the ``Lumiera Design Process'' is to coordinate and document
+important discussions and decisions regarding the Architecture, the fundamental
+technologies used, the coding framework and development methods.
+
+CAUTION: Since several years now, _Ichthyo_ is working alone. +
+         The Design process is ``dormant'' currently (2025).
+
+
+Proceedings
+-----------
 Design Process entries (Request for Comment) can be created by anyone.
 Each entry goes through several stages until it's accepted (or rejected).
 All our RfC entries are filed here, either in the  link:rfc_final/index.html[RfC accepted] section,
@@ -21,23 +30,46 @@ or as link:rfc_pending/index.html[pending RfC] or as link:rfc_dropped/index.html
 * Every proposal starts out as _*Idea*_, allowing other people to review and comment on it, while still working out details.
 * When the _Idea_ is in a proper shape and worked out in most details it becomes a _*Draft*_.
   This _Draft_ need to be carefully reviewed, commented, perhaps corrected and rated by the other Developers.
-* We decide on some proposals to talk about that another time, these get a _*Parked*_ state.
+* We may decide to discuss some proposals at a later date; these will be postponed for now and
-* At some point we may decide that a _*Draft*_ becomes a _*Final*_.
+  transition into _*Parked*_ state.
+* At some point we may decide that a _*Draft*_ is accepted and can transition to _*Final*_ state.
   Usually, this happens in our link:/devs-vault/meeting/index.html[monthly developers meetings].
 * Sometimes proposals will become dropped for some reason, this is indicated by changing their state to _*Dropped*_,
   they still stay in the system for further reference.
 
-Generally you should refrain from editing someone others proposals (except for typo and grammar fixes)
+In general, you should not edit other people's proposals (except to correct typos and grammar mistakes)
-when this is not acknowledged with the original author. Rather only add comments to the pages and please
+unless this has been agreed upon with the original author. Instead, please only add comments at the end
-care to sign your comments in order to make it easier to find out who is the contact person for some note.
+of the page and sign them with your name and the date so that it is easier to follow the sequence of
+arguments and to find the contact person for each note. Furthermore, when the ongoing discussion
+happens to transform a proposal into something entirely different, you should not try to amend
+the original proposal to reflect the changes, but rather _drop it_ and open a new one,
+referring back to the original text.
+
+
+What qualifies as RfC proposal
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The RfC documents summarise important decisions where participating developers need to agree
+upon some course of action, going forward. It is not the proper format to bring up ``interesting''
+ideas for general discussion, nor is it meant to document technical details and findings, or to
+promote feature wishes. Prior to opening a RfC entry, an informal discussion should have taken place
+to determine whether the idea has a reasonable chance of receiving support, whether there is a need
+for further discussion, or whether a consensus already exists. It should also be ensured that
+Someone^TM^ will take care of the implementation, or that the topic is considered important enough
+to be defined as a long-term goal.
+
+- The proposal should revolve around a single idea, topic, method or solution
+- It should be specific and describe _one_ proposed _solution approach,_ even while
+  the intention of the proposal might be to discuss the further direction to take,
+  or to achieve a decision regarding various possibilities ahead.
+- The proposal should be well defined and actionable.
+- It should be roughly clear what steps need to be taken to make the proposal happen.
+- It _must_ be possible to underpin the benefits (``pro'') and the drawbacks (``con'')
+  with _valid arguments_, that can be debated by reasoning.
+- It should be possible to examine and reason about at least one alternative.
 
-What qualifies as an RfC proposal
----------------------------------
-CAUTION: to be written
 
 Handling of RfC entries in practice
------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
 .Adding a new Proposal:
 . Check if there is no similar proposal below! If yes, contact it's author and contribute to that one.
 . Think of a good/descriptive _Name-ID_ for the Proposal. It will be used to create a RfC sub-page, so no embedded spaces please.

doc/technical/infra/Release.txt

@@ -3,7 +3,7 @@ Release preparation
 :Author: Ichthyo
 :Date: Nov 2025
 
-We have nothing to show and don't provide public releases yet --
+We have nothing to show yet and don't provide public releases --
 but we ought to rehearse and practice the release process.
 This document contains some hints and a checklist of steps
 to perform for a proper release.
@@ -14,6 +14,18 @@ IMPORTANT: Lumiera uses link:{ldoc}/technical/code/GitBranching.html[Git-flow]
            automation of these steps was not yet considered. So please be
            sure to adhere to the established conventions.
 
+.Each Release has three phases
+- Development
+- Convergence
+- Preparation
+
+During the »convergence phase«, all participants must prioritise code stability.
+After the »release cut«, development can resume freely on branch `integration`,
+while »release preparation« ensues on the _release branch_. The
+published documentation branch and the website will follow suit on the
+release branch. Please mark the current phase on the
+link:{ldoc}/devel/Status.html[Development Status] page.
+
 
 Steps to perform for a release
 ------------------------------
@@ -21,6 +33,7 @@ Steps to perform for a release
  . Pre-Release _»convergence phase«_
 
    - care for code stability and refrain from breaking changes
+   - announce and mark »convergence« on the link:{ldoc}/devel/Status.html[Status] page.
    - verify that the _current version number_ is already set to
      the version number expected for the upcoming release, yet
      decorated with the `~dev` suffix -- if it turns out that
@@ -133,5 +146,5 @@ what you set here *must* be the next version _after the release_
    - clean-up and discard obsoleted old distributions and packages
 
  . Close the **Release Ticket**
-
+   and update the link:{ldoc}/devel/Status.html[Status] page.
 

wiki/renderengine.html

@@ -2177,6 +2177,48 @@ Similar to an Asset, an identification tuple is available (generated on the fly)
 → MetaAsset
 </pre>
 </div>
+<div title="EventCQRS" creator="Ichthyostega" modifier="Ichthyostega" created="202510122028" modified="202510122047" tags="Concepts Model Mutation def" changecount="3">
+<pre>//~Command-and-Query-Responsibility-Separation (CQRS) describes an asynchronous architecture without a central data model.//
+In this arrangement of components, the old guideline to separate the processing of queries and mutations is applied to the relation of interfaces and functional clusters within the system. The chain of //business logic// processing is completely segregated from the date models and is organised essentially as a pipeline, where desired operations are instructed as //commands//. Each command is validated, and then performed within a conditioned environment, which is isolated from the persistent data in the system. The effect of a command execution is then propagated and distributed to various //»projections«// to produce the actual persistent mutation of the data in the system. On the other hand, any interface to query the state and the data content is provided by services altogether unrelated to any //processing// in the system.
+
+An architecture based on CQRS can be challenging to build properly, because any //effect// has to be //represented// instead of //just happening//. Yet this architecture style is known to offer several unique benefits:
+* processing is guaranteed to be side-effect free
+* it is easy to define and verify well-defined behaviour for each command
+* it is possible to maintain several, specialised projections which focus on specific aspects of the effect
+* the data model within some query-oriented service is an implementation detail and can be modified at will, as long as the defined effect is retained.
+
+CQRS is typically combined with EventSourcing to represent the effects of processing as a sequence of //events// in an EventLog
+</pre>
+</div>
+<div title="EventLog" creator="Ichthyostega" modifier="Ichthyostega" created="202510092241" modified="202510122053" tags="Mutation def design draft" changecount="4">
+<pre>//The global ''Event Log'' records the fact that something ''has happened'' as result from a command or instruction.//
+The EventLog is a central element of the [[CQRS|EventCQRS]] architecture model.
+After some //event has been recorded,// it is propagated to the »projections«, which are listeners to the event log and may mutate their internal state in response to some event. Notably a data model is attached as a projection, and thus the complete content of such a data model can be seen as a materialisation of the event sequence. The entire state of the data in the model can any time be reproduced by //re-playing// the entire event log to a clean slate.
+
+!Structure of Events
+First and foremost, each event must be well defined and can be addressed by an unique identifier (hash based). Furthermore, each event is marked with a specification version -- and the implementation of the the expected effects of a given version is never changed. This allows the system to evolve while in use: improved implementations of some event can coexist with earlier versions of the same event in the same log.
+
+Events serve as foundation to allow corrections and revisions of the history of events: any event can be un-done, by replaying the event log without the event in question. In practice however this requirement can be difficult to uphold, since it might lead to a proliferation of complicated events. It is thus desirable to introduce //transactions// -- defined as a group of events which are considered to happen in compound. Each such group or transactional compound of events is considered itself an event. Notably the processing of some //command// might produce several events, some of which are generated automatically to reflect effects of this command based on the current state of data, rules and configuration. As an example, if the execution of business logic needs to query fro some default, this processing of a rule query might generate a //binding//, which also becomes part of the next state and thus need to be represented as a further event within that command's transactional event group.
+</pre>
+</div>
+<div title="EventSourcing" creator="Ichthyostega" modifier="Ichthyostega" created="202510092238" modified="202510122002" tags="Concepts Model Mutation discuss draft" changecount="3">
+<pre>//''Event Sourcing'' is an Architecture pattern and used together with [[CQRS|EventCQRS]].//
+Over the course of the years, it gradually became clear that the goals defined regarding consistency and fine-grained control of the arrangement in the session seem to converge towards an architecture based on these principles
+
+!Difficulties and Contradictions
+An insidious problem arises from the aspiration to control widespread behaviour through common rules.
+Allowing to change rules and facts seems to be in direct contradiction to the requirement of deterministic and reproducible behaviour.
+Notably, the facts can be a representation of the environment, like e.g. the sound setup in a Studio vs. working on a Laptop.
+
+Since a long time, I used the formula to //separate decisions from the processing logic// in the code.
+
+An analysis of the kinds of decisions relevant for the situation with editing a media arrangement reveals that a dangerous conflict might ensue when the foundation of a past rule application changes, possibly by undo or replay of the EventLog.
+
+!!!Solution: record the relation
+A solution could be not only to apply rules, but also capture and materialise the fact that a rule has been applied and especially to record a connection between the setting and
+the rule it was based on. This amounts to documenting the reasoning why some decision came about. If done correct, such a data model would allow to re-evaluate past decisions
+quickly in case the facts or the rules are changed.</pre>
+</div>
 <div title="ExitNode" modifier="Ichthyostega" created="200706220322" modified="202412221801" tags="def discuss" changecount="2">
 <pre>//The point where to pull the finished output of one Render Pipeline (Tree or Graph).//
 This term is already used in the Cinelerra2 codebase. In Lumiera however it is a distinct term only related to the data retrieval point for a [[job|RenderJob]]. The precise relation to a concrete ProcNode and [[port #|NodePort]] still needs to be worked out {{red{as of 12/2024}}}.
@@ -4535,8 +4577,11 @@ Meta assets are ''immutable'' -- but they can be //superseded.//
 For each meta asset instance, initially a //builder// is created for setting up the properties; when done, the builder will &quot;drop off&quot; the new meta asset instance. The same procedure is used for augmenting or superseding an existing element.
 </pre>
 </div>
-<div title="Model" modifier="Ichthyostega" created="201003210020" modified="201003210021" tags="overview">
+<div title="Model" modifier="Ichthyostega" created="201003210020" modified="202510092231" tags="overview" changecount="1">
-<pre>Lumiera's Steam-Layer is built around //two interconnected models,// mediated by the [[Builder]]. Basically, the &amp;rarr;[[Session]] is an external interface to the HighLevelModel, while the &amp;rarr;RenderEngine operates the structures of the LowLevelModel.</pre>
+<pre>Lumiera's Steam-Layer is built around //two interconnected models,// mediated by the [[Builder]]. Basically, the &amp;rarr;[[Session]] is an external interface to the HighLevelModel, while the &amp;rarr;RenderEngine operates the structures of the LowLevelModel.
+
+! Changing the Model
+An essential question of the design is how the model is changed (through the EditingOperations) and how such changes can be coordinated and propagated. The initial design was based on ''Commands'' -- yet, over time, it became clear that for consistent and predictable behaviour, it is preferably to [[record Events|EventSourcing]] in a global EventLog.</pre>
 </div>
 <div title="ModelDependencies" modifier="Ichthyostega" created="201003020150" modified="201702142325" tags="SessionLogic Model operational spec draft img" changecount="6">
 <pre>Our design of the models (both [[high-level|HighLevelModel]] and [[low-level|LowLevelModel]]) relies partially on dependent objects being kept consistently in sync. Currently (2/2010), __ichthyo__'s assessment is to consider this topic not important and pervasive enough to justify building a dedicated solution, like e.g. a central tracking and registration service. An important point to consider with this assessment is the fact that the session implementation is deliberately kept single-threaded. While this simplifies reasoning, we also lack one central place to handle this issue, and thus care has to be taken to capture and treat all the relevant individual dependencies properly at the implementation level.