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

Compare commits

base: ichthyo:prg@ichthyostega.de/integration_signature
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
..
compare: ichthyo:master
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

No commits in common. "prg@ichthyostega.de/integration_signature" and "master" have entirely different histories.
prg@ichthy ... master

13 changed files with 305 additions and 1318 deletions
Show stats Expand all files Collapse all files

18
NEWS
View file

@ -1,6 +1,6 @@
Lumiera -- Significant Changes
==============================
Version: 0.pre.05~dev
Version: 0.pre.04
:Date: 11/2025
*************************************************************
@ -16,7 +16,7 @@ from `git://git.lumiera.org/LUMIERA`
At the current stage of development, the focus is primarily on the
In 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 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.
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.
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.05~dev
Version: 0.pre.04
:Date: 11/2025
*************************************************************

2
admin/scons/Setup.py
View file

@ -22,7 +22,7 @@ import Options
#-------------------------------------------------------Configuration
TARGDIR = 'target'
VERSION = '0.pre.05~dev'
VERSION = '0.pre.04'
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.05~dev
version = 0.pre.04
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
View file

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

2
doc/devel/Doxyfile
View file

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

167
doc/devel/Doxyfile.browse
View file

@ -14,12 +14,10 @@
#---------------------------------------------------------------------------
DOXYFILE_ENCODING = UTF-8
PROJECT_NAME = Lumiera
PROJECT_NUMBER = 0.pre.05~dev
PROJECT_BRIEF = "»edit your freedom«"
PROJECT_NUMBER = 0.pre.04
PROJECT_LOGO = draw/rendered/LumiLogo-small.png
OUTPUT_DIRECTORY =
OUTPUT_DIRECTORY =
CREATE_SUBDIRS = NO
ALLOW_UNICODE_NAMES = NO
OUTPUT_LANGUAGE = English
BRIEF_MEMBER_DESC = YES
REPEAT_BRIEF = YES
@ -39,87 +37,62 @@ INLINE_INHERITED_MEMB = YES
FULL_PATH_NAMES = YES
STRIP_FROM_PATH = ../../src/ \
../../tests/
STRIP_FROM_INC_PATH = ../../src/
STRIP_FROM_INC_PATH =
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 = NO
IDL_PROPERTY_SUPPORT = YES
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
TYPEDEF_HIDES_STRUCT = NO
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
EXTRACT_ALL = YES
EXTRACT_PRIVATE = NO
EXTRACT_PACKAGE = NO
EXTRACT_PRIVATE = YES
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_MEMBERS = NO
HIDE_UNDOC_CLASSES = NO
HIDE_FRIEND_COMPOUNDS = NO
HIDE_IN_BODY_DOCS = NO
INTERNAL_DOCS = NO
INTERNAL_DOCS = YES
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 = NO
SORT_MEMBERS_CTORS_1ST = YES
SORT_BRIEF_DOCS = YES
SORT_GROUP_NAMES = NO
SORT_BY_SCOPE_NAME = NO
STRICT_PROTO_MATCHING = NO
GENERATE_TODOLIST = NO
GENERATE_TESTLIST = NO
GENERATE_BUGLIST = NO
GENERATE_BUGLIST = YES
GENERATE_DEPRECATEDLIST= NO
ENABLED_SECTIONS =
MAX_INITIALIZER_LINES = 50
MAX_INITIALIZER_LINES = 10
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 = NO
WARN_IF_UNDOCUMENTED = YES
WARN_IF_DOC_ERROR = YES
WARN_NO_PARAMDOC = NO
WARN_AS_ERROR = NO
WARN_NO_PARAMDOC = YES
WARN_FORMAT = "$file:$line: $text"
WARN_LOGFILE = doxygen-warnings-browse.txt
@ -128,31 +101,34 @@ 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
@ -163,15 +139,14 @@ STRIP_CODE_COMMENTS = YES
REFERENCED_BY_RELATION = YES
REFERENCES_RELATION = YES
REFERENCES_LINK_SOURCE = YES
SOURCE_TOOLTIPS = YES
USE_HTAGS = NO
VERBATIM_HEADERS = NO
CLANG_ASSISTED_PARSING = NO
VERBATIM_HEADERS = YES
#---------------------------------------------------------------------------
# Configuration options related to the alphabetical class index
#---------------------------------------------------------------------------
ALPHABETICAL_INDEX = YES
COLS_IN_ALPHA_INDEX = 5
IGNORE_PREFIX = lumiera:: \
lumiera_ \
lumi_ \
@ -183,58 +158,26 @@ IGNORE_PREFIX = lumiera:: \
GENERATE_HTML = YES
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
HTML_HEADER =
HTML_FOOTER =
HTML_STYLESHEET =
HTML_ALIGN_MEMBERS = YES
GENERATE_HTMLHELP = NO
GENERATE_ECLIPSEHELP = NO
TOC_EXPAND = NO
GENERATE_DOCSET = NO
DISABLE_INDEX = NO
ENUM_VALUES_PER_LINE = 4
GENERATE_TREEVIEW = YES
TREEVIEW_WIDTH = 250
ENUM_VALUES_PER_LINE = 4
EXT_LINKS_IN_WINDOW = NO
HTML_FORMULA_FORMAT = svg
FORMULA_FONTSIZE = 9
USE_MATHJAX = NO
FORMULA_FONTSIZE = 10
SEARCHENGINE = NO
#---------------------------------------------------------------------------
# Configuration options related to the LaTeX output
# Configuration options for other output formats
#---------------------------------------------------------------------------
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
@ -245,43 +188,47 @@ ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = NO
EXPAND_ONLY_PREDEF = NO
SEARCH_INCLUDES = YES
INCLUDE_PATH =
INCLUDE_FILE_PATTERNS =
PREDEFINED = __cplusplus DEBUG EBUG_ALPHA
EXPAND_AS_DEFINED =
INCLUDE_PATH =
INCLUDE_FILE_PATTERNS =
PREDEFINED =
EXPAND_AS_DEFINED =
SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
# Configuration options related to external references
#---------------------------------------------------------------------------
TAGFILES =
GENERATE_TAGFILE =
TAGFILES =
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_NUM_THREADS = 0 # use all cores
DOT_FONTNAME = FreeSans
DOT_FONTPATH =
CLASS_GRAPH = NO
COLLABORATION_GRAPH = NO
GROUP_GRAPHS = YES
HIDE_UNDOC_RELATIONS = YES
GROUP_GRAPHS = NO
UML_LOOK = YES
UML_LIMIT_NUM_FIELDS = 12
TEMPLATE_RELATIONS = YES
TEMPLATE_RELATIONS = NO
INCLUDE_GRAPH = NO
INCLUDED_BY_GRAPH = NO
CALL_GRAPH = NO
CALLER_GRAPH = NO
DIRECTORY_GRAPH = NO
GRAPHICAL_HIERARCHY = NO
DOT_IMAGE_FORMAT = svg
INTERACTIVE_SVG = NO
DIRECTORY_GRAPH = NO
DOT_IMAGE_FORMAT = png
DOT_PATH =
DOTFILE_DIRS =
DOT_GRAPH_MAX_NODES = 50
MAX_DOT_GRAPH_DEPTH = 10
DOT_TRANSPARENT = NO
DOT_MULTI_TARGETS = NO
GENERATE_LEGEND = NO
DOT_CLEANUP = YES

