ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Compare commits

merge into: ichthyo:master
Branches Tags
ichthyo:master
ichthyo:dev/play
ichthyo:integration
ichthyo:v0.pre.04
ichthyo:prg@ichthyostega.de/integration_signature
ichthyo:platform/Trixie
ichthyo:platform/Buster
ichthyo:platform/Jessie
ichthyo:0.pre.03
ichthyo:0.pre.02
ichthyo:0.pre.01
ichthyo:prg@ichthyostega.de/gui_signature
ichthyo:dummy-player
ichthyo:GUI-plugin-startup
ichthyo:Lumiera-is-born
...
pull from: ichthyo:integration
Branches Tags
ichthyo:dev/play
ichthyo:integration
ichthyo:master
ichthyo:v0.pre.04
ichthyo:prg@ichthyostega.de/integration_signature
ichthyo:platform/Trixie
ichthyo:platform/Buster
ichthyo:platform/Jessie
ichthyo:0.pre.03
ichthyo:0.pre.02
ichthyo:0.pre.01
ichthyo:prg@ichthyostega.de/gui_signature
ichthyo:dummy-player
ichthyo:GUI-plugin-startup
ichthyo:Lumiera-is-born

6 commits
master ... integratio

Author SHA1 Message Date
Ichthyostega
bd48b17f70 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
 2025-12-11 05:11:55 +01:00
Ichthyostega
d0f7b3787c Merge branch 'rel/0.pre.04' into integration 2025-12-03 14:44:55 +01:00
Ichthyostega
8bff48fd2f Design: ramifications for the Event-Log 
Expand on this problem with the consequences of rule changes.
Need to consider how recording this information is related
to the data structures of the Event-Log...

__Remark__: this topic belongs into the ''next planned'' Vertical Slice »LoadClip«
 2025-10-12 22:54:09 +02:00
Ichthyostega
38ea195555 Design: Idea how to reconcile rules with controlled change 
Allowing to change rules and facts seems to be in direct contradiction
to using an Event-Log for 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 Event-Log.

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.
 2025-10-10 00:43:08 +02:00
Ichthyostega
c0082593b4 Design: consider what makes decision logic problematic... 
While I am currently deeply entrenched in the history of Lumiera
and related general questions of dealing with complexity, some
ramifications became clear for the next topics to address,
notably related to ''Event Sourcing''
 2025-10-09 19:35:17 +02:00
Ichthyostega
aba5781754 Dev: bump version to 0.pre.05~dev 
__Explanation__: in line with the Git-flow scheme, the version number
embedded in-tree will now indicate the ''expected next release version,''
yet marked with a suffix `~dev` (which sorts ''before'' this version number)
 2025-07-21 18:54:15 +02:00
13 changed files with 1318 additions and 305 deletions
Show stats Expand all files Collapse all files

18
NEWS
View file

@ -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,
followed by clean-up of workarounds now obsoleted. On the GUI side, we largely
made the transition to GTK-3, which leads to a rework of our timeline widget,
which is in progress but not finished yet. This work also spurred an effort
to reorder the connection and communication between core and the UI, which
is expected to be asynchronous. Due to the limited developer resources,
work on the Engine and Player part is stalled.
The codebase has been upgraded to C++14 and Debian/Jessie as reference platform,
followed by clean-up of several workarounds now obsoleted. On the GUI side,
the transition to GTK-3 was accomplished, which however necessitates a rework
of our timeline widget, which is in progress but not finished yet. This work
also spurred an effort to reorder the connection and communication between
the core and the UI, which is expected to be asynchronous. Due to the limited
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

2
README
View file

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

2
admin/scons/Setup.py
View file

@ -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'

2
data/config/setup.ini
View file

@ -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

1
doc/devel/Changelog Symbolic link
View file

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

2
doc/devel/Doxyfile
View file

@ -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 =

149
doc/devel/Doxyfile.browse
View file

@ -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
GENERATE_HTMLHELP = NO
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
#---------------------------------------------------------------------------
# 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_FONTPATH =
DOT_NUM_THREADS = 0 # use all cores
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
DOT_PATH =
DOTFILE_DIRS =
GRAPHICAL_HIERARCHY = NO
DOT_IMAGE_FORMAT = svg
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

139
doc/devel/Doxyfile.pdf
View file

@ -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_FONTPATH =
DOT_NUM_THREADS = 0 # use all cores
CLASS_GRAPH = NO
COLLABORATION_GRAPH = NO
GROUP_GRAPHS = NO
UML_LOOK = NO
TEMPLATE_RELATIONS = NO
GROUP_GRAPHS = YES
HIDE_UNDOC_RELATIONS = YES
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 =
DOTFILE_DIRS =
INTERACTIVE_SVG = NO
DOT_GRAPH_MAX_NODES = 50
MAX_DOT_GRAPH_DEPTH = 10
DOT_TRANSPARENT = NO
DOT_MULTI_TARGETS = YES
DOT_MULTI_TARGETS = NO
GENERATE_LEGEND = NO
DOT_CLEANUP = YES

64
doc/devel/Status.txt Normal file
View file

@ -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"]

56
doc/devel/design_process.txt
View file

@ -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.
* At some point we may decide that a _*Draft*_ becomes a _*Final*_.
* We may decide to discuss some proposals at a later date; these will be postponed for now and
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)
when this is not acknowledged with the original author. Rather only add comments to the pages and please
care to sign your comments in order to make it easier to find out who is the contact person for some note.
In general, you should not edit other people's proposals (except to correct typos and grammar mistakes)
unless this has been agreed upon with the original author. Instead, please only add comments at the end
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.

17
doc/technical/infra/Release.txt
View file

@ -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.

49
wiki/renderengine.html
View file

@ -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">
<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>
<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.
! 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.

1088
wiki/thinkPad.ichthyo.mm
View file

File diff suppressed because it is too large Load diff