155
doc/devel/Doxyfile.pdf
View file

@ -1,4 +1,4 @@
# Doxyfile 1.8.13
# Doxyfile 1.5.6
# Variation of the Lumiera Doxygen configuration for PDF output
#
@ -12,15 +12,12 @@
#---------------------------------------------------------------------------
DOXYFILE_ENCODING = UTF-8
PROJECT_NAME = Lumiera
PROJECT_NUMBER = 0.pre.05~dev
PROJECT_BRIEF = "»edit your freedom«"
PROJECT_LOGO = draw/rendered/LumiLogo-small.png
OUTPUT_DIRECTORY =
PROJECT_NUMBER = 0.pre.03
OUTPUT_DIRECTORY =
CREATE_SUBDIRS = YES
ALLOW_UNICODE_NAMES = NO
OUTPUT_LANGUAGE = English
BRIEF_MEMBER_DESC = YES
REPEAT_BRIEF = YES
REPEAT_BRIEF = NO
ABBREVIATE_BRIEF = "The $name class" \
"The $name widget" \
"The $name file" \
@ -36,48 +33,28 @@ ALWAYS_DETAILED_SEC = NO
INLINE_INHERITED_MEMB = NO
FULL_PATH_NAMES = YES
STRIP_FROM_PATH = ../../src/ \
../../tests/
STRIP_FROM_INC_PATH = ../../src/
STRIP_FROM_INC_PATH =
SHORT_NAMES = NO
JAVADOC_AUTOBRIEF = YES
QT_AUTOBRIEF = NO
MULTILINE_CPP_IS_BRIEF = NO
PYTHON_DOCSTRING = NO
DETAILS_AT_TOP = 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 = 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
TYPEDEF_HIDES_STRUCT = NO
#---------------------------------------------------------------------------
# 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
@ -85,29 +62,21 @@ 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 = YES
GENERATE_TESTLIST = NO
GENERATE_BUGLIST = NO
GENERATE_DEPRECATEDLIST= NO
ENABLED_SECTIONS =
MAX_INITIALIZER_LINES = 50
MAX_INITIALIZER_LINES = 10
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
@ -117,7 +86,6 @@ 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
@ -125,32 +93,35 @@ WARN_LOGFILE = doxygen-warnings-pdf.txt
# Configuration options related to the input files
#---------------------------------------------------------------------------
INPUT_ENCODING = UTF-8
INPUT = ../../src/ \
../../tests \
../../admin/scons
INPUT = ../../src/
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
@ -161,15 +132,14 @@ 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_ \
@ -179,31 +149,11 @@ 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
ENUM_VALUES_PER_LINE = 4
EXT_LINKS_IN_WINDOW = NO
HTML_FORMULA_FORMAT = svg
FORMULA_FONTSIZE = 9
USE_MATHJAX = NO
FORMULA_FONTSIZE = 10
SEARCHENGINE = NO
#---------------------------------------------------------------------------
@ -215,24 +165,16 @@ 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 =
EXTRA_PACKAGES =
LATEX_HEADER =
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
@ -243,43 +185,46 @@ ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = NO
EXPAND_ONLY_PREDEF = NO
SEARCH_INCLUDES = YES
INCLUDE_PATH =
INCLUDE_FILE_PATTERNS =
PREDEFINED = __cplusplus DEBUG EBUG_ALPHA
EXPAND_AS_DEFINED =
INCLUDE_PATH =
INCLUDE_FILE_PATTERNS =
PREDEFINED =
EXPAND_AS_DEFINED =
SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
# Configuration options related to external references
#---------------------------------------------------------------------------
TAGFILES =
GENERATE_TAGFILE =
TAGFILES =
GENERATE_TAGFILE =
ALLEXTERNALS = NO
EXTERNAL_GROUPS = NO
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_NUM_THREADS = 0 # use all cores
DOT_FONTNAME = FreeSans
DOT_FONTPATH =
CLASS_GRAPH = NO
COLLABORATION_GRAPH = NO
GROUP_GRAPHS = YES
HIDE_UNDOC_RELATIONS = YES
UML_LOOK = YES
UML_LIMIT_NUM_FIELDS = 12
TEMPLATE_RELATIONS = YES
GROUP_GRAPHS = NO
UML_LOOK = NO
TEMPLATE_RELATIONS = NO
INCLUDE_GRAPH = NO
INCLUDED_BY_GRAPH = NO
CALL_GRAPH = NO
CALLER_GRAPH = NO
DIRECTORY_GRAPH = NO
GRAPHICAL_HIERARCHY = NO
DIRECTORY_GRAPH = NO
DOT_IMAGE_FORMAT = png
INTERACTIVE_SVG = NO
DOT_PATH =
DOTFILE_DIRS =
DOT_GRAPH_MAX_NODES = 50
MAX_DOT_GRAPH_DEPTH = 10
DOT_MULTI_TARGETS = NO
DOT_TRANSPARENT = NO
DOT_MULTI_TARGETS = YES
GENERATE_LEGEND = NO
DOT_CLEANUP = YES

64
doc/devel/Status.txt
View file

@ -1,64 +0,0 @@
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,17 +11,8 @@ Design Process
//Menu: attach child 'rfc'
.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
-----------
How it Works
------------
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,
@ -30,46 +21,23 @@ 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 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.
* 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*_.
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.
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.
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.
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 yet and don't provide public releases --
We have nothing to show and don't provide public releases yet --
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,18 +14,6 @@ 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
------------------------------
@ -33,7 +21,6 @@ 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
@ -146,5 +133,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,48 +2177,6 @@ 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}}}.
@ -4577,11 +4535,8 @@ 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="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 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>
<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