diff --git a/AUTHORS b/AUTHORS index 68cadbab9..47be52115 100644 --- a/AUTHORS +++ b/AUTHORS @@ -1,60 +1,39 @@ Lumiera Authors and Credits =========================== -Version: 0.pre.03 -:Date: 11/2015 +:Date: 11/2025 -|========================================== -|*Architecture and Design*| -|graphical - user interface | JOEL HOLDSWORTH -| | HERMANN VOSSELER -| | BRIAN RYTEL -|processing layer | HERMANN VOSSELER -|backend | CHRISTIAN THÄTER +Architecture:: +- Hermann Voßeler +- Christian Thäter +- Joel Holdsworth -| | -| | -|*Workflow design* | -|concept | BRIAN RYTEL -| | MIKE PROVOST -| | NIKOLA DUPER -| | CHRISTOPH VARGA +Workflow Concept:: +- Hermann Voßeler +- Wouter Verwijlen +- Christoph Varga +- Brian Rytel +- Clay Barnes -| | -| | -|*Programming*| -|session and engine| HERMANN VOSSELER -|backend | CHRISTIAN THÄTER -| | MICHAEL PLOUJNIKOV -|graphical - user interface| JOEL HOLDSWORTH -| | STEFAN KANGAS -| | MICHAEL FISHER -|library | HERMANN VOSSELER -| | CHRISTIAN THÄTER -| | ANTON YAKOVLEV -| | STEFAN KANGAS -|testsuite | CHRISTIAN THÄTER -| | NICHOLAS SINNOTT-ARMSTRONG -| | HERMANN VOSSELER -| | -| | -|*Programming Documentation*| -| | CHRISTIAN THÄTER -| | HERMANN VOSSELER -| | MICHAEL PLOUJNIKOV -| | ODIN HØRTHE OMDAL -| | SIMEON VÖLKEL -| | MANO STIENEN -| | HENDRIK BOOM -| | BENNY LYONS -| | -| | -|*Server Administration*| -| | CHRISTIAN THÄTER -|========================================== +Core Developers:: +- 2007-2025 Hermann Voßeler +- 2008-2009 Joel Holdsworth +- 2007-2011 Christian Thäter +Programming:: +- 2007-2010 Michael Ploujnikov +- 2010-2011 Stefan Kangas +- 2010-2012 Michael Fisher +- 2007-2008 Simeon Völkel + +Documentation:: +- Hermann Vosseler +- Christian Thäter +- Odin Hørthe Omdal +- Simeon Völkel +- Mano Stienen +- Hendrik Boom +- Benny Lyons @@ -76,7 +55,10 @@ The Lumiera project feels especially obliged to:: Further Credits --------------- -- inspirations and some UI components were taken from http://Ardour.org[Ardour] +- inspirations and some UI components were taken from https://ardour.org/[Ardour] + +- https://github.com/x42/xjadeo[xjadeo] by Robin Gareus was very helpful + for learning how to output raw video from a desktop application - Parts of the Implementation are heavily inspired by + *The Loki Library* (c) 2001 by *Andrei Alexandrescu* diff --git a/COPYING b/COPYING index eeb586b39..227b449d5 100644 --- a/COPYING +++ b/COPYING @@ -1,12 +1,12 @@ - GNU GENERAL PUBLIC LICENSE - Version 2, June 1991 + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + Copyright (C) 1989, 1991 Free Software Foundation, Inc., + Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. - Preamble + Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public @@ -15,7 +15,7 @@ software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by -the GNU Library General Public License instead.) You can apply it to +the GNU Lesser General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not @@ -55,8 +55,8 @@ patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. - - GNU GENERAL PUBLIC LICENSE + + GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains @@ -110,7 +110,7 @@ above, provided that you also meet all of these conditions: License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) - + These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in @@ -168,7 +168,7 @@ access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. - + 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is @@ -225,7 +225,7 @@ impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. - + 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License @@ -255,7 +255,7 @@ make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. - NO WARRANTY + NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN @@ -277,9 +277,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. - END OF TERMS AND CONDITIONS - - How to Apply These Terms to Your New Programs + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it @@ -291,7 +291,7 @@ convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. - Copyright (C) 19yy + Copyright (C) This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -303,17 +303,15 @@ the "copyright" line and a pointer to where the full notice is found. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - + You should have received a copy of the GNU General Public License along + with this program; if not, see . Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: - Gnomovision version 69, Copyright (C) 19yy name of author + Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. @@ -330,11 +328,12 @@ necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. - , 1 April 1989 - Ty Coon, President of Vice + , 1 April 1989 + Moe Ghoul, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the -library. If this is what you want to do, use the GNU Library General +library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. + diff --git a/INSTALL b/INSTALL deleted file mode 120000 index c3b5125d9..000000000 --- a/INSTALL +++ /dev/null @@ -1 +0,0 @@ -doc/user/tutorials/building.txt \ No newline at end of file diff --git a/LICENSE b/LICENSE index aa23fae45..29de74adb 100644 --- a/LICENSE +++ b/LICENSE @@ -1,24 +1,60 @@ -- the *Lumiera* source code is (C) by the original authors (see `AUTHORS`) +Lumiera is Free Software +======================== +:Date: 11/2025 + +This source tree or package is based on various contributions +and its use is permitted under the conditions of the *GNU General Public License* + + +- the *Lumiera* source code is copyrighted and licensed by the original authors ++ +-- + * (c) 2007-2025 Hermann Voßeler + * (c) 2007-2011 Christian Thäter + * (c) 2008-2009 Joel Holdsworth +-- + ----------------------------------------------------------------------------- -Lumiera is free software -- you may use and redistribute it under the -Terms and conditions of the GNU GENERAL PUBLIC LICENSE (GPL); -either version 2 of the License, or (at your option) any later version. +Lumiera is free software; you can redistribute it and/or modify it +under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, +or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +See the GNU General Public License for more details. For a copy of the GPL Version 2 see the file COPYING ----------------------------------------------------------------------------- -- Website, design documents and accompanying materials are covered by - the same license as the source code, + - in addition they are also dual-licensed under *CC-By-SA 3* +- The full source code can always be retrieved from + https://git.lumiera.org/?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`] + + * there are a lot of additional authors, which all hold copyright + on their respective contributions made under this license; + see the copyright statements of individual files + + * furthermore, a full list of contributors can be retrieved + from the Git repository: + + git log --format="\"%an <%ae>\",%ad" --date=short HEAD + + * see also the file `AUTHORS` -- at various places, the implementation draws on solutions - and comments published at http://Stackoverflow.com[Stackoverflow] -- - according to the http://stackexchange.com/legal[License Agreement] page, - any ``subscriber content'' on that site is provided under *CC-By-SA 3*.. + +- Website, design documents and accompanying materials are covered + by the same license as the source code (GPL2+), + + in addition they are also dual-licensed under *CC-By-SA 4* + + +- at various places, the implementation draws on solutions and comments + published at http://Stackoverflow.com[Stackoverflow] -- according to the + https://stackoverflow.com/legal/terms-of-service/public#licensing[License Agreement], + any ``subscriber content'' on that site is provided under *CC-By-SA 4*. We attribute significant usages of solutions published this way in the doxygen comments of the relevant source code entities. @@ -27,7 +63,7 @@ For a copy of the GPL Version 2 see the file COPYING *The Loki Library* (C) 2001 by *Andrei Alexandrescu* + ----------------------------------------------------------------------------- -Loki is governed by a MIT-License. See: http://loki-lib.sourceforge.net +Loki is governed by a MIT-License. See: https://sourceforge.net/projects/loki-lib/ Permission to use, copy, modify, distribute and sell this software for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this diff --git a/NEWS b/NEWS new file mode 100644 index 000000000..eb7df407e --- /dev/null +++ b/NEWS @@ -0,0 +1,80 @@ +Lumiera -- Significant Changes +============================== +Version: 0.pre.05~dev +:Date: 11/2025 + +************************************************************* +Lumiera is a non-linear video editing and compositing tool. + +NOTE: as of 11/2025, Lumiera is in early development stage; +it is not usable yet. This is a preview Release of a +current development snapshot in pre-alpha stage. + +Source code and a list of all contributors can be retrieved +from `git://git.lumiera.org/LUMIERA` +************************************************************* + + + +In the current stage of development, the focus is primarily on the +overall integration of fundamental functionality at all levels of +the code base. + + +Lumiera pre-Alpha Versions +-------------------------- + +As of _11/2025_ (0.pre.04):: +This version is again motivated by a series of major upgrades and clean-up. +Compilation now requires C++23 and Debian/Trixie is considered the reference +platform. The GUI is connected to the core over an asynchronous messaging +bus and the timeline display has been reshaped to accommodate flexibly +nested structures of media content, instructed by the session through +a series of _diff messages_. A scheduler has been implemented to drive +the Render Engine, but the connection to the player and UI for output +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. + +As of _10/2013_ (0.pre.02):: +The data models have been elaborated and some significant parts of the session +are finished. Work has continued with time handling, a draft of the output +connection framework, a draft of the player subsystem and interfaces to the +engine and processing network. Unfortunately there was a considerable slowdown +and decrease in team size, yet still the code base is growing towards 90k LOC. +No tangible progress regarding the GUI and the backend. + +As of _1/2011_ (0.pre.01):: +The project has created and documented a fairly consistent design, +and some parts implemented -- progressing from the technical foundations. +The code base is approaching 65k LOC. Roughly half of this is test code. +The Application can be installed and started to bring up a GTK GUI framework, +but the GUI is rather preliminary and not connected to core functionality. +The video processing pipeline exists only in the blueprints. + +As of _2/2008_:: +The project has been separated completely from Cinelerra, the parent project. +The Community, which at that time was largely identical to the Cinelerra-CV community, +choose the new project name **Lumiera** through a collaborative selection and vote. +The basic project infrastructure was established, and work on the new codebase +was underway. It is clear that no results other than a test suite can be shown +in the foreseeable future. + +As of _7/2007_:: +A group of volunteers has formed to address some longstanding issues and limitations +of **Cinelerra**, which we all used for video editing tasks requiring professional quality. +The plan was to restructure some central parts of the render engine: introduce a Builder +for render pipelines and use Placements to control arrangement of clips and a unified +Data-Backend to coordinate usage of system resources. These innovations would serve +as anchor, with the intention to propose the reworked codebase as a new version +of Cinelerra, in the hope of turning Cinelerra development into a more +participatory process going forward. + diff --git a/README b/README index e254e74d3..2ebbe23df 100644 --- a/README +++ b/README @@ -1,16 +1,14 @@ Lumiera -- the video NLE for Linux -==================================== +================================== Version: 0.pre.05~dev -:Date: 11/2015 +:Date: 11/2025 ************************************************************* Lumiera is a non-linear video editing and compositing tool. +The Application will allow to edit footage using common +multimedia formats and audio/video stream codecs. -The Application will allow to edit footage in the common -multimedia formats (quicktime, ogg, mkv, avi) and audio/video -stream codecs (dv, mpeg1/2/4, h264 ...) - -Lumiera features non-destructive editing, compositing tools, +Lumiera features nondestructive editing, compositing tools, a selection of effects plugins, processing in RGB, YUV and RGB-float colour models and the ability to mix media with differing sizes and framerates. Lumiera is especially well @@ -19,12 +17,11 @@ with lots of material, several scenes, nested sequences, colour grading, 3D support, full fledged sound montage and multiple edit versions prepared in parallel. -NOTE: as of 11/2015, Lumiera is in early development stage; +NOTE: as of 11/2025, Lumiera is in early development stage; it is not usable yet. The above describes the Lumiera project -vision, which will need years to implement. This preview Release -installs a current development snapshot in pre-alpha stage. +vision, the implementation of which will require many more years. -Visit http://Lumiera.org and join the mailing list +Visit https://Lumiera.org and join the mailing list when interested in Lumiera planning and development. **************************************************************** @@ -32,48 +29,20 @@ when interested in Lumiera planning and development. Lumiera pre-Alpha Versions -------------------------- -**This source tree doesn't yet contain a working video editing application** + -Rather, it contains the framework and technology core -of the envisioned Application ``Lumiera''. +.This source tree doesn't contain a working video editing application yet. +Rather, it contains the framework and technology core of the envisioned +Application »Lumiera«. What we attempt to build here is innovative, +and we must engage in a series of integration steps to search for +suitable pathways towards our envisaged architecture. -See http://issues.lumiera.org/roadmap[Project roadmap] +Since 2024, the integration of the Render Engine takes centre stage, +in an effort to establish a steady state realtime processing and +display pipeline, still relying on generated video data rather +than using a library to read and playback a video file. -As of _11/2015_ (0.pre.03):: -a lot of long standing maintennance work has been done. The Project switched -to C++11 and in the end even to C++14 and Debian/Jessie as reference platform, -followed by clean-up of now obsolete workarounds. On the GUI side, we largely -made the transition to GTK-3, which lead to rework of our timeline widget, not -finished yet. This work also spured an effort the connection and communication -between Proc and the UI, which is expected to be asynchroneous. Due to the -limited developer resources, work on the Engine and Player part is stalled. +- https://Lumiera.org/documentation/design/governance/integration.html[Integration steps] +- See also https://issues.lumiera.org/roadmap[Project roadmap] -As of _10/2013_ (0.pre.02):: -the data models have been elaborated and some significant parts of the session -are finished. Work has continued with time handling, a draft of the output -connection framework, a draft of the player subsystem and interfaces to the -engine and processing network. Unfortunately there was a considerable slowdown -and decrease in team size, yet still the code base is growing towards 90k LOC. -No tangible progress regarding the GUI and the backend. - -As of _1/2011_ (0.pre.01):: -the project has created and documented a fairly consistent design, -partially coded up -- starting from the technical foundations and working up. -The code base is approaching 65k LOC. Roughly half of this is test code. -The Application can be installed and started to bring up a GTK GUI framework, -but the GUI is very preliminary and not connected to core functionality. -The video processing pipeline exists only in the blueprints. - -As of _2/2008_:: -the project has been separated completely from ``Cinelerra'', the parent project. -The Community, which at that time was largely identical to the Cinelerra-CV community, -choose the new project name ``Lumiera'' through a collaborative selection and vote. -The basic project infrastructure is up and running, and work on the new codebase -has started. We can show nothing beyond a test suite for some time to come. - -As of _7/2007_:: -we started with the backend and render engine draft, some example code -complemented by several unit tests. There is a TiddlyWiki with detailed -design considerations and developer documentation and a UML model @@ -82,19 +51,24 @@ Build Requirements For building Lumiera, you'll need: - * C99 / C++14 compiler GCC `>=4.9` or Clang `>=3.5` + * C++23 compiler GCC >=14 (Clang fails atm) * Git Version management system - * http://www.scons.org/[SCons build system] - * http://www.boost.org/[Boost libraries] - * http://gmerlin.sourceforge.net/[GAVL library] - * http://nobug.pipapo.org/[NoBug library] - * http://www.gtkmm.org/en/[GTKmm] - * http://alsa-project.org[ALSA libasound2-dev] - * http://cgit.freedesktop.org/xorg/lib/libXv[libXv] - * https://wiki.gnome.org/LibRsvg[lib rSVG] - * https://git.gnome.org/browse/gdl[lib GDL] + * https://www.scons.org/[SCons build system] + * https://www.boost.org/[Boost libraries] + * https://github.com/bplaum/gavl[GAVL library] + * https://www.alsa-project.org/[ALSA (libasound2-dev)] + * https://nobug.pipapo.org/[NoBug library] + * https://gtkmm.gnome.org/en/[gtkmm] + * https://cgit.freedesktop.org/xorg/lib/libXv[libXv] + * https://wiki.gnome.org/Projects/LibRsvg[lib rSVG] + * https://git.lumiera.org/?p=debian/gdl;a=summary[lib GDL] + * https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL-mm bindings] -See the online documentation at http://Lumiera.org/download.html +Further information: + + * Online documentation at https://Lumiera.org/download.html[Build and install]. + * Documentation is also available in-tree in 'doc/user/tutorials/building.txt' + * Source code can be retrieved with `git clone git://git.lumiera.org/LUMIERA` diff --git a/SConstruct b/SConstruct index 32afeaab0..147b8b7cd 100644 --- a/SConstruct +++ b/SConstruct @@ -4,7 +4,7 @@ ## # Copyright (C) -# 2008, Hermann Vosseler +# 2008-2025 Hermann Vosseler # # **Lumiera** is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the @@ -16,7 +16,7 @@ # NOTE: scons -h for help. # This script /defines/ the components and how they fit together. # SCons will derive dependencies and the necessary build steps. -# Read more about the SCons build system at: http://www.scons.org +# Read more about the SCons build system at: https://www.scons.org # NOTE: Lumiera SCons extension modules and plugins @@ -52,7 +52,6 @@ SConscript(dirs=['data','src','src/tool','research','tests','doc'], exports='env # additional files to be cleaned when cleaning 'build' env.Clean ('build', [ 'scache.conf', '.sconf_temp', '.sconsign.dblite', 'config.log' ]) -env.Clean ('build', [ 'src/pre.gch' ]) @@ -63,8 +62,8 @@ env.Clean ('build', [ 'src/pre.gch' ]) Import('lumiera plugins tools gui testsuite') build = env.Alias('build', lumiera + plugins + tools + gui) +# this defines the SCons **default target** env.Default('build') -# SCons default target #env.Alias ('all', build + testsuite + doxydoc) diff --git a/admin/buildVersion.py b/admin/buildVersion.py index cf1309cd5..690c289e3 100755 --- a/admin/buildVersion.py +++ b/admin/buildVersion.py @@ -47,7 +47,7 @@ def parseAndBuild(): ,choices=['maj','min','rev'], const='rev' ,help='bump the version detected from Git (optionally bump a specific component)') parser.add_argument ('--suffix','-s' - ,help='append (or replace) a suffix (by default attached with ~)') + ,help='append (or replace) a suffix (attached with ~); False -> remove suffix') parser.add_argument ('--snapshot' ,action='store_true' ,help='mark as development snapshot by appending ~dev.YYYYMMDDhhmm, using UTC date from HEAD commit') @@ -72,11 +72,30 @@ def getTimestampFromGit(): -def rebuild (version, bump=None, suffix=None, snapshot=False): - mat = re.fullmatch (VER_SYNTAX, version) +def parseVerNr (verStr): + """ parse a version spec from a git tag, + possibly preprocess to translate _ -> ~ + """ + NOT_SFX = r'(?:[^_\W]|[\.\+])+' + DECODE = r'('+NOT_SFX+')(?:_('+NOT_SFX+'))?' + # + mat = re.fullmatch (DECODE, verStr) if not mat: - __FAIL ('invalid version syntax in "'+version+'"') + __FAIL ('version string contains invalid characters: "'+verStr+'"') + verStr = mat.group(1) + if mat.group(2): + verStr += '~'+mat.group(2) + # + # check syntax of translated version spec + mat = re.fullmatch (VER_SYNTAX, verStr) + if not mat: + __FAIL ('invalid version syntax in "'+verStr+'"') + else: + return mat + +def rebuild (version, bump=None, suffix=None, snapshot=False): + mat = parseVerNr (version) maj = mat.group(1) min = mat.group(2) rev = mat.group(3) @@ -97,7 +116,10 @@ def rebuild (version, bump=None, suffix=None, snapshot=False): if snapshot: suf = 'dev.'+getTimestampFromGit() elif suffix: - suf = suffix + if not evalBool(suffix): + suf = None + else: + suf = suffix version = maj if min: @@ -128,10 +150,26 @@ def runGit (argStr): proc = subprocess.run (argList, check=True, capture_output=True, encoding='utf-8', env={'LC_ALL':'C'}) return proc.stdout.rstrip() # Note: sanitised env except: - __FAIL ('invoking git-describe') + __FAIL ('invoking git '+argStr) +def evalBool (val) ->bool: + """ evaluate as bool value + @author: Tim Poulsen + @note: Adapted from the original, published 2023, CC-By-SA-4 + https://www.timpoulsen.com/2023/python-bool-from-any.html + """ + try: + return float(val) > 0 + except: + if type(val) is str: + return val.lower() not in ['false', 'no', 'n', 'none', 'null'] + else: + # rely on Python's type coercion rules + return bool(val) + + def __ERR (*args, **kwargs): print (*args, file=sys.stderr, **kwargs) diff --git a/admin/build_lumiera-build-dependencies.sh b/admin/build_lumiera-build-dependencies.sh deleted file mode 100755 index 96fbf8a76..000000000 --- a/admin/build_lumiera-build-dependencies.sh +++ /dev/null @@ -1,61 +0,0 @@ -#!/bin/sh -# -# build_lumiera-build-dependencies.sh - prepare/build on a pristine Debian/Ubuntu system (Docker) -# -# -#------------------------------------------------------Setup -# The Debian DEB Depot to retrieve the source packages -DEBIAN_REPO="http://lumiera.org/debian/" -SRC_DISTRO="stretch" -REPO_SECTION="experimental" -# -# GPG pubkey to trust for signed packages -TRUSTED_GPG=$(dirname $0)/deb.lumiera.org.PUB.gpg -# -# Directory for building DEB packages -PACK_DIR=./pack -# -#------------------------------------------------------Setup(End) -# -fail() { - echo "\nFAIL: $1\n\n" - exit 1 -} - -# Sanity-Checks -[ -f $TRUSTED_GPG ] || fail "GPG Key not found: $TRUSTED_GPG" -mkdir -p $PACK_DIR -[ -w $PACK_DIR ] || fail "Unable to build. Can not write to $PACK_DIR" - - -# prepare the host system with Lumiera package sources -cp $TRUSTED_GPG /etc/apt/trusted.gpg.d/ -chmod a+r-x /etc/apt/trusted.gpg.d/$(basename $TRUSTED_GPG) -echo "deb-src $DEBIAN_REPO $SRC_DISTRO $REPO_SECTION" > /etc/apt/sources.list.d/55-lumiera.list - -apt update -apt install -y build-essential ca-certificates -apt update - -# build some special build dependencies from source -WORKDIR=$(pwd -P) -cd $PACK_DIR - -echo "\n\n======= building NoBug =======\n" -apt-get -y build-dep nobug -apt-get source --compile nobug -dpkg -i nobug-dev*deb libnobug*deb || fail "installing NoBug" -echo "\n\n======= building GDLmm =======\n" -apt-get -y build-dep libgdlmm-3-dev -apt-get source --compile libgdlmm-3-dev || fail "installing GDLmm" -dpkg -i libgdlmm-3*deb - -# install the build dependencies of Lumiera from DEB -echo "\n\nInstalling Lumiera build dependencies...\n" -apt-get -y build-dep lumiera - -# return to the working directory -cd $WORKDIR - -echo "Build-Dependencies of Lumiera successfully installed.\n\n" - diff --git a/admin/deb.lumiera.org.PUB.gpg b/admin/deb.lumiera.org.PUB.gpg index 6403dc3b6..f049db8f8 100644 Binary files a/admin/deb.lumiera.org.PUB.gpg and b/admin/deb.lumiera.org.PUB.gpg differ diff --git a/admin/docker_open-lumiera-buildenv.sh b/admin/docker_open-lumiera-buildenv.sh deleted file mode 100755 index 2c245c209..000000000 --- a/admin/docker_open-lumiera-buildenv.sh +++ /dev/null @@ -1,44 +0,0 @@ -#!/bin/sh -# -# docker_open-lumiera-buildenv.sh - launch Docker container with interactive build shell -# -# -#------------------------------------------------------Setup -# -# Working directory path on the host -WORKDIR_HOST="/home/$USER/devel/lumi" -# -# bind-mount of the working dir in the container -WORKDIR_GUEST="/lumi" -# -# Docker image-ID to launch -DOCKER_IMAGE="ubuntu:bionic" -# -# Script code to inject into interactive shell -COMMANDS=$(cat) < -# -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License as -# published by the Free Software Foundation; either version 2 of -# the License, or (at your option) any later version. -##################################################################### - -# history: 8/2008 adapted for Lumiera build system -# changed to accept a list of precompiled header defs - -# TODO: WIP-remove these comments when port to Python 3.x is DONE -# types.py does not contain ListType in Python 3.x -# # Why do we require ListType? -# To do something like -# if type(item) is ListType: -# .... -# But types.py does not have ListType anymore -# if isinstance(item, list): -#from types import ListType - -import SCons.Action -import SCons.Builder -import SCons.Scanner.C -import SCons.Util -import SCons.Script - -SCons.Script.EnsureSConsVersion(0,96,92) - -GchAction = SCons.Action.Action('$GCHCOM', '$GCHCOMSTR') -GchShAction = SCons.Action.Action('$GCHSHCOM', '$GCHSHCOMSTR') - -def gen_suffix(env, sources): - return sources[0].get_suffix() + env['GCHSUFFIX'] - - -GchShBuilder = SCons.Builder.Builder(action = GchShAction, - source_scanner = SCons.Scanner.C.CScanner(), - suffix = gen_suffix) - -GchBuilder = SCons.Builder.Builder(action = GchAction, - source_scanner = SCons.Scanner.C.CScanner(), - suffix = gen_suffix) - -def setup_dependency(target,source,env, key): - scanner = SCons.Scanner.C.CScanner() - path = scanner.path(env) - deps = scanner(source[0], env, path) - - if key in env and env[key]: - for header in env[key]: - header_path = header.path.strip('.gch') - if header_path in [x.path for x in deps]: - print("Precompiled header(%s) %s \t <--- %s" % (key,header_path,source[0])) - env.Depends(target, header) - - -def static_pch_emitter(target,source,env): - SCons.Defaults.StaticObjectEmitter( target, source, env ) - setup_dependency(target,source,env, key='GCH') - return (target, source) - -def shared_pch_emitter(target,source,env): - SCons.Defaults.SharedObjectEmitter( target, source, env ) - setup_dependency(target,source,env, key='GCH-sh') - return (target, source) - - -def generate(env): - """ Add builders and construction variables for the Gch builder. - """ - env.Append(BUILDERS = { - 'gch': env.Builder( - action = GchAction, - target_factory = env.fs.File, - ), - 'gchsh': env.Builder( - action = GchShAction, - target_factory = env.fs.File, - ), - }) - - try: - bld = env['BUILDERS']['GCH'] - bldsh = env['BUILDERS']['GCH-sh'] - except KeyError: - bld = GchBuilder - bldsh = GchShBuilder - env['BUILDERS']['PrecompiledHeader'] = bld - env['BUILDERS']['PrecompiledHeaderShared'] = bldsh - - env['GCHCOM'] = '$CXX -o $TARGET -x c++-header -c $CXXFLAGS $_CCCOMCOM $SOURCE' - env['GCHSHCOM'] = '$CXX -o $TARGET -x c++-header -c $SHCXXFLAGS $_CCCOMCOM $SOURCE' - env['GCHSUFFIX'] = '.gch' - - for suffix in SCons.Util.Split('.c .C .cc .cxx .cpp .c++'): - env['BUILDERS']['StaticObject'].add_emitter( suffix, static_pch_emitter ) - env['BUILDERS']['SharedObject'].add_emitter( suffix, shared_pch_emitter ) - - -def exists(env): - return env.Detect('g++') diff --git a/admin/scons/Buildhelper.py b/admin/scons/Buildhelper.py index a6cc7006f..a0c9e5de7 100644 --- a/admin/scons/Buildhelper.py +++ b/admin/scons/Buildhelper.py @@ -4,7 +4,7 @@ ## # Copyright (C) -# 2008, Hermann Vosseler +# 2008-2025 Hermann Vosseler # # **Lumiera** is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the @@ -104,19 +104,6 @@ def isSrcDir(path, patterns=SRCPATTERNS): -def filterNodes(nlist, removeName=None): - """ filter out scons build nodes using the given criteria. - removeName: if set, remove all nodes with this srcname - """ - if removeName: - predicate = lambda n : not fnmatch.fnmatch(os.path.basename(str(n[0])), removeName) - else: - predicate = lambda n : True - - return list(filter(predicate, nlist)) - - - def getDirname (d, basePrefix=None): """ extract directory name without leading path, or without the explicitly given basePrefix @@ -218,7 +205,7 @@ def extract_localPathDefs (localDefs): pattern and returns them wrapped into a Record for convenient access """ def relevantPathDefs (mapping): - for (k,v) in list(mapping.items()): + for (k,v) in mapping.items(): if (k.startswith('src') or k.startswith('build') or k.startswith('install')) and Util.is_String(v): v = v.strip() if not v.endswith('/'): v += '/' diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py index d50b4db04..dd8f8a6fe 100644 --- a/admin/scons/LumieraEnvironment.py +++ b/admin/scons/LumieraEnvironment.py @@ -4,7 +4,7 @@ ## # Copyright (C) -# 2008, Hermann Vosseler +# 2008-2025 Hermann Vosseler # # **Lumiera** is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the @@ -16,7 +16,8 @@ from os import path import SCons.SConf -from SCons.Action import Action +from SCons.Action import Action, FunctionAction +from SCons.Script import File as SConsFile from SCons.Environment import Environment from Buildhelper import * @@ -29,21 +30,36 @@ class LumieraEnvironment(Environment): using global vars. Idea inspired by Ardour. """ def __init__(self, buildSetup, buildVars, **kw): - kw.update(VERSION = buildSetup.VERSION - ,TARGDIR = buildSetup.TARGDIR - ,DESTDIR = '$INSTALLDIR/$PREFIX' - ,toolpath = [buildSetup.TOOLDIR ] - ,variables = buildVars - ) - Environment.__init__ (self, **kw) - self.path = Record (extract_localPathDefs(buildSetup)) # e.g. buildExe -> env.path.buildExe + Environment.__init__ (self, toolpath = [buildSetup.TOOLDIR ] + , variables = buildVars # ◁───── reads settings from the commandline (see Options.py) + , **kw) + # + self['TARGDIR'] = buildSetup.TARGDIR + self['VERSION'] = buildSetup.VERSION + self['DESTDIR'] = '$INSTALLDIR/$PREFIX' + self['SHARE' ] = '$DESTDIR/share' + self._anchor_relative('INSTALLDIR') + self._anchor_relative('TARGDIR') + # + self.path = Record (extract_localPathDefs(buildSetup)) # ◁───── e.g. buildExe -> env.path.buildExe self.libInfo = {} self.Tool("BuilderDoxygen") self.Tool("ToolDistCC") self.Tool("ToolCCache") - register_LumieraResourceBuilder(self) + register_LumieraIconBuilder(self) + register_LumieraResourceBuilders(self) register_LumieraCustomBuilders(self) + def _anchor_relative(self, key): + """ ensure that a relative path spec becomes anchored at build-root + @note: a special convention within scons: '#' implies directory of SConstruct + """ + spec = self[key].strip() + if not (spec.startswith('/') or spec.startswith('#')): + spec = '#'+spec + self[key] = spec + + def Configure (self, *args, **kw): kw['env'] = self @@ -61,9 +77,9 @@ class LumieraEnvironment(Environment): if other in self.libInfo: self.mergeConf(self.libInfo[other]) else: - self.Append (LIBS = other.get ('LIBS',[])) - self.Append (LIBPATH = other.get ('LIBPATH', [])) - self.Append (CPPPATH = other.get('CPPPATH', [])) + self.Append (LIBS = other.get('LIBS',[])) + self.Append (LIBPATH = other.get('LIBPATH', [])) + self.Append (CPPPATH = other.get('CPPPATH', [])) self.Append (LINKFLAGS = other.get('LINKFLAGS', [])) return self @@ -109,26 +125,55 @@ class LumieraConfigContext(ConfigBase): + + ############################################################################### ####### Lumiera custom tools and builders ##################################### -def register_LumieraResourceBuilder(env): - """ Registers Custom Builders for generating and installing Icons. +def register_LumieraIconBuilder(env): + """ Registers a custom Builder for generating and installing Icons from SVG. Additionally you need to build the tool (rsvg-convert.c) used to generate png from the svg source using librsvg. """ import IconSvgRenderer as renderer # load Joel's python script for invoking the rsvg-convert (SVG render) - renderer.rsvgPath = env.subst("$TARGDIR/rsvg-convert") + renderer.rsvgPath = env.subst("$TARGDIR/rsvg-convert").removeprefix('#') + # # the prefix '#' is a SCons specific convention, + # # which the external tool can not handle + # + # MD5 signature for this specific python source code... + thisCodeSignature = SConsFile(__file__).get_csig() + SConsFile(renderer.__file__).get_csig() + thisCodeSignature = bytearray(thisCodeSignature, 'utf-8') - def invokeRenderer(target, source, env): - source = str(source[0]) - targetdir = env.subst(env.path.buildIcon) - if targetdir.startswith('#'): targetdir = targetdir[1:] - renderer.main([source,targetdir]) - return 0 + + class IconRenderAction(FunctionAction): + """ SCons Action subclass to provide a controlled cache signature. + @note: usually it would be sufficient to pass just a callable to the Builder, + however, our implementation calls into an external Python module and thus + the default signature from SCons would not be stable, since it relies + on a code representation including memory addresses. Without this, + the icons would be frequently rebuilt unnecessarily. + """ + def __init__(self): + FunctionAction.__init__(self, IconRenderAction.invokeRenderer + , {'cmdstr' : "rendering Icon: $SOURCE --> $TARGETS"} + ) + + def get_contents(self, target, source, env): + """ a stable signature based on the source code """ + return thisCodeSignature + + @staticmethod + def invokeRenderer(target, source, env): + """ render the SVG icon with libRSVG """ + source = str(source[0]) + targetdir = env.subst(env.path.buildIcon).removeprefix('#') + renderer.main([source,targetdir]) + return 0 + + def createIconTargets(target,source,env): """ parse the SVG to get the target file names """ source = str(source[0]) @@ -146,6 +191,20 @@ def register_LumieraResourceBuilder(env): return (generateTargets, source) + + buildIcon = env.Builder( action = IconRenderAction() + , single_source = True + , emitter = createIconTargets + ) + env.Append(BUILDERS = {'IconRender' : buildIcon}) + + + + +def register_LumieraResourceBuilders(env): + """ Registers further Custom Methods for installing various Resources. + """ + def IconResource(env, source): """ copy icon pixmap to corresponding icon dir. """ subdir = getDirname(str(source)) @@ -155,7 +214,7 @@ def register_LumieraResourceBuilder(env): return env.Install(toBuild, source) def GuiResource(env, source): - """ pick up giben source resource and install + """ pick up given source resource and install them (flat) into the configured target """ toBuild = env.path.buildUIRes @@ -165,9 +224,11 @@ def register_LumieraResourceBuilder(env): def ConfigData(env, prefix, source, targetDir=None): """ install (copy) configuration- and metadata. - target dir is either the install location configured (in SConstruct), - or an explicitly given absolute or relative path segment, which might refer - to the location of the executable through the $ORIGIN token + @param targetDir: when None, then use he install location configured (in Setup.py), + otherwise an explicitly given absolute or relative path segment, + which might refer to the location of the executable through the $ORIGIN token + @param prefix: a prefix relative to the current path (location of SConscript), + i.e. typically a subdirectory where to find the source config file """ source = path.join(prefix,str(source)) subdir = getDirname(source, prefix) # removes source location path prefix @@ -188,15 +249,31 @@ def register_LumieraResourceBuilder(env): env.Install (toInstall, source) return env.Install(toBuild, source) + def DocFile(env, prefix, source, target=None): + """ install (copy) files for documentation. + Always places the documentation below the standard location 'installDoc' configured in Setup.py + @param prefix: relative to current path (SConscript), will be stripped at destination + @param target: when given, the target will be named explicitly, or (when only a directory) + placed into a specific subdir, otherwise (when None) the source spec will be placed + into the corresponding subdir after stripping the prefix + """ + source = path.join(prefix,str(source)) + subdir = getDirname(source, prefix) # removes source location path prefix + if not target: + target = subdir+'/' + elif target.endswith('/'): + target = target+subdir+'/' + toInstall = path.join(env.path.installDoc, target) + if toInstall.endswith('/'): + return env.Install(toInstall, source) + else: + return env.InstallAs(toInstall, source) # this renames at target + - buildIcon = env.Builder( action = Action(invokeRenderer, "rendering Icon: $SOURCE --> $TARGETS") - , single_source = True - , emitter = createIconTargets - ) - env.Append(BUILDERS = {'IconRender' : buildIcon}) env.AddMethod(IconResource) env.AddMethod(GuiResource) env.AddMethod(ConfigData) + env.AddMethod(DocFile) @@ -262,7 +339,6 @@ class LumieraExeBuilder(WrappedStandardExeBuilder): """ custEnv = lumiEnv.Clone() custEnv.Append( LINKFLAGS = "-Wl,-rpath=\\$$ORIGIN/modules,--enable-new-dtags" ) - custEnv.Append( LINKFLAGS = "-Wl,-rpath-link=target/modules" ) ### Workaround for bug in binutils > 2.23 /////TICKET #965 if 'addLibs' in kw: custEnv.Append(LIBS = kw['addLibs']) return custEnv @@ -282,7 +358,7 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder): Lumiera modules; modules are assumed to reside in a subdirectory below the executable. """ custEnv = lumiEnv.Clone() - custEnv.Append(LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw)) + custEnv.Append( LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw)) custEnv.Append( LINKFLAGS = "-Wl,-rpath=\\$$ORIGIN/../modules,--enable-new-dtags" ) if 'addLibs' in kw: custEnv.Append(LIBS = kw['addLibs']) @@ -292,6 +368,26 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder): def getInstallDestination(self, lumiEnv): return lumiEnv.path.installLib + def installTarget(self, env, buildTarget, **kw): + """ ensure a shared library is not marked executable. + The default toolchain on Linux often installs shared libraries as executable, which seems + to be necessary on some arcane Unix platforms. However, Debian Policy prohibits that. + See https://unix.stackexchange.com/questions/400187/why-should-or-should-not-shared-libraries-be-executable-e-g-red-hat-vs-debian + """ + toInstall = super().installTarget(env, buildTarget, **kw) + if toInstall: + def _Chmod(target, source, env): + """ Workaround since env.Chmod is present only in SCons 4.10 """ + import os + for t in target: + os.chmod(str(t), 0o644) + return None +# removeExecBit = env.Chmod(toInstall, 0o644) # ◁◁◁ could use this for SCons > 4.10 + msg = '....... clear exec perm %s' % [str(t) for t in toInstall] + removeExecBit = env.Action(_Chmod, msg) + env.AddPostAction(toInstall, removeExecBit) + return toInstall + def defineSoname (self, target, **kw): """ internal helper to extract or guess a suitable library SONAME, either using an diff --git a/admin/scons/Options.py b/admin/scons/Options.py index 842fea5ba..d79acf254 100644 --- a/admin/scons/Options.py +++ b/admin/scons/Options.py @@ -42,9 +42,7 @@ def defineCmdlineVariables(buildVars): # ,EnumVariable('DIST_TARGET', 'Build target architecture', 'auto', # allowed_values=('auto', 'i386', 'i686', 'x86_64' ), ignorecase=2) ,PathVariable('PREFIX', 'Installation dir prefix', 'usr/local', PathVariable.PathAccept) - ,PathVariable('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathIsDir) - ,PathVariable('PKGLIBDIR', 'Installation dir for plugins, defaults to PREFIX/lib/lumiera/modules', '',PathVariable.PathAccept) - ,PathVariable('PKGDATADIR', 'Installation dir for default config, usually PREFIX/share/lumiera', '',PathVariable.PathAccept) + ,PathVariable('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathAccept) ) diff --git a/admin/scons/Platform.py b/admin/scons/Platform.py index 9083a39cf..ea11fd9c3 100644 --- a/admin/scons/Platform.py +++ b/admin/scons/Platform.py @@ -4,7 +4,7 @@ ## # Copyright (C) -# 2012, Hermann Vosseler +# 2012-2025 Hermann Vosseler # # **Lumiera** is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the @@ -35,6 +35,23 @@ def configure(env): if not conf.TryAction('pkg-config --version > $TARGET')[0]: problems.append('We need pkg-config for including library configurations, exiting.') + # A special check in case we are compiling with GCC... + compiler = env.subst('$CXX') + verGCCmin = (14,) # note no trailing zero for version ordering check + expectedFeature = 'solid C++23 support' + if compiler.startswith("g++"): + # verify sufficient compiler version + try: + import subprocess + res = subprocess.check_output([compiler,'-dumpversion'], universal_newlines=True).strip() + res = tuple(int(x) for x in res.split('.')) + except Exception: + res = None + # + if res and res < verGCCmin: + problems.append('The compiler "%s" reports version %s, yet we need at least %s for %s.' + % (compiler, res, verGCCmin, expectedFeature)) + if not conf.CheckLibWithHeader('m', 'math.h','C'): problems.append('Did not find math.h / libm.') @@ -60,7 +77,7 @@ def configure(env): print('Valgrind not found. The use of Valgrind is optional; building without.') if not conf.CheckPkgConfig('nobugmt', 201008.1): - problems.append('Did not find NoBug [http://nobug.pipapo.org/].') + problems.append('Did not find NoBug [https://nobug.pipapo.org/].') else: conf.env.mergeConf('nobugmt') @@ -84,45 +101,45 @@ def configure(env): problems.append('We need boost::program_options (including binary lib for linking).') - if not conf.CheckPkgConfig('gavl', '1.4'): + if not conf.CheckPkgConfig('gavl', '2.0'): problems.append('Did not find Gmerlin Audio Video Lib [https://github.com/bplaum/gavl].') else: conf.env.mergeConf('gavl') - if not conf.CheckPkgConfig('alsa', '1.0.23'): + if not conf.CheckPkgConfig('alsa', '1.2'): problems.append('Support for ALSA sound output is required') - if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'): + if not conf.CheckPkgConfig('gtkmm-3.0', '3.20'): problems.append('Unable to configure the mm-bindings for GTK-3') - if not conf.CheckPkgConfig('glibmm-2.4', '2.39'): + if not conf.CheckPkgConfig('glibmm-2.4', '2.66'): problems.append('Unable to configure the mm-bindings for Glib') - if not conf.CheckPkgConfig('sigc++-2.0', '2.2.10'): + if not conf.CheckPkgConfig('sigc++-2.0', '2.12'): problems.append('Need the signal-slot-binding library SigC++2') - if not conf.CheckPkgConfig('glib-2.0', '2.40'): + if not conf.CheckPkgConfig('glib-2.0', '2.80'): problems.append('Need a suitable Glib version.') - if not conf.CheckPkgConfig('gthread-2.0', '2.40'): + if not conf.CheckPkgConfig('gthread-2.0', '2.80'): problems.append('Need gthread support lib for Glib based thread handling.') - if not conf.CheckPkgConfig('cairomm-1.0', '1.10'): + if not conf.CheckPkgConfig('cairomm-1.0', '1.14'): problems.append('Unable to configure Cairo--') - verGDL = '3.8' # lowered requirements to allow building on Ubuntu/Trusty & Mint (was originally '3.12') + verGDL = '3.40' # now orphaned and thus directly provided from Lumiera.org -> can require latest available verGDLmm = '3.7.3' - urlGDLmm = 'http://ftp.gnome.org/pub/GNOME/sources/gdlmm/' + urlGDLmm = 'git://git.lumiera.org/debian/gdlmm' urlGDLmmDEB = 'http://lumiera.org/debian/' if not conf.CheckPkgConfig('gdl-3.0', verGDL): problems.append('GNOME Docking Library not found. We need at least GDL %s ' 'and suitable C++ ("mm")-bindings (GDLmm >=%s)' % (verGDL, verGDLmm)) if not conf.CheckPkgConfig('gdlmm-3.0', verGDLmm, alias='gdl'): problems.append('We need the C++ bindings for GDL by Fabien Parent: GDLmm >=%s ' - '(either from GNOME %s or use the debian package from %s)' % + '(either from %s or use the debian package from %s)' % (verGDLmm, urlGDLmm, urlGDLmmDEB)) - if not conf.CheckPkgConfig('librsvg-2.0', '2.30'): + if not conf.CheckPkgConfig('librsvg-2.0', '2.40'): problems.append('Need rsvg Library for rendering icons.') if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'): @@ -140,8 +157,7 @@ def configure(env): print("*** unable to build due to the following problems:") for isue in problems: print(" * %s" % isue) - print() - print("build aborted.") + print("\nbuild aborted.") Exit(1) print("** Gathered Library Info: %s" % list(conf.env.libInfo.keys())) diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py index 416aa802c..d2d8941b0 100644 --- a/admin/scons/Setup.py +++ b/admin/scons/Setup.py @@ -4,7 +4,7 @@ ## # Copyright (C) -# 2012, Hermann Vosseler +# 2012-2025 Hermann Vosseler # # **Lumiera** is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the @@ -28,21 +28,24 @@ OPTCACHE = 'optcache' CUSTOPTFILE = 'custom-options' # these are accessible via env.path.xxxx -buildExe = '#$TARGDIR' -buildLib = '#$TARGDIR/modules' -buildPlug = '#$TARGDIR/modules' -buildIcon = '#$TARGDIR/gui/icons' # for IconResource() and IconRender() -buildUIRes = '#$TARGDIR/gui/' # for GuiResource() -buildConf = '#$TARGDIR/config' # for ConfigData() -installExe = '#$DESTDIR/lib/lumiera' -installLib = '#$DESTDIR/lib/lumiera/modules' -installPlug = '#$DESTDIR/lib/lumiera/modules' -installIcon = '#$DESTDIR/share/lumiera/icons' -installUIRes = '#$DESTDIR/share/lumiera/' -installConf = '#$DESTDIR/lib/lumiera/config' +buildExe = '$TARGDIR' +buildLib = '$TARGDIR/modules' +buildPlug = '$TARGDIR/modules' +buildIcon = '$TARGDIR/gui/icons' # for IconResource() and IconRender() +buildUIRes = '$TARGDIR/gui/' # for GuiResource() +buildConf = '$TARGDIR/config' # for ConfigData() +installExe = '$DESTDIR/lib/lumiera' +installLib = '$DESTDIR/lib/lumiera/modules' +installPlug = '$DESTDIR/lib/lumiera/modules' +installIcon = '$DESTDIR/share/lumiera/icons' +installUIRes = '$DESTDIR/share/lumiera/' +installConf = '$DESTDIR/lib/lumiera/config' +installDoc = '$DESTDIR/share/doc/lumiera/' #-------------------------------------------------------Configuration + buildSetup = Record(locals()) +# passed to LumieraEnvironment() -> env.path.xxxx @@ -54,9 +57,9 @@ def defineBuildEnvironment(): define locations in source and target tree, parse the commandline and pick up options """ - EnsureSConsVersion(2,0) - EnsurePythonVersion(2,6) - Decider('MD5-timestamp') # detect changed files by timestamp, then do a MD5 + EnsureSConsVersion(4,0) + EnsurePythonVersion(3,10) + Decider('content-timestamp') # detect changed files by timestamp, then do a MD5 buildVars = Variables([OPTCACHE, CUSTOPTFILE]) Options.defineCmdlineVariables(buildVars) @@ -80,11 +83,7 @@ def defineBuildEnvironment(): appendVal(env,'OPTIMIZE', 'CCFLAGS', val=' -O3') appendVal(env,'DEBUG', 'CCFLAGS', val=' -ggdb') - # setup search path for Lumiera plugins - appendCppDefine(env,'PKGLIBDIR','LUMIERA_PLUGIN_PATH=\\"$PKGLIBDIR/:ORIGIN/modules\\"' - ,'LUMIERA_PLUGIN_PATH=\\"ORIGIN/modules\\"') - appendCppDefine(env,'PKGDATADIR','LUMIERA_CONFIG_PATH=\\"$PKGLIBDIR/:.\\"' - ,'LUMIERA_CONFIG_PATH=\\"$DESTDIR/share/lumiera/:.\\"') + # NOTE: could define optional compile features here.... Options.prepareOptionsHelp(buildVars,env) buildVars.Save(OPTCACHE, env) diff --git a/admin/setVersion b/admin/setVersion index ea95fe63b..1a60b7c55 100755 --- a/admin/setVersion +++ b/admin/setVersion @@ -40,5 +40,6 @@ rewrite doc/devel/Doxyfile 'PROJECT_NUMBER\s*=' "$VER" rewrite doc/devel/Doxyfile.browse 'PROJECT_NUMBER\s*=' "$VER" rewrite admin/scons/Setup.py 'VERSION\s*=' "\'$VER\'" rewrite README 'Version:' "$VER" +rewrite NEWS 'Version:' "$VER" echo -e "\nSUCCESSFULLY rewritten version $VER\ncheck git diff\n\n" diff --git a/data/SConscript b/data/SConscript index d2407b502..e04d5f2fa 100644 --- a/data/SConscript +++ b/data/SConscript @@ -21,5 +21,9 @@ config = ( env.ConfigData('config','setup.ini', targetDir='$ORIGIN') + env.ConfigData('config','dummy_lumiera.ini') ) +#further resources... +env.Install('$SHARE/applications/' , 'desktop/lumiera.desktop') +env.Install('$SHARE/icons/hicolor/scalable/apps/', 'desktop/lumiera.svg') + Export('icons config') diff --git a/data/desktop/lumiera.desktop b/data/desktop/lumiera.desktop new file mode 100644 index 000000000..771d6d0a5 --- /dev/null +++ b/data/desktop/lumiera.desktop @@ -0,0 +1,13 @@ +[Desktop Entry] +Type=Application +Version=1.5 +Name=Lumiera +Comment=Video editing and compositing (unfinished; development preview) +GenericName=VideoEditor +Exec=lumiera +TryExec=lumiera +Icon=lumiera +Terminal=false +Categories=AudioVideo;Video;AudioVideoEditing; +Keywords=media;film;editing;compositing;fx; + diff --git a/data/desktop/lumiera.svg b/data/desktop/lumiera.svg new file mode 100644 index 000000000..bcf70b504 --- /dev/null +++ b/data/desktop/lumiera.svg @@ -0,0 +1,146 @@ + + + + + Lumiera Icon + + + + image/svg+xml + + + Lumiera Icon + August 2009 + + + Thorsten Wilms + + + + + CC By SA + + + + + Lumiera project + + + Lumiera Logo + After the Lumiera Logo contest, several flavours were created for use on posters, T-shirts and desktop icons + + + Raffaella Traniello, Thorsten Wilms, Odin Hørthe Omdal, Ichthyoste + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/SConscript b/doc/SConscript index 537b9b137..e0abc0ebb 100644 --- a/doc/SConscript +++ b/doc/SConscript @@ -8,9 +8,10 @@ Import('env') doxydoc = env.Doxygen('devel/Doxyfile') +env.Clean(doxydoc, doxydoc + ['devel/,doxylog','devel/doxygen-warnings.txt']) -# env.Install(dir = '$DESTDIR/share/doc/lumiera$VERSION/devel', source=documentation) -env.Clean (doxydoc, doxydoc + ['devel/,doxylog','devel/doxygen-warnings.txt']) +# HTML-documentation: this is a *placeholder* (eventually we'll build a user manual via Asciidoc) +env.DocFile('devel', 'LumieraHelpLandingPage.html', 'manual-html/index.html') Export('doxydoc') diff --git a/doc/design/application/ApplicationStart.txt b/doc/design/application/ApplicationStart.txt index 41206a4c5..a460039e4 100644 --- a/doc/design/application/ApplicationStart.txt +++ b/doc/design/application/ApplicationStart.txt @@ -98,7 +98,7 @@ within the engine independently, relying on worker jobs and a thread pool. Initialisation and Lifecycle ---------------------------- After some discussion,footnote:[See the -link:{ldoc}/devel/rfc/GlobalInitialization.html[GlobalInitialisation] RfC +link:{rfc}/GlobalInitialization.html[GlobalInitialisation] RfC from spring 2008. In the beginning, we all agreed to ``keep matters simple'' and build an `init()` function within one central piece of code everyone knows and hooks into. However, while the outline of the application emerged, there diff --git a/doc/design/application/Config.txt b/doc/design/application/Config.txt index e6cbaf1e7..dec73272b 100644 --- a/doc/design/application/Config.txt +++ b/doc/design/application/Config.txt @@ -10,6 +10,6 @@ The Lumiera application uses two quite different sources for configuration to be resolve employing a rules based system '(planned)'. Configuration rules will be provided by the application (defaults), a session template and rules stored in the actual session. --> see also the link:{ldoc}/technical/vault/ConfigLoader.html[Config Loader brainstorming from 2008] (implementation details) +-> see also the link:rfc/ConfigLoaderDraft2008.html[Config Loader brainstorming from 2008] (implementation details) diff --git a/doc/design/architecture/ETD.txt b/doc/design/architecture/ETD.txt index b2a828f94..0adac6747 100644 --- a/doc/design/architecture/ETD.txt +++ b/doc/design/architecture/ETD.txt @@ -1,7 +1,7 @@ External Tree Description ========================= :Author: Ichthyostega -:Date: Fall 2015 +:Date: Autumn 2015 @@ -17,11 +17,11 @@ Any collaboration requires, as an underlying, some kind of common understanding. And any formalised, mechanical collaboration requires to represent that common point of attachment -- at least as _symbolic representation._ The »External Tree Description« is shaped to fulfil this need: _in theory,_ the whole field could be represented, symbolically, as a network of hierarchically -structured elements. Yet, _in practice,_ all we need is to conceive the presence of such a representation, +structured elements. Yet, _in practice,_ all we need is to presuppose the presence of such a representation, as a backdrop to work against. And we do so -- we work against that symbolic representation, -by describing *changes* made to the structure and its elements. Thus, the description of changes, -the link:{ldoc}/technical/library/DiffFramework.html[diff language], refers to and partially embodies -such symbolically represented elements and relations. +by describing *changes* made to the structure and its elements. And so the description of changes, +the link:{ldoc}/technical/library/DiffFramework.html[diff language], thus refers to and partially +embodies such symbolically represented elements and relations. Elements, Nodes and Records --------------------------- @@ -29,7 +29,7 @@ We have to deal with _entities and relationships._ Entities are considered the building blocks, the elements, which are related by directional links. Within the symbolic representation, elements are conceived as *generic nodes* (`GenNode`), while the directed relations are impersonated as being attached or rooted at the originating side, -so the target of a relation has no traces or knowledge of being part of that relation. Moreover, each +so that the target of a relation has no knowledge of being part of that relation. Moreover, each of our nodes bears a _relatively clear-cut identity._ That is to say, within the relevant scope in question, this identity is unique. Together, these are the building blocks to represent any *graph*. diff --git a/doc/design/architecture/playRender.txt b/doc/design/architecture/Playback.txt similarity index 93% rename from doc/design/architecture/playRender.txt rename to doc/design/architecture/Playback.txt index 9c866e0e1..f85f39685 100644 --- a/doc/design/architecture/playRender.txt +++ b/doc/design/architecture/Playback.txt @@ -3,7 +3,7 @@ Design: Playback and Render Control :Author: Ichthyostega :Date: 5/2011 -//MENU: label Player subsystem +//MENU: label Playback ************************************************************************************** This part of the architecture is concerned with how to initiate, coordinate and control @@ -24,10 +24,12 @@ discussions and brainstorming sessions. * discussions regarding time values and timecode handling shed some light on the requirements to be fulfilled by a player subsystem - - link:http://article.gmane.org/gmane.comp.video.lumiera.general/2116[Timecode Widget and Framerates] - - link:http://article.gmane.org/gmane.comp.video.lumiera.general/2109[Time, Time-spans, Quatisation and Timecode] - - link:{l}/wiki/renderengine.html#TimeQuant[Definition of Time entities] - from the implementation notes in the TiddlyWiki + - https://lists.lumiera.org/pipermail/lumiera/2010-July/001984.html[Timecode formats and time widget] + - https://lists.lumiera.org/pipermail/lumiera/2010-December/002197.html[Timecode Widget and Framerates] + - https://lists.lumiera.org/pipermail/lumiera/2010-December/002190.html[Time, Time-spans, Quatisation and Timecode] + + * at the _framework level_ a set of definitions has been created to handle + link:/x/TimeUsage.html[time values and quantisation]. Reasoning Behind the Player Subsystem's Structure @@ -152,8 +154,8 @@ reconfigure the vault layer services. Frame quantisation ^^^^^^^^^^^^^^^^^^ -link:../TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding, quantisation is -a dangerous operation because it kills information content. +link:/x/TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding, +quantisation is a dangerous operation because it kills information content. Thus, there are three fundamental guidelines when it comes to rounding: diff --git a/doc/design/architecture/index.txt b/doc/design/architecture/index.txt index 83dadaa02..f3b4468a0 100644 --- a/doc/design/architecture/index.txt +++ b/doc/design/architecture/index.txt @@ -5,7 +5,6 @@ Design Documents: Lumiera Architecture // Menu : prepend child Subsystems // Menu : prepend child ArchitectureSummary -// Menu : attach child TimeQuant after TimeUsage This section will feature some rather high-level considerations regarding the architecture of the application. @@ -14,6 +13,12 @@ the architecture of the application. See link:ArchitectureSummary.html[here] for a short summary of the core architecture ideas of the envisioned Lumiera Application. +.Time and Time-code +link:time/[Handling of time values] and link:time/TimeCode.html[Time Code] is +essential for an editing application and requires some forethought to avoid +some of the common inconsistencies and pitfalls; precision can be a challenge, +given the extremely large range of time scales to cover. + .Rendering and Playback Control This part of the architecture is concened with how to initiate, coordinate and control the calculation processes necessary to generate visible / audible data from our source @@ -21,6 +26,6 @@ media. This design is _not so much_ concerned with the actual calculations; inde takes on an ``bird eye's view'', treating the actual render engine mostly just as an opaque entity providing some service. --> link:playRender.html[Design: Playback and Rendering] +-> link:Playback.html[Design: Playback and Rendering] diff --git a/doc/design/architecture/time/TimeCode.txt b/doc/design/architecture/time/TimeCode.txt new file mode 100644 index 000000000..0baa901c9 --- /dev/null +++ b/doc/design/architecture/time/TimeCode.txt @@ -0,0 +1,13 @@ +Handling of Time Code Formats +============================= + +.A Design draft +Since handling of time values and time code formats is of uttermost importance +for editing film, a draft concept was created in the early phase of Lumiera design. +The chosen approach relies heavily on a framework for representation of temporal data +developed for this purpose in the Lumiera support library. However, the implementation +of various actual time code formats was deferred for later -- while the viability of +this design yet needs to be validated by actual usage. + +Detailed analysis and planning can be found in the +link:/x/fwd/DevWiki.TimeCode.html[DevWiki: TimeCode]. diff --git a/doc/design/architecture/time/TimeMutation.txt b/doc/design/architecture/time/TimeMutation.txt new file mode 100644 index 000000000..42c21b5fb --- /dev/null +++ b/doc/design/architecture/time/TimeMutation.txt @@ -0,0 +1,48 @@ +Modify Quantised Time Values +============================ + +.Challenges +Temporal data can be complex and given in several flavours; a request to _modify_ +some given time data adds a further layer of complexity, since the required modification +can itself be specified in various forms. And on top of that, the temporal data can be +quantised, or can be represented through a quantised view, while also the modification +can be given in any form of quantification, even based on a different time grid. +When it comes to resolving this kind of multi-layered complexity, it is crucial +to stick to the principles of logically sound reasoning; furthermore, especially +the situation where several disjoint time grids are involved may require some +additional decision rule to determine which grid has to take priority. + +.Problematic choices of design +While the Lumiera developers immediately recognised the danger of code quality problems, +there was no consensus how to approach these difficulties. Should everything in the +Render Engine be based on frame counts? Can questions of grid alignment be pushed out +to the system's boundaries? Is grid alignment mostly a problem of UI representation? +An attempt was made to base time handling on simple integral data types, with a plain-C +library to provide quantisation and timecode functions -- which however could not prevent +the proliferation of ad-hoc computations at various places, given that temporal data +seems to be ``just simple numbers''. In an attempt to get this situation under control +before problems start to accumulate and spread, _Ichthyo_ pushed for a radical approach +to rely on the _C++ type system_ and use _opaque_ entities with controlled arithmetic. +Unfortunately, those basic time entities were also defined to be _immutable_ -- following +a trend towards functional programming, which became increasingly popular at that time. + +This new framework proved itself successful as a device to identify and eliminate ad-hoc +solutions -- yet state, being a part of the real world, can not be eliminated by dictum, +and will claim it's right sooner or later. + +- very soon, a `TimeVar` datatype was introduced, since ``pure'' functional concepts + can never compete with the _intuitivity_ of ``just using numbers'' +- from a users point of view, the GUI exposes time-related entities which can be + manipulated -- notably the playback position. An attempt was made, to _encapsulate_ + these manipulations as a `time::Control` + +In this (slightly compromised) form, the new framework was able to support all +time-data related tasks encountered for the first (GTK-2) version of the UI. +Some more technical explanations can be found in the +link:/x/fwd/DevWiki.TimeMutation.html[DevWiki: TimeMutation]. + +In hindsight, using opaque types was very successful -- while the immutability seems +to be a mistake and induces a lot of unnatural complications. A design change to +rectify the situation was planned and documented as +link:/x/ticket/1261.html[#1261 »reconsider (im)mutability of time entities«] + diff --git a/doc/design/architecture/TimeQuant.txt b/doc/design/architecture/time/TimeQuant.txt similarity index 97% rename from doc/design/architecture/TimeQuant.txt rename to doc/design/architecture/time/TimeQuant.txt index 155fd7e00..083108606 100644 --- a/doc/design/architecture/TimeQuant.txt +++ b/doc/design/architecture/time/TimeQuant.txt @@ -44,7 +44,7 @@ changing time:: Time values are _immutable,_ like numbers. + Only a *time variable* can be changed -- yet some of the special time entities - can recieve link:TimeMutation[mutation messages], allowing e.g. for + can receive link:/x/TimeMutation.html[mutation messages], allowing e.g. for adjustments to a time interval selection from the GUI '''' @@ -99,7 +99,7 @@ frame count:: timecode:: Quantisation also is the foundation of all kinds of formalised time specifications actually even a frame count is some kind of (informal) timecode -- other timecodes - employ a standardised format. //Every// presentation of time values and every + employ a standardised format. _Every_ presentation of time values and every persistent storage and exchange of such values is based on time codes. Yet quantisation and time code aren't identical: a given quantised time value typically can be cast into multiple timecode formats. @@ -202,11 +202,9 @@ There is a common baseclass `TCode` though, which can be used as marker or for _type erasure._ -> more on link:TimeUsage.html[usage situations] -//// -// TODO integrate those cross links + --> Timecode link:TimecodeFormat[format and quantisation] +-> Timecode link:/x/TimeCode.html[format and quantisation] + --> Quantiser link:QuantiserImpl[implementation details] -//// +-> Quantiser link:/x/imp/TimeQuantiser.html[implementation details] + diff --git a/doc/design/architecture/TimeUsage.txt b/doc/design/architecture/time/TimeUsage.txt similarity index 93% rename from doc/design/architecture/TimeUsage.txt rename to doc/design/architecture/time/TimeUsage.txt index 10ef5cf16..4dd492716 100644 --- a/doc/design/architecture/TimeUsage.txt +++ b/doc/design/architecture/time/TimeUsage.txt @@ -8,7 +8,7 @@ Time Usage Situations the following collection of usage situations helps to shape the details of the time values and time quantisation design. + --> see also link:TimeQuant.html[more about time quantisation] +-> see also link:/x/TimeQuant.html[more about time quantisation] time position of an object:: indeed the term ``time position'' encompasses two quite different questions @@ -45,7 +45,7 @@ updating the playback position:: possible loop positions are way finer than the processing block size) dispatching individual frames for calculation:: - when a link:PlayProcess[render or playback process] is created, at some point + when a link:/x/PlayProcess.html[render or playback process] is created, at some point we need to translate this logical unit (``calculation stream'') into individual frame job entries. This requires to break continuous time into individual frames, and then ennumerating these frames. @@ -113,7 +113,7 @@ desirable somehow to move these distinctions out of the scope of this design and offload them onto the client (code using these time classes). Another closely related problem is *when to allow mutations*, if at all (-> see -link:TimeMutation[more here...]). We can't completely do away with mutations, +link:/x/TimeMutation.html[more here...]). We can't completely do away with mutations, simply because we don't have a pure functional language at our disposal. The whole concept of _reference semantics_ doesn't play so well with immutable objects. The Lumiera high-level (session) model certainly relies on objects @@ -140,8 +140,8 @@ in this case quantised values and quantisation are approached in the reverse direction, compared with the other uses. Here, after establishing a start point on the time scale, we proceed with ennumerating distinct frames and later on need to access the corresponding raw time, especially to find out about the -link:Segmentation[timeline segment] to address, or for retrieving parameter -automation. -> link:FrameDispatcher[see frame dispatching]. +link:/x/Segmentation.html[timeline segment] to address, or for retrieving parameter +automation. -> link:/x/FrameDispatcher.html[see frame dispatching]. Note that the *display window might be treated as just an independent instance of quantisation*. This is similar to the approach taken above for modifying @@ -176,11 +176,11 @@ closing the circle. substantial problems to be solved --------------------------------- -* how to link:TimeGridAlignment[align multiple grids] -* how to integrate link:TimeMutation[modifications of quantised values]. ([green]#✔ solved#) +* how to align multiple grids -- what grid to use for playback? +* how to integrate link:/x/TimeMutation.html[modifications of quantised values]. ([green]#✔ solved#) * how to isolate the Time/Quantisation part from the grid MetaAsset in the - session -> we use the link:Advice[Advice] system ([green]#✔ solved#) + session -> we use the link:/x/Advice.html[Advice] system ([green]#✔ solved#) * how to design the relation of Timecode, Timecode formatting and Quantisation - -> link:TimecodeFormat[more here] [yellow-background]#WIP# + -> link:/x/TimeCode.html[more here] [yellow-background]#WIP# diff --git a/doc/design/architecture/time/index.txt b/doc/design/architecture/time/index.txt new file mode 100644 index 000000000..9f86f33ea --- /dev/null +++ b/doc/design/architecture/time/index.txt @@ -0,0 +1,21 @@ +Time Handling +============= + +// Menu : sort children +// Menu : attach child TimeQuant after TimeUsage +// Menu : append child TimeMutation + + +While Lumiera will be able to handle various kinds of different content and data, +the task of _editing_ implies to arrange elements into a temporal dimension. +Thus representation of time and expression of relations in time plays a pivotal role. + +At first sight, time seems to we well-known, commonplace and trivial to understand -- +which however is a deception, since anything related to time, timings, duration and +time scales is notoriously difficult to spell out with precision and tricky to +handle in the practice of programming. A high-level discussion should thus + +- start with an analysis of link:TimeUsage.html[usage situations] +- alignment to a pre-determined grid scale, the so called + link:TimeQuant.html[Time Quantisation] requires careful attention +- formal representation of link:TimeCode.html[Time Code] is central to film editing. diff --git a/doc/design/engine/PlayModes.txt b/doc/design/engine/PlayModes.txt index d616aff9e..8e95583a3 100644 --- a/doc/design/engine/PlayModes.txt +++ b/doc/design/engine/PlayModes.txt @@ -55,8 +55,7 @@ Requirement analysis of playback modes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For the task of editing a piece of media, the following modes of playback presentation can be determined + See also the more -link:wiki/renderengine.html#NonLinearPlayback%20PlayService%20PlayProcess%20CalcStream%20FrameDispatcher%20OutputManagement[ -technical discussion of playback in the TiddlyWiki] +link:imp/NonLinearPlayback.html[technical discussion of non-linear playback] regular playback:: diff --git a/doc/design/engine/PlayProcess.txt b/doc/design/engine/PlayProcess.txt new file mode 100644 index 000000000..11cdffb90 --- /dev/null +++ b/doc/design/engine/PlayProcess.txt @@ -0,0 +1,11 @@ +Playback and Render Processing +============================== + +.Prototyping and Exploration +On a conceptual level, this topic reaches far beyond the mere data processing +and is undeniably one of the most complex and interwoven aspects of Lumiera. +As of 2025, most structures in this realm are in a state of prototyping -- +many topics are in flux and what works well needs to be figured out yet. + +Many detailed notes can be found in the +link:/x/fwd/DevWiki.PlayProcess.html[DevWiki: PlayProcess]. diff --git a/doc/design/engine/index.txt b/doc/design/engine/index.txt index 0852b6bac..75c1cb741 100644 --- a/doc/design/engine/index.txt +++ b/doc/design/engine/index.txt @@ -2,5 +2,5 @@ Design Documents: Renderengine ============================== This section contains design documents regarding the overall workings of the Render Engine, -and the handling of output generation and output connections. +data processing and the handling of output generation and output connections. diff --git a/doc/design/governance/integration.txt b/doc/design/governance/integration.txt index 605becf1e..6a1085fe8 100644 --- a/doc/design/governance/integration.txt +++ b/doc/design/governance/integration.txt @@ -6,12 +6,12 @@ Towards Integration //Menu: label Integration The Lumiera project creates innovative software, geared towards professional, high-quality work; -it aims at high flexibility, offering user-control over a broad spectrum of configurable parameters, -and with smooth workflows that scale well to larger and more intricate projects. Building such -software involves some degree of exploration and search for adequate methods to reconcile -conflicting goals. There is no ready-made blueprint that just needs implementation -- rather, -we have to resort to a sequence of integration efforts, aimed at establishing core tenets -of the envisioned architecture. +it is characterised by comprehensive flexibility, allowing precise control of a wide range of +parameters, as well as seamless workflows capable of handling even large and complex projects. +Building such software involves some degree of exploration and the search for suitable ways to +reconcile sometimes conflicting goals. There is no ready-made blueprint that simply needs to be +implemented -- rather, we have to resort to a sequence of integration efforts, to establish the +core tenets of our envisioned architecture. Vertical Slices diff --git a/doc/design/gui/GuiDiscussion/ConceptProposals/AkhiL.txt b/doc/design/gui/GuiDiscussion/ConceptProposals/AkhiL.txt index 6e66a6c0f..f8a0d0943 100644 --- a/doc/design/gui/GuiDiscussion/ConceptProposals/AkhiL.txt +++ b/doc/design/gui/GuiDiscussion/ConceptProposals/AkhiL.txt @@ -10,5 +10,5 @@ Wiring nodes within the timeline In fall 2007, rather then using an external node editor, AkhiL proposed to do wiring of effect nodes directly within the timeline. He did the following Mockup: -image::{imgg}/AkhiL.proposal.png[] +image::{imgg}/proposal.AkhiL.png[] diff --git a/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt b/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt index 104ca8d8c..09b250d95 100644 --- a/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt +++ b/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt @@ -35,7 +35,7 @@ and add new functions. Of course this modules I am talking about, are not the modules described in the architecture overview. This is the gui, which is an abstraction of the real program. -image::{imgg}/Alcarinque.proposal.png[Alcarinque's GUI proposal] +image::{imgg}/proposal.Alcarinque.png[Alcarinque's GUI proposal] Here I made a sample of the architecture of the UI. Please don't take this too seriously, it is just a draft so you can understand the workflow. I haven't diff --git a/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt b/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt index b97a18128..241b62829 100644 --- a/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt +++ b/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt @@ -3,7 +3,7 @@ GUI Proposal by Clay Barnes :Author: R. Clayton Barnes (»rcbarnes«) :Date: 2008-05-21 --> https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry] +-> https://web.archive.org/web/20120128160238/https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry] .About the Author *********************************************************************************************************** @@ -17,15 +17,15 @@ I’ve pulled together some drafts of my ideas for the design of the timeline po of the Lumiera non-linear video editor (hopefully, the successor to http://cinelerra-cv.wikidot.com[Cinelerra]). The un-annotated version:: - image:{imgg}/Barnes.proposal.png[ + image:{imgg}/proposal.Barnes.png[ "Lumiera UI proposal",width=300, - link="{imgg}/Barnes.proposal.png"] + + link="{imgg}/proposal.Barnes.png"] + (click to enlarge) The annotated version:: (explaining some of the finer points) - image:{imgg}/Barnes.proposal-annotated.png[ + image:{imgg}/proposal.Barnes-annotated.png[ "Lumiera UI proposal (annotated)",width=300, - link="{imgg}/Barnes.proposal-annotated.png"] + link="{imgg}/proposal.Barnes-annotated.png"] diff --git a/doc/design/gui/GuiDiscussion/ConceptProposals/RichardSpindler.txt b/doc/design/gui/GuiDiscussion/ConceptProposals/RichardSpindler.txt index 30fc9fe84..051429331 100644 --- a/doc/design/gui/GuiDiscussion/ConceptProposals/RichardSpindler.txt +++ b/doc/design/gui/GuiDiscussion/ConceptProposals/RichardSpindler.txt @@ -25,4 +25,4 @@ represent another View, and the connection from the timeline to the compositing nodes will be by Name, and not by arrows. Default Names would be "Video Track #1", etc. -image::{imgg}/RichardSpindler.proposal.png[] +image::{imgg}/proposal.RichardSpindler.png[] diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt index ca21bc5ab..e634bf29b 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt @@ -5,9 +5,8 @@ GUI Brainstorming Reviewed State of the GUI ---------------- -image:{l}/media/img/design.gui/screenshot090124-resources.jpg[Screenshot 090124] +image::{imgg}/screenshot2009-01.jpg[title="Screenshot 2009-01",width="80%"] -Updated 18/01/09 Done @@ -20,7 +19,8 @@ One Window can be tiled (horizontally/vertically) giving areas where screen elem * Multiple windows + Can open multiple windows on one head and (optionally) tile them as above --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' * My personal preference would be to produce the GUI in C++ with Gtkmm. Gnome is the most popular desktop for Linux, and GTK now has good support both for Win32, Mac and KDE (except that GTK on Mac still needs X11, probably for some more time) @@ -42,7 +42,8 @@ High Priority * A good entry level gui together with an advanced key driven system like about blender (not so much the ui) - Yes Blender's UI isn't that great a model to follow (though there is some good stuff in there). I agree about good keyboard support. A good place to start would be the standard + accelerators, as well as context menu mnemonics. We should be able cover the entire command set with the these. I don't see us needing anything more advanced than that. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:48:03Z)]] ++ +JoelHoldsworth:: '2008-07-22T20:48:03Z' Medium Priority @@ -50,17 +51,25 @@ Medium Priority * Fullscreen Support + Windows can be made fullscreen with no decorations (but tiling left intact) --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: This can be done with relative ease. We should add this feature. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Work well with tiling window managers + I propose that the future Lumiera GUI is designed without too much (or anything) about the user's screen apart from what is acceptable based on the X11 protocol(?) in order to work well with tiling window managers. The main problem to watch out for is assuming specific dimensions. The nature of tiling window managers is that most of the time, the windows without focus are dramatically downsized in one or two dimensions. This causes poorly designed GUIs to behave strangely, sometimes as bad as constantly jumping between layouts and thus causing unnecessary CPU load. --- link:MichaelPloujnikov[] [[DateTime(2008-04-14T22:29:12Z)]] ++ +MichaelPloujnikov:: '2008-04-14T22:29:12Z' - Comment: As much as anything this is a case for good testing on tiling window managers. People who use them need to do this, and file bugs, or better yet patches. It would be good for me to start using one as well, I think. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Window configurations can be stored/restored in customizable presets and are part of the project (see blender again) @@ -68,19 +77,25 @@ I propose that the future Lumiera GUI is designed without too much (or anything) A jog tool is a sliding ui element that when clicked and held, will play the video at a certain rate as the mouse drags left or right. As the mouse drags the the left the video plays forward faster (It should advance very slowly at first.). It acts the same way when the mouse drags to the right, except that the video plays in reverse. Again, it can be tedious trying to make frame-accurate cuts to long video files. Without a jog tool it makes it more tedious to get to the exact frame you want to cut on because you must scan through, then click the next frame button half a dozen times. A jog tool would remedy this because one could easily vary the playback rate, even reverse it, zeroing in on the frame much more quickly. Together these two features could really increase the speed at which one can edit precisely in Cinelerra. - Comment: This idea seems feasible, it could be worked together with cehteh shuttle slider proposal. --- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]] ++ +joelholdsworth:: '2008-07-19T19:42:04Z' * most numeric value entries (sliders, spinbuttons) can be changed when hovering the mouse over it and turn the scroll wheel (maybe with an additional modifier key?) -- The scroll wheel is accelerated depending on how fast it is operated by the user, snapping it slowly gives frame/interval precise increments, turning it faster will exponentially increases the increment (2,4,8.. frames per click) --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' * "Render AS" + The *process for creating a DVD* where Video and Audio have to be rendered separately is laborious. A script could easily handle this, and make the use of the program so much easier, attractive, inviting, productive, time efficient, bla bla. All the user needs to do is set the parameters and file name (once) and then "do". Many commonly used formats for saving could be saved as presets that completely avoid all the questions (say in the "File" drop down menu, as a customizable "Render AS" choice). This could also be done for HDTV, iPod, Ringtones, VCD, Various formats that give the best performance for uploading to Youtube and all the other video sharing sites. + When a whole magazine article(s) can be written about the task of exporting a file to make a DVD, you know the process is a long one. mmm ... Any well paid journalists out there want to sponsor programmed task efficiency? - "NO?" - oh well. --- link:Tree[] [[DateTime(2008-05-07T16:44:00Z)]] ++ +Tree:: '2008-05-07T16:44:00Z' - This could probably be solved by having a series of format presets in the Render dialog. The default set could contain settings for the values you mention. We could even allow the user to save their own presets. Cinelerra already has this functionality - these are called profiles, but it doesn't come with a default set at all. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:13:28Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:13:28Z' +-- * Reduced quality previews + There needs to be a way of giving the user the choice to see the movie at full quality - computationally expensive, or at reduced quality for times when full framerate would be impossible. @@ -89,14 +104,21 @@ There needs to be a way of giving the user the choice to see the movie at full q Let the user have more flexibility over the track view height. Some tracks can be set to minimal, others to visible (but basically iconic), others enough to see features, and one or two to good resolution. Some may even be blanked. + The track view height could be individually selectable , for example, by changing the "draw media" icon from toggle mode to drop down menu. The drop down selection options could include "don't show", followed by track sizes as per the drop down menu at the bottom of track view. --- link:Tree[][[DateTime(2008-05-07T17:30:00NZ)]] - - - Comment: Yes, I was thinking about this idea myself. At first I was thinking of just allowing the user to expand or collapse the track with a +/- button. But then I wondered if it would be good to have the track completely sizable. My current thinking is the best way would be to have it sizable but with a kind of snap-to-grid behaviour so the whole thing doesn't become really messy. --- link:JoelHoldsworth[] [[DateTime(2008-08-04T16:03:24Z)]] ++ +Tree:: '2008-05-07T17:30:00NZ' + -- -* Ardour provides an example for this: the track height can be changed (by buttons or with the mouse wheel + modifyer key), but there is only a fixed set of possible track heights, some of which have a preconfigured layout. For example, in "smallest" size the track head shows only the track label without any buttons and the track is reduced to a tiny waveform. --- link:Ichthyostega[] [[DateTime(2008-08-08T15:18:31Z)]] + ** Comment: Yes, I was thinking about this idea myself. At first I was thinking of just allowing the user to expand or collapse the track with a +/- button. But then I wondered if it would be good to have the track completely sizable. My current thinking is the best way would be to have it sizable but with a kind of snap-to-grid behaviour so the whole thing doesn't become really messy. ++ +-- +JoelHoldsworth:: '2008-08-04T16:03:24Z' +-- + + ** Ardour provides an example for this: the track height can be changed (by buttons or with the mouse wheel + modifyer key), but there is only a fixed set of possible track heights, some of which have a preconfigured layout. For example, in "smallest" size the track head shows only the track label without any buttons and the track is reduced to a tiny waveform. ++ +-- +Ichthyostega:: '2008-08-08T15:18:31Z' +-- -- @@ -106,29 +128,37 @@ Low Priority * Multi Head + Can open Windows on different heads of the same server, and is aware of the existence of different physical monitors (ie. Xinerama-aware) - - Comment: Xinerama seems to be a decreasingly popular way of doing multi-monitor. This probably could be implemented, but I don't have a Xinerama based setup, and I've never talked to anyone who does. I use link:TwinView[], and it seems like a more practical way of doing dual screen to me. Surely RandR based multi-monitor is the main need today. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + - Comment: _Xinerama_ seems to be a decreasingly popular way of doing multi-monitor. This probably could be implemented, but I don't have a _Xinerama_ based setup, and I've never talked to anyone who does. I use _TwinView_, and it seems like a more practical way of doing dual screen to me. Surely _RandR_ based multi-monitor is the main need today. ++ +joelholdsworth:: '2008-07-21T21:58:48Z' + -- * Multi-Head != Xinerama ... This is very important and quite common, We want to support monitors driven at the native Video Format (resolution, framerate, interlacing, overscan, ....). For a professional setup this is really required! --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] + -Xinerama and twinView test comparison http://www.phoronix.com/scan.php?page=article&item=387&num=1[] ++ +ct:: '2008-07-22T07:11:11Z' + +* Xinerama and twinView test comparison -> https://www.phoronix.com/review/387[see @Phoronix...] -- * Automatic Clip Creation based on video content. + When scanning through an hour long video clip, it can be tedious to go through it all making clips. It would allow the user to get right to work if Lumiera could split the video into clips based on scene changes. Each clip would begin at precisely the frame the current shot begins and end at the last frame before the next shot. As long as the user could then edit these clips on the timeline, this would decrease the time spent sifting through the raw footage. - Comment: This seems like a good idea, and quite easy to implement. I think that when we get the video-capture and media manager code working this would a be a good subproject for someone to take on. --- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]] ++ +joelholdsworth:: '2008-07-19T19:42:04Z' * Import and Export SMIL files + Many current cinelerra users probably use kino for their capturing of DV. it uses less resources, so less system demand during capture. Good display monitor while capturing. Open Movie Editor is a good multitrack editor that can share Kino's SMIL files. A good progression in complexity of editing is start with kino, move to OME, then cinelerra (lumiera). A really convenient way to assist stepping up from Kino is to handle the SMIL files. + Automatic scene detection is a great feature in Kino. The simpler editors make it easy for less skilled people to look after the selection of preliminary clips, while lumiera is used by the folks who put it all together, and finish it off. ---link:Tree[][[DateTime(2008-05-09T15:10:00NZ)]] . ++ +Tree:: '2008-05-09T15:10:00NZ' - Comment: SMIL is quite cool technology. It's not just a Kino thing. It'd be quite good to be able to import this standard format. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:41:02Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:41:02Z' +-- More Discussion Needed @@ -141,40 +171,66 @@ Timeline Make the timeline view _sparse_, that means the time on top is not continuous anymore but \'boring' sequences get omitted and \'interesting' sequences get displayed, probably even stretched to cover at least a single thumbnail. + This needs an ui (menu or whatever) to turn this feature on and some selection which events the user is interested in (scene cuts, transitions begin/end/mids, keyframes (begin/mid), labels, ...) --- link:ct[] [[DateTime(2008-05-21T13:46:51Z)]] - - - Comment: Do you think we could use view splitting to accomplish this? You can see this sort of thing OpenOffice.org calc. Where you drag a splitter out from the ends of the scrollbar, this allows you compare 2 or 4 parts of a big spreadsheet at the same time. Implementing something like that might be reasonably doable. But if you're talking about hiding periods on the timeline, that sounds a lot less easy to me, and it feels like a bit a bit of an odd thing to do. What do you think ct? --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* No, view-splitting is something different, usually one splits the timeline to few places (2 or 3). Managing those splits requires a lot manual interaction (resizing the splits, zooming into the right time resolution, scrolling to the desired range, ...). In contrast this 'sparse' timeline does that all automatically by possibly adding hundreds of those split points (there should be no split bar on the gui). One just has to select POI's with some menu or such. Well and the timeline ruler needs to adapt to it, that might be tricky --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +ct:: '2008-05-21T13:46:51Z' +-- + +** Comment: Do you think we could use view splitting to accomplish this? You can see this sort of thing OpenOffice.org calc. Where you drag a splitter out from the ends of the scrollbar, this allows you compare 2 or 4 parts of a big spreadsheet at the same time. Implementing something like that might be reasonably doable. But if you're talking about hiding periods on the timeline, that sounds a lot less easy to me, and it feels like a bit a bit of an odd thing to do. What do you think ct? ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- + +*** No, view-splitting is something different, usually one splits the timeline to few places (2 or 3). Managing those splits requires a lot manual interaction (resizing the splits, zooming into the right time resolution, scrolling to the desired range, ...). In contrast this 'sparse' timeline does that all automatically by possibly adding hundreds of those split points (there should be no split bar on the gui). One just has to select POI's with some menu or such. Well and the timeline ruler needs to adapt to it, that might be tricky ++ +-- +ct:: '2008-07-22T07:11:11Z' -- * "Sparse Timeline" is in Trackview" - see Track view section lower down the page + This is the kind of features I have suggested in the Trackview section lower down the page. I like the name you give it - "Sparse" because it allows the user to not have to bother viewing OR scrolling past all the stuff in between two end points (or more items) just to tweak the ends of a segment. But I would emphasize that instead of reducing the width of the timeline because of the narrow time span needs for the one task, that more tasks can be carried out in the same view. This is because the view just misses out all the stuff in between, for each task. + I am playing around with a few thoughts and maybe might attach an image of how it might work. But in conjunction with "tabbed views" it would result in the convenient ability to display all the work areas in a concentrated display, meaning a whole lot less scrolling around, and clicking to bring windows to the foreground. --- link:Tree[][[DateTime(2008-05-23T16:59:00NZ)]] - - - Comment: See above. With regards to tabbed based UI in the timeline view, I do have this in mind, and it seems reasonably straightforward to allow two tabs which contain views of the same timeline - just scrolled to different places. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] - -* Clip Mode + -This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there. -- link:rexbron[] + -The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together. +-- +Tree:: '2008-05-23T16:59:00NZ' +-- - - Comment: This sounds a bit odd in some ways. But I'd be interested to find out more. I'll probably do some research into it at some stage. Maybe you can post some screenshots. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] +** Comment: See above. With regards to tabbed based UI in the timeline view, I do have this in mind, and it seems reasonably straightforward to allow two tabs which contain views of the same timeline - just scrolled to different places. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- + +* Clip Mode ++ +This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there. ++ +rexbron:: '2008-05' ++ +-- +* The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together. + +** Comment: This sounds a bit odd in some ways. But I'd be interested to find out more. I'll probably do some research into it at some stage. Maybe you can post some screenshots. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- +-- * I propose an assembly system where the source material is left untouched where effects are added on the fly similar to html and dtp packages. In this system the system is linked together using an node system similar to gstreamer and jack. - - Comment: Yes the core of lumiera will work on a scen graph of connected nodes, and we want to provide the user with a way of using that power. We need to discuss how node wiring and the timeline-track tree go together. Note that node wiring only seems to make good UI when the node graph is fixed for the duration of the whole project timeline. We need to work out how this fits together with the timeline tree, and if metaclips help this problem at all. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] - -Comment to all those sparse timeline and clip mode proposals: The benefits of those are obvious, as they directly correspond to the working with storyboards. Almost every serious movie uses storyboards to quite some extent. But for the implementation, I'd propose not to see it as an alternative view/mode of the timeline. Rather, I'd treat it like a media/asset folder. Probably we'll have the ability for the user to group the media asset into various "bins" (virtual sub folders). Moreover, pre-cut clips appear as clip assets as well (similar in Cinelerra and most other video editors). Thus, we just need a function to "play" such a clip bin. It could be implemented by defining a ordering on the clips in the bin (from top to bottom and from left to right?). Then, this function would create an transient EDL on-the-fly, containing just these clips, and hand it over to the engine for building/playback. Thus, the user can see his "draft-cut" played back in real time, and thats all what is really needed. When satisfied, he could mark the clips in the bin and drag them to the timeline, which would add them in the same order starting at the current position. I don't think we need to go though all the pain of creating an separate, dedicated UI for this purpose. --- link:Ichthyostega[] [[DateTime(2008-07-27T23:20:19Z)]] +** Comment: Yes the core of lumiera will work on a scen graph of connected nodes, and we want to provide the user with a way of using that power. We need to discuss how node wiring and the timeline-track tree go together. Note that node wiring only seems to make good UI when the node graph is fixed for the duration of the whole project timeline. We need to work out how this fits together with the timeline tree, and if metaclips help this problem at all. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- +*** Comment to all those sparse timeline and clip mode proposals: The benefits of those are obvious, as they directly correspond to the working with storyboards. Almost every serious movie uses storyboards to quite some extent. But for the implementation, I'd propose not to see it as an alternative view/mode of the timeline. Rather, I'd treat it like a media/asset folder. Probably we'll have the ability for the user to group the media asset into various "bins" (virtual sub folders). Moreover, pre-cut clips appear as clip assets as well (similar in Cinelerra and most other video editors). Thus, we just need a function to "play" such a clip bin. It could be implemented by defining a ordering on the clips in the bin (from top to bottom and from left to right?). Then, this function would create an transient EDL on-the-fly, containing just these clips, and hand it over to the engine for building/playback. Thus, the user can see his "draft-cut" played back in real time, and thats all what is really needed. When satisfied, he could mark the clips in the bin and drag them to the timeline, which would add them in the same order starting at the current position. I don't think we need to go though all the pain of creating an separate, dedicated UI for this purpose. ++ +-- +Ichthyostega:: '2008-07-27T23:20:19Z' +-- Widgets @@ -182,7 +238,7 @@ Widgets * Generalized Fader + -image:images/fader.png[fader.png] +image:{imgg}/mock.Fader-ct2008-02.png[title="fader proposal"] + All faders are the same kind of custom widget, that is: @@ -203,43 +259,69 @@ All faders are the same kind of custom widget, that is: -- + for the application all faders provide a float (or double) value, nothing else. --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: I think making some kind standardized fader widget is probably going to be necessary for this project. We need a good way of combining together the artistic "genstural" elements of a slider widget with the precise numerical behavior of an edit widget, and it needs to be compact - the UI will have a lot of these. I'm not sure how often we'll need to see a level meter with these. Most of the time a control is either an input or a readout - very rarely both. Generally speaking I'm against the idea of having a popup menu to configure this widget. I believe that it should be configured to work in a way which is user friendly by default. There may be many of these widgets and asking the user to configure each of these before they behave well seems a bit unfair to me. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* I agree, the defaults should be reasonable set per-item, that will be that the meter is in most cases off and the spinner will be off on many cases too. I tried to show whats needed for the most generic case with all bells and whistles. When we generalize this we need to support all eventualities even if turned off by default. Note that some things could be done in tooltips, see below "about tooltips and statusbar", the above fader is just an early proposal/brainstorm --- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' ++ + +** I agree, the defaults should be reasonable set per-item, that will be that the meter is in most cases off and the spinner will be off on many cases too. I tried to show whats needed for the most generic case with all bells and whistles. When we generalize this we need to support all eventualities even if turned off by default. Note that some things could be done in tooltips, see below "about tooltips and statusbar", the above fader is just an early proposal/brainstorm ++ +-- +ct:: '2008-07-23T09:41:25Z' +-- -- * Magnifying Glass for the Faders + Faders should have a "magnifying glass" mode, which can be activated by a key combination or modifier key. When activated, you can fine tune the current value: The step increment is lowered ideally to the real limit of the underlaying parameter, or, if this is too much, at least it should be much smaller than anything you get by dividing the possible value range by the fader length in screen pixels. In this mode, the fader doesn't cover the whole range, rather it is centered at the current value. Changing the value by these small increments should give an obvious visible feedback. Ideally, an accompanying automation curve display will switch to the extreme vertical zoom as well. And it's important that you don't have to zoom, you enter/leave with one keypress. + Partially, this is covered by the Adaptive Mouse Wheel too; but, especially when working with sound, the problem is that the parameter range cover several orders of magnitude. For example, even 16bit PCM sound has a volume parameter which can be adjusted in 32768 steps, and yes, there are situations when these fine steps make an audible difference, while most software faders give you not much more then a view hundred subdivisions even under optimal circumstances. --- link:Ichthyostega[] [[DateTime(2008-02-07T22:34:08Z)]] - - - Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below). --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] - - - This concept of "magnifying faders", is well explained in http://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation. --- link:oracle2025[] [[DateTime(2008-02-08T00:40:05Z)]] - - - Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +Ichthyostega:: '2008-02-07T22:34:08Z' +-- +** Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below). ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- ++ +*** This concept of "magnifying faders", is well explained in https://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation. ++ +-- +oracle2025:: '2008-02-08T00:40:05Z' +-- ++ +**** Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- Scripting ^^^^^^^^^ * Usability (ease of use) - mouse clicks and motions, inputs decisions, etc required to achieve tasks. Macros are really handy for allowing the user to speed up repetitive tasks that the program designers have not anticipated and made easy to do from the outset. Macros can be shared on a central web site. Plus developers can look and see what the macros are being used for, as this gives a very important indication of where vital tasks are. --- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]] ++ +-- +Tree:: '2008-05-07T16:44:00NZ' +-- - Comment: We need to have some discussion about scripting. To do macro scripting we'll need to implement a DOM interfaces etc. into 2 or even all 3 layers of the system. If we want to do this, then we'll need to begin planning for it early. We have talked already about making scripting the movie itself AviSynth style. Both are worth talking about. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:58:22Z)]] + - - See also rcbarnes compound filters proposal. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:25:57Z)]] +-- +JoelHoldsworth:: '2008-07-22T21:58:22Z' +-- + + ** See also rcbarnes compound filters proposal. ++ +-- +JoelHoldsworth:: '2008-07-24T16:25:57Z' +-- Others @@ -247,10 +329,14 @@ Others * Time estimates for lengthy Tasks before committing to the action. + Handy to have time estimates for lengthy task indicated even before committing to the task. Also an estimate for the % increase or reduction in time of adjusting parameters. So you can make a good tradeoff between the result and and the time taken to get it. When a task is carried out, measurements are made to improve the accuracy of future guesses. ---link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]] ++ +Tree:: '2008-05-07T21:34:00NZ' - Comment: This would be quite a nice feature if we can do it. Though it's often hard to know how long something will take until you start doing it. For example estimating the time to render a 1000 frame animation might involve rendering the first 10 frames, then multiplying that time by 100. Problem is that could potentially be quite complex to set up - especially when we're working with render farms. The backend guys would need to think about this I think. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:24:50Z' +-- Joelholdsworth is Skeptical @@ -258,40 +344,58 @@ Joelholdsworth is Skeptical * Multi server + Display GUI components on different Xservers, some critical components (GL rendering etc) might be only supported on local displays --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: This doesn't seem like a very common use case. I can't see any immediate advantage in doing this, and I'm struggling to think of a scenario where this would be helpful. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* Having more than one workstation each driving a display on its own, getting more bang. But I agree this is not a important feature and rather a corner case. --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' ++ + +** Having more than one workstation each driving a display on its own, getting more bang. But I agree this is not a important feature and rather a corner case. ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- * 3x3 Menus + Have a mostly quadratic 3x3 dialpad like popup menu poping up so that the center is the mouse position (adjusted when near screen corners). The middle field is always the close/cancel functionality and the 8 fields around offer the menu entries. Navigation can be done by mouse, cursor keys or numpad! Menu entries can open 3x3 submenus again, either incremental so that closing brings you up to the higher menu or exclusive that closing aborts the whole menu. --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: Cehteh really want this feature. Personally I'm skeptical. It seems clumsy and non-standard to me, and not good in terms of command discoverability, so I don't want to implement it. But then he does seem to want it pretty badly, so I'm a bit cautious about putting it straight in the "Won't Implement" category. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* not only me, but ichthyo and simav too and anyone i talked with liked this idea but you --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' ++ + +** not only me, but ichthyo and simav too and anyone i talked with liked this idea but you ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- -* User Precautions get built out of user interface and into program.+ +* User Precautions get built out of user interface and into program. ++ When attaching such and such effect to a track, disable "play" before attaching it, then re-enable play aft attaching it. (we don't tell you this before hand, and we never will, unless you ask the question and search the net, then you might find out in the "secrets manual", And you'll have to remember this (always)!! If there are circumstances that apply to an effect (or for that matter any other part of the program), then the feature could have a flag in it that warns the system to take note of it, and it then reports what its requirement or tweak feature is, so the system can automatically handle it the best way. (A sort of OO process handler). This not only saves potential lengthy wastes of time, but saves concentration on sideline issues, speeds up work, adds to reliability and good time user experience. ---link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]] ++ +Tree:: '2008-05-07T21:34:00NZ' - Comment: I'm not sure I quite understand what this is about. Your explanation is a bit hard to read. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]] + -- -* I wouldn't even be skeptical, I am against such a proposal. Any feature we add should just work, without crashing the application and trashing the users efforts. If a feature doesn't work, it needs to be fixed, instead of automatically warning the user that this feature is broken. The fact that for Cinelerra you need the "secrets" tells quite a lot about the state of affairs regarding Cinelerra, and because we wanted to change this, Lumiera was born. ;-) --- link:Ichthyostega[] [[DateTime(2008-07-27T23:04:42Z)]] --- +JoelHoldsworth:: '2008-07-24T16:24:50Z' ++ + ** I wouldn't even be skeptical, I am against such a proposal. Any feature we add should just work, without crashing the application and trashing the users efforts. If a feature doesn't work, it needs to be fixed, instead of automatically warning the user that this feature is broken. The fact that for Cinelerra you need the "secrets" tells quite a lot about the state of affairs regarding Cinelerra, and because we wanted to change this, Lumiera was born. ;-) ++ +-- +Ichthyostega:: '2008-07-27T23:04:42Z' +-- +-- May Implement Some Day ~~~~~~~~~~~~~~~~~~~~~~ @@ -299,14 +403,19 @@ May Implement Some Day * Widget overlay/Fullscreen + Some Widgets can be made half transparent and overlay video giving a head up display editing while the video is at native resolution in background. Window configurations can be stored/restored in customizable presets and are part of the project (see blender again) --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: This is difficult to do. XVideo and Gtk don't really mix. But I can't think of any controls that need to be overlaid. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* Would be nice but not a primary feature. I'd rather think about some some special on-screen-menu overlay, not necessary gtk (libosd?) maybe this can be implemented with OpenGL overlay or so. As noted before, having a monitor which runs on the native Video resolution is a requirement. Giving this Monitor some (limited) GUI features, like mask editing or other simple manipulations gains extra points. Not a primary/important feature but I'd rather like it seen as "Will implement _someday_" The window configuration customization should be its own point, I think thats easy with GTK (Gimp does that) adding a small Configuration management GUI shouldn't be hard. --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' + + * Would be nice but not a primary feature. I'd rather think about some some special on-screen-menu overlay, not necessary gtk (libosd?) maybe this can be implemented with OpenGL overlay or so. As noted before, having a monitor which runs on the native Video resolution is a requirement. Giving this Monitor some (limited) GUI features, like mask editing or other simple manipulations gains extra points. Not a primary/important feature but I'd rather like it seen as "Will implement _someday_" The window configuration customization should be its own point, I think thats easy with GTK (Gimp does that) adding a small Configuration management GUI shouldn't be hard. ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt index 8a3f92e15..7db552ef7 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt @@ -7,14 +7,24 @@ GuiBrainstorming Reviewed - Won't Implement Sometimes help files and tutorials are improvable. Keeping track of which help is to which amount useful for a majority of users will provide data about which help files are improvable. It will also provide data about which features most often users use help and might be candidate for usability consideration. like: []solved my problem []got me on the right way []needed to find help elsewhere []problem not solved - This is surprisingly hard to implement (I think), and in a sense it's already obvious to us whether the docs are quality - filled with nice graphics, simple steps, and lots of clear information or whether they need improvement. This feature might have some use on the website. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:47:35Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:47:35Z' +-- * Suggest an improvement Feature - for users to help improvement + -Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. Or get sent to a link:BrainStorming[] page like this one (specifically for the panel they were in). --- link:Tree[][[DateTime(2008-05-26T12:01:00NZ)]] +Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. +Or get sent to a ``BrainStorming'' page like this one (but marked specifically for the panel they were in). ++ +-- +Tree:: '2008-05-26T12:01:00NZ' +-- - This isn't really a GUI issue - much of this is more for the website, which the GUI will probably link to from an item in the help menu. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:45:00Z' +-- * Help System - rolling tips and tutorials + Sometimes, when a beginner is using the program, they just sit back and look at the general picture. It's a behaviour that gets down naturally. It looks like a "break", but going through their minds are questions like ; "Am I doing this efficiently?", "What would make this easier, and is there already an easy way to do it in the program?", "How long do I think this will take, and what can I do to make it in time?", and much more. Sit back, look at the whole screen, maybe cruise around the menu, conceptualise the project and steps involved - it's a kind of task oriented learning - on the job (self) training. @@ -26,66 +36,117 @@ Because of the creative effort needed when composing video projects, there is qu If it was context sensitive, then it would provide relevant information, similar to having a tutor or an expert leaning over your shoulder, explaining further possibilities and applications. + Video tips and Tutorials could be available via Youtube, which also doubles as promotion for the project. Users could choose to download groups of videos on selected topics. --- link:Tree[][[DateTime(2008-06-11T17:04:00NZ)]] ++ +-- +Tree:: '2008-06-11T17:04:00NZ' +-- - If the user stops to thing I think we should give them some peace while they get their thoughts together. I'm sure if they want help they'll ask for it. Remember how annoying Clippy was in MS Office? :-P --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:45:00Z' +-- * Help and visual prompts use GIFs for visual cue as to time behaviour of feature. + Icons are handy when they portray some sort of cue for the task that they do. A number of tasks in video editing are time related. It would be handy to have some form of visual que as to what the time related task does. Since Gifs can show motion, they would be very good for this task. PNGs could also do it it they were timed to cycle through their images. Example uses would be to show the difference between "track" and "stabilise" in motion tracker - a strip showing a pogo stick going along a footpath would be suitable to show the differences between track and stabilise (and could also be used to show the differences between the forms of vector calculation. GIFs could also be used to show editing functions that involve several important steps. ---link:Tree[][[DateTime(2008-05-26T08:45:00NZ)]] ++ +-- +Tree:: '2008-05-26T08:45:00NZ' +-- - If we did want animated icons we'd be better off with MNG or a PNG image strip because then we'd get transparency. There are 2 reasons why I think this is a bad idea. 1. There's an aweful lot of drawing to be done. We already need to produce perhaps 100 high quality tango style icons for the user interface. If they're animate someone would have to draw 1000s of these, with all the quality control problems that go with it. 2. I'm not sure it's something people will find very helpful. Even if the animation only begins when we hover over the icon, it could even be quite annoying and distracting. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:39:36Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:39:36Z' +-- * Help System - available for user improvement + _Similar to tool tip and status bar suggestion above._ A *"hover" hint / help* facility would be a major bonus. Just make the function available, the box can start with an index number, and users can type in their own help comments (either in a *help text entry management* section, or directly into the pop-up hover box - in optional help edit mode). + These can be pooled at a central web site in to languages, and brevity/completeness (options to links to further help, links to examples, links to video tutorials). So the developers do not have to spend time writing help files - just make it possible for the users to. The developers might like to add a few comments to the verbose files at some later point, or clear up inaccuracies. translators can also do the work for other languages. Very quickly the supporting documentation's usefulness would add to the attractiveness of the program. --- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]] ++ +-- +Tree:: '2008-05-07T16:44:00NZ' +-- - A wiki style approach is often an effective way to get community input on documentation. This may be a good way to get people working on it. But it's best for us to publish a tidied up documentation set and ship that, instead of creating a complex editable help system - which is vulnerable to vandalism. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:29:25Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:29:25Z' +-- * User selectable Experience Level - Task Oriented Layout + The user could be asked to choose their experience level, and more complex options then get greyed out. The user could be asked the common tasks that the want to do, and other options could be greyed out. They can choose whether they want "grayed" out options to be available, or viewable, or not. The options which are advanced (or 2 levels greater than their current expertise level) could be "dark grayed" out and the user could have similar choices about their display). ---link:Tree[][[DateTime(2008-05-09T20:50:00NZ)]] ++ +-- +Tree:: '2008-05-09T20:50:00NZ' +-- - Comments: I can't see any good reason for this. The user interface ought to be usable for everyone. The problem is that we want to enable everyone to be an "expert" by making power intuitively available even to beginners. The other problems is that light users might use only 10% of the functionality - but different light users use a different 10% from each other. So hiding things doesn't actually help make things simpler. It's much better to have things tidily arranged with clear descriptions etc. to help the user understand what a command might do - rather than hiding the command from them. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T22:25:58Z)]] ++ +-- +JoelHoldsworth:: '2008-07-22T22:25:58Z' +-- * SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compisitor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency bluring and the ability to interpolate these events over time...things that can be incorperated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better. --- jb [[DateTime(2008-07-21T21:58:48Z)]] +-- jb '2008-07-21T21:58:48Z' - Comment: I am hoping that we can implement a simple set of skins for Lumiera. But we will be using the GTK based styles system, which is the standard. This allows theming to be done with a simple script file. These styles files are the more natural choice for UI theming, because WebKit is designed primarily for web, and would add a lot of unnecessary bloat to the app. Icons will be drawn as SVGs; a good choice for drawing the graphics, but these will be prerendered into PNGs at compile time as is standard practice for most free-desktop apps. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Client / Server Model + The server process will act as the master coordinator for the system, and will accept input from multiple GUI clients, and dictate tasks to multiple slave processes (even on separate physical servers). The GUI client application could be multi-platform. File transfer and communication could take place over SSH and make use of SVN for project management. Proxy editing will be the norm, due to the higher resolutions of final videos (the RED Epic will handle 5K). The entire system could easily work on a single Linux workstation, for easy adaptibility from handling home videos to expand to editing cinema films (which could benefit from dedicated GUIs to handle video, sound, etc.). - Comment: Because the different parts of a project are so tightly integrated, it won't be possible to have one instance of the GUI that only has audio, and another that only does video etc. Moreover, the controller PC will hold the source video data. It is true that we plan to make a distributed backend, but the core and GUI layers will remain on the controller PC. It's very hard to make a distributed GUI, and even harder to make lumiera have both a distributed front and backend. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Navigation Systems + There may be several methods to make menu selections, and other choices. The Gui could be made quite adaptable/customisable. Using a "skin" approach to the Gui, would provide a system for users who are not programmers, to help develop improved user interfaces. Mouse "gestures" (may be patent considerations) are another option. The way that options are communicated with the program functions could be made so that even as yet undesigned "user chooser systems" can be added. --- link:Tree[] [[DateTime(2008-05-14T08:40:00NZ)]] - - - Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone! --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile. --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +Tree:: '2008-05-14T08:40:00NZ' -- +** Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone! ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- + + +*** I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile. ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- + + * Burst frames to graphics card. + I am not sure how the current video play system works, but speed might be increased if several frames got sent to the video card at once. The video card can act as a video cache and play them as required. The number of interrupts to the process is reduced, to much less than one per frame, freeing up more CPU time for calculating the effects etc.. ---link:Tree[][[DateTime(2008-07-18T18:18:00NZ)]]. ++ +-- +Tree:: '2008-07-18T18:18:00NZ' +-- - Comment: Good idea, but not really necessarily. Firstly because XVideo is pretty fast, and the bottle neck is in rendering not drawing. Second, we can't get direct access to video RAM anyway because X abstracts it away. --- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]] ++ +-- +joelholdsworth:: '2008-07-19T19:42:04Z' +-- -* GUI development - flexible approach - using "Skin Methods" + +* GUI development ++ +-- + - flexible approach + - using "Skin Methods" +-- ++ In developing a GUI, the approach would normally be for the developers to design the Gui as the project progresses, and it comes out at the end. This is not bad, especially as there is a GUI to be had. But if there is a desire (which there appears to be a healthy desire here) to try new things, and look at options, then it would be quite useful to have a development method that allows for experimentation with options, side by side comparisons and assessments. Assessments by users and developers. + GUI design could be available for release for whoever wants to do a spin-off project re-GUI. So a GUI gets made by default by the development team, but the _skin kit_, and _methods of activating/interaction with the "engine"_ are made available. Users can then run their own tests and some sort of concensus arrived at later as to what is considered to work well, in what sorts of different user situations (newbie, small, large/expert). @@ -93,10 +154,16 @@ GUI design could be available for release for whoever wants to do a spin-off pro If there is vibrant enthusiasm for teams to work on alternative GUIs, then the developers may even avoid the need to do much of the work on GUI, and just announce what the interface requirements are - the (choices of) GUIs for some sections could be ready before the program is finished. The GUIs could be developed and discussed concurrently (or advance of) the respective program code. On the other hand the GUIs could lag behind the developemnt of the engine, but not hold the engine up. Some GUI groups could be ahead of others in some parts of the program and behind in others - the user could even choose to the GUI (widget appearance) from one theme for one part of the interface, and GUI from another theme for other parts. + There could be agreement between GUI teams working on different themes, to cover separate parts of the interface first, so that there is at least some type of theme for the GUI for the whole program ASAP. ---link:Tree[] [[DateTime(2008-06-05T20:33:00NZ)]] ++ +-- +Tree:: '2008-06-05T20:33:00NZ' +-- - Comment: To achieve that sort of thing one would normally expect the project to be forked. If our architecture is any good (and I think it will be), then a Lumiera fork would have no problem attaching a different UI to the system because there will be clear separation between the layers. But I can't see any good reason to help people fragment the project. If there are problems with the standard UI then we should fix them for everyone. If people want to write code for better UI they should contribute it patches. We really don't want to encourage people to fork any part of Lumiera. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:56:07Z)]] ++ +-- +JoelHoldsworth:: '2008-07-22T20:56:07Z' +-- * About Tooltips and Statusbar + Tooltips are really valuable items, they should not be wasted for simple things like brief help texts. Instead they might display the actual state of the underlying widget in a textual form (numeric+unit) with _maybe_ some hints. Long time ago I proposed for Cinelerra to add a special mode to make tooltips editable, that is with a shortcut the actual tooltip becomes a small text input field where the user can enter exact values for some things, this value is committed with the return key and leaving this mode should be really easy (as simple as just moving the mouse, ESC key). @@ -104,17 +171,26 @@ Tooltips are really valuable items, they should not be wasted for simple things The Status bar can show more information but isn't directly in the users view, here we may play help infos like available options on the mouse buttons, important keyboard shortcuts etc. take a look at \'qcad' .. xfig has also static area where it shows available (mouse) options, just not a status bar but in the upper right of the screen. + This might be a bit different to some common other user interfaces (M$...) but I think this is much more valuable. --- link:ct[] [[DateTime(2008-04-08T01:26:06Z)]] - - - Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:42:32Z)]] + -- -* My argument is, that the \'figure out' thing could be done in the status bar, thats slightly less convinient but a user who searches for help will discover it (xfig, qcad and other programs do such kinds of dedicated help places instead tooltips). Popping up Tooltips only help _very_ early beginners, for someone who is even marginally used to the programm they don't add any value anymore, yet to be at a very prominent screenspace, right at your cursor. I think thats really a waste. I want interactive tips and help, but please where they are disciverable for help, but don't waste screen estate with information one might not really need. In contrast, the numeric value of a fader is a very important thing to know, at least when you want to alter it (cinelerra does that with its round knobs). And having a direct enter mode would be even more powerful for experienced users while not disturb anyone else. This might only complement the 'generalized fader' fader above, means when the fader is configured to show only a small scroller entry (to safe screen space) then displaying the numeric value and/or offer to edit it in a tooltip would be a good way to make it precise, without needing to reconfigure the fader, taking more screen space. --- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]] +ct:: '2008-04-08T01:26:06Z' -- -* Default settings after install set to most reliable and least requirements + +** Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change. ++ +-- +JoelHoldsworth:: '2008-07-22T21:42:32Z' +-- + +*** My argument is, that the ``figure out'' thing could be done in the status bar, thats slightly less convinient but a user who searches for help will discover it (xfig, qcad and other programs do such kinds of dedicated help places instead tooltips). Popping up Tooltips only help _very_ early beginners, for someone who is even marginally used to the programm they don't add any value anymore, yet to be at a very prominent screenspace, right at your cursor. I think thats really a waste. I want interactive tips and help, but please where they are disciverable for help, but don't waste screen estate with information one might not really need. In contrast, the numeric value of a fader is a very important thing to know, at least when you want to alter it (cinelerra does that with its round knobs). And having a direct enter mode would be even more powerful for experienced users while not disturb anyone else. This might only complement the 'generalized fader' fader above, means when the fader is configured to show only a small scroller entry (to safe screen space) then displaying the numeric value and/or offer to edit it in a tooltip would be a good way to make it precise, without needing to reconfigure the fader, taking more screen space. ++ +-- +ct:: '2008-07-23T09:41:25Z' +-- + + +* Default settings after install set to most reliable and least requirements ++ The program may be tweaked to get performance on PC with great graphics systems, plenty of Ram and good hard drive speed. For people with lower spec'd gear, there may be some tuning needed, just to get going. There is the likelihood that people with low spec'd gear are not so able or inclined to read up on their hardware, and "search" for help on their video editor, to find out the solution to a problem (which they may not even have much idea of what the problem is). Consequently, they are likely to give up and not use the program. + Everybody enjoys a program that can be easily installed, and is ready to run. Few are upset by a program that is easy to install, setup, and is ready to run. But quite a few have nothing but disappointment with a program that is relatively easy to install, no idea how to set up, won't run or crashes, and not much clue about where to get help which is much further away than a click. @@ -132,16 +208,28 @@ A similar colour coding for speed could be used ; blue for low speed, green for This colour coding for the two parameters (reliability and speed) means that when new driver/setup options are available that provide a speed increase, (yet are unreliable or unknown reliability at the time), the user has a very easy visual prompt to help them make decisions, and adapt their trial and error path to optimisation. + Feature to save different hardware settings, with notes in the hardware specs, and share them. Upload to Lumiera web site, so that better first guesses for new users are available. And if an intelligent system is used for hardware detection in future, then the information for best choices will already be available. --- link:Tree[] [[DateTime(2008-05-28T09:41:00NZ)]] ++ +-- +Tree:: '2008-05-28T09:41:00NZ' +-- - Comment: The problem is that unlike games, in movie editors there isn't very much that can be done in the way of tweaking. With video editing, by and large there are no shortcuts. So the calculations that must take place to render a video on a Quad Core workstation are the same as the ones that need to happen on an EeePC. Lumiera needs to be intelligent about how much RAM it uses etc. but that sort of thing ought to be automatic. The only thing that this could apply to is reduced quality previews, which I've put in the blueprint list. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:34:20Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:34:20Z' +-- * Menu Bar disconnectable from track view + The menu bar could be made disconnected from the track view. This would allow the track view to be covered by a window, but the menu still kept on top. The menu bar could by default start at the top left and run across the screen. It could remain on top view. It could include easy single click tabs to jump from one window view to another. + The menu items that are specific to track view could be separated out and left as dedicated menu attached to the top of the track view. --- link:Tree[][[DateTime(2008-05-07T21:06:00NZ)]] ++ +-- +Tree:: '2008-05-07T21:06:00NZ' +-- - Comment: Actually if you look at the state-of-ui you can see that the menu bar will be shown at the top of workspace. We might make it detachable, but actually it's not very useful to be able to attach the menu bar to the sides or bottoms of windows. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:47:08Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:47:08Z' +-- diff --git a/doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt b/doc/design/gui/GuiDiscussion/PieMenu.txt similarity index 80% rename from doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt rename to doc/design/gui/GuiDiscussion/PieMenu.txt index 16ddfa042..01b88b116 100644 --- a/doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt +++ b/doc/design/gui/GuiDiscussion/PieMenu.txt @@ -4,7 +4,7 @@ Menu and Shortcuts :Date: 2008-05-14 -link:Lumiera/GuiBrainstorming/MenuAndShortcuts[] should explain most heavily discussed GUI features being related to Lumiera's GUI. +This pace is a place where to discuss some of the more controversial GUI features proposed for Lumiera's GUI. 3x3 Menus, Version 1 diff --git a/doc/design/gui/GuiDiscussion/scrolling.txt b/doc/design/gui/GuiDiscussion/Scrolling.txt similarity index 100% rename from doc/design/gui/GuiDiscussion/scrolling.txt rename to doc/design/gui/GuiDiscussion/Scrolling.txt diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/Timeline.txt similarity index 95% rename from doc/design/gui/GuiDiscussion/TimelineDiscussion.txt rename to doc/design/gui/GuiDiscussion/Timeline.txt index 7a5d8ecd8..b0ad5835f 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/Timeline.txt @@ -1,15 +1,19 @@ -Timeline: Discussion -==================== +Timeline: Extended Discussion +============================= :Author: Joel Holdsworth :Date: Fall 2008 -This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome. +This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming +to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. +Comments are welcome. * Avid vs FCP 2006 - http://www.fini.tv/articles/avidfcp2006.html[] + Archived 2008 from https://web.archive.org/web/20071211184722/http://www.fini.tv/articles/avidfcp2006.html[fini.tv] * Final Cut Pro 5 - A First Look - http://www.kenstone.net/fcp_homepage/fcp_5_new_martin.html[] - * SpeedEdit Tutorials - http://www.newtek.com/speededit/tutorials/index.php[] + * SpeedEdit Tutorials + + 'http://www.newtek.com/speededit/tutorials/index.php' ~[red]#dead link#~ Brainstorming @@ -126,7 +130,7 @@ Joel Conclusions: Timeline like this: -image::http://www.kenstone6.net/fcp_homepage/images_fcp_5_new_martin/07_fc_studio_new_martin.jpg[] +image::{imgg}/Joel-Conclusions-UI-layout.jpg[Conclusions for the UI layout] Tracks '''''''''' @@ -220,14 +224,14 @@ Christian asked "why then not also controlling plugin parameters by placement?". I must admit, both of you have a point. Christians proposal goes even beyond what I proposed. It is completely straight forward when considered structurally, but it is also clearly beyond the meaning of the term/idea/concept "placement". -But what, if we re-adjust the concepts and think in terms of ''Advice'' ? +But what, if we re-adjust the concepts and think in terms of _Advice_ ? Thus, a placement would bind an media object into the session/sequence and also attach additional advice? As an example, to apply this re-adjusted Idea to the gain control: When a track group head has an gain/fade control this would just denote an advice to set the -gain. It does ''not'' mean that signal data has to flow "through" this -track/track group, it does ''not'' mean the gain is actually applied at this -point and it does ''not'' mean that any routing decision is tied to this gain. +gain. It does _not_ mean that signal data has to flow "through" this +track/track group, it does _not_ mean the gain is actually applied at this +point and it does _not_ mean that any routing decision is tied to this gain. Even signal chains being routed to quite different master busses can receive this advice, given the source clips are placed within the scope of this track group. The only difference needed on the GUI to implement this approach would be @@ -292,7 +296,7 @@ otherwise just normal effects in a master sequence)? Regarding effects, I should point out that in our concept, mask, "camera" and "projector" (Cinelerra's terms) are just some specific effects. Given that, it -is clear that effects need to be applicable ''both'' pre transition and post +is clear that effects need to be applicable _both_ pre transition and post transition. But the following limitation seems reasonable to me and seems to match the actual use: @@ -312,14 +316,14 @@ Btw. I very much agree with you that putting clips on group head tracks would be rather confusing, while I think placing an effect at a group head track is OK and feels natural. It will just be applied post-transition to all media within the covered range. And, note again the power of the placement+advice concept: -this does ''not'' mean the data need to be merged together and piped through the +this does _not_ mean the data need to be merged together and piped through the effect at this point. Rather, it means that each signal processing chain in the covered range will get an instance of this plugin wired in at a position equivalent to the place the effect is found on the group track with respect to the track hierarchy. I.e. after wiring in the transition(s), instances for effects placed at tracks are wired in order and ascending the track tree, and finally the connection will be made to the mixing step or output destination -according to the output advice found for ''this individual'' object (but in most +according to the output advice found for _this individual_ object (but in most cases this output destination advice will be inherited from the context, i.e. some root track) diff --git a/doc/design/gui/GuiDiscussion/Workspaces.txt b/doc/design/gui/GuiDiscussion/Workspaces.txt index 3e42239f0..e11b303bd 100644 --- a/doc/design/gui/GuiDiscussion/Workspaces.txt +++ b/doc/design/gui/GuiDiscussion/Workspaces.txt @@ -7,7 +7,7 @@ Workspaces After some debate on IRC last night, it emerged that there are some differing ideas about how projects, sessions, panels and main-windows should work together, and it seems that there are different paradigms for workspaces. -I have my personal preferences, but my thinking is definitely incomplete - I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences. +I have my personal preferences, but my thinking is definitely incomplete -- I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences. Paradigm 1: Super-IDE Style @@ -18,7 +18,7 @@ The end result would be like getting multiple Xnests of Ion, and bear some simil This would make sense if the normal workflow would involves many projects, and a lot of inter-project work. -There are some plusses: +There are some pluses: * It's very orthogonal, and it lets the user configure their window layout to be exactly what they want. Lots of flexibility. @@ -48,7 +48,7 @@ joelholdsworths's Conclusion ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I favour this paradigm #2. The freedom from paradigm #1 enables some extra possibilities for window arrangement, but at the cost of a lot of extra complexity, and at the cost of allowing some pretty ugly configurations that both the programmer and the user would rather not have to think about. It seems to me that if you're doing a lot of inter-project work, you can drag windows into a formation - that's pretty normal for this rare case. -I wonder what the proffessional video editors think. Please leave comments. +I wonder what the professional video editors think. Please leave comments. @@ -57,48 +57,64 @@ Comments -------- Basically I agree/you convinced me with #2, Initially I was more after #1 but you pointed out some problems. But still -I would like to make some execptions from the rule, because I see viable use-cases. +I would like to make some exceptions from the rule, because I see viable use-cases. As you suggest, a window is related to a project, I would like to have a \'import' feature there where one can include/dock a component from another project. This then becomes a \'real' import which means the first project notes "display the timeline of project 2 in my window". This gives clean semantics for working with projects and windows and gives a clean abstraction of an \'import' we can even store in the session down. This imported components are then not -part of project 2's session. Usecases are side by side comparsion and work on 2 or more pojects, arrange timelines for -easier drag and drop operations, make this config a project setting (you dont have to open all dependent projects and +part of project 2's session. Use-cases are side by side comparison and work on 2 or more projects, arrange timelines for +easier drag and drop operations, make this config a project setting (you don't have to open all dependent projects and arrange a multitude of windows). Prolly the same (to a lesser extent) counts for importing the \'resources' of another project (hey have you thought about some collection of boilerplace footage, logos, intro sequence etc as clips stored -in a site-wide project withot timeline, but then you have all your production companies \'default' resources at +in a site-wide project without timeline, but then you have all your production companies \'default' resources at hand?). Next sharing viewers in one window, possible fullscreen on a 2nd monitor then you can have a 2x2 tiling or such for all kinds of previews, even external projects. + --- link:ct[] [[DateTime(2009-01-29T03:03:22Z)]] + +ct:: '2009-01-29T03:03:22Z' - Agreed. A nice "include" feature, so one project could refer to another would cover most of what you could imagine to do with multiple projects + --- link:Ichthyostega[] [[DateTime(2009-01-29T03:36:08Z)]] ++ +Ichthyostega:: '2009-01-29T03:36:08Z' Ah just to have it noted, I told that often on irc: Dock windows shall not be a second class citizen. You mentioned that you want one able to open more windows for a project, undocking a pane shall just do that too. All windows can then be treated equal, can have a (toggleable) menu, toolbar and statusbar etc. Especially when working with big and/or multiple monitors it becomes really ugly when you have to move the mouse over your whole desktop setup just to reach a menu entry. (same for looking around to check information on the status bar, which shall represent the status -of the window which has focus anyways). And last but not least, the current GDL docks implement thir own drag handles, +of the window which has focus anyways). And last but not least, the current GDL docks implement their own drag handles, moving windows around has a big performance problem with some window managers, moving windows shall be the job of the window manager and not the job of the application, the only thing the application may do is hinting positions to the -WM. These second class dock windows are neither ICCCM conforming (http://tronche.com/gui/x/icccm/[]) nor do they add any +WM. These second class dock windows are neither https://tronche.com/gui/x/icccm/[ICCCM] conforming nor do they add any extra user experience, instead the user has to learn a new kind of window class. + --- link:ct[] [[DateTime(2009-01-29T03:15:03Z)]] + +ct:: '2009-01-29T03:15:03Z' To chime in with the commenting... this comparison rather strengthened my preference for paradigm #2 _for our situation here._ But I think we should try to exploit some of the extended possibilities which you usually rather find in those Super-IDE type applications: -perspectives, freely configurable pannels, multiple top level windows, something like palettes or tiling. +perspectives, freely configurable panels, multiple top level windows, something like palettes or tiling. When you compare the situation when working on software with the situation when working on a feature film, it seems to me that the situation don't match up. The rationale of having multiple software projects opened is (a) "lets see how I solved the same problem 2 months ago there..." and (b) working on a larger software compound, comprised of multiple parts, which may even be deployed distributed. I think none of these applies to film editing. (Maybe the situation is a bit different for putting together a TV show) -According to my own editing experiences, both film and sound, the "bringing in media into the project"-phase makes only a very small percentage of the overall time spent with a given project. Initially, after bringing in the raw footage, for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage and maybe try out some possible cuts and combinations in a throwaway fashion, just to get a feeling about the material. Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having muliple projects opened at the same time). What follows is a long fine tuning and augmenting phase. So, for me, setting things up so I can work comfortably in a rather focussed and limited part of the application couold be more important then exploring multiple projects at the same time. + --- link:Ichthyostega[] [[DateTime(2009-01-29T03:31:54Z)]] +According to my own editing experiences, both film and sound, the ``bringing media into the project''-phase makes only a very small percentage +of the overall time spent with a given project. Initially, after bringing in the raw footage, +for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage +and maybe try out some possible cuts and combinations in a throw-away fashion, just to get a feeling about the material. +Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having +multiple projects opened at the same time). What follows is a long fine tuning and augmenting phase. +So, for me, setting things up so I can work comfortably in a rather focused and limited part of the application could be +more important then exploring multiple projects at the same time. + -Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes) must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window (with one exception, that is fatal errors which will block the application until resolved). Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to cinelerra, but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log. + --- link:ct[] [[DateTime(2009-02-01T09:40:08Z)]] +Ichthyostega:: '2009-01-29T03:31:54Z' + +Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes) +must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window +(with one exception, that is fatal errors which will block the application until resolved). +Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to Cinelerra, +but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log. + +ct:: '2009-02-01T09:40:08Z' diff --git a/doc/design/gui/GuiDiscussion/archive/rawGuiBrainstorming.moinmoin b/doc/design/gui/GuiDiscussion/archive/rawGuiBrainstorming.moinmoin index 7585e4e0e..6358af4b0 100644 --- a/doc/design/gui/GuiDiscussion/archive/rawGuiBrainstorming.moinmoin +++ b/doc/design/gui/GuiDiscussion/archive/rawGuiBrainstorming.moinmoin @@ -10,7 +10,8 @@ = State of the GUI = -attachment:Lumiera/GuiBrainstorming/screenshot090418.jpg +`attachment:Lumiera/GuiBrainstorming/screenshot090418.jpg` +img:{imgg}/screenshot2009-04.jpg[] Updated 18/04/09 @@ -204,7 +205,8 @@ Some people contributed drafts/sketches/ideas/brainstorming... * ["alcarinque"] has an idea about defining the '''gui''' in '''different modules'''.[http://telniratha.atspace.com/spec.html see here] Feedback appreciated. * Pablo Lizardo made a mockup for the timeline based in the Cinelerra UI elements.[http://farm4.static.flickr.com/3067/3003432151_e30258be3e_o.png see here] . == Toward a Concrete Sketch == -See this sketch [attachment:GtkGUI-0.1.png attachment:GtkGUI-0.1.png] +See this sketch +[attachment:GtkGUI-0.1.png]+ +image:{imgg}/lum_gui_mockup-2008.png The sketch is certainly not complete by any means - this is a v0.1. There are many Avid and Cinelerra features that ought to feature in the final product. However it shows a few ideas that I think would be good. @@ -290,7 +292,7 @@ All the controls are built around the side(s)(perimeter) of the (magnifying) vie The layout of the keys make sit very easy to move both hands up and down the keyboard, choosing more and less. In the first pass of '''''live adjustments''''', they may not give perfect results, but they certainly make it plain to the user, what it was they were wanting to do, when they return to edit the strip later (in non-linear static time mode). Other toggle/mode of use buttons can be built into the tool. Local "preview"-er can be attached and be of any size. Transition and effects selector can also be attached, if wanted in the set-up set. The user could select actions (buttons/purposes of sliders) to be included in the tool's perimeter, and save the setup (gets named - and can determine what situations it gets used as the assumed default set-up to use) for future re-use. Some attached tools like previewer and resources could be set to minimise when the mouse is moved away from the locality of the tool. -attachment:Screenshot-Cinelerra_trackview-crosshairs_widget_01.jpg +img:{imgg}/mock.Cinelerra_trackview-crosshairs_widget-tree2008-09.jpg Widgets can be'''''"connected" in their influence''''', so that adjustments made in one widget are also made (and maybe scaled) in other "connected" widgets at other locations. Edits made within widgets can be saved and re-applied at later times in other places and projects (just another way to collect input data similar to the use of "undo"/macro feature). The track/thumbnail height and width within the magnifier may be increased, and toggeld/switched between levels of magnification. @@ -1186,21 +1188,22 @@ Not only may the view layouts be customizable, but the number of times they appe All the general program '''''menu items''''''''''''''''''''''''''''' would be '''''placed''''' above the tabs bar. All the process specific menu items (including what might be specific to "some" other processes), get placed below the tab bar, in the process window. Editing widgets can be of common design in each process - e.g. track fine timeline editing, track size. Methods of retrieving nodes designs, transitions and effects. - . attachment:Screenshot-Cinelerra_nodes-view-tree-02.jpg + . img:{imgg}/mock.Cinelerra_nodes-view-tree2008-05.jpg . Notes on Node display. - * The node situation is display vertically across the tracks on the timeline in trackview. - * The node tab can be viewed in short form iconic mode, or expanded network-pipe view mode. - * The node tab can be used in an edit mode, where the tracks can be selected as input, and output, and effects are added by dragging and dropping from a master list, or local project toolbox, or (right) click and choose what to insert from a drop down list). - * The node tab is assigned a name (in the example above it is simply a Nxx number). Hovering over the tab name can show the description. The local toolbox/kit of effects is shown even when the '''''tab is displayed in short form (as in N17)''''' , and this allows easy drag and drop to insert and connect the effects. The short form display shows which effects ra ebeing used (and which of the toolbox are not), and roughly to which tracks they are being aplied. - * The '''''edit mode''''' allows an input or effects "box"/icon to be (right) clicked on to open up the parameters to be altered. There can be an option to allow the alterations to apply to only that clip, the group of clips, or update the node set to apply to the whole project whwere ever it is used, or save as a new option set. An effect (the purple one with the tick) has been selected for adjustment in N16. Nodes junctions can be re-ordered, bypassed (set to null), routes split or deleted by clicking and dragging the connection lines. - * The '''''camera and projector areas of the inputs''''' can be roughly set directly within the window of the node editor, to allow for fast general concept/sketch of the layout. But can be (right) clicked on to bring up an enlarged view for more accurate positioning (and settings) at a later stage of production. - * The '''''node settings can be managed''''' by being saved, given a name, description and metatags to assign when assigning the nodeset, so that the effects can be easily applied time and again to clips/timestrips (drag and drop, or select from menu, toolbar, toolbox, drop down list - from full main set or local project kit). - * The tab can be scrolled along the timeline, and the parameters in the node tab can be shown to vary with time. - * The node tab shows which tracks are used for input and which are used for output - there is no assumption or forcing the upper tracks to have priority the lower tracks. Each node does not have to send their output to the same output track as other nodes. - * More than one node tab can be active at any point in time. (a check would be needed that no eternal loops are created when more than one node tab is active at once). - * The same node tab could be viewed at once in several locations on the timeline, just like keyframes, so the user can immediately see how the states have changed at each of the chosen points in time time. - * The node tabs used anywhere in the project can all be created,edited, stored and managed in a view tab for nodes management, and could be quickly accessed by some tabs down the right hand side of the track view. - * The video editor has '''''similarites to an audio mixer''''' . An audio mixer has inputs on left, effects on each channel running down, buses horizontally, and outputs on right. The '''''video editor is similar but rotated sideways''''' . So inputs are on top, effects are applied to tracks or subclips at times (can either be applied to clips/sets, or time positions), output are at bottom, and so '''''nodes/busses''''' which show the path from selected inputs to outputs would sensibly be vertical (as shown above). '''''Groups''''' (as in sets of tracks that get edited, "trimmed" or "moved" as a set from time to time as desired), are also connected vertically, but are probably better placed on the left side, where Cinelerra has previously allowed manual and temporary selection of (one) group (needed to be changed every time you wanted a different combination for a group, and couldn't be saved to easily return to a previous group). ecah groups could be a horizontal tab (choose which groups to be shown as tabs), or as a single column but column title area has a drop down menu to allow user to select which group is currently active. The group management/dropdown list also has options to save, assign name, add description, delete current group, create new group. + + * The node situation is display vertically across the tracks on the timeline in trackview. + * The node tab can be viewed in short form iconic mode, or expanded network-pipe view mode. + * The node tab can be used in an edit mode, where the tracks can be selected as input, and output, and effects are added by dragging and dropping from a master list, or local project toolbox, or (right) click and choose what to insert from a drop down list). + * The node tab is assigned a name (in the example above it is simply a Nxx number). Hovering over the tab name can show the description. The local toolbox/kit of effects is shown even when the '''''tab is displayed in short form (as in N17)''''' , and this allows easy drag and drop to insert and connect the effects. The short form display shows which effects ra ebeing used (and which of the toolbox are not), and roughly to which tracks they are being aplied. + * The '''''edit mode''''' allows an input or effects "box"/icon to be (right) clicked on to open up the parameters to be altered. There can be an option to allow the alterations to apply to only that clip, the group of clips, or update the node set to apply to the whole project whwere ever it is used, or save as a new option set. An effect (the purple one with the tick) has been selected for adjustment in N16. Nodes junctions can be re-ordered, bypassed (set to null), routes split or deleted by clicking and dragging the connection lines. + * The '''''camera and projector areas of the inputs''''' can be roughly set directly within the window of the node editor, to allow for fast general concept/sketch of the layout. But can be (right) clicked on to bring up an enlarged view for more accurate positioning (and settings) at a later stage of production. + * The '''''node settings can be managed''''' by being saved, given a name, description and metatags to assign when assigning the nodeset, so that the effects can be easily applied time and again to clips/timestrips (drag and drop, or select from menu, toolbar, toolbox, drop down list - from full main set or local project kit). + * The tab can be scrolled along the timeline, and the parameters in the node tab can be shown to vary with time. + * The node tab shows which tracks are used for input and which are used for output - there is no assumption or forcing the upper tracks to have priority the lower tracks. Each node does not have to send their output to the same output track as other nodes. + * More than one node tab can be active at any point in time. (a check would be needed that no eternal loops are created when more than one node tab is active at once). + * The same node tab could be viewed at once in several locations on the timeline, just like keyframes, so the user can immediately see how the states have changed at each of the chosen points in time time. + * The node tabs used anywhere in the project can all be created,edited, stored and managed in a view tab for nodes management, and could be quickly accessed by some tabs down the right hand side of the track view. + * The video editor has '''''similarites to an audio mixer''''' . An audio mixer has inputs on left, effects on each channel running down, buses horizontally, and outputs on right. The '''''video editor is similar but rotated sideways''''' . So inputs are on top, effects are applied to tracks or subclips at times (can either be applied to clips/sets, or time positions), output are at bottom, and so '''''nodes/busses''''' which show the path from selected inputs to outputs would sensibly be vertical (as shown above). '''''Groups''''' (as in sets of tracks that get edited, "trimmed" or "moved" as a set from time to time as desired), are also connected vertically, but are probably better placed on the left side, where Cinelerra has previously allowed manual and temporary selection of (one) group (needed to be changed every time you wanted a different combination for a group, and couldn't be saved to easily return to a previous group). ecah groups could be a horizontal tab (choose which groups to be shown as tabs), or as a single column but column title area has a drop down menu to allow user to select which group is currently active. The group management/dropdown list also has options to save, assign name, add description, delete current group, create new group. -- ["Tree"][[DateTime(2008-05-07T20:54:00NZ)]] updated [[DateTime(2008-09-01T18:29:54:00NZ)]] == Transition, Levels or Effects Widget remains on top while swapping windows between track view and composer == @@ -1341,7 +1344,8 @@ The track can be played underneath the dockable cross tools, or they can be drag It might be possible to have more than one per track, so the end points of a stretch of video can be worked on, withou having to jump through several labels, or remembering where to "go to". These tools would act as a means to identify areas that are "being" worked on. Very easy for the user to "park" a task and work elsewhere, then come back. - . attachment:Screenshot-Cinelerra_trackview-crosshairs_tool-other_way-synchro_mode-undocked-tree-02.jpg +img:{imgg}/mock.Cinelerra_trackview-crosshairs_tool-tree2008-05.jpg + '''Notes on Mouse Ergonomics''' 1) In the GUI shown above, the buttons in the small camera and projector view are small. They are clickable, but fiddly. These ease of targeting them is improved, by making use of the fact that to their left are'''''"nearby regions that do not need to be active"'''''. The area used to detect the cursors vertical position, can therefore be extended well towards the left of the buttons. This allows for horizontal inaccuracy of the mouse, while concentrating on the targeting the vertical position. @@ -1842,7 +1846,7 @@ The motion tracker boxes and vectors are not colour code (or line styled) to hel == Motion Tracker - Concept for improved features and GUI == The following image is an example of how the panel)s) for the motion tracker could be improved. Note the tabs for workflow left to right. Note the order of decisions from top to bottom. 3 axis separation, reduced confusion as to what setting to use for what purpose. -attachment:motion_tracker-tree_version_03.jpg +img:{imgg}/mock.motion_tracker-tree2008-05.jpg . --["Tree"][[DateTime(2008-05-25T23:32:00NZ)]] . == Motion Tracker - alternative to manual use of "Blur" and "Histogram" effects to improve result == @@ -2028,12 +2032,13 @@ Not shown in the example; In the tab label or near the top of the tab strip, there could be some icons for easy access to tasks such as ; - 1. dump this transition from the queue. - 1. execute this transition NOW - 1. move this transition up the queue. - 1. move this transition down the queue - 1. open this transition for viewing and editing The tools, look and feel is in keeping with the rest of the program, and is very similar to the node designer, and usual transition & effects editor. -attachment:Screenshot-Cinelerra_live-capture-view-tree-01.jpg + . dump this transition from the queue. + . execute this transition NOW + . move this transition up the queue. + . move this transition down the queue + . open this transition for viewing and editing The tools, look and feel is in keeping with the rest of the program, and is very similar to the node designer, and usual transition & effects editor. ++ +img:{imgg}/mock.Cinelerra_live-capture-view-tree2008-09.jpg ''--["Tree"][[DateTime(2008-09-03T12:58:00NZ)]] .'' diff --git a/doc/design/gui/GuiDiscussion/index.txt b/doc/design/gui/GuiDiscussion/index.txt index ce300e896..f6479285b 100644 --- a/doc/design/gui/GuiDiscussion/index.txt +++ b/doc/design/gui/GuiDiscussion/index.txt @@ -1,11 +1,18 @@ GUI Design and Feature Discussion ================================= +//Menu: prepend child GuiBrainstormingWontImplement +//Menu: prepend child GuiBrainstormingReviewed //Menu: put child ConceptProposals after GuiBrainstormingWontImplement -//Menu: put child TimelineDiscussion after ConceptProposals +//Menu: put child GuiDiscussion/Timeline after ConceptProposals -In the early days of the Lumiera project, there was a lot of debate regarding -GUI concepts, -features and proposals. +In the early days of the Lumiera project, there was an extended debate regarding +GUI concepts and -features, including many proposals from the community. +Bearing in mind that we have meanwhile gained a clearer understanding what wee +need to build for the GUI, this _brainstorming phase_ is completed. + +However, a more focused discussion regarding »Workflow« +link:/x/Verweijlen.html[ensued in 2025]. GUI Brainstorming:: We got a lot of proposed cool features. In order to channel this great influx of ideas, @@ -22,13 +29,15 @@ GUI Proposals:: * link:ConceptProposals/Alcarinque.html[Alcarinque] * link:ConceptProposals/Barnes.html[Clay Barnes] * link:ConceptProposals/RichardSpindler.html[Richard Spindler] + +Feature discussion:: + Some topics spurred some heightened interest and (controversial) discussion * link:Workspaces.html[about Workspace organisation] - * link:scrolling.html[about scrolling..] - * link:MenuAndShortcuts.html[Ideas for menus and shortcuts] + * link:Scrolling.html[about scrolling..] + * link:PieMenu.html[menu / shortcuts] Timeline Discussion:: In 2008, Joel reviewed all the available proposals and distilled a more coherent vision - especially about the timeline, which certainly is at the heart of any video editor. - This page with link:TimelineDiscussion.html[Conclusions by Joel Holdsworth] is - _must read_ for anyone engaged into Lumiera GUI development. + especially about the timeline, which certainly is at the heart of any video editor. + + 💡 Note the link:Timeline.html#_joel_conclusions[Conclusions by Joel Holdsworth] as a summary. diff --git a/doc/design/gui/index.txt b/doc/design/gui/index.txt index 082c70684..eebcd27fa 100644 --- a/doc/design/gui/index.txt +++ b/doc/design/gui/index.txt @@ -1,20 +1,38 @@ Design Documents: GUI ===================== -In the early stages of the project, there was a lot of debate regarding -GUI concepts and -features and proposals. +//MENU: append child GuiDiscussion -link:GuiDiscussion/index.html[Here] is a collection of documents from these early + +In the early stages of the project, there was a lot of debate regarding +GUI concepts and -features and proposals. Extended discussions ensued on +the Mailinglist and several people provided concept drawings. + +-> link:GuiDiscussion/index.html[Here] is a collection of documents from these early discussions. +'''' + +In the current phase of the project, the UI conception focuses on a way +to build the interface in a systematic way, to support complex workflows +with low friction. The following questions need to be addressed: + +- How to use _Perspectives_, Views, Docking Panels and Layout +- how to adapt the Layout, ranging from a single Laptop screen to multiple monitors +- how to allocate and place new views and property panes intelligently +- how to allow for a coherent navigation scheme that works seamlessly + and intuitively over a mixture of several _Control Systems_.footnote:[The term »Control System« + refers to one technical realisation of an human-computer-interface, which is used coherently and + can coexist with other such interfaces + -> link:/x/InteractionControl.FoundationConcepts.html[more here]... + + The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...] +- how to build such a link:/x/InteractionControl.html[Layer of Interaction-Control] + without interfering with the evolution of the underlying UI toolkit ⚠ ... -.[red]#TODO# more contributions please... ;-) -We had several additional discussions and contributions on the mailinglist, -several people did even concept drawings. Collect these and add them here NOTE: We use the term *Workflow* in our discussions to denote the more integral concerns of how to achieve given tasks within the application in the most suitable and stringent fashion. We tend to separate those more global - considerations from the discussion of individual GUI features. - -> link:../workflow/index.html[read more here...] + considerations from the discussion of individual GUI features. + + -> link:/x/Workflow.html[more about Workflow...] diff --git a/doc/design/model/Segmentation.txt b/doc/design/model/Segmentation.txt new file mode 100644 index 000000000..dcd14e75b --- /dev/null +++ b/doc/design/model/Segmentation.txt @@ -0,0 +1,21 @@ +Segmentation of Timeline +======================== + +.A junction between the models +The term ``Segmentation of the Timeline'' describes both a data structure and a step in the +build process, which translates the structures of the *high-level-Model* into a corresponding +graph of Render Nodes. The latter is also known as the *low-level-Model* and can be seen +as a set of preconfigured render pipelines. When such a pipeline is ``pulled''. the render +computations are invoked. The _access points_ to all these pipelines are hooked into a +_backbone_ data structure, designated as the *Fixture* -- which breaks down each top-level +Timeline into a sequence of temporal segments: what differentiates these segments is the +topology of the Render Nodes in the pipeline; whenever a change in this topology is +necessary, a new segment is started. Such a change might e.g. be caused by a transition +between two clips, which has to cover a range of some frames. + +As of 2025, this part of the model is only roughly drafted, mostly using placeholder code +to achieve some level of functional integration. + +Detailed design planning and explanations can be found in the +link:/x/fwd/DevWiki.Segmentation.html[DevWiki: Segmentation]. + diff --git a/doc/design/model/index.txt b/doc/design/model/index.txt index 31dd74534..f1ba202d7 100644 --- a/doc/design/model/index.txt +++ b/doc/design/model/index.txt @@ -2,5 +2,5 @@ Design Documents: Model ======================= * two models: high-level and low-level - * RfC: link:{rfc}/../rfc/ProcHighLevelModel.html[high-level model basics] + * RfC: link:{rfc}/ProcHighLevelModel.html[high-level model basics] diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt new file mode 100644 index 000000000..1d884f7f0 --- /dev/null +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -0,0 +1,177 @@ +Meeting at FrOSCon 2025 +======================= +:Date: 2025-08-17 +:Author: Benny Lyons and Hermann Voßeler +:toc: + +Present:: +- Wouter Verwijlen +- Benny Lyons +- Hermann Voßeler + +End goal:: + To produce a design document. + +This Meeting is based on the document link:WorkflowProposals.html[»Lumiera Workflow Proposals«] by Wouter Verwijlen. +Wouter travelled to FrOSCon to meet the core team in person. This meeting discussed some central points +of the planned workflow support in the Lumiera GUI. We discussed problems, agreed on various points +and decided to produce a design document. Here we attempt to reconstruct and document the original meeting. + +Points discussed +---------------- +We agreed upon the importance of a link:WorkflowProposals.html#\_tracks_vs_trackless[magnetic timeline], +as introduced by Final Cut X. +However, our link:{rfc}/ProcPlacementMetaphor.html[Placement concept (2008)] +which predates FCPX's release,footnote:[Final Cut Pro X was +link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic +Timeline« is generally considered a novel concept introduced with this update. The initial reception +was rather controversial.] +shares similar goals but its scope is more far-reaching. We consider _Magnetic Timeline_ to be an +important advancement to legacy track oriented GUI schemes; but it is more mouse confined and does +not support several Control Systems footnote:[The term »Control System« refers to one technical +realisation of an human-computer-interface, which is used coherently and can coexist with other +such interfaces -> link:/x/InteractionControl.FoundationConcepts.html[more]. + +The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...] +on an equal footing, which is our vision. + +Modes, Tools and Views +~~~~~~~~~~~~~~~~~~~~~~ +Modes are generally frowned upon in the User Interface Design discipline. On the other hand, they enjoy +popularity in video editing applications. Tools and Views were introduced to improve the usability +of Modes. We agreed to adopt tools as the more preferable system, but only if we manage to develop +a suitable handling mechanism that can be used naturally throughout all Control Systems. + +Taking inspiration from Blender, _Hermann_ proposed a fundamental shift by extending the scope of tool usage +to the entire UI. To do this, we agreed to introduce a top-level tool to navigate throughout the UI. +_Wouter_ expressed some concerns on how effect parameters and mixer stripes could be accessed. This +remains a problem to be resolved. We agreed that this default navigation tool should map down +naturally to conventional usage of the mouse. + +We discussed that a consequence of that decision might be to introduce a special tool dedicated +to dragging and moving clips, but we were concerned that such a mode might hamper fluid working +with the UI. It seems preferable to introduce the moving of clips as a sub-mode into the +navigation tool, with the option to lock moving of clips. + +_Wouter_ introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI. +The ability of Tools to support sub-modes is a simple extension of this proposal. +With this functionality, it would then be possible to switch between trim-, roll-, slide- and slip-edit +after activating the edit tool. Similarly, the _gear switch_ as proposed in a previous online discussion +would be integrated as a sub-mode into various other modes if a user decided to manipulate any setting value. + +Internationalisation +~~~~~~~~~~~~~~~~~~~ +The language of the UI is English. This does not mean that we exclude any language +(all contributions are welcome). Certain words and terminology should never be translated, e.g., +Track, Clip, Placement, ... . We have no plans to support translations that require a re-ordering +of UI elements such as languages written right-to-left. This is due to priorities that we define. + + +Unlimited Placement Constraints +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The use of fine-grained placement constraints is plagued with overwhelming the user with +excessive relationships. This can be improved by using a small number of prototype set-ups: +magnetic, relative and music anchored. _Wouter_ points out that a similar scheme can be applied +here as with the flavours of editing: A _placement prototype_ can be pre-selected for a newly added +clip -- with the ability for adjustment through the tool palette. Moreover, we require a diagnostic +to reveal the reason why a given clip is positioned at where it is. + +.Routing +_Hermann_ explained how the routing in Render Engine is based on Placements. +All data streams are grouped according to the medium (video, audio,...) by default. +Mixing-groups can be automatically established if resources are tagged. + + +Layering order +~~~~~~~~~~~~~~ +The layering order is usually arranged according to track sequence in the UI. +To retain this configuration we would have to put some content into a track which can be +located at a distance from other related content: not an ideal situation. One way to alleviate +this problem is to allow the user to configure the layer ordering for a single track so that +all content is always fixed to be above a reference clip. While this promises to be an +interesting mechanism to improve the track sequence dilemma and provide the user a greater +track arrangement freedom, further practical tests need to be carried out to determine its +feasibility. + +Grouping Devices +~~~~~~~~~~~~~~~~ +One idea presented in _Wouter_'s document was the introduction of a light-weight grouping device. +This would solve some problems, for example, a number of objects can be collectively moved +as one unit together. _Hermann_ proposed to use placements to achieve the same effect. +It is yet to be resolved how this grouping can be visually represented. + +One important issue proposed by _Wouter_ was to use segments to arrange the narrative at the +top level. To implement this feature would require on the one hand a considerable effort +by developers, on the other hand, it does not naturally fit into the Lumiera core design +as it would be a very specific extension instead of a homogeneous building block in Lumiera. +_Hermann_ proposes to use nested sequences to implement this feature which is already been +planned for the session model. All these nested sequences will have their own track structure, +which is a tree relationship. For example, expanding one structure would not necessarily +expand neighbouring structures. Another advantage of using this mechanism is that it can +be used to construct a transition between adjacent chapters of a film while still retaining +the ability to reshuffle chapters to explore various narratives. We can thus solve two +problems with the same feature. + +_Wouter_ was concerned that it might be tedious to navigate between different chapters, +especially if it is necessary to expand or collapse these elements repeatedly. One +countermeasure to relieve constant opening and closing elements would be to expand +the elements step wise while still retaining the ability to edit the contents. +Furthermore, rendering a condensed preview of a virtual clip's internal structure +could help to avoid having to open and expand the clip in many situations. + + +Target audience +~~~~~~~~~~~~~~~ +It is important to identify our target audience to be able to frame a clear +picture of which features are more preferable to include and those features which +might be less suitable to incorporate into Lumiera. +Define such groups will allow us to fine-focus into the particular needs of these groups +and provide us with a mechanism to curtail our long feature list. Eventually we might have +a list of features ordered according to priority. + +In his link:WorkflowProposals.html[»Lumiera Workflow Proposals«], _Wouter_ +identified six groups which would most likely be attracted to Lumiera and its goals. + +- The highly specialised editor who works in an environment where different parts of the + post-production of a film are handled by different people: assistant editors, colourists, + audio engineers, etc. +- The all-round contract editor who handles all aspects of post-production +- The all-round artistic filmmaker who also edits +- The all-round social media creator who appreciates the use of visual effects, + motion graphics and sound effects. +- The free-flowing editor without a fixed idea of the edit, who prefers to explore the + footage and move things around, and who might not work in a linear fashion: + they might, for example, do a bit of colour correction to acquire a better feel for a scene + and then go back to coarse-grained editing. +- The editor who has the film already cut in their head and have a very strong sense of + what they want to do and progress through structured and precise steps towards realising their vision. + +These groupings are naturally provisional and will most likely change -- which +is very good -- as we add important features that are deemed essential but fit to +no group in our selection. + +_Benny_ proposed to order these groups according to, in our opinion, those who would be +most interested to those he would be less interested. In the following discussion, we +identified the first group (the specialised editor within an industrial work environment) +and also the social media creators to be a more challenging audience, since these require +rather specialised tools to perform their tasks. + + +Conclusions +----------- +While we reached agreement in many points, the goal is to produce a design document for +the GUI workflow. This task will require to spell out many details, thereby validating +the viability of our ideas. + +- it remains to be shown that a generic _gesture concept_ can be mapped onto different + control systems coherently +- it is not clear yet to which extent it is possible to include other UI elements like + the effect property settings into an overarching _navigation mode_ +- a scheme must be worked out which allows to add a _placement prototype_ to each clip + added to the timeline; furthermore we need to develop a representation that exposes + the detailed _placement constraints_ in an understandable way +- the proposed mechanism to control the layering order should be actually implemented + and put into practical use to determine its feasibility +- we need to consider in more detail how the proposed _light-weight grouping_ can be + represented graphically and what actual features can be attached to such a new device. +- a detailed analysis is required to establish gradual steps of expanding / collapsing, + so that the overall timeline remains balanced and excess complexity can be hidden. diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt new file mode 100644 index 000000000..cfe579ef4 --- /dev/null +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -0,0 +1,1108 @@ +Lumiera Workflow Proposals +========================== +:Author: Wouter Verwijlen +:Date: 19 August 2025 +:TOC: + +I would like to share a first version of a collection of workflow ideas for Lumiera. These ideas come +from having cut hundreds (or possibly thousands) of videos over the past 20 years as a professional +editor, working in Avid Media Composer, Adobe Premiere Pro (from before it was called "Pro"), +Lightworks and DaVinci Resolve. + +This document focuses on analysing the behaviour of Non-linear Editors (NLE's), in other words +software in which a user can edit films and videos, in order to discuss possible solutions for the +design of Lumiera. + +The main ideas behind these proposals are: + +* Editing should feel as organic as possible. An editor should perceive the NLE as an +extension of their body, where interaction with the NLE will ultimately become natural. This +does not mean that a user should immediately understand everything without there being a +certain learning curve. Some new concepts might take a while to master. + +* An editor should not be able to accidentally overwrite part of their work in the timeline when +that part is not within sight (in other words: when it's offscreen). This includes throwing +things out of sync, losing transitions, or overwriting clips. + +* Interaction with an NLE shouldn't depend on a specific device. It should be possible to +operate Lumiera with only the keyboard, only the mouse, other peripherals or a combination +of these. We can nudge people towards ways of working we think are optimal, but we +shouldn't dictate how to use this application. Many different editors work on many different +types of content, and each type of content requires different workflows, some of which we +might not even foresee. We can't make a one size fits all solution in terms of workflow, +unless we would target Lumiera at a very specific professional field (for example: only long +form films and not short social media content). But even within the same types of content +I've seen different editors using different ways of working. ++ +So if the aim for Lumiera is to be a general purpose video editing application, then we can +not force any specific way of doing things and instead we should support many different +workflows, in other words: provide a platform with possibilities for each editor to make it +their own (which will arguably be a harder goal to achieve). Instead of a ``we know what's +best for you'' approach I propose a ``smart defaults with many options for configuration'' +approach. + +* A big question is: who is »the user«? We aim to create a tool for professionals, but there are +many types of professionals working in entirely different parts of the media industry or in +other fields. In the previous paragraph it was mentioned that different types of content +require different types of workflows. How to accommodate all of these different people who +work on different things? ++ +I would like to propose a set of personas to keep in mind while designing the application. +Examples of such personas could be: ++ +** The highly specialised editor who works in an environment where different parts of the +post-production of a film are handled by different people: assistant editors, colourists, +audio engineers, etc. +** The allround contracted editor who handles all aspects of post-production +** The freelance editor who does both commissioned work and passion projects +** The allround artistic/indie filmmaker, who also edits +** The allround social media creator who values the use of visual effects, motion graphics +and sound effects. ++ +And a few subtypes: ++ +*** The free-flowing editor who doesn't have a fixed idea of how the edit should be and +instead wants to play and move things around, and who might not work in a linear +fashion: they might do a bit of colour correction to get a better sense of how a scene feels, +then go back to editing, etc. +*** The editor who has the film already cut in their head and have a very strong sense of +what they want to do and work in a very structured way towards accomplishing this +vision. ++ +Of course, there are many more types of people and many people who are a combination of +personas. These are only meant to paint the spectrum of possibilities. + +* Lumiera provides a chance to re-imagine how an NLE could work, in other words: how it +can be designed around modern ways of interacting with computers. In that sense there is +total freedom to create innovative new solutions to improve how people edit videos. On the +other hand, if we create paradigms that are too uncommon, new users might not understand +Lumiera fast enough and move on to something else. There's a balance to be found between +providing familiarity and innovation, and we need to think carefully when breaking +traditional paradigms about the reason they have existed for so long and if it's worth +breaking them. ++ +In any case, I think we should at least make an effort to study the way current NLE's work, +and while we might never know for sure what the reasoning behind their workflow designs +was, we should make an attempt to understand this reasoning. Some designs might have +come from technical limitations, and others might have had really clever thinking behind +them. Let's see what we can learn from that. + +* Ideally we should also include workflows for editors using XR headsets in combination with +controllers or even hand tracking. While I do have a headset at work that I experiment with, +we might want someone with actual XR design skills to be involved here. + +Initially I would like to focus on the most fundamental tasks that each and every editor has to deal +with while creating a video: + +1. Finding the parts you need out of a lot of source material (logging and organising footage) +2. The timeline as the editor's canvas: inserting and grouping material, arranging clips, +trimming and other timeline features +3. Finishing: audio mixing, colour correction, titles, effects, exporting +4. The broader GUI concept + +Many of the ideas presented here are not necessarily unique: a lot of these either exist in one NLE +or another, or might be more common in so-called Digital Audio Workstations (DAWs). This +document closely inspects the working of other software applications to see how we can learn from +those. + +These proposals are by no means finished or complete. They are merely meant to be the starting +point for discussion and would also require user testing. We will want to iterate over certain ideas so +that they will evolve over time, while others might be rejected completely, which is totally fine, of +course. + +The current NLE landscape +------------------------- +A few decades ago there was this idea that only a single application could be called ``the best'', in +other words: the one true NLE to rule them all. Some even went as far as calling it »the NLE wars«. +There was fierce competition between Avid Media Composer, Final Cut Pro, and Adobe Premiere +and each had its fans. Over the years this discussion faded away. Final Cut Pro was disregarded by +many after the radical rewrite that was released as Final Cut Pro X. Avid Media Composer retained +its spot as the industry standard for television and feature film, while Adobe Premiere Pro +conquered the rest of the media industry. It became clear that no single NLE would be ``the best'' for +all people and all purposes. They each had their own sets of strengths and weaknesses, and therefore +each would find its own audience. + +While NLE's evolved in the 2010's, differences between them grew. + +Media Composer and Lightworks were already very powerful NLE's, specialised in the core editing +process, mostly for longer format productions. They offered many configuration options and in turn +had a high learning curve. + +Final Cut Pro X sat on the other end of the spectrum. It had few configuration options but was easy +to learn. It became popular among a new crowd: the solo content creators. + +Then in between sat Premiere Pro, comfortably. It profited massively from being part of the +Creative Suite, later the Creative Cloud: for many media companies it was very cost effective to pay +Adobe a single sum of money (pre-Creative Cloud) and later subscription fees, and receive all the +tools they could possibly need for media creation. But also the application itself was an all-in-one +solution for all parts of post-production: it offered many tools for audio mixing, colour grading, +visual effects, etc. Sure, Media Composer and FCPX also offered tools for these jobs, but were less +developed in these areas and often required plugins to achieve many of the more advanced tasks. + +Then came along DaVinci Resolve, a colour grading application that was bought by Blackmagic +Design and transformed into another all-in-one powerhouse, which slowly started to take a seat next +to Premiere's throne. + +In the meantime the media landscape changed. NLE's became more affordable and hardware more +capable, and the result was that editing was no longer a thing only done by professionals: everybody +became an editor, and everybody could edit any moment, anywhere, on laptops, tablets or +smartphones. Social media became a huge new platform where many new makers developed their +own channels and found an audience for their videos. And so came NLE's that were focused on +social media content, most notably CapCut. It took FCP's idea of easy to learn even farther and +offered many one-click visual effects, automatic subtitles and mostly: a lot of effect presets and +assets (titles, other graphics, music) available within the application. + +Right now we are witnessing the early stages of the introduction of AI in most NLE's. This expands +the possibilities for manipulating video and audio without requiring much technical knowledge. +Voices, music, video clips and even rough cuts can be generated. Audio issues can easily be fixed, +mixing and mastering can be done automatically, tracking en keying becomes a lot easier than it +used to, to name a few things. + +And that's basically where we are now. There's not one editor to rule them all, there are many, and +they all shine in different fields or sectors. Some NLE's try to expand and cater to different crowds +(Lightworks for example, received an easier GUI and many presets and assets to attract social +media content creators), others decided to just keep on doing what they've always been good at. + +The question is: where will we position Lumiera? Due to targeting the Linux platform, it makes +most sense to try and sit in the middle of everything. If we specialise too much, the potential user +base might be too small, although in all fairness, this is an assumption not backed by any real world +data. Would there be a way to check the validity of this statement? And how should we quantify +"too small"? This is a topic that requires more discussion. + + +Chapter 1: working with source material +--------------------------------------- +This chapter will not cover every detail of the process of ingesting, project organisation and +logging. It will focus on the main strategies of how a user goes through all of their material within a +specific project in order to select the parts needed for the final edit. I will compare the ways in +which different NLE's handle this and will propose possible directions for Lumiera to support +certain workflows. + +[red]#To be written:# + +- Asset organisation: bins vs metadata-based structures (+ search bins/filters) +- Viewing footage: single clips vs source reels; continuous playback from browser +- Source monitor + program monitor vs a single monitor +- Creating selects: selects reels, subclips and keyword collections +- On markers and notes +- From selects to editing in the timeline: Timelines in the source viewer: reel to reel editing + +Chapter 2: the timeline +----------------------- +The timeline is the core of the editing application. This is the editor's canvas: the space where the +actual film or video is constructed, or rather: crafted. Therefore it is of the highest importance for +Lumiera to feature a timeline that takes the best of what current NLE's have to offer, while thinking +carefully on how we can improve upon these ways of working. There are many different aspects to +working in the timeline which I will explore in the different subsections of this chapter. + +Tracks vs trackless +~~~~~~~~~~~~~~~~~~~ +In general, we can observe two extremes when it comes to editing: + +* On the one hand, there are NLE's modelled to resemble working with analogue gear (i.e. +classic editing stations from KEM, Steenbeck, Moviola). A lot of terminology in editing +software (``bins'', ``reels'', ``cut'', ``mark in/out'', among many others) stems from the analogue +origins of editing. Lightworks is an example of this. When trimming you ``unjoin'' a cut, +make changes, and then ``join'' the cut again, as if working with analogue film that needs to be +taped together. It works best in conjunction with the Lightworks Console, a hardware device +that was designed specifically to make software editing feel as if editing analogue film. Very +hands-on, very tactile, according to editors who have worked with these consoles +(unfortunately I haven't had a chance to try this myself). ++ +Not just Lightworks, but also Avid is said to have been greatly influenced by analogue +equipment, and Adobe Premiere's predecessor ReelTime was created to work like 3/4" tape +decks. Blackmagic's Speed Editor (and corresponding Cut Page in Resolve) has also been +designed according to this principle: to make editing feel like you're operating a machine. +Pressing buttons, rotating dials. This has a great feel to it, but it's less flexible than the other +extreme: + +* Editing and trimming designed to be performed by mouse. Most NLE's added this earlier or +later during their development. Final Cut Pro was from its core designed to be used this way. +It's fast, and in combination with the clip connections and magnetic timeline, it's the least +destructive way to edit. Trimming and editing by mouse is less precise though, which is why +even FCP offers many keyboard shortcuts for precise trimming by keyboard. Using a mouse +feels slightly less tactile than using physical buttons and dials. ++ +In this same category we can also mention touch screens (as they offer similar interactions +as a mouse, with the addition of finger gestures). Editing on a smartphone or tablet, when +not using a pen, feels even further removed from giving you a physical connection between +your hands and the buttons on the screen. + +Because of its analogue roots, traditionally, NLE's have been track-based. I'd like to quote Randy +Ubillos, original creator of ReelTime and Final Cut Pro: +____ +``In a track based system the layers at the beginning, middle and end all share the exact same tracks +and you're always potentially disrupting things in other parts of the project when you make changes +in another area. One of the most common things I heard from editors was that as a project +progressed the likelihood of a change in one part of a project having an unintended effect +somewhere else in the timeline went up dramatically. Tracks implicitly put a relationship between +all of the items in that track, even though they may be actually completely unrelated.'' +____ +Source: https://www.linkedin.com/pulse/interview-randy-ubillos-developer-fcp-x-david-busse[Interview with Randy Ubillos] + +Tracks have several advantages: + +* They give us a way to organise our timeline by dedicating certain types of clips to certain +tracks. + +** For example: +*** Interview shots on V1 +*** B-roll on V2 +*** Graphics on V3 + +** Or for audio: +*** Dialog on A1 + A2 +*** Music on A3 + A4 +*** Sound effects on A5-A8 + +* They allow for track-based effects (usually only implemented on the audio side). + +* They support editing by keyboard, as you can toggle tracks on and off and bind this to keys. + +Tracks have disadvantages as well: + +* They're quite inflexible: you can't easily change their order. + +* As we saw in Randy's quote, later in the editing process, when timelines become more +complex, it's easy to mess things up. Often not all tracks are visible within the viewport and +therefore you will need to remember its state (enabled/disabled/sync locked) and contents +or else a trim operation might throw things out of sync, or you might accidentally overwrite +clips. Similar issues can happen horizontally. In Avid for example, I've seen people make an +entire row of empty cuts at the end of their timeline, simply so they can check later if +anything was accidentally thrown out of sync. Lightworks has out-of-sync indicators to +mitigate sync issues. + +* Clips that naturally belong together are separated, for example b-roll and associated sound +effects. Instead, clips that only share a shallow relation are grouped together. + +* To me, personally, track management (i.e. the enabling and disabling of tracks and/or sync +locks in order to get a certain result when performing editing operations) takes me out of +my storytelling flow. It's a necessity that doesn't directly aid in the creative process. + +Editors often proudly share screenshots of their timelines on social media, and they do look +impressive, but these are in fact pretty fragile structures. + +.One of my own timelines, which is relatively simple by comparison to those of many Hollywood movies +image::{imgg}/wouter/01-timeline.jpg[width="110%", alt="Screenshot of a timeline", link="{imgg}/wouter/01-timeline.jpg"] + +So naturally, a question would be: what will happen if we would let go of the track paradigm? This +is what Final Cut Pro has done, starting from the rewrite of Final Cut Pro X. At the time, a +disastrous marketing campaign caused many editors to leave the application, although more and +more people are starting to realise that many of its ideas were way ahead of its time. It's still the +only big NLE out there that was designed with computers in mind, and not analogue hardware. + +It's not entirely trackless, but it manages to hide the concept of tracks from the user. There are no +buttons to enable or disable tracks or other track controls, and instead, the tracks are called ``layers''. +In a nutshell, it works by having a primary storyline (in a track-based NLE this would be V1+A1) +where you build the foundation of your edit. Then the video clips you put on top and the audio clips +you put below get connected to one or more clips from the primary storyline. Move a clip on the +primary storyline, and all connected clips automatically move with it. With a modifier key you can +ignore clip connections, so that you can also easily move a primary clip elsewhere without its +connected siblings coming along. + +image::{imgg}/wouter/02-trim-magnetic-1.jpg[width="100%", alt="(before trim)"] + +.Extending one clip will automatically move all connected clips in order to keep sync +image::{imgg}/wouter/02-trim-magnetic-2.jpg[width="100%", alt="(after trim)"] + +_Sounds good._ Why not just copy this? One reason is that FCP assumes that all clips that are not on +the primary storyline should be connected to this primary storyline. This might work well for fiction +films, but not necessarily for other types of video. Earlier I mentioned an example of sound effects +that share a connection to b-roll on a higher layer. FCP won't allow you to connect them. Another +limitation of FCP is that it's primarily designed to be operated by mouse. It's not possible to use +keyboard commands to, for example, swap the position of clips (other than by cut and paste), or to +perform slip edits (the trim keys will work, but the clip needs to be selected by mouse using the +Trim tool). + +How else could we group clips together that ought to be connected? + +We could create groups that are directly editable, like so: + +.Compound clips +image::{imgg}/wouter/03-grouped-1.png[width="100%", alt="Timeline with compound clips"] + +However, there are a few problems with this: we expect rendering to happen from top to bottom, in +which case the b-roll would cover the subtitles. On top of that, it's hard to see at which points video +clips overlap. Last but not least: it looks rather unorganised. + +Can we restructure this? Perhaps like this: + +.Overlapping compound clips +image::{imgg}/wouter/03-grouped-2.png[width="100%", alt="Timeline with stacked overlapping compound clips"] + +But how exactly would a user interact with a timeline like this? I will leave the answer to that +question for an actual design document, as for now I just wanted to show the concept of grouping so +that it becomes clear that alternative ways to organise the timeline might be of great value. + +Tools + modes + views +~~~~~~~~~~~~~~~~~~~~~ +If we observe existing NLE's, we can distinguish several ways to change timeline interactions. +Some use a tool-based approach (Adobe Premiere, Final Cut Pro), others a mode-based approach +(Avid Media Composer, Lightworks and DaVinci Resolve), and we can also see a view-based +approach (FCP's use of the precision editor, explained in more detail later). Which of these +interaction methods would be preferred for Lumiera? + +* Using *modes* is somewhat controversial, as it increases cognitive load (the user needs to remember +which mode they're in) and can lead to user errors (an action in one mode might do something +different than intended in another mode). Another thing about modes is that they require a user +action for entering and exiting. +* A *tool*-based approach however, is very mouse-centred. It changes the behaviour of the mouse, not +of keyboard actions, and this change is visible in the cursor. Tools are of little use to the keyboard +editor. +* A *view*-based approach is not too different from using modes, with the difference that it drastically +alters the contents of a view or panel in the user interface. It's less common and can be seen in +FCP's precision editor. It doesn't change the working of keyboard shortcuts or the mouse and it +alters the timeline via animations in a very fluid way. + +.Final Cut Pro's precision editor +image::{imgg}/wouter/04-fcp-precision-editor.jpg[precision editor] + +Another example is the Trim View in DaVinci Resolve: whenever you perform a trimming +operation, the program monitor displays a trim view (showing the frames left and right of the cut +next to each other). As soon as you start doing something else, it exits this trim view. It needs no +dedicated user action. + +This might seem like a great approach (and can be combined with tools and/or modes), but it does +mean a user needs to reorient a bit when they exit the altered view and return to its default state. +Perhaps that's a small price to pay, when not overdone. + +When we more closely examine the behaviour of NLE's, we see that things are not as black and +white as they seem. No NLE exclusively uses one method over others. Resolve's modes do in fact +also change the mouse cursor's look and behaviour and can therefore be considered a hybrid +mode/tool system. FCP's Select and Position tools also change the behaviour of trimming keys and +can therefore indeed also be considered modes, which gives us a hybrid design as well. Specialised +views can be combined with tools or modes. + +To conclude: all methods have pros and cons. Tools, modes and views aren't mutually exclusive, so +I think we should use whichever method or combination of methods is appropriate for different +actions in Lumiera. Whenever we can, we should try to avoid all three and design the app to be as +consistent as possible. Whenever we use a mode, we should see if we can design it in a way in +which a user fluidly enters and exits this mode, without requiring extra actions: _contextual modes._ +Most mode-based NLE's already implement this for their trim mode in a way where selecting a trim +side automatically enters trim mode. However, a user does still need to explicitly exit trim mode. + +Regardless of the method, immediate visual differentiation of tools/modes/views is important and +I'd like this to extend to any timeline option that can be toggled on/off. Therefore I'd like to propose +the use of a _contextual bar_ that appears over the bottom part of the timeline whenever a contextual +mode is active. + +.Contextual bar with options for the mode/tool +image::{imgg}/wouter/05-contextual-bar.png[width="100%", alt="contextual bar"] + +Currently I'm thinking of using this bar on two or three occasions: + +1. When selecting clips. It can feature: + + * a Group Clips button + * a Cut button + * a Duplicate button + * a Nudge Left '<' button + * a Nudge Right '>' button + * a Ripple toggle + * a Snap toggle + +2. When trimming. It can feature: + + * a Trim radio button + * a Slip radio button + * a Slide radio button + * a Trim Left '<' button + * a Trim Right '>' button + * a Ripple Trim toggle + +3. When adding clips to the timeline. + + + It can feature options like Insert, Overwrite, Replace, etc. + + + -> See the next subchapter: »Adding clips to the timeline«. + +Colours could be used (for example as an outline around the bar) to indicate which contextual mode +is active. + +A limitation of such a bar is that it might overlap with content that a user wishes to interact with. If +this is the case, then clicking on the grid with dots will let a user drag this bar out of the way. As an +extra option I would like to suggest to use a modifier key (Ctrl?) which temporarily hides the +contextual bar. Another consideration could be to attach this bar to the bottom of the timeline and +combine it with the zoom and navigation sliders, although I feel a more central default position will +get things done quicker. + + +Adding clips to the timeline +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All NLE's offer multiple ways to get your material in the timeline, and those methods fall into the +following categories: + +* Drag and drop from either the project contents panel, another timeline, or directly from a file +browser +* By creating a timeline out of selected clips in a bin +* N point editing, of which the most commonly used is three point editing: you load a source +clip (or timeline) into a (source) viewer/monitor, mark an in point, out point and use one of +multiple options (by clicking their buttons, by pressing the corresponding keyboard shortcut, +or by dragging your clip from the source viewer into the program monitor onto a list of +zones), of which the most common ones are: ++ +** Insert (based on playhead position) +** Overwrite (based on playhead position) +** Place on top (based on playhead position) +** Append (added to the end of the timeline) ++ +Three point editing also works by only providing an in-point on the source clip, and marking +in and out points on the timeline. In order to choose on which tracks your clips end up, +track-based NLE's usually provide a way to route source tracks to timeline tracks via the +track header. ++ +Some NLE's support four point editing, where speed adjustments are applied to make the +selected duration in the source clip match the selected duration in the timeline. + +* Avid features a Replace Edit option: a selected clip on the timeline can be replaced by the +contents in the source browser with a single click or keystroke. + +All of these options make sense, but in general I rarely remember more than two options (insert and +overwrite) and easily forget any surplus options that NLE's offer. We should also try to limit the +amount of keyboard shortcuts that a user needs to memorise, so I would like to propose a single +``Add Clip'' action. This will insert a clip and will show the different options via the contextual bar. +You can then change the desired method after the fact, until you commit by doing something else. +In this case, adding a clip will enter and exit another contextual mode. +One last thing I would like to address is the destruction that an insert operation can cause. Usually +this can be prevented by proper track management, but you can wonder why you would ever want +an insert action to cause the following: + +image::{imgg}/wouter/06-sync-insert-1.png[height=110, alt="sync insert"] + +.Inserting a clip with sync locks enabled for V2 might split a clip in Avid Media Composer. +image::{imgg}/wouter/06-sync-insert-2.png[height=110, alt="sync insert"] + +In this case, if you'd like the clips on V2 to stay in sync, the overlapping clip will be split in two. +If you don't want this to happen you would have to move the overlapping clip to another track +temporarily, or move everything on V2 by hand with the same amount of frames as the duration of +the clips that's inserted. My point is, however, that while the behaviour above makes sense when +you strictly follow the logic of how such a timeline works, in real-life you would rarely want a clip +to be split only to keep sync. Therefore, I would like to propose insert operations to be nondestructive +by nature. Overlapping clips on other tracks or layers will simply move in its entirety. + +Another thing to consider, as I put much emphasis on grouping (or linking) clips, is that we might +want to differentiate between inserting a clip into the currently active group, or inserting it in a +newly created group. This way a clip will always end up in a group without much manual work. + + +Navigating the timeline +~~~~~~~~~~~~~~~~~~~~~~~ +Quick timeline navigation is key in editing. Let's start by examining how other NLE's deal with +this. We need to make a distinction between: + +* Moving the viewport: the visible section of the timeline. + +* Moving the playhead (which will ultimately also move the viewport, once the playhead goes +offscreen). + +Moving the viewport, by mouse: + +* This usually happens by dragging scrollbars. + +* In pretty much every application the scrollwheel can be used to scroll either horizontally or +vertically (usually a setting defines the default direction, and the other direction can be +toggled with a modifier key). + +* DaVinci Resolve allows moving the viewport by middle mouse dragging. Quite useful, +actually. + +Moving the viewport, by keyboard: + +* Some apps use Page Up/Down for this (i.e. Premiere). + +* Resolve scrolls the timeline vertically with Page Up and Down and supports shortcuts for +Previous/Next Timeline Page. + +Moving the viewport, by other device: + +* I don't recall having seen this option anywhere. + +Moving the playhead, by mouse: + +* Avid allows doing this by clicking anywhere in the timeline (as long as the smart tools are +disabled, else you need to click in empty areas). + +* FCP skims the timeline by default when moving the mouse. Clicking parks the playhead in a +new location. + +* Others require clicking in the ruler above the timeline or dragging the actual playhead. + +* The playhead will obviously also move during playback, which can be started and stopped +by clicking buttons underneath viewers or above the timeline. + +Moving the playhead, by keyboard: + +* Through playback, using j/k/l as a shuttle (repeated taps increase playback speed). + +* Most apps provide keyboard shortcuts for moving single frames left and right. + +* Most apps provide keyboard shortcuts for moving steps of multiple frames left and right (in +Premiere you can choose how large the steps are, Resolve only supports single seconds). + +* Most apps provide keyboard shortcuts for going to the previous or next cut. + +* Most apps provide keyboard shortcuts for going to the previous or next marker. + +* Most apps will use the Home and End keys to move to the start and end of the timeline. + +* Most apps provide keyboard shortcuts for going to the previous or next keyframe. + +* Most apps provide ways for typing timecodes. + +Combining mouse and keyboard: + +* Adobe Premiere and several DAWs (Ardour, Reaper) have a ``move playhead to cursor'' +feature that can be bound to a key. Very useful! Resolve has added this in version 20.1 as +well. + +Using other devices: + +* Shuttle: allows controlling playback speeds and direction depending on how far you turn the +dial left or right. + +* Jog wheel: allows stepping left or right, frame by frame. + +* Blackmagic's Speed Editor has the option to change the function of its wheel between +shuttle, jog and scroll. The shuttle mode is practically unusable, but jog and scroll provide +amazingly fluid ways to navigate the timeline. Especially in combination with markers and +jumping between these by keyboard shortcuts, this is a wonderful way to work. + +Zooming also needs to be mentioned here, because often we might be zoomed in, do some work, +zoom out to get an overview of the timeline, and zoom in to another part of the timeline. +Zooming in and out, by mouse: + +* Usually done either by using a zoom tool, + +* Or by using zoom sliders. + +Zooming in and out, by keyboard: + +* Every NLE has keys to zoom in and out horizontally. Some (Premiere, Resolve, Avid) +support keys to expand and shrink all track heights at once (vertical zooming). + + +Navigating with keyboard shortcuts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +I can imagine that all of the keyboard shortcuts for navigation were invented simply to provide +many options for each editor to choose what they need. This way, every editor can pick the +shortcuts that best fit their workflow. + +Navigation by means of keyboard has very good support in most apps and it's a matter of providing +similar shortcuts in Lumiera. It could be expanded by allowing the creation of *navigation markers* +(a special category of markers) that are bound to keys or numbers. A user can jump to specific +markers by pressing a ``go to navigation marker'' key, followed by the key they bound. This is +basically Vim's way of doing it (m+0-9a-zA-Z to bind, backtick+0-9a-zA-Z to jump). Or we might +want to keep it as simple as having the regular ``add marker'', ``add and edit marker'' and ``go to +next/previous marker'' keyboard shortcuts. + +Sections (explained xref:_organising_the_timeline_sections[later in this chapter]) +will get navigation markers automatically, so a user doesn't have to create each marker manually. +Or we might want to include keyboard shortcuts for ``go to previous/next section''. + +*Fast forward and fast rewind keys* as found in Reaper might be a helpful addition to the +aforementioned keys. This would give as a quick way to skim a timeline by keyboard. While fast +forward and rewind can be achieved by the regular j/k/l shuttle controls, this requires a lot of +tapping to get to the desired speed, over and over again. + + +About mouse navigation +~~~~~~~~~~~~~~~~~~~~~~ +Scrollbars and zoom sliders have a different set of reasons for being chosen as the de facto standard +widgets for navigation. Familiarity on the one hand, and visibility on the other. By having these +controls visible at all times, yet outside of the working area itself, each user will be able to locate +them while they remain out of the way. These are very good reasons for their existence and +positioning, but they come at the cost of speed: moving your mouse cursor out of your main +working area towards the edges and back takes time and interrupts the creative flow. It works, but +it's not ideal. That's why I would like to propose an additional way to navigate by mouse, which is +by *popup widgets*. These will pop up around the cursor, triggered by a keyboard press (similar to +how Blender uses pie menus): + +Skim widget:: by moving the mouse in a small bar we can quickly skim the entire timeline. This +will move both the viewport and playhead. Clicking the left mouse button will accept the new +position and close the widget. ++ +.Skim widget +image::{imgg}/wouter/07-1-skim.png[width="100%", alt="A skim widget rendered as overlay"] + + +Autoscroll widget:: when the user moves the mouse cursor slightly left or right, it will enter zones +in which the timeline view will scroll left or right (much like the autoscroll feature in Firefox). +When the user moves the mouse farther away from the initial starting point, the scrollspeed will +increase. This will also work vertically. The playhead will move along as well. ++ +.Autoscroll widget +image::{imgg}/wouter/07-2-autoscroll.png[width="100%", alt="A widget for auto-scrolling"] + + +Zoom widget:: moving the mouse left or right from the centre will zoom horizontally, up and +down will zoom vertically. ++ +.Zoom widget +image::{imgg}/wouter/07-3-zoom.png[width="100%", alt="An overlay widget to control zooming"] + +Mouse-only navigation: + +Combined widget:: we could make a widget that combines skimming, autoscroll (only +horizontally) and zooming (horizontally). This widget is triggered by clicking and pressing the right +mouse button. When released, it will commit to the new location/view. If a user right clicks and +immediately releases the button, a regular context menu will appear. ++ +.Combined skim, zoom and scroll widget +image::{imgg}/wouter/07-4-combined.png[width="100%", alt="Overlay widget to combin skim, zoom and autoscrol function"] + + +Why popup widgets? +^^^^^^^^^^^^^^^^^^ +I can't speak for others, but personally I dislike moving the mouse downwards towards the edge of +the screen to access scrollbars or zoom sliders. We'd like the mouse to stay in the centre of where +we're working. + +With popup widgets, we might be able to improve navigation speed, but at the cost of familiarity +and visibility. That's why I propose to include all aforementioned widgets. We keep the traditional +sliders and scrollbars, but also add the popup widgets as an extra method for navigation for whoever +is willing to learn this. + +Potential downsides +^^^^^^^^^^^^^^^^^^^ + +* Widgets might be partially displayed offscreen when the mouse is near the edge of the +screen. + +* Very long timelines might make the skimming widget oversensitive. Possible solution: +either enlarge the bar, or create zones near the edges of the bar where the behaviour changes +to be similar to the autoscroll widget. + +* When using the keyboard shortcut versions: a downside is having even more keyboard +shortcuts that need quick access from the one hand that stays on the keyboard. + + +Selecting clips +~~~~~~~~~~~~~~~ +Selecting a single clip happens in all NLE's by left mouse clicking. Selecting multiple clips happens +through box-select, by using left mouse and drag. Premiere and Resolve both offer ``Selection +follows playhead'', where the position of the playhead determines which clip gets selected. Then +there are keyboard shortcuts, to select the next or previous clip on a track. Final Cut Pro lets you +move the clip selection up and down by Cmd+up/down. + +Selecting multiple clips by keyboard has no support that I know of in any big NLE. I would suggest +to add this though, because the alternative for keyboard selection is the famous mark in/out range. +That's a pretty arbitrary way to indicate what you'd like to extract, lift or remove, and, in all +fairness, this works great as long as your timeline has few tracks. However, once you have multiple +overlapping clips on different tracks, combinations of mark/lift/extract/insert/overwrite require +careful track selection and there are serious risks of throwing tracks out of sync. It's not very +convenient either, the moment you start creating J- or L-cuts. It's a butcher's knife that pays no +respect to any kind of clip connections. + +While we should support marking in and out points (and I'd advice to copy Lightworks' _mark and +park,_ where you only need to set a single mark and the playhead becomes the second mark) simply +because most professional editors are so used to them, we should aim to include less destructive +ways of arranging clips on the timeline. The natural element in the timeline is the clip, so I would +suggest to focus on providing proper ways to select clips and edit the positions and durations of +these clips, instead of relying on in and out marks to do the job. + +I would propose to use the arrow keys for navigating clips and groups. There can be a cursor (for +example, a white dot) which we can move left, right, up, and down by using the arrow keys. +Changing the cursor from clip to clip will also move the playhead to the start of the highlighted clip +- but this is secondary. A clip-based focus instead of playhead/cut-based focus will be different from +what any other NLE does at the moment, but enabling multi-clip selection by keyboard will be a +good reason to go in this direction. + +.Selection mockup: selected clips are highlighted in yellow, the cursor is a white dot. +image::{imgg}/wouter/08-selection.png[width="100%", alt="selecting clips"] + +For selecting, we can introduce an ``add to selection'' key which adds the highlighted clip to the +current selection (apart from the convention of using Ctrl+mouse click). We could also think of +adding box-select by keyboard, by using a system with grid coordinates. +One thing to note is that we do still need extra keyboard shortcuts to move the playhead frame by +frame, independently from the clip selection. See the navigation subchapter for more details. +Selection will be one of the previously mentioned _contextual modes._ The user can always return to +their previous selection until they make a new one, by pressing the corresponding keyboard shortcut +(S). + +Most NLE's have functions for selecting many clips at once, called ``select forward'' and ``select +backward''. In Adobe Premiere these are tools: click and you select all clips to either the left or right +of the mouse cursor, and using Shift will toggle between selecting all clips on a single track or on +all tracks (it doesn't respect track activation status though, which it should). Other NLE's (Resolve, +Avid, Lightworks) only have keyboard shortcuts for these functions, which do only affect activated +tracks. This is a bit faster: in Premiere you need to switch to the Select Forward/Backward Tool, +make your selection, then switch back to your previous tool. With a keyboard shortcut you only +have to press a single key (if your track selection is correct). + +Arranging clips +~~~~~~~~~~~~~~~ +Most NLE's handle the arranging of clips in a destructive way. Drop one clip over another, and the +clips underneath disappear. Move one of two clips that are connected by a transition, and the +transition disappears. While it's certainly true that experienced editors will understand the risks +involved in moving clips and will therefore avoid such destructive behaviour unless they intend for +something to be destroyed, accidents still occur and most probably someone won't notice until much +later, when undo cannot help to recover the lost work anymore. + +At the same time, something as fundamental as swapping the position of two neighbouring clips is +harder than it should. Premiere has Ctrl+Alt+drag, but the results can be destructive. Resolve has a +similar modifier combination, and keyboard shortcuts for swapping left and right, but these also +easily mess up parts of your edit if you're not careful with your track selection. Avid's smart tool +has a Segment Mode that can be set to extract/splice-in, which will do a similar thing. It only has an +effect on the tracks that hold the clip selection and results can get messy when there are J- or L-cuts. +An alternative is to select a clip by mouse, use ``ripple cut'', move the playhead to the next cut, and +use ``paste insert'', but this can also be destructive when not being careful with track management. + +We've talked about using in and out marks already in the previous subchapter, so I will skip that for +now. + +FCP is the only widely used NLE as of now that allows non-destructively changing the order of +clips, by having other clips move out of the way: the so-called _magnetic timeline_ +(see xref:_tracks_vs_trackless[above]). How come the +other professional NLE's make it so difficult to simply change the order of clips? The reason for +that, I can only assume, is that the software doesn't know how clips on different tracks relate to +each other. And as a result, it will be very hard to guess how to exactly change the order. FCP solves +this problem by having clips always connect to a primary storyline. Lumiera could do a similar +thing by utilising its grouping features, in combination with a Ripple-toggle in the contextual bar of +the selection mode. As long as clip relations are clear, changing the order of clips should be simple +to achieve. + + +Trimming clips +~~~~~~~~~~~~~~ +Trimming means extending or shortening the duration of one or more clips (simultaneously), either +from its start or end. In most applications, there are two distinct ways to trim: ripple trimming and +non-ripple trimming. Ripple trimming means that when you extend or shorten a clip, all other clips +on the same track and possibly on other tracks move along. When non-ripple trimming, all clips +stay in place, and when a clip is shortened, a gap appears. To choose a trim type, NLE's use either +tools or modes. + +* FCP's Select tool defaults to ripple trimming, and it's Position tool does non-ripple +trimming. + +* In Premiere it's the other way around: the default selection tool does non-ripple trims, and +the ripple edit tool... well, it's in the name. A user doesn't have to switch tools per se: +pressing the Ctrl modifier will inverse a tool's mode of operation. + +* Resolve talks in terms of modes, not tools, and it has two modes related to trimming: the +default Selection Mode and Trim Edit Mode. The latter lets you ripple trim (by dragging the +edges of clips), slip (dragging inside a clip, upper half) and slide (dragging inside a clip, +lower half) -- more on slip and slide edits later. + +* Avid has a trim mode that can be in overwrite trim or ripple trim mode, indicated by the +colour of the trim sides (red or yellow). The timeline will be in either of these modes when +entering trim mode. + +* Lightworks has a trim mode that defaults to ripple trimming, unless you specifically use the +“drag to black” feature by Control-clicking trim edges when entering trim mode. When +using the keyboard, one needs to mark a section and use the Remove command (similar to +Avid''s ``lift'') to create a gap. + +Next to ripple/non-ripple trimming there are three other edit operations closely related to trimming +that need to be mentioned: + +* Roll edits. This is where you move a cut left or right, so that as a result, one clips gets +extended, while the other gets shortened. + +* Slip edits. Nothing gets extended or shortened. Instead, you shift the contents of one or more +clips on the timeline. + +* Slide edits. This moves a selected clip (or clip selection) left or right, thereby keeping its +own duration, while the duration of its surrounding clips gets altered. + +Some apps use their trimming system for slip and slide edits (Avid, Lightworks). Others use a +special tool or mode and/or separate keyboard shortcuts for this (FCP, Premiere, Resolve). + + +Selecting trim sides +^^^^^^^^^^^^^^^^^^^^ +Every trim starts by selecting which sides of which clips need to be included in the trimming. How +many sides to select greatly depends on how many tracks are involved and if the NLE has a sync +lock system or not. Sync locks makes sure that when you ripple trim selected clips, clips on other +tracks automatically stay in sync. This means (manually) enabling or disabling the sync lock per +track. Once set, trimming a single clip can be enough to have all tracks move along, although you +might still need to manually select trim sides for overlapping clips to get the desired result. + +image::{imgg}/wouter/09-sync-trim-1.png[height=140, alt="trimming with sync-lock(before)"] + +.Avid's sync locks will split longer clips by default, in order to keep sync. Such destructive behaviour should be avoided in Lumiera. +image::{imgg}/wouter/09-sync-trim-2.png[height=140, alt="trimming with sync-lock(after)"] + +Without sync locks you will have to select trim sides on every track that needs to stay in sync, +although, as we'll see, even that can be accomplished by a single keystroke. FCP is the exception +here: it does not use sync locks (as it has a trackless design), but keeps sync not based on tracks, but +on clip connections (this is discussed in the subchapter ``Tracks vs Trackless''). + +Let's first examine trim side selection by mouse. This is generally as simple as clicking near the +edge of a clip, or on the edge between two clips to select both sides for a roll edit. + +Adding additional trim sides often works by using a modifier like Ctrl + left click (Premiere, Resolve, +Lightworks, Avid). FCP does not allow the selection of multiple trim sides and therefore does not +support _asymmetric trimming._ Such trims are still possible, but need to be performed in +multiple steps rather than one. + +Keyboard selection of trim sides happens in general by providing shortcuts for selecting the left (A) +side, the right (B) side, or both, of a cut (Avid, Premiere, Resolve and FCP, although the latter does +not have a shortcut for selecting both sides as it uses a dedicated Trim tool for roll edits). This +applies to the cut nearest to the playhead. Lightworks is the only NLE with a slightly different, but +very powerful method: instead of A/B/both, it has four shortcuts: + +* Trim last out +* Trim in +* Trim out +* Trim next in + +These apply to all clips (or gaps) on enabled tracks underneath the playhead. +These commands can be combined: when pressing multiple keys, new trim sides are added to the +selection. This allows for quickly selecting many trim sides on many tracks. + +.One keystroke led to the selection of these four trim sides in Lightworks +image::{imgg}/wouter/10-trim-side.png["select trim side"] + +Another feature that was already mentioned in a previous chapter, is FCP's precision editor, which +can be triggered by double clicking a cut or by keyboard shortcut. This shows how much footage +from each clip is available for trimming and allows ripple trimming as well as roll edits to be +performed by mouse or keyboard. DaVinci Resolve added a similar thing called Trim Editor, but +positions it at the bottom of the Timeline Viewer. + +Performing the trim +^^^^^^^^^^^^^^^^^^^ +Usually we see four ways to perform a trim: + +1. Frame by frame. This can be done by mouse by clicking and dragging the edges of a clip, or +by keyboard by using shortcuts for ``left one frame'', ``right one frame'', ``left 10/many frames'', +``right 10/many frames''. Instead of using keyboard shortcuts, dedicated hardware can be used +to joggle left or right to perform trimming. +2. By specifying an exact amount of frames. Pretty much every NLE supports using the plus +and minus keys on the keypad to enter exact frame numbers. Lightworks and Avid do an excellent +job at this: when not entering any amount (so just plus/minus + enter) they will repeat the last +entered amount of frames. +3. Dynamic trimming. This means moving the cut (or slipping or sliding a clip) by using the +JKL-playback controls. Avid and Lightworks have dynamic trimming support within their +trim modes. Resolve has a separate switch for this that needs to be toggled, and Premiere has +a separate mode for dynamic trimming, simply called ``Trim Mode''. FCP does not seem to +support dynamic trimming at the time of writing -- although some people disagree and say +that the ``Extend Edit'' function, when used in the Precision Editor, achieves a similar result. +4. All of the big NLE's have keyboard shortcuts that will trim either the start or the end of a +clip to the position of the playhead, in ripple and non-ripple flavours. + +Previewing the cut +^^^^^^^^^^^^^^^^^^ +Most NLE's feature a Preview keyboard shortcut with user-adjustable pre-roll and post-roll +duration. Avid always does a looped preview around the cut in trim mode when triggering playback. + +Entering and exiting trim mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Avid and Lightworks have keyboard commands to both enter and exit their trim modes. When used +for entering, Lightworks will re-enable the previous trim side selection. FCP's precision editor can +be closed with the Escape key, as can Avid's trim mode. + + +Analysis and proposal +^^^^^^^^^^^^^^^^^^^^^ +My proposal is to use the clip selection system to highlight a clip, and then have three commands: + +* Select the clip's in point as trim side +* Select the clip's out point as trim side +* Select the clip's in point for a roll edit + +If the latter is pressed a second time, it will take the clip's out point for a roll edit. When the first +two shortcuts are pressed once, they select the trim side for ripple trims. When pressed again, they +will switch to non-ripple trims (and back again with another press). There should be a clear visual +difference between these two (perhaps through the colour of the brackets, as in Avid). + +Note that this approach resembles Lightworks, and is different from Avid, FCP, Premiere and +Resolve. Those apps take a cut (closest to the playhead) as the basis for choosing a trim side. +Lightworks takes the underlying clip as its basis. Since we already have a mechanism for navigating +clips, we should probably not add another mechanism just for navigating cuts. + +I propose to not make use of sync locks. They apply to entire tracks and we previously established +that clips that have no relation to each other might share a track, so it makes little sense to provide +track based operations. We should instead take the actual clip connections that the user establishes +into account. This way we also don't need to be able to select multiple trim sides at once (for +complex asymmetric trimming operations), as this can create sync problems elsewhere on a track. + +Trimming itself doesn't need to be reinvented. Trimming frame by frame, by a specific amount of +frames or dynamically through playback make perfect sense and offer a full range of options, from +extremely precise to trimming on gut feeling. +Ideally trimming sides should stay active and we won't need to enter or exit a trim mode. However, +we should consider that we need the following keyboard shortcuts: + +* Trim left many frames +* Trim left 1 frame +* Trim right 1 frame +* Trim right many frames + +These same keys can't double for nudging clips, the way it does in many apps, without using modes. +Therefore my proposal is indeed to introduce a Trim mode. As said, it should be designed as a +contextual mode that we fluidly enter and exit and that is visually easy to distinguish from the +regular mode, which we can call the Navigation mode. Trim mode can be accentuated by marking +the part of the timeline we'll be previewing. As in Avid, in trim mode playback could always +preview the selected cut, so we won't need a special Preview (sometimes called ``Play around'') +shortcut, (editing transitions should also engage the trim mode, in that case). Trim mode will be +exited automatically whenever the user clicks in an empty spot of the timeline or presses the trim +mode key (T). This key can also be used to return to the last-used trim configuration. + +.Mockup of the trim mode. The striped area marks the pre- and post-roll that will be previewed. +image::{imgg}/wouter/11-trim-mode.png[width="100%", alt="using trim mode"] + + +Splitting and merging clips +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Tool-based NLE's offer a Blade or Cut tool that will cut clips wherever a user clicks. All NLE's +offer a dedicated keyboard shortcut for creating a cut at the playhead as well. + +Merging two timeline clips with so-called ``through edits'' is often possible by selecting the cut for a +roll edit and pressing the delete key. A through edit occurs when two successive segments of the +same source clip are placed directly next to each other in the timeline (so as a result, it looks as if +there wasn't a cut at all). +A Blade tool, a shortcut for Add Cut and the ability to remove through edits with backspace seem +all worth implementing. + + +Removing clips +~~~~~~~~~~~~~~ +In general, we find the following options to remove clip from a timeline: + +* Select a clip, then: backspace or delete key, or (ripple) cut command. +* In and out points, then lift or extract. +* Lightworks lets you remove a clip by dragging it outside of the timeline window. +* Trimming a clip so it will end up with a duration of 0 frames. + +These operations are so common that I would not change them. + +* Dropping another clip on top. This is something that we could consider changing, especially +when the clips that will be removed are offscreen. + +Organising the timeline: sections +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +I would like to propose the ability to divide a timeline into multiple sections. Each of these sections +will have a header in the ruler that can be edited, to give each section a name (similar to how +duration markers in Premiere are displayed). + +image::{imgg}/wouter/12-sections.png[width="100%", alt="Timeline with sections"] + +The benefits of sections: + +* Creating a broad sense and clear overview of how a timeline is constructed. Background +colours in the timeline will make it easy to differentiate between different sections. + +* Easy navigation between sections by keyboard shortcuts. + +* Keeping sync. All clips in a section are encapsulated. If you work in one section, you will +not be able to throw clips in other sections out of sync. Users could also time-lock a section, +so it will stay in place regardless of other edit operations. This is especially useful when +editing on music, but will also prevent losing sync between other elements that have been +carefully lined up. Sections will not prevent anyone throwing anything out of sync within a +section, but at least not the entire timeline will be affected. + +* The order of sections can easily be changed by clicking and dragging. This way sections can +be used to, for example, easily change the order of scenes. The free-flowing editor for +example, can construct different parts of their edit on different parts of the timeline in +different sections, and then arrange them later. + +* Sections could have a versioning system: this would allow the user to try different cuts +within a section and to quickly change between these different versions. + +Several other characteristics of sections: + +* Clips can be excluded from being part of a section. For example: music tracks could span +the entire length of a video by not being included in any section. + +* When working within a section, its size will adapt to your edit operations (so its edges will +shrink or expand automatically while trimming or moving clips). + +* A new timeline will have one large section spanning its entire length. A “split section” +button and keyboard shortcut will create new sections. + +Things to consider: + +* How to move clips from one section to another? +* If sections can be time-locked then they will probably need to be able to overlap. + + +Adding and editing transitions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +There's usually a variety of ways to add transitions: + +* Right clicking on a cut and choosing a transition from a context menu + +* Double clicking or dragging a transition from an effects or transitions panel + +* With keyboard shortcuts. Premiere has separate shortcuts for audio and video transitions, +others (Lightworks, Resolve) have a single transition shortcut that detects whether a video or +audio transition needs to be added. The default length can often be adjusted in the app's +settings, as well as the default transition type. Some apps have shortcuts to create a +transition from a clip's start or end to the position of the playhead. + +* Avid has a configuration panel for adding transitions: + +image::{imgg}/wouter/13-transition.png[align="center", alt="transition properties"] + +* Some apps allow adding transitions to every cut in the in-out range (Avid, Lightworks). Avid +gives you the option to skip cuts that already have a transition. Very useful for adding short +(2-4 frame) audio transitions to each audio clip that doesn't have a specific transition applied +already. + +* Most apps allow adding transitions to a selection of clips. + +* Blackmagic's Speed Editor lets you select different transitions through a button press and the +big dial, and lets you adjust its length through the dial as well. + +Editing transitions: + +* Changing a transition's duration always works by dragging the transition handles in between +clips (in Avid you will need to have Transition Manipulation enabled for this to work). + +* Changing a transition's position sometimes works by dragging it left or right (Premiere, +Avid). + +* Avid lets you type in the duration underneath the viewers. + +* Often you can double click a transition to enter a duration. + +* Final Cut Pro has a right click context menu option called ``Change Duration'' (Ctrl+D) +which lets you enter the desired duration by keyboard and press enter, for video transitions. +Audio transitions are actually performed by creating fades and having these fades between +clips overlap. They can be adjusted with the fade handles and require the ``Show Audio +Lanes'' or ``Expand Audio'' options to be enabled. + +* Lightworks lets you trim transitions via its trim mode like any other cut. + +* DaVinci Resolve and Final Cut Pro have a Transition tab on their Inspector panels where +length and position of transitions can be adjusted, among other settings. + +Most of these established ways of working with transitions can be applied to Lumiera. I would like +to suggest to also add Avid's option to add transitions to a large number of cuts while skipping +existing transitions (and this should even be the default). + +One thing we do need to address is how transitions magically disappear in pretty much any NLE +except Avid and Final Cut Pro, the moment you move one of the two adjacent clips elsewhere, or +whenever you replace a clip by another. Transitions take time to setup in the right way, and they +shouldn't disappear by themselves. I would suggest to follow Avid and FCP's behaviour and leave +transitions in place by default. + + +Changing timeline clip properties +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Each NLE has an effect properties panel en most have a generic properties panel for changing all +basic properties of clips in the timeline, such as: + +* X & Y position +* scaling +* orientation +* rotation +* opacity and blend mode +* stabilisation + +Avid is the only NLE out there that still requires adding an effect to change these basic clip +properties (``3D DVE''). Quick access to such properties saves a lot of time, so enabling this is +essential. Depending on the actual effects workflow we might want basic properties to be part of an +effect that is automatically applied to each clip when it's added to the timeline. A separate Properties +panel (as in Premiere) is less ideal: the fewer panels, the better. FCP and Resolve use a tabbed +approach for their panels (which is named ``Inspector'') to keep different categories of properties +separated. + +Chapter 3: finishing +-------------------- +[red]#To be written.# + +Chapter 4: a broader GUI concept +-------------------------------- +[red]#To be written.# + +- Panels vs fixed layouts. +- Workspaces. diff --git a/doc/design/workflow/Verwijlen/index.txt b/doc/design/workflow/Verwijlen/index.txt new file mode 100644 index 000000000..3155d0adc --- /dev/null +++ b/doc/design/workflow/Verwijlen/index.txt @@ -0,0 +1,25 @@ +Lumiera Workflow Proposals +========================== +Date: 2025 + +//MENU: label Workflow Proposals Verwijlen +//MENU: prepend WorkflowProposals + +************************ +Wouter Verwijlen is a documentary filmmaker from Utrecht (Netherlands). +************************ + +Many years ago, the Lumiera team first got to know Wouter on occasion +of the link:https://lac.linuxaudio.org/2010/[Linux Audio Conference]. +In spring 2025, he proposed to contribute with concept work related to +UI and workflow, drawing on his longtime experience working with all +professional editing software packages as part of his work in media +production and filmmaking. Knowing those applications in and out, +with all their various strengths and weaknesses allows to compile +a comprehensive overview how the central tasks of film editing +are handled by contemporary software solutions -- and how +this handling might be improved. + +- link:WorkflowProposals.html[»Lumiera Workflow Proposals«] by Wouter Verwijlen +- link:FrosconMeeting.html[Discussion at FrOSCon 2025] + diff --git a/doc/design/workflow/index.txt b/doc/design/workflow/index.txt index d2f4e367b..9e2c03a0f 100644 --- a/doc/design/workflow/index.txt +++ b/doc/design/workflow/index.txt @@ -1,6 +1,9 @@ Design Documents: Workflow ========================== +//MENU: prepend child LumieraWorkflowOutline +//MENU: put child InterfaceConcept_Varga after LumieraWorkflowOutline + In our discussions, the term *Workflow* denotes specific considerations about _the way_ a given task can be achieved, within the application, in the most suitable and stringent fashion. This effort is closely related to GUI and interface design, but likewise quite integral, @@ -8,6 +11,7 @@ so we tend to treat it as a distinct effort, separate from the design of individ * link:LumieraWorkflowOutline.html[Workflow/Requirements outline by BJMR] * link:InterfaceConcept_Varga.html[Interface Concept by Christoph Varga] +* link:/x/Verweijlen.html[Workflow Proposals by Wouter Verweijlen] --> see also link:../gui/index.html[general GUI discussion...] +-> see also link:/x/GuiDiscussion.html[general GUI discussion...] diff --git a/doc/devel/Doxyfile b/doc/devel/Doxyfile index faef72d4f..70aa9eb70 100644 --- a/doc/devel/Doxyfile +++ b/doc/devel/Doxyfile @@ -157,7 +157,8 @@ REFERENCES_LINK_SOURCE = NO SOURCE_TOOLTIPS = YES USE_HTAGS = NO VERBATIM_HEADERS = NO -CLANG_ASSISTED_PARSING = YES +#CLANG_ASSISTED_PARSING = YES +CLANG_ASSISTED_PARSING = NO CLANG_OPTIONS = -DDEBUG -DEBUG_ALPHA #--------------------------------------------------------------------------- diff --git a/doc/devel/DoxygenLayout.xml b/doc/devel/DoxygenLayout.xml index 63a67fff4..8fb457962 100644 --- a/doc/devel/DoxygenLayout.xml +++ b/doc/devel/DoxygenLayout.xml @@ -2,42 +2,43 @@ - - - - - - - - + + + + + + + + + + + + + - - - + + + - - - - - - - + + + + - - - + + @@ -62,13 +63,15 @@ + + - - + + @@ -84,12 +87,18 @@ - + + + + + + + @@ -97,24 +106,41 @@ + + + + + + + + + + + - + - + + + + - + - + + + + @@ -134,14 +160,19 @@ + + + + + @@ -160,6 +191,8 @@ + + @@ -172,10 +205,28 @@ - + + + + + + + + + + + + + + + + + + + diff --git a/doc/devel/LumieraHelpLandingPage.NOTICE b/doc/devel/LumieraHelpLandingPage.NOTICE new file mode 100644 index 000000000..6a4525d7b --- /dev/null +++ b/doc/devel/LumieraHelpLandingPage.NOTICE @@ -0,0 +1,16 @@ +NOTE: this is a placeholder -- the intention is to build a user Manual via Asciidoc + +As of 2025, Lumiera is not usable, and thus only a placeholder HTML page is provided +for the DEB-Package. The content on this page is identical to the "User-Manual" page: +https://Lumiera.org/documentation/user/manual.html + +For the delivery +- this page has been rendered with Asciidoc +- the resulting HTML has been processed with the "Print Edit WE" plugin of Firefox, + which inlines any resources (CSS, images) + +This page will be installed by the Lumiera SCons build into $prefix/share/doc/lumiera +(see doc/SConsscript) + +Hint: for updates, re-render the Asciidoc and then use git/diff to combine the + new or changed content with the embedded inline images (base64 data) diff --git a/doc/devel/LumieraHelpLandingPage.html b/doc/devel/LumieraHelpLandingPage.html new file mode 100644 index 000000000..fa19103df --- /dev/null +++ b/doc/devel/LumieraHelpLandingPage.html @@ -0,0 +1,699 @@ + + + + + + + + + + + + + +Lumiera User Manual + + +
+
Lumiera
+
The new emerging NLE for GNU/Linux
+
+
+
+ +
+ + + +
+
+
+
There is no »User Manual« — yet

The plan is to create the manual and tutorials later in a collaborative way.
+This work is postponed until the software is actually usable.

+
What is »Lumiera«?

Lumiera is a Free/Open Source project to build a Non-Linear Video Editing (NLE) +and compositing application for GNU/Linux. +Its primary focus is professional editing, quality, usability and flexibility. +On the one hand, it must meet the rigours of a professional +film and video production environment; on the other hand, it must +be flexible enough to satisfy the needs of more modest single-user +equipment.

+

These ambitious goals have led us to a complex and flexible internal structure, +over the course of the last years. Many elements still need to be connected and +integrated, so that the functionality becomes visible and can be explored by users. +And we are a small team. Nevertheless, please be assured that work on the project is ongoing.

+
+
+
+
+

UI Experiments

+
+

While most of the work is focused at the inner workings of the Render Engine +(as of Nov.2025), the User Interface has been upgraded to GTK-3 and outfitted with +some experimental connection channels, to test interplay with the application core.

+

After launching the lumiera application, a main window will be displayed.

+

+ + + +

+
+

Video Output

+

The play / pause / stop buttons will activate some video output demo code, +which is actually quite old — it was extracted 2009 from the Kino +video editing software and used for various experiments since then. In its current shape, +this dummy playback ensures that Lumiera is properly built and linked to use the +XVideo standard with the help of the X11 XServer. +This archaic standard from 1991 presumably was the first widely available and vendor-neutral interface +for passing raw video frames to the GPU, which then scales and integrates them into the desktop display.

+

The video frames for this demo are not generated by the Lumiera Render Engine — and +thus this code is largely obsolete; maybe it will continue to live somewhere as a fallback +for systems without proper support of OpenGL?

+
+
+

The UI-Bus

+

Instead of accessing a shared data model, the Lumiera UI is connected to the core +through an asynchronous messaging channel, to dispatch command instructions into the +session and to push responses up into the UI. There is a demo to verify this setup +by pushing info and error messages into the »Info Box«

+
    +
  • +

    +In the “Help” menu, there is the entry ‘Help > Self Tests’ +

    +
  • +
  • +

    +The tab #1099 in this non-modal dialog box + allows to push notification messages into the UI-Bus… +

    +
      +
    • +

      +enter some text into the input widget at the top +

      +
    • +
    • +

      +send a display message with this text at Info / Warn / or Error level +

      +
    • +
    • +

      +or push the “mark” button to send a mark message, selected from the + drop-down +

      +
    • +
    +
  • +
+
+
+

Timeline Display

+

The second tab in this “Test and Diagnostics” dialog box (‘Help > Self Tests’) +allows to Populate the Timeline Display with a structure corresponding to session content. +This structure is sent over the UI-Bus as a “Diff Message” — basically the core can notify +the UI about changes in structured content elements, which both sides know, without ever sharing +a common data representation.

+

This demo engages this mechanism to populate an previously empty Timeline with structured content; +the actual content is hard-wired for this test, offering two flavours (“Sequence 1” and “Sequence 2”).

+
+
+Sequence 1 +
+
+

+ A single Track, with two Clips, which can be clicked and dragged; they have a fixed given length, + but no further content. +

+
+
+Sequence 2 +
+
+

+ A complex arrangement of nested tracks, some of which are expanded, and some have overview rulers. + Note that it is possible to scroll vertically, while the top-level overview rulers remain always + visible and pinned on top. Note furthermore that the Track-Head display in the left pane scrolles + alongside, and remains in sync with the main content pane. Tracks can not yet be expanded / collapsed +

+
+
+

The Button “move elements” is part of an ongoing experiment and currently disabled.

+
+ + + +
+Note +the panes can be undocked and re-arranged, but retain their identity, so that + they can be addressed via UI-Bus without knowing where they are actually located + in the UI. And there are various known problems related to those docks…
+
+
+
+
+
+

+
+
+ + + diff --git a/doc/devel/meeting_summary/2008-02-01.txt b/doc/devel/meeting_summary/2008-02-01.txt index 98a2655ef..919f48c44 100644 --- a/doc/devel/meeting_summary/2008-02-01.txt +++ b/doc/devel/meeting_summary/2008-02-01.txt @@ -18,24 +18,35 @@ __Participants__ * Velmont -Discuss the open points in [Lumiera/DesignProcess] --- do we need this formalism? ---------------------------------------------------------------------------------- -At start of the project last summer, Cehteh made a http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process proposal]. We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. One point in the agenda of future meetings will be to work through proposals in the queue +Discuss the open points in the link:/x/DesignProcess.html[Design Process] +------------------------------------------------------------------------- - * proposals in the "idea" state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page. - * proposals in the "draft" state are ready for conclusive discussion and will be treated in one of the next meetings - * "final" proposals are either "accepted" or "dropped". We don't differentiate the latter, but should write a short note why it was dropped. +Do we need this formalism? -- + +At start of the project last summer, _Cehteh_ made a link:{rfc}/LumieraDesignProcess.html[»Design Process« proposal]. +We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. +One point in the agenda of future meetings will be to work through proposals in the queue. + + * proposals in the `Idea' state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page. + * proposals in the `Draft' state are ready for conclusive discussion and will be treated in one of the next meetings + * `Final' proposals are either `Accepted' or `Dropped'. We don't differentiate the latter, but should write a short note why it was dropped. * if there is need for more or finer grained categories, we'll extend the page and the template as needed or provide different views The development model --------------------- -We employ a distributed model based on GIT. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a "Mob GIT", i.e. anonymously pushable git (which is untrusted of course). Cehteh is currently working on a git web frontend which makes the codebase in the mob-repo web-editable like a wiki. -Will we need a stable version or an official branch? not yet — as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it. -Ichthyo proposes a new requirement: All devs should ensure the "master" branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator. -A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature — esp. when it fits into the core focus of the project — instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits. +We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course). _Cehteh_ is currently working on a Git web frontend (``webgit'') which makes the codebase in the mob-repo web-editable like a wiki. + +Will we need a stable version or an official branch? not yet -- as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it. + +Ichthyo proposes a new requirement: All devs should ensure the `master' branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator. + +A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature -- esp. when it fits into the core focus of the project -- instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits. + And, pretty much obvious, we try to stick to modern programming standards. Read: modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion. + Currently, the project can be separated into three layers, which could evolve into sub-projects: Backend, Proc-Layer, GUI. For each part, the dev most deeply involved and most knowledgeable will take on the sometimes necessary leadership and have the last word in case of quarrels. Currently, Cehteh cares for the Backend and Ichthyo headed for the Proc-Layer. We have postponed any work on the GUI for now and don't participate in GUI toolkit discussions. If there is a dev willing to care for the GUI, collect proposals, care for usability and the users needs and finally code it up, then he will the one to decide what toolkit to use. + We plan to make the discussion about GPL v3 a point on the agenda of the next meeting. @@ -43,11 +54,11 @@ Monthly meetings ---------------- * make it thursday, not friday - * time for now 21:00 GMT — if some (potential) participants have problems with this time, please speak up (maybe alternating times?) + * time for now 21:00 GMT -- if some (potential) participants have problems with this time, please speak up (maybe alternating times?) * write a short status report for each mayor part *prior* to the meeting (saves us time). Maybe add an TODO list there * go through the open issues for the design process drafts - * publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the link:TiddlyWiki[] and on pipapo.org - * News, Protocols and the agenda of the next meeting can be found at link:MonthlyMeetings[this page here] + * publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the TiddlyWiki and on `pipapo.org` + * News, Protocols and the agenda of the next meeting can be found at link:{ldoc}/devel/meeting_summary/index.html[Monthly meetings page] * next meeting on first Thursday in March (6.3.2008) @@ -71,11 +82,11 @@ Since the render nodes are stateless they can be driven in multiple threads (but The naming discussion --------------------- -The discussion looks healthy so far... People can add new proposals on the http://www.pipapo.org/pipawiki/Lumiera/Names[pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-) +The discussion looks healthy so far... People can add new proposals on the [pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-) Let's say, we need a person volonteering to guide/moderate the selection, going over the list and scratching inammprobiate ones. Criteria for good names being: * should not be an existing project - * should be "googleable" + * should be ``googleable'' * should not be offensive * should have one of the free top level domains (.net, .org) * should be compatible with educational institutions (sorry, no pr0nedit :) diff --git a/doc/devel/meeting_summary/2008-03-06.txt b/doc/devel/meeting_summary/2008-03-06.txt index 4b28897b8..131d1868d 100644 --- a/doc/devel/meeting_summary/2008-03-06.txt +++ b/doc/devel/meeting_summary/2008-03-06.txt @@ -26,8 +26,8 @@ Boilerplate Organization of this meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - * cehteh writes the protocol - * hermanr does chairman + * _Cehteh_ writes the protocol + * _Hermanr_ does chairman Leftovers from last meeting @@ -41,80 +41,93 @@ Go through Ideas and Drafts in design process Idea: time_handling ~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[] +link:{rfc}/TimeHandling.html[time handling] -Point 1 is superseded by using gavl. +Point 1 is superseded by using Gavl. Points 2 and 3 are still valid. -Ichthyo asked gmerlin if there are any problems according gavl for the points 2 (position of frames) and 3 (position for keyframes and automation). Gmerlin acknowledges that he doesnt see any problems. +_Ichthyo_ asked _Gmerlin_ if there are any problems according Gavl for the points 2 (position of frames) and 3 (position for keyframes and automation). +_Gmerlin_ acknowledges that he does not see any problems. -Oracle2025 brings interlacing on topic "are you aware that automations and keyframes could/should also apply to fields?". We agree that this must be handled "in interlacing, a frame is a pair of 2 subsequent fields". +_Oracle2025_ brings interlacing on topic ``are you aware that automations and keyframes could/should also apply to fields?''. +We agree that this must be handled ``in interlacing, a frame is a pair of 2 subsequent fields''. -Conclusion: - Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting +Conclusion:: Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting Idea: Unit tests in Python ~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UnitTests_Python[] +link:{rfc}/UnitTests_Python.html[RfC: Unit Tests in Python] -We have a testsuite based on cehtehs 'test.sh' which superseedes this proposal. +We have a testsuite based on _Cehtehs_ `test.sh` which superseeds this proposal. -Conclusion: - Drop it. +Conclusion:: Drop it. Idea: Todo Lists ~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TodoLists[] +link:{rfc}/TodoLists.html[Todo Lists] to organise tasks to be done.... -This Idea is in a very early state an not yet mature. -Cehteh explains: "I want something which doesn't need much human care and i want one big \'milestones' thing and a small \'mini-task' thing". Ichthyo refines this as "Roadmap" and "Near time task list". We agree that this shall not be too strict. There are some ideas floating, like adding this things to the testsuite or use the wiki. Ichthyo shows how he uses the tiddlywiki's task macro (http://ichthyostega.de/cin3/wiki/renderengine.html#PlanningNodeCreatorTool[]). He likes it but doubts its usefulness when it is used without guessing the hours/days of work. +This idea is in a very early state an not yet mature. +Cehteh explains: ``I want something which doesn't need much human care and i want one big »milestones« +thing and a small »mini-task« thing''. Ichthyo refines this as »Roadmap« and »Near time task list«. +We agree that this shall not be too strict. There are some ideas floating, like adding this things +to the testsuite or use the wiki. _Ichthyo_ shows how he uses the TiddlyWiki's `task macro`. +He likes it but doubts its usefulness when it is used without guessing the hours/days of work. -Conclusion: - We use the Tiddlywiki task macro thing for now. +Conclusion:: We use the TiddlyWiki task macro thing for now... Draft: CCodingStyleGuide ~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/CCodingStyleGuide[] +link:{rfc}/CCodingStyleGuide.html[C-coding style guide] -Ichthyo tells that the discussion on the wiki page made this clear now. Cehteh explains that he uses this style with success for diffrent projects. We make clear that this is meant for C, in C++ we use namespaces. Overall we agree that code shall be self-documenting. +_Ichthyo_ tells that the discussion on the wiki page made this clear now. +_Cehteh_ explains that he uses this style with success for different projects. +We make clear that this is meant for C, in C++ we use namespaces. +Overall we agree that code shall be self-documenting. -Conclusion: - Make it final. +Conclusion:: Make it final. Draft: DevelopmentFramework ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DevelopmentFramework[] +link:{rfc}/DevelopmentFramework.html[Development Framework] -Cehteh explains that he will transfer this propoal to a tiddlywiki covering compatibility guides and dependencies. We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet. +_Cehteh_ explains that he will transfer this propoasl to a TiddlyWiki covering compatibility guides and dependencies. +We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet. -A short discussion about build systems came up, we still use autotools and scons in parallel, delaying the decision later. oracle2025 mentioned that scons could be used for development and autotools for release. No decision about that everyone has different opinions. But we agree that it works as is. +A short discussion about build systems came up, we still use Autotools and SCons in parallel, delaying the decision later. +_Oracle2025_ mentioned that SCons could be used for development and Autotools for release. +No decision about that everyone has different opinions. But we agree that it works as is. -Conclusion: +Conclusion:: Cehteh will make the proposed wiki which shall be maintained to reflect the state and this topic will be finalized by that. Draft: Skills Collection ~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/SkillsCollection[] +link:{rfc}/SkillsCollection.html[RfC: Collection of Skills] This might be only useful if there are more developers working on the project. -Conclusion: +Conclusion:: Leave in draft state for now. Draft: Architecture Overview ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[] +link:{rfc}/ArchitectureOverview.html[Architecture Overview] -Ichthyo drawn a diagram showing the planned architecture. Cehteh raises concerns about codecs/plugins/effects in backend. After that there was some discussion about details. Cehteh suggests to place plugins in a extra box, gmerlin suggests that \'plugins' don't fit into the diagram, there should be "filters", "sources",..; Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements. +_Ichthyo_ has drawn a diagram to show the planned architecture. +_Cehteh_ raises concerns about codecs/plugins/effects in backend. +After that there was some discussion about details. +_Cehteh_ suggests to place plugins in a extra box, _Gmerlin_ suggests that ``plugins'' don't fit into the diagram, +there should be ``filters'', ``sources'',..; +Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements. -Conclusion: +Conclusion:: Good idea, needs some refinements, work in progress. @@ -122,47 +135,65 @@ Conclusion: Call for Design --------------- -Ichthyo explains that the wants the overall design a bit more formalized. He put this topic on the agenda to remind that we have to work it out in link:DesignProcess[] and already started to make some design proposals. +Ichthyo explains that the wants the overall design a bit more formalized. +He put this topic on the agenda to remind that we have to work it out in link:/x/DesignProcess.html[the Design Process] +and already started to make some design proposals. -Conclusion: - Things need to be worked out in link:DesignProcess[], take a look and review it. +Conclusion:: + Things need to be worked out as RfC -- take a look and review it. Naming ------ -Raffa, Velmont, goibhniu and others collected and managed proposed names past weeks which finally ended in a community voting. Results are at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_9fad0d1d10c23d38[] -Lumiera won, Lumiera.org is free and no one of in this meeting has objections against this name. Velmont offers to register and pay for the lumiera.org domain which will be hosted on our own server (see topic below). Hermanr raises concerns if it is ok when the name is registered on another site and by another person than the server, cehteh explains that he like this distribution where doable and no one other objects. Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds. After a short discussion we agree that we use the full name and no abbreviation. We now have to rename the source and the wiki. Anyone renames the sourcecode where he is responsible for. Cehteh will go over the pipapo.org wiki and rename things. +_Raffa_, _Velmont_, _Goibhniu_ and others collected and managed proposed names past weeks which finally ended in a community voting. +Results are at [purple]##. The name *Lumiera* won, +"`Lumiera.org`" is free and no one of in this meeting has objections against this name. +_Velmont_ offers to register and pay for the Lumiera.org domain which will be hosted on our own server (see topic below). +_Hermanr_ raises concerns if it is ok when the name is registered on another site and by another person than the server, +_Cehteh_ explains that he like this distribution of responsibilities where doable and no one other objects. +Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds. +After a short discussion we agree that we use the full name and no abbreviation. +We now have to rename the source and the wiki. Anyone renames the source code where he is responsible for. +_Cehteh_ will go over the `pipapo.org` wiki and rename things. -Finally we express our great thanks to the people who put the efforts into the name selection, thanks raffa, Velmont, goibhniu & co. +Finally we express our great thanks to the people who put the efforts into the name selection, thanks _Raffa_, _Velmont_, _Goibhniu_ & co. -Conclusion: - Projectname is Lumiera, we have a lot things to rename. +Conclusion:: + Project name is *Lumiera*, we have a lot things to rename. Project Server, setup, organization, administration --------------------------------------------------- -Some people gathered together and rented a server at http://www.hetzner.de[hetzner.de] which will host some free project pages and personal sites. Cehteh is the one who signed for the server and officially respobsible for it. +Some people gathered together and rented a server at https://www.hetzner.com/[hetzner.de] which will host some free project pages and personal sites. +_Cehteh_ is the one who signed for the server and will be officially responsible for it. -The server is split into isolated \'vservers' which are created as needed. Idea is to work cooperatively to get the best out of its resources. +The server is split into isolated »VServers« which are created as needed. Idea is to work cooperatively to get the best out of its resources. -For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things. Velmont offered to help with lumiera.org, hermanr takes care of cinelerra.org, raffa will help with maintaining the webpages. oracle2025 will care for developer chroots, build and test environments. cehteh will make a page on pipapo.org which reflects the current server setup http://www.pipapo.org/pipawiki/RootServerSetup[]. There are still a lot jobs to do! +For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things. +_Velmont_ offered to help with Lumiera.org, _Hermanr_ takes care of Cinelerra.org, _Raffa_ will help with maintaining the webpages. +_Oracle2025_ will care for developer `chroots`, build and test environments. +_Cehteh_ will make a page on pipapo.org which reflects the current server setup [purple]##. There are still a lot jobs to do! -Cehteh asked about how to manage emergency root access on the host/root server when he is unreachable. There where several suggestions between one root key for all who pay for the server to shared key schemes. We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access. +_Cehteh_ asked about how to manage emergency root access on the host/root server when he is unreachable. +There where several suggestions between one root key for all who pay for the server to shared key schemes. +We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access. -The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer vserver shared between all developers. Maybe a shared mail server. +The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer VServer shared between all developers. Maybe a shared mail server. -Hermanr asked about how to handle distribution of large media files. There was some discussion about bittorrent vs http. We concluded to work that out as needed. +_Hermanr_ asked about how to handle distribution of large media files. There was some discussion about Bittorrent vs HTTP. We concluded to work that out as needed. -In the forthcoming discussion about cehteh stresses that "it is a public server, if you place confidential information unencrypted on it, its you fault". Ssh keys shall be kept secret by the users but we can't enforce policies on those. +In the forthcoming discussion about security, _Cehteh_ stresses that ``it is a public server, if you place confidential information unencrypted on it, its you fault''. +SSH keys shall be kept secret by the users but we can't enforce policies on those. -Ichthyo asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, cehteh explains that webgit isn't ready yet but should be useable in a few days (pipapo.org will use that too). Velmont suggest a \'real' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org. +_Ichthyo_ asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, _Cehteh_ explains that webgit isn't ready yet but should be useble in a few days (pipapo.org will use that too). +_Velmont_ suggest a ``real'' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org. -Hermanr asked Velmont about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things. +_Hermanr_ asked _Velmont_ about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things. -Ichthyo asks about keeping the Lumiera project pages on pipapo.org until the server is ready, this is ok. +_Ichthyo_ asks about keeping the Lumiera project pages on pipapo.org until the server is ready, _Cehteh_ confirms this is OK. -Conclusions: +Conclusions:: We have our own server which now needs volunteers for maintenance. The projects will slowly move there, until ready Lumiera stays on pipapo.org. @@ -170,10 +201,16 @@ Conclusions: GPL3 pros cons, license rationale --------------------------------- -Ichthyo and cehteh would like to investigate a license change to GPLv3, neither of us has experience with problems this -might raise. Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses. The others here thinking that "GPLv2 or later" would be most-compatible. Gmerlin tells that he uses some "GPLv2 only" mplayer code in gavl which is itself "GPLv2 or later". Cehteh explains that "GPLv2 only" code is a problem, where "GPLv2 or later" is not. Ichthyo raises concerns that the Support library may need to be LGPL, cehteh mentions that it would likely be enough if we only apply that to the plugin-loader. After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner. +_Ichthyo_ and _Cehteh_ would like to investigate a license change to GPLv3, neither of us has experience with problems this might raise. +Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses. +The others here thinking that ``GPLv2 or later'' would be most-compatible. _Gmerlin_ tells that he uses some ``GPLv2 only'' MPlayer code in Gavl, +which is itself ``GPLv2 or later''. _Cehteh_ explains that ``GPLv2 only'' code is a problem, where ``GPLv2 or later'' is not. +_Ichthyo_ raises concerns that the Support library may need to be LGPL, +while _Cehteh_ mentions that it would likely be enough if we only apply that to the plugin-loader. +After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses +and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner. -Conclusion: +Conclusion:: Learn more about GPLv3, use GPLv2 or later and propose to switch to GPLv3 when we are ready to do public beta releases when possible. @@ -185,5 +222,5 @@ The next meeting will be at thuesday 3rd april 21:00GMT (if not rescheduled see Ichthyo tells that Martin Ellison wrote he couldn't attend because of the time. So again we made a short discussion about changing/alternating timings to allow people in downunder/japan to attend. They have to speak up an make time suggestions. -Conclusion: +Conclusion:: Next meeting 3rd april 21:00GMT. But Aussies, please speak up if you want the time changed! diff --git a/doc/devel/meeting_summary/2008-04-03.txt b/doc/devel/meeting_summary/2008-04-03.txt index 36cad109f..05248b154 100644 --- a/doc/devel/meeting_summary/2008-04-03.txt +++ b/doc/devel/meeting_summary/2008-04-03.txt @@ -20,7 +20,7 @@ Boilerplate Organization of this meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - * sakalli writes the protocol, ichthyo will help reviewing it + * _sakalli_ writes the protocol, ichthyo will help reviewing it Recurring Topics @@ -32,20 +32,25 @@ Call for volunteers ------------------- (which tasks are to do, how can we interest people...?) -There was a sense that there are people willing to help but they might need direction or cannot do actual coding. But there is also a lot of tasks that could be done by beginners and non-programmers. These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers. Examples of such tasks: +There was a sense that there are people willing to help but they might need direction or cannot do actual coding. +But there is also a lot of tasks that could be done by beginners and non-programmers. +These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers. +Examples of such tasks: * Protocol writing * maintaining to do lists and isolating tasks * constant code and documentation review * unit/functional testing - * header file "task force" - some fundamentals discussed by the developers on libopenvideo should find their way into basic .h files + * header file ``task force'' - some fundamentals discussed by the developers on libopenvideo should find their way into basic `.h` files * installing and maintaining project tracking and automated builds/tests on the server -See http://www.lumiera.org/wiki/todo.html#Tasks[] +See [purple]## -It was also noted that at current phase some basic development is still needed before we can accommodate a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example. +It was also noted that at current phase some basic development is still needed before we can accommodate +a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example. -To make it easier for "beginners" to get aquainted with the program it was decided that one *official Lumiera GIT repository* should be established. +To make it easier for ``beginners'' to get acquainted with the program it was decided that +one *official Lumiera GIT repository* should be established. (-> `git://git.lumiera.org/LUMIERA`) @@ -53,7 +58,16 @@ Project announcements/registration ---------------------------------- (freshmeat, gnu, etc...) any takers? -The discussion was about advertising the project on various sites. There were some concerns raised that it is too early to do too much publicity at the moment. That the right time should be shortly before the first public release. But there is also some value in registering to the project in planning/alpha stage to interest people such as prospective coders. It was noted that the http://www.linux.com/feature/126441[article on linux.com] resulted in a lot of people contacting ichthyo and cehteh. http://plot.bek.no/pipermail/piksel/2008-January/003328.html["I believe in Cinelerra"] by Leo Germani also generated a lot of traffic by developers. Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on. +The discussion was about advertising the project on various sites. +There were some concerns raised that it is too early to do too much publicity at the moment; +the right time should be shortly before the first public release. But there is also some value +in registering to the project in planning/alpha stage to interest people such as prospective coders. +It was noted that the +https://web.archive.org/web/20090601174640/http://www.linux.com/archive/feature/126441[article on Linux.com] +resulted in a lot of people contacting Ichthyo and Cehteh. +https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-January/012806.html[»I believe in Cinelerra«] +by Leo Germani also generated a lot of traffic by developers. +Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on. Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful) @@ -62,51 +76,76 @@ Conclusion: volunteer needed to coordinate publicity (not overly urgent, but hel Informal talk about the GUI --------------------------- -Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo: GUI and backend should be completely separated and communicate via pipes. It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used. Some comments: +Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo: +GUI and backend should be completely separated and communicate via pipes. +It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used. +Some comments: - * cehteh standalone gui is a nice to have, but implementation details have to be worked out - * gmerlin Video playback can be separated in a separate X connection - * cehteh suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later - * rgareus IMHO you want to share memory for the video-frame buffer beween the player and backend - with pipes you'll go the video-jack way. + * _cehteh_: standalone gui is a nice to have, but implementation details have to be worked out + * _gmerlin_: Video playback can be separated in a separate X connection + * _cehteh_ suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later + * _rgareus_ IMHO you want to share memory for the video-frame buffer between the player and backend - with pipes you'll go the video-jack way. -joelholdsworth is a new developer in the group and had showed interest in developing the GUI. he stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm. There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME). Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language. +_JoelHoldsworth_ is a new developer in the group and had showed interest in developing the GUI. +He stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards +to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm. +There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME). +Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language. Cario was suggested to be used for implementing the canvas in the timeline view. -The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins. Tracks can be nested. Use tiling windows and dockeable views and tools palettes. For example some configuration within session/renderpipeline may cause some pluggable elements to be added to the gui. A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews). A video track renders thumbnails, automation curves on top. +The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins. +Tracks can be nested. Use tiling windows and dockable views and tools palettes. +For example some configuration within session / render-pipeline may cause some pluggable elements to be added to the gui. +A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews). +A video track renders thumbnails, automation curves on top. -Workflow is another important aspect to take into account in the design. A lot of information needs to come from editors and users in the design process. Different thoughts about the workflow: +Workflow is another important aspect to take into account in the design. +A lot of information needs to come from editors and users in the design process. +Some thoughts about the workflow: * Should not make a predefined workflow. Just produce a tool that can be adapted to different workflows. It can be predefined, but should not be fixed. - * We dont have the resources to develop a "workflow" in the formal manner, we will go the "propose and comment" route. + * We dont have the resources to develop a »workflow« in the formal manner, we will go the ``propose and comment'' route. * We should take the best ideas from popular competing products such as Final Cut Pro, AVID, Premiere plus After Effects. Customisation is deemed important. Some points brought up in the discussion: - * sakalli: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well. - * cehteh: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional + * _sakalli_: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well. + * _cehteh_: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional * Customization should be possible without recompile, but not too cheap. * There should be a working skeleton or some fixed anchor but gui operations should be bound to a scripting language to achieve customization. * The whole gui in a script with some performance critical widgets coded in C/C++ * Some parts should just be customizable, other parts should be kept fixed. - * cehteh suggested to start out by making a \'high level' description with no language/toolkit in mind .. what widgets do we need etc and after that to work on the skeleton mockup. - * cehteh / hermanr: Lumiera should allow to choose theme independently from desktop .. because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour + * cehteh suggested to start out by making a ``high level'' description with no language/toolkit in mind ... + what widgets do we need? etc and after that to work on the skeleton mockup. + * _cehteh_ + _hermanr_: Lumiera should allow to choose theme independently from desktop ... + because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour -ichthyo brings up the role of customization for the middle layer and gives an overview of his plans for the new participants. -He had good experiences with a rule based aproach in various projects. He wants to embed a Prolog interpreter that can answer to "configuration queries". There is a "builder" component in the middle layer to derive the render nodes graph based on a "high level model", which is visible to the user (in the GUI) and based on these configuration queries. +_Ichthyo_ brings up the role of customization for the middle layer and gives an overview of his plans for the new participants. +He had good experiences with a rule based approach in various projects. He wants to embed a Prolog interpreter that can answer +to ``configuration queries''. There is a ``builder'' component in the middle layer to derive the render nodes graph based on +a ``high level model'', which is visible to the user (in the GUI) and based on these configuration queries. -Rationale for using prolog is: The rules are very readable because they rather represent facts and relations, not the way "how dings are done" but the way "how things are related". Example: how to configure some effects when the footage is interlaced. Additionally, we want to have some global swithces, which could control these rules, like "I want maximum quality", or "I want as much as possible set up automatically". The prolog rules are stored in the session and can be editd by advanced users. Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue but it would have consequences for the GUI. +Rationale for using prolog is: The rules are very readable because they rather represent facts and relations, +not the way ``how things are done'' but the way ``how things are related''. +Example: how to configure some effects when the footage is interlaced. +Additionally, we want to have some global switches, which could control these rules, +like ``I want maximum quality'', or ``I want as much as possible set up automatically''. +The prolog rules are stored in the session and can be edited by advanced users. +Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue +but it would have consequences for the GUI. some discussion: - * joelholdsworth: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc. + * _joelholdsworth_: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc. * rules within the middle layer/session could bind to some properties exposed in the GUI - * gmerlin joelholdsworth: Agree, but point out that this can become difficult - * cehteh joelholdsworth: skeleton and plugins who attach into some gui areas, so you can add custom widgets - * ichthyo: also the ability to attach "tags" to various objects, so the rules can bind on those tags - * cehteh: maybe a standard set of widgets, not really completely custom ones (gmerlin agrees) - * joelholdsworth: probably you need to be able to do both well - * joelholdsworth in many apps the value/colour/string set works perfectly well, but in luminierra the controls will likely need to be much richer + * _gmerlin_, _joelholdsworth_: Agree, but point out that this can become difficult + * _cehteh_ + _joelholdsworth_: skeleton and plugins who attach into some GUI areas, so you can add custom widgets + * _ichthyo_: also the ability to attach ``tags'' to various objects, so the rules can bind on those tags + * _cehteh_: maybe a standard set of widgets, not really completely custom ones (_gmerlin_ agrees) + * _joelholdsworth_: probably you need to be able to do both well + * _joelholdsworth_ in many apps the value/colour/string set works perfectly well, + but in Lumiera the controls will likely need to be much richer Some brainstorming points about usability: @@ -116,20 +155,23 @@ Some brainstorming points about usability: One extra point: - * we have agreed to make all of the big interfaces between the layers as plain C interfaces, because this is the most widely supported common denominator. + * we have agreed to make all of the big interfaces between the layers as plain C interfaces, + because this is the most widely supported common denominator. GUI CONCLUSION ~~~~~~~~~~~~~~ - * joelholdsworth is now the official GUI maintainer for Lumiera! - * sakalli, hermanr, ichthyo announced interest in contributing to discussions about GUI, workflows and usability. gmerlin noted that he knows some gtk secrets and is willing to help out here too. + * _joelholdsworth_ is now the official GUI maintainer for Lumiera! + * _sakalli_, _hermanr_, _ichthyo_ announced interest in contributing to discussions about GUI, workflows and usability. + * _gmerlin_ noted that he knows some GTK secrets and is willing to help out here too. Froscon application ------------------- -http://www.froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented. Cehteh will be there as well as Ichthyo. Question is wether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june. +https://froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented. +Cehteh will be there as well as Ichthyo. Question is whether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june. We made no decision about official presence but most likely there will be a developer meeting if nothing else. @@ -139,7 +181,7 @@ Timecode metadata discussion ---------------------------- This Discussion started out on the libopenvideo list: The question was wether we agree on one uniform format solution from decoder up to app level regarding timecode. And what this format would be: arithmetic or struct type. Regarding metadata (including type of timecode) the question is if we should work out a rather fixed data format, or go the route towards rather open description records. -Conclusion: Gmerlin does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further. +Conclusion: _Gmerlin_ does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further. _A (shortended) digest of the timecode and metadata discussion is attached below_ diff --git a/doc/devel/meeting_summary/2008-05-08.txt b/doc/devel/meeting_summary/2008-05-08.txt index 6ab08ebde..d435521ad 100644 --- a/doc/devel/meeting_summary/2008-05-08.txt +++ b/doc/devel/meeting_summary/2008-05-08.txt @@ -24,44 +24,45 @@ Organization of this meeting Webpage-Infrastructure, Maintenance ----------------------------------- -Cehteh put this on topic because it's really urgent to bring up some +_Cehteh_ put this on topic because it's really urgent to bring up some infrastructure to manage the information we produce. The Lumiera pages on pipapo.org were always meant as intermediary -solution. Pipapo.org gets much spam on the moinmoin wiki and cehteh +solution. Pipapo.org gets much spam on the MoinMoin wiki and _Cehteh_ expresses that he wants to move pipapo.org to a new infrastructure -based on asciidoc and git he created -(see http://git.pipapo.org/uWiki.html[]). This system is barely useable +based on Asciidoc and Git he created +(see [purple]#`http://git.pipapo.org/uWiki.html` #). +This system is barely usable and needs lots of work to be completed. It would be nice to use it for Lumiera too, if the others agree. Maintaining and extending (scripting) needs someone who knows shell scripting and doesn't need to be done by the core devs freeing their resources to work on -Lumiera. Cehteh expresses that none of the people who proposed to +Lumiera. _Cehteh_ expresses that none of the people who proposed to help before showed up yet. WesLappy tells he might help (addendum not this week, because he is busy). -Next there was a suggestion by cehteh to convert the tiddlywikis to -asciidoc. Ichthyo expresses that he likes the tiddlywikis, Joel +Next there was a suggestion by _Cehteh_ to convert the TiddlyWikis to +Asciidoc. Ichthyo expresses that he likes the TiddlyWikis, Joel mentions that they feel a little odd. Generally we all agree that they have some problems in sense of workflow and merging. -Ichthyo makes the suggestion to keep the tiddlywikis as scrapbook and -build up \'official' documentation based on their content in -whatever-we-use-then (asciidoc) documentation system. All agree on +_Ichthyo_ makes the suggestion to keep the TiddlyWikis as scrapbook and +build up ``official'' documentation based on their content in +whatever-we-use-then (Asciidoc) documentation system. All agree on this approach. -Back to the new wiki, cehteh suggests to make stricter access rules to -prevent spam: "There will be a group of \'Validated' people which -following rules: only Validated people can edit general content and -\'Validated' people can add new people to \'Validated' themselves". That +Back to the new wiki, _Cehteh_ suggests to make stricter access rules to +prevent spam: ``There will be a group of `Validated' people which +following rules: only `Validated' people can edit general content and +`Validated' people can add new people to `Validated' themselves''. That means that we can have a lightweight self-administrating authentication where new people have to be introduced by someone who is already there. -Ichthyo suggests to send a reply to Serge G. who send an introduction +_Ichthyo_ suggests to send a reply to Serge G., who send an introduction to the cinelerra mailing list expressing that he would like to help. -Raffa will take care of content/design as much her time/knowledge permits. +_Raffa_ will take care of content/design as much her time/knowledge permits. Conclusion @@ -69,25 +70,25 @@ Conclusion * We really need someone to help with the webpage scripting. * Documentation needs to be well organized and moved over. - * Content of the pipapo.org moinmoin wiki should be moved over. - * The new website should be well organized with a nice looking frontpage + * Content of the pipapo.org MoinMoin wiki should be moved over. + * The new website should be well organized with a nice looking front page * All other documentation should be below that -Whats pending in link:DesignProcess[] -------------------------------------- +Whats pending in the DesignProcess / RfC +---------------------------------------- MistakestoAvoid ~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[] +link:{rfc}_dropped/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design] -rick_777 wrote a "MistakestoAvoid" page which explains some possible +_rick_777_ wrote a "MistakestoAvoid" page which explains some possible gotchas. We basically agree with most points there while we already decided to address some things differently than he suggested. One -noteable difference is that we do not intent to provide a windows -version of Lumiera, which was explained in serveral places. Cehteh +notable difference is that we do not intent to provide a windows +version of Lumiera, which was explained in several places. _Cehteh_ added some comments to the page explaining some things. @@ -96,29 +97,28 @@ nothing more to discuss in \'Ideas', we go over to \'Drafts' ArchitectureOverview ~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[] +link:{rfc}/ArchitectureOverview.html[RfC: Architecture Overview] -Cehteh suggests to put that drawing under version control, as .fig. -Ichthyo explains that it is already a .SVG and that he does not like -.fig. +_Cehteh_ suggests to put that drawing under version control, as .fig. +Ichthyo explains that it is already a `.SVG` and that he does not favour `.fig`. -Conclusion: We agree to keep it as .SVG, add it to the repository and +Conclusion:: We agree to keep it as `.SVG`, add it to the repository and improve/complete it. GitSubmoduleTransistion ~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GitSubmoduleTransistion[] +link:{rfc}/GitSubmoduleTransistion.html[RfC: Git Submodules] -Another suggestion made by cehteh is to make managing of subprojects -within the sourcetree easier. Joel and ichthyo oppose that it is not -really needed now and needs more understanding of git. Ichthyo -suggests that the documentation might be separated into its own git, +Another suggestion made by _Cehteh_ is to make managing of subprojects +within the sourcetree easier. _Joel_ and _Ichthyo_ object that it is not +really needed now and needs more understanding of Git. _Ichthyo_ +suggests that the documentation might be separated into its own Git, he further explains that the things are not settled yet and we don't know if we will some rearrangements and movements of files between modules. -Conclusion: We transform the documentation to a submodule and see how +Conclusion:: We transform the documentation to a submodule and see how it works. Other things will be decided much later. @@ -126,19 +126,19 @@ it works. Other things will be decided much later. GlobalInitialization ~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GlobalInitialization[] +link:{rfc}/GlobalInitialization.html[RfC: Global Init] -This topic is discussed and agreed on the link:DesignProcess[] page already. +This topic is discussed and agreed on the RfC page already. -Conclusion: finalize it +Conclusion:: finalize it MasterRepositorySetup ~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MasterRepositorySetup[] +link:{rfc}/MasterRepositorySetup.html[RfC: Shared Master Repository] Setting up an master repository was decided on the last meeting. -cehteh now set one up which also does some automatic, but intended +_Cehteh_ now set one up which also does some automatic, but intended fragile merging from subsystem maintainer branches. 1. it updates automatically for the maintainers repo for conflict free fast-forwards @@ -146,7 +146,7 @@ fragile merging from subsystem maintainer branches. The others agree on the setup. -Ichthyo stresses that maintainers shall watch that their \'master' +Ichthyo stresses that maintainers shall watch that their `master' branch should compile cleanly and pass the testsuite always, test which are not operational should be tagged as PLANNED. We all agree, while cehteh's master is currently in a broken state (note: @@ -155,9 +155,9 @@ fixed now). Then a short discussion about building and synchronizing the docs follows. Problem is that docs build in maintainer branches are different for each branch, rsyncing them up to the server will always -change a lot of things. We agree that the \'official' docs shall be -build from the LUMIERA/master repository, preferably on the \'devel' -vserver which has to be set up. +change a lot of things. We agree that the ``official'' docs shall be +build from the LUMIERA/master repository, preferably on the "devel" +VServer which has to be set up. Conclusions: Make this final, setup build environment in the devel server and build docs there. @@ -166,28 +166,28 @@ server and build docs there. NoBugFlags ~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/NoBugFlags[] +link:{rfc}/NoBugFlags.html[RfC: NoBug flags] Defining a debugging control hierarchy. This is work in progress and -cehteh explains that he works it out and deploys it, this depends on -the link:GlobalInitialization[] decided earlier. +_Cehteh_ explains that he works it out and deploys it, this depends on +the link:{rfc}/GlobalInitialization.html[GlobalInitialization] decided earlier. -Conclusion: accepted, finish and finalize it. +Conclusion:: accepted, finish and finalize it. Further Technical Discussion ---------------------------- -Ichthyo asks how the GUI will be pulled up. Since he didn't attend IRC +_Ichthyo_ asks how the GUI will be pulled up. Since he didn't attend IRC discussions recently he has no information yet whats going on. We explain him that we already made some discussions. Integrate the GUI into the build system probably linked as library, nothing finally decided yet. Communication will go over the plugin/interface facility (Plain C API). This things should be worked out and documented in -link:DesignProcess[]. +link:/x/DesignProcess.html[RfCs]. -Cehteh made a small tool `./admin/headercheck` which will gradually +_Cehteh_ made a small tool `./admin/headercheck` which will gradually extended to proof that headers are sufficiently selfstanding. @@ -195,42 +195,42 @@ extended to proof that headers are sufficiently selfstanding. Progress -------- -Cehteh finished low level file handling and working in mmaping and +_Cehteh_ finished low level file handling and working on mmapping and frameprovider next. When thats finished, the finalization of the Plugin loader and interface definition things is the most urgent thing. -Ichthyo works on the builder internals and next on some sort of -"connection manager". +_Ichthyo_ works on the builder internals and next on some sort of +``connection manager''. -Joel goes on with GUI programming and integrating it into the source +_Joel_ goes on with GUI programming and integrating it into the source tree next. -Gmerlin and cehteh discuss about how to handle the index files which -avdecoder uses internally. cehteh would like to manage them in the +_Gmerlin_ and _cehteh_ discuss about how to handle the index files which +avdecoder uses internally. _cehteh_ would like to manage them in the Lumiera backend to, because filehandles are a precious resource. -Gmerlin explains that this index files are just loaded and kept in +_Gmerlin_ explains that this index files are just loaded and kept in memory. So this poses no problem for filehandle exhaustion. We will discuss this further via email. -Cehteh suggests that we should think about some kind of +_Cehteh_ suggests that we should think about some kind of preferences/registry sometime next to store default configs. -Following a discussion about how messages are passed between GUI and +A a discussion followed about how messages are passed between GUI and core. Generally we will use the interfaces defined by the plugin -system. Gmerlin says that he uses message queues in \'gmerlin', Joel +system. _Gmerlin_ says that he uses message queues in `gmerlin', _Joel_ requests that a lot of things should be done synchronous and he wants -to avoid message queues. Cehteh suggests to use use the scheduler for +to avoid message queues. _Cehteh_ suggests to use use the scheduler for GUI things too. For the parts where the GUI interacts with the high -level proc model ichthyo and joel agree on working something -(synchronous) out. Ichthyo stresses that the edit core is not +level proc model _ichthyo_ and _joel_ agree on working something +(synchronous) out. _Ichthyo_ stresses that the edit core is not threadsafe by design and relies on the backends scheduler. The underlying builder might sometimes to expensive for synchronous -calls (ichthyo plans a rule system there) this needs to be worked out. +calls (_ichthyo_ plans a rule system there) this needs to be worked out. -Ichthyo explains that the builder needs to detect cycles and check if +_Ichthyo_ explains that the builder needs to detect cycles and check if the high level model is translateable into the low level model (in case plugins git removed and so on). Parts in the render graph which -are not \'doable' should be flagged as erroneous but not dropped since +are not ``doable'' should be flagged as erroneous but not dropped since one doesn't want to loose project information when loading a project on a machine with different installed plugins. In any case it should be possible that the GUI gets immediate synchronous feedback for such diff --git a/doc/devel/meeting_summary/2008-06-06.txt b/doc/devel/meeting_summary/2008-06-06.txt index 20088b68c..9a9bdb468 100644 --- a/doc/devel/meeting_summary/2008-06-06.txt +++ b/doc/devel/meeting_summary/2008-06-06.txt @@ -23,41 +23,61 @@ Discuss Ideas and Drafts in design process ------------------------------------------ There are no new design proposals and no proposals that can be finalized. -Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in "idea" state. Following that, most of the meeting is spent on discussing the details of two of these proposals. +Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in `Idea' state. +Following that, most of the meeting is spent on discussing the details of two of these proposals. Idea: Design the Render Nodes interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface[] +link:{rfc}/DesignRenderNodesInterface.html[RfC / Call for a Render Node interface] -*Cehteh* points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. Later on, interface versions will be numbered. If needed, we could add a special "draft" or "experimental" tag, or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface. +_Cehteh_ points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. +Later on, interface versions will be numbered. If needed, we could add a special ``draft'' or ``experimental'' tag, +or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface. -*Ichthyo* agrees, but adds he also meant "interface" in this proposal in a wider sense, like in "what do we need and require from a processing node". Knowing how generally Lumiera will handle the processing nodes while rendering helps him with defining and implementing the builder +_Ichthyo_ agrees, but adds he also meant ``interface'' in this proposal in a wider sense, +like in ``what do we need and require from a processing node''. +Knowing how generally Lumiera will handle the processing nodes while rendering helps him +with defining and implementing the builder -__Conclusion__: "currently in work". For now, grow interfaces on demand. +Conclusion:: ``currently in work''. For now, grow interfaces on demand. Idea: Placement Metaphor used within the high-level view of Proc-Layer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[] +link:{rfc}/ProcPlacementMetaphor.html[RfC: Placement Metaphor] -In the course of the discussion, *Ichthyo* explains the rationale +In the course of the discussion, _Ichthyo_ explains the rationale * one common mechanism for sticking objects together and putting them into the session - * either specify the "placement"-parameters (time, output destination, track) directly, link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks) + * either specify the ``placement''-parameters (time, output destination, track) directly, + link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks) * ability to build a system of high-level media objects (clips, effects...) which re-adjust automatically on change - * extensible to handle or derive some parameters based on conditions and rules, e.g. for semi-automatic wiring of the output destination based on tags + * extensible to handle or derive some parameters based on conditions and rules, + e.g. for semi-automatic wiring of the output destination based on tags -*Joelholdsworth* is concerned that this proposal may go too far and tries to tie things together which aren't really connected. While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object, he can't see a clear benefit of controlling sound pan or video layer order from the placement. Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment. For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output, layer number or sound pan would be properties of the object. +_Joelholdsworth_ is concerned that this proposal may go too far and tries to tie things together which aren't really connected. +While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object, +he can't see a clear benefit of controlling sound pan or video layer order from the placement. +Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment. +For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output, +layer number or sound pan would be properties of the object. -But that's exactly what Ichthyo wants to avoid. Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases. But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing, working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video. +But that's exactly what _Ichthyo_ wants to avoid. +Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases. +But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing, +working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video. -On the whole, there is no conclusion yet. Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments), maybe parts of the functionality should be separated out. +On the whole, there is no conclusion yet. +Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments), +maybe parts of the functionality should be separated out. While in this discussion, several aspects of the cooperation of GUI and Proc layer are considered. - * it is not necessary to make all of the Placement proposal visible to the GUI (and the user). Proc layer may as well provide a simplyfied and hard wired API for the most common properties (layer index, pan) and only use this part of the Placement concept for building and wiring the nodes. + * it is not necessary to make all of the Placement proposal visible to the GUI (and the user). + Proc layer may as well provide a simplified and hard wired API for the most common properties (layer index, pan) + and only use this part of the Placement concept for building and wiring the nodes. * the adjustment of objects linked together by a placement can be handled as follows: . GUI notifies Proc of a position/parameter change of one object and gets immediate, synchronous feedback (OK or fail) . Proc detects the other linked objects affected by the change and notifies GUI (both synchronous and asynchronous is possible) to update information regarding those objects diff --git a/doc/devel/meeting_summary/2008-07-06.txt b/doc/devel/meeting_summary/2008-07-06.txt index a7255a802..55415dee9 100644 --- a/doc/devel/meeting_summary/2008-07-06.txt +++ b/doc/devel/meeting_summary/2008-07-06.txt @@ -23,7 +23,7 @@ Boilerplate Organization of this meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * dmj726 intends to write the protocol - * ichtyo is chairman + * _Ichthyo_ is chairman * there is no agenda, so this is a freeform meeting Leftovers from last meeting @@ -37,18 +37,21 @@ Because there are quite some new participants, an introduction of the project Lu There are 3 core devs: - * ichthyo: proc layer, render graph, in the middle, C++, he maintains scons - * cehteh: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git - * joelholdsworth: GUI in C++/Gtkm + * _Ichthyo_: proc layer, render graph, in the middle, C++, he maintains SCons + * _Cehteh_: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git + * _JoelHoldsworth_: GUI in C++/Gtkmm + Other people involved: - * rcbarnes: ui designer and coder - * raffa: web content - * Simav: gives a hand when and where he can - * Teld: web infrastructure -The foundations of the design are already done but a lot of detail needs to be worked out. cehteh and ichtyo provide a non exhaustive list. + * _rcbarnes_: ui designer and coder + * _raffa_: web content + * _Simav_: gives a hand when and where he can + * _Teld_: web infrastructure -cehteh: +The foundations of the design are already done but a lot of detail needs to be worked out. +_Cehteh_ and _Ichtyo_ provide a non exhaustive list. + +_Cehteh_: * improvement of the testsuite (simple Bash) * start of a worker thread manager (Posix knowledge required) @@ -58,35 +61,53 @@ cehteh: * system administration * setup of a build/test environment on the server * setup and maintain postfix/dovecot by a mail administrator -ichtyo: + +_Ichthyo_: * asset management (keeping track of all media files, captures, clips, scenes) * session loading saving and the issues of compound documents * session structure related issues to be able to Import/Export/Connect via e.g. OSC (Open Sound Control) or JACK - * flesh out the more high level "edit operations" and the interface to UNDO - * Prolog integration after the first integration round has been reached. The Prolog interpreter will do some of the more advanced configuration (example: if effect XYZ is used, then deinterlace beforehand). + * flesh out the more high level ``edit operations'' and the interface to UNDO + * Prolog integration after the first integration round has been reached. + The Prolog interpreter will do some of the more advanced configuration + (example: if effect XYZ is used, then deinterlace beforehand). * integration with some sort of production support software (like Celtx) -cehteh emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit as long as he communicates and acknowledges with the persons involved. ichtyo points out that the plugin structure is very important: anything that is not legally completely clean (proprietary), should be factored out into a sister project and be loaded as plugin. + +_Cehteh_ emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit +as long as he communicates and acknowledges with the persons involved. +_Ichthyo_ points out that the plugin structure is very important: anything that is not legally completely clean +(e.g. proprietary technology), should be factored out into a sister project and be loaded as plugin. Issues and questions that come up --------------------------------- - * handling of config errors. -When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. Therefore, the config system will be built to log a warning and the user code does not need to care. The user just gets an alert and the application continues to work. + * handling of config errors. + +When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. +Therefore, the config system will be built to log a warning and the user code does not need to care. +The user just gets an alert and the application continues to work. * scripting language. -There will be a scripting interface. ichtyo does not want scripts everywhere, only at well defined interfaces. That implies also that scripts cannot just do anything, only that what is permitted in a controlled way. The meeting agrees on that. cehteh wants one default language and proposes Lua: light, simple. ++ +-- +There will be a scripting interface. _Ichthyo_ does not want scripts everywhere, only at *well defined interfaces*. +That implies also that scripts _cannot just do anything,_ only that what is permitted in a controlled way. +The meeting agrees on that. _Cehteh_ wants one default language and proposes Lua: light, simple. Other members suggestions: Python, Ruby, Scheme. However, Python and Ruby are very slow. Scheme has many variants. +-- - * editing on small devices (eeePC) -Problem: video editors GUIs are some of the most elaborate and complicated GUIs. However, basic functions consist of only a few buttons. Proxy editing could be a solution. It is decided that it is not a primary goal now. First the basics have to be implemented. + * editing on small devices (eeePC) + +Problem: video editors GUIs are some of the most elaborate and complicated GUIs. +However, basic functions consist of only a few buttons. Proxy editing could be a solution. +It is decided that it is not a primary goal now. First the basics have to be implemented. - * uWiki. + * uWiki. + uWiki is the glue between a markup driver (Asciidoc) and revision control (git). Haserl with Bash is used now. Haserl appears to have problems with conditional includes. Its limits have been reached while prototyping. Lua could very well be a valid replacement. It will be investigated. PHP is rejected because it is not stable and suffers from serious security problems. - * \'musical\' timeline in bars and beats -The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. Discussion is still going on, especially with the GUI developer joelholdsworth. See for detailed information: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[] + * ``musical'' timeline in bars and beats + +The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. +Discussion is still going on, especially with the GUI developer _JoelHoldsworth_. +See for detailed information: link:{rfc}/ProcPlacementMetaphor.html[RfC Placement Metaphor] Next meeting diff --git a/doc/devel/meeting_summary/2008-09-04.txt b/doc/devel/meeting_summary/2008-09-04.txt index dbb7b0e5a..697300b84 100644 --- a/doc/devel/meeting_summary/2008-09-04.txt +++ b/doc/devel/meeting_summary/2008-09-04.txt @@ -29,11 +29,11 @@ There are no leftovers Mailing Lists ------------- - * any improvements should be reported to cehteh - * need volunteers to be moderators. The only volunteers are cehteh and joelholdsworh_ + * any improvements should be reported to _cehteh_ + * need volunteers to be moderators. The only volunteers are _cehteh_ and _joelholdsworh_ * moderating the ML might not be that big a job - we might not get that much spam * it's preferable to allow people to post to the mailing list even if they're not subscribed - * cehteh eventually wants the mailing list to interact with uwiki. + * _cehteh_ eventually wants the mailing list to interact with uwiki. Plugin Interfaces ----------------- @@ -41,7 +41,7 @@ Plugin Interfaces * this includes enumerating structured data within the plugins. It might sometimes be desirable to store this in a text file, but in this case still the list will be exported through the interfaces. If this were not the case, it would not be possible to make plugins which are wrappers of LADSPA plugins for example. * For a lumiera plugin there is only one entry point, thats an interface itself which bootstraps all the other interfaces in that plugin. -Lib Dependancy Problems +Lib Dependency Problems ----------------------- * we've agreed to stick to one compatibility level: Debian/Lenny for perhaps up to 3 years from now * others will be supported - RedHat etc. @@ -49,7 +49,7 @@ Lib Dependancy Problems Builds and Buildbot ------------------- * ichthyo asks for help setting up a test/build server - * We now have build scripts based on scons and autotools. + * We now have build scripts based on SCons and Autotools. * All current build systems have different problems. * ichthyo will take care of the Debian packages for Lumiera and NoBug @@ -69,6 +69,6 @@ The next meeting will be held Thursday, 2 oct 21:00 utc. Comment ~~~~~~~ -re "ichthyo asks for help setting up a test/build server" for "Debian" +re ``ichthyo asks for help setting up a test/build server'' for "Debian" -see "Build Server" at http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming?action=edit&editor=gui[] +see "Build Server" at [purple]## diff --git a/doc/devel/meeting_summary/2008-10-10.txt b/doc/devel/meeting_summary/2008-10-10.txt index 93de6ca38..0f33162ed 100644 --- a/doc/devel/meeting_summary/2008-10-10.txt +++ b/doc/devel/meeting_summary/2008-10-10.txt @@ -11,7 +11,7 @@ __Participants__ * ichthyo * joelholdsworth * alcarinque - * !KenSentMe + * KenSentMe * Plouj * raffa * thorwil @@ -30,7 +30,7 @@ The Lumiera Logo ---------------- Summary of the situation: discussion regarding a logo for Lumiera is going on sporadically since quite some time. Several people from the community have made proposals. Also, there was discussion about the criteria a logo would have to fulfil. Especially the core devs raised the bar and required quite some professional level of design. On the contrary, several members of the community were concerned that such a demanding attitude will hinder creativity in a domain which is far off from coding. Moreover, many people complained they are really excited about Lumiera and strongly want to participate in some manner, but find it very difficult in the current phase of the project to give any valuable contribution. -This summer, one of the proposals by http://farm4.static.flickr.com/3060/2927333034_ac94be80ea_b.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and http://www.pipapo.org/pipawiki/JoelHoldsworth/LogoThoughts[explained] his reservation. Prior to this meeting some people joined a brainstorming session and came up with http://www.pipapo.org/pipawiki/Lumiera/Logos?action=AttachFile&do=get&target=combo.png[another design] compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users. +This summer, one of the proposals by link:{imgg}/LumieraLogoLeonardoRiberio.2008.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and explained [purple]## his reservation. Prior to this meeting some people joined a brainstorming session and came up with _another design_([purple]#broken-URL `combo.png`#) compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users. Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest: @@ -48,7 +48,7 @@ Conclusion There will be a Lumiera Logo contest. * we should further discuss requirements on the Mailinglist until the end of the next week - * the '''deadline for submissions''' will be the next meeting (Nov 12 2008) + * the *deadline for submissions* will be the next meeting (Nov 12 2008) * then, after a pre-selection phase, the vote shall be conducted prior to the December meeting. Some minimal technical requirements will be enforced: @@ -63,7 +63,7 @@ Some minimal technical requirements will be enforced: Besides, we give some artistic guidelines * it should be recognisable - * it should contain something like a sign, not just "Lumiera" in a fancy font + * it should contain something like a sign, not just ``Lumiera'' in a fancy font * it should not rely on transparencies, gradients and subtle shades, * it should be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented @@ -75,22 +75,22 @@ Raffa volunteers to help organizing the contest and the voting. Recurring Topics: design proposals ---------------------------------- -Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. Mistakes to avoid ~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[Mistakes to avoid in the Lumiera Design] +link:{rfc}/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design] We are carrying this one along since quite some time and we'd like to get rid of it, either by reworking it or by dropping it as-is. Because it contains a mixture of things * we fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic here. We are aware of the recurring problems with open source video editing. That's why we are here. - * the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements. + * the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to underpin these statements. -While it is certainly ''desirable'' to be cross-platform as much as possible and especially '''target Microsoft Windows''', we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform. +While it is certainly _desirable_ to be cross-platform as much as possible and especially *target Microsoft Windows*, we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform. -While it is certainly ''desirable'' to make the application as robust as possible, we don't see how '''using multiple separate processes''' could help us with this goal ''without creating major scalability or performance problems'' due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner. +While it is certainly _desirable_ to make the application as robust as possible, we don't see how *using multiple separate processes* could help us with this goal _without creating major scalability or performance problems_ due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner. -__Conclusion__: drop it +[underline]#Conclusion#: drop it on the question of separate processes @@ -101,8 +101,8 @@ The only practical solution would be to separate the GUI. Separating backend and Tag Clouds ~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TagCloudsOnResources[Tag clouds on resources] -Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DelectusShotEvaluator["Delectus"] +link:{rfc}/TagCloudsOnResources.html[Tag clouds on resources] + +Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: link:/x/Delectus.html[»Delectus«] __Conclusion__: drop it @@ -111,7 +111,7 @@ __Conclusion__: drop it Overview of Lumiera Architecture ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[Architecture Overview] +link:{rfc}/ArchitectureOverview.html[Architecture Overview]: The purpose of this drawing to give an first impression what subsystem is where and what the names mean. Since discussed last time, Ichthyo re-arranged the plugins as requested and added some details for the backend. Joelholdsworth points out that it's OK for him to show the GUI just as a single block here (and of course the GUI has much more internal structure). Cehteh adds that maintaining this drawing surely is a moving target, so we better remove the rendered image and just retain the textual description and link to the source (SVG), which is in GIT. __Conclusion__: accept it, change the image to a link @@ -121,7 +121,7 @@ __Conclusion__: accept it, change the image to a link EDLs as Meta-Clips ~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/EDLsAreMetaClips[EDLs are meta-clips] +link:{rfc}/EDLsAreMetaClips.html[EDLs are meta-clips] + This is just a high-level proposal, which doesn't go into technical details of implementing nested EDLs. It just poses the question "do we want to treat nested EDLs as being meta-clip" -- which we do. __Conclusion__: accepted @@ -131,7 +131,7 @@ __Conclusion__: accepted The Builder ~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcBuilder[Builder in the Proc-Layer] +link:{rfc}/ProcBuilder.html[Builder in the Proc-Layer] + Similar to the previous one, this is a high-level proposal. It covers the fundamental approach Ichthyo takes within the Proc-Layer. Cehteh adds that he agrees to 98% and the remaining 2% are just matter of favour. Personally, he would have preferred one large graph which gets garbage collected (instead of the segmented graph) __Conclusion__: accepted @@ -141,7 +141,7 @@ __Conclusion__: accepted High-level Model ~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcHighLevelModel[Overview of the High-level model within the Proc-Layer] +link:{rfc}/ProcHighLevelModel.html[Overview of the High-level model within the Proc-Layer] + Cehteh queries if this shouldn't be better moved over to the documentation? He is fine with the contents, but it seems to be a bit voluminous for a design proposal. Ichthyo asks to leave it there just for now, as he feels it still needs review. __Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation? @@ -151,8 +151,16 @@ __Conclusion__: leave it for now, maybe retract it from the design proposals and Lua scripting language ~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ScriptingLanguage[use Lua as required scripting language] -All core devs agree with this decision. Joelholdsworth points out that he is fine with Lua, just he didn't want to write the GUI in it. Ichthyo adds that Lua is probably the best choice from today's mainstream scripting languages, because it is very lightweight. He further points out, that having Lua as ''required'' scripting language doesn't rule out using other popular languages (Python, Ruby) for scripting. Just they aren't required for running Lumiera. Cehteh will have a look at the details as soon as possible, but has currently other more urgent things in the queue. (Plouj shows interest to help here) +link:{rfc}/ScriptingLanguage.html[use Lua as required scripting language] + +All core devs agree with this decision. +_Joelholdsworth_ points out that he is fine with Lua, just he didn't want to write the GUI in it. +_Ichthyo_ adds that Lua is probably the best choice from today's mainstream scripting languages, +because it is very lightweight. He further points out, that having Lua as _required_ scripting language +does not rule out using other popular languages (Python, Ruby) for scripting. +Just they aren't required for running Lumiera. +_Cehteh_ will have a look at the details as soon as possible, +but has currently other more urgent things in the queue. +(_Plouj_ shows interest to help here) __Conclusion__: accepted @@ -161,8 +169,8 @@ __Conclusion__: accepted Time Handling ~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[time handling] -A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done ''on demand.'' Joelholdsworth sais sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time. +link:{rfc}/TimeHandling.html[time handling] + +A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done _on demand._ Joelholdsworth says sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time. __Conclusion__: accepted @@ -171,7 +179,7 @@ Note: the proposed rigid testsuite for time handling is necessary only when we i Interface naming convention ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -See the design proposal http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/InterfaceNamespaces[Interface Namespaces]. While working on the plugin loader, '''Cehteh''' and '''nasa''' did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry. +See the design proposal link:{rfc}/InterfaceNamespaces.html[Interface Namespaces]. While working on the plugin loader, _Cehteh_ and _nasa_ did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry. __Conclusion__: accepted @@ -180,13 +188,23 @@ general Topics Config System ------------- -'''cehteh''' landed the first version of this subsystem and asked for review and testing. Currently it's "work with no progress", but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type). +_Cehteh_ landed the first version of this subsystem and asked for review and testing. Currently it's ``work with no progress'', but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type). Use of Namespaces ----------------- -Currently there is no clear uniform rule regarding namespaces use. *Joelholdsworth* places his code within lumiera::gui and below. He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies and all of Lumiera should comply and put anything below a lumiera:: root. On the contrary, *Ichthyo* deliberately moved his implementation code away from the central lumiera:: interface hierarchy into shallow namespaces and avoids nesting. He argues that having all code below lumiera:: effectively makes this namespace global or forces it to be void of any function; rather he'd prefer to import every interface explicitly into the implementation namespace. *Cehteh* argues that having a global lumiera::, even if empty, would mark a general claim and stand for the uniformity of the project. Generally, there should be some correspondence between folders and namespaces. +Currently there is no clear uniform rule regarding namespaces use. +_JoelHoldsworth_ places his code within lumiera::gui and below. +He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies +and all of Lumiera should comply and put anything below a lumiera:: root. +On the contrary, _Ichthyo_ deliberately moved his implementation code away from the central `lumiera::` +interface hierarchy into shallow namespaces and avoids nesting. +He argues that having all code below `lumiera::` effectively makes this namespace global or forces it to be void of any function; +rather he'd prefer to import every interface explicitly into the implementation namespace. +_Cehteh_ argues that having a global `lumiera::`, even if empty, +would mark a general claimand stand for the uniformity of the project. +Generally, there should be some correspondence between folders and namespaces. No conclusion yet, to be discussed further. @@ -194,9 +212,13 @@ No conclusion yet, to be discussed further. Interface Definition Language ----------------------------- -In his work on the plugin loader, '''Cehteh''' created a first draft how to export an interface, and calls for review. An example can be found in http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=tests/backend/test-interfaces.c;h=fb1c4d30a34414767a313d24df60e679c96ad2a7;hb=7323114e77348995ccaf03417136aef7ee332776[tests/backend/test-interfaces.c] +In his work on the plugin loader, _Cehteh_ created a first draft how to export an interface, and calls for review. +An example can be found in +https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/backend/test-interfaces.c;h=09fa25afa3cb57b79a2717d0bf3a8253afeba000;hb=ebcc5c7fd2d8700f3375e3309b724ac2517a0f40[tests/backend/test-interfaces.c] -An interface is a list of "slots" mapping functions. The interface descriptor is itself realised as interface, an thus can be versioned, extended and specialised. By use of some glue code and macros we create a simple Interface Definition Language +An interface is a list of »slots« mapping functions. The interface descriptor is itself realised as interface, +and thus can be versioned, extended and specialised. +By use of some glue code and macros we create a simple Interface Definition Language * after exporting a header with the C interface, including the types to be used... * LUMIERA_INTERFACE_DECLARE creates an interface description (i.e. the official interface) @@ -204,22 +226,33 @@ An interface is a list of "slots" mapping functions. The interface descriptor is * LUMIERA_INTERFACE_INSTANCE creates an instance on-the-fly (e.g. for descriptors) * LUMIERA_EXPORT for defining a table of functions/interfaces to export from the core * LUMIERA_PLUGIN for defining an interface table for functions located within a dynlib module (plugin) - * besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps onto an existing function directly + * besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps + onto an existing function directly -The plugin loading system cares for mapping the given implementation function to the interface slots. Interfaces from the core need to be registered before they can be used, while for plugins this is done automatically on loading the module. The client code later just calls {{{interface_open()}}} and {{{interface_close()}}} where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, registry and/or plugin-DB shall manage it transparently. +The plugin loading system cares for mapping the given implementation function to the interface slots. +Interfaces from the core need to be registered before they can be used, +while for plugins this is done automatically on loading the module. +The client code later just calls `interface_open()` and `interface_close()` +where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, +registry and/or plugin-DB shall manage it transparently. -Version numbering starts with 1 and uses minor version numbers for compatible changes and major version numbers for everything that breaks existing asumptions. Version number zero is reserved for experimental work and per definition always the most recent version number. +Version numbering starts with 1 and uses minor version numbers for compatible changes +and major version numbers for everything that breaks existing assumptions. +Version number zero is reserved for experimental work and per definition always the most recent version number. The system is designed to be very flexible and extensible, but this foundation really needs thorough review. -Joelholdworth expresses some concern regarding the UIDs in octal notation used within the interface description. Cehteh explains they never need to be specified by client code. They are just distinctive IDs and provided for some special case within the plugin loader / serializer. He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code. +_Joelholdworth_ expresses some concern regarding the UUIDs in octal notation used within the interface description. +_Cehteh_ explains they never need to be specified by client code. +They are just distinctive IDs and provided for some special case within the plugin loader / serializer. +He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. +The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code. Conclusion ~~~~~~~~~~ -looks good, agreement by all core devs. - + +Looks good, agreement by all core devs. + Should be reviewed and investigated in detail to find any hidden problems. @@ -227,6 +260,7 @@ Should be reviewed and investigated in detail to find any hidden problems. Next meeting ------------ -There were some problems with the meeting schedule. Using the first week of month seems to be problematic. We'll try with second wednesday... +There were some problems with the meeting schedule. Using the first week of month seems to be problematic. +We'll try with second Wednesday... -The next meeting is scheduled for '''Wednesday Nov 12 2008 19:30 UTC''' at #lumiera +The next meeting is scheduled for **Wednesday Nov 12 2008 19:30 UTC** at #lumiera diff --git a/doc/devel/meeting_summary/2008-11-12.txt b/doc/devel/meeting_summary/2008-11-12.txt index f48d4e6e0..7b5cc42bc 100644 --- a/doc/devel/meeting_summary/2008-11-12.txt +++ b/doc/devel/meeting_summary/2008-11-12.txt @@ -48,7 +48,7 @@ eg. fader, panner, blur. _joelholdsworth_ points out that configurability can't replace real GUI and workflow design. He quotes from a recent Blender GUI discussion -[quote, the Belnder UI reviews] +[quote, the Blender UI reviews] ____________________________________________________________________ Lastly, I’d like to address another misconception, this time about customizability. There has been a notion that the solution to most of the UI problems can be solved with added customizability. @@ -71,7 +71,7 @@ from the defaults to match another 3D application such as Maya or Softimage XSI for users of those applications to adapt to Blender. ____________________________________________________________________ -Consequently, Joel wants to try just doing the UI _right_, then add a little bit of customization back in here and there. +Consequently, _Joel_ wants to try just doing the UI _right_, then add a little bit of customization back in here and there. Additionally, agreement is to have a kind-of ``perspective switcher'' (like in Eclipse), so saving different panel layouts would be covered easily diff --git a/doc/devel/meeting_summary/2008-12-10.txt b/doc/devel/meeting_summary/2008-12-10.txt index 412a89a95..5f3290822 100644 --- a/doc/devel/meeting_summary/2008-12-10.txt +++ b/doc/devel/meeting_summary/2008-12-10.txt @@ -23,17 +23,17 @@ __Participants__ The Lumiera Logo ---------------- -The logo contest is a great success: http://www.pipapo.org/pipawiki/Lumiera/Logos[105 entries]. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection[presented] so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight. +The logo contest is a great success: *105 entries*. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are presented ([purple]#`http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection`#) so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight. Recurring Topics ---------------- -Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. EDL vs Sequence ~~~~~~~~~~~~~~~ -There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in [wiki:self:../DesignProcess/TimelineSequenceOutput Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows. +There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in link:{rfc}/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows. __Conclusion__: the name Sequence will be used instead of EDL @@ -45,7 +45,7 @@ Ichtyo explains that the idea is that between layers only the C Language interfa Threads ~~~~~~~ -The UI will mostly run on a single thread, i.e. gtk_main will run in this GUI thread and when it terminates, the GUI is "done" and signals back that it is done. Cehteh points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation +The UI will mostly run on a single thread, i.e. »gtk_main« will run in this GUI thread and when it terminates, the GUI __is ``done''__ and signals back that it is done. _Cehteh_ points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation. @@ -55,12 +55,12 @@ General Topics Video format ~~~~~~~~~~~~ -Kirk asks to what video format footage has to be converted so that it can be used in Lumiera. Ichtyo and cehteh point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way. +_Kirk_ asks to what video format footage has to be converted so that it can be used in Lumiera. _Ichtyo_ and _Cehteh_ point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way. Knowledge base ~~~~~~~~~~~~~~ -Kirk has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. Kirk proposes to help in this area. +_Kirk_ has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. _Kirk_ proposes to help in this area. diff --git a/doc/devel/meeting_summary/2009-01-14.txt b/doc/devel/meeting_summary/2009-01-14.txt index 2a6f0b4ba..4531e2702 100644 --- a/doc/devel/meeting_summary/2009-01-14.txt +++ b/doc/devel/meeting_summary/2009-01-14.txt @@ -36,54 +36,72 @@ Conclusion ~~~~~~~~~~ Two groups are created, each of these have someone responsible to bring them forward. -The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This 'supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it. +The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This `supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it. Work discussion will proceed on the Mailing List but following the directions stated during the IRC meetings. + -Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. [[BR]] Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization. +Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. + +Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization. Group 1 [WORKFLOW] ^^^^^^^^^^^^^^^^^^ - . director/supervisor: nikola_ (Nikola Duper) -Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout. + -The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs.[[BR]] The core dev responsible for the GUI is joelholdsworth (Joel Holdsworth).[[BR]] One of the group goals is to make the dev point of view dialogate with the editor point of view. + . director/supervisor: _nikola_ (Nikola Duper) +Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout. -The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs. + -It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. [[BR]] It thinks about ergonomics. +- The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs. + +- The core dev responsible for the GUI is _joelholdsworth_ (Joel Holdsworth). + +- One of the group goals is to create a dialogue between the developer's point of view and the editor's point of view. + +The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs. + +It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. + +It considers aspects of ergonomics. Group 2 [ARTWORK] ^^^^^^^^^^^^^^^^^ - . director/supervisor: raffa (Raffaella Traniello) + . director/supervisor: _raffa_ (Raffaella Traniello) The group discuss about logo, themes, the look and feel... Getting the 'non-coders' community to help ------------------------------------------ -goibhniu proposes an issue tracker. +_goibhniu_ proposes an issue tracker. -The documentation needs love: it's currently horribly scattered all around. + -All the content needs to be converted to asciidoc and to the git repo at lumiera.org.[[BR]] Waiting for uWiki, the site will be in asciidoc+git [[BR]] The site needs a structure or other means to increase discoverability of all our information[[BR]] goibhniu proposes organizing a "sprint" to help get people involved and set a date for it (documentation migration/organisation) +* The documentation needs love: it's currently horribly scattered all around. +* All the content needs to be converted to asciidoc and to the git repo at lumiera.org. +* Waiting for uWiki, the site will be in asciidoc+git +* The site needs a structure or other means to increase discoverability of all our information +* _goibhniu_ proposes organizing a ``sprint'' to help get people involved and set a date for it (documentation migration/organisation) Conclusion ~~~~~~~~~~ - * goibhniu volunteers to set up Trac. - * raevol volunteers to maintain it. - * The link:AsciiDoc[] Day idea will be discussed at the next meeting. + * _goibhniu_ volunteers to set up *Trac*. + * _raevol_ volunteers to maintain it. + * The »*AsciiDoc Day*« idea will be discussed at the next meeting. Possible GUI-Integration: Display a frame? ------------------------------------------ There was some discussion about the need for a component which does the timing and communicates with the scheduler and where it should sit in the stack. -For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality. The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend. It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning. It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server. It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks. For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later. +For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality. +The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend. +It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning. +It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server. +It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks. +For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later. The devs agreed to meet up on Saturday to get the latest version up and running. -http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=src/common/guifacade.cpp;h=7f781845ad79b4a3e2cd820b96b87f5e702a80d3;hb=8e89506d289f3986af133493a40e3705b7919c87#l64[] +NOTE: Demonstration in https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/common/guifacade.cpp;h=60a16d0f67bd95b43e44662daa9c0525235e14f5;hb=5f10e65852de2c51364c2e2a5a1cf29cae81c6b2#l64[guifacade.cpp] + (The thread shall be forked from within the GUI code not from the facade) This was discussed and ichthyo has already pushed a new cleaned up state and resolved most of the dependency problems with the liblumiera. It raised the question: do we prefer a UI facade to a GUI facade or do we want an extra script facade someday? -It was discussed whether joelholdsworth should wait for cehteh to make a playback interface or use a dummy one for now. Cehteh wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Icythyo has been using the link:GuiNotification[] as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which cehteh and joelholdsworth planned to flesh out in the near future. +It was discussed whether _joelholdsworth_ should wait for _cehteh_ to make a playback interface or use a dummy one for now. +_Cehteh_ wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Ichythyo has been using the `GuiNotification` as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which _cehteh_ and _joelholdsworth_ planned to flesh out in the near future. # Errors, Assertions, Checks, Dev- and Release-Builds @@ -97,7 +115,7 @@ in new nobug you can do: alpha code here ) it's the same for BETA RELEASE and there's a NOT variant for each but even then that should be avoided and higher level nobug facilities should be used instead. -(http://www.lumiera.org/nobug.html)[] +(https://nobug.pipapo.org/[NoBug]) beta and release builds shall be possible with nobug soon .. waiting for metta to integrate the new test.sh test.sh with regex is awesome because you can test output which contains no exact things like addresses, version numbers, times @@ -106,7 +124,7 @@ and running the testsuite under valgrind works properly now Workflow/Interface ~~~~~~~~~~~~~~~~~~ -Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say "don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup". This is where the tree of tracks plays an important role because each track with its children forms a group. +Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say ``don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup''. This is where the tree of tracks plays an important role because each track with its children forms a group. There was further discussion on the general aims, objectives and focus of Lumiera and the reasoning behind them. Integration with control surfaces, jog wheels, sliders etc. should also be considered for the workflow. Nikola expressed the importance of stability and a simple and clean UI. diff --git a/doc/devel/meeting_summary/2009-09-09.txt b/doc/devel/meeting_summary/2009-09-09.txt index c4a95db77..445a7160d 100644 --- a/doc/devel/meeting_summary/2009-09-09.txt +++ b/doc/devel/meeting_summary/2009-09-09.txt @@ -29,7 +29,7 @@ This success wouldn't be possible without a lot of people helping. + So lets say: *Thank you all*! We plan to be there again next year with another Lumiera meeting (possibly -all the 3 core devs present). _Ichthyo_ consideres to do a dedicate talk +all the 3 core devs present). _Ichthyo_ considers to do a dedicate talk (in German). Participation as a group to other possible events has been considered for + @@ -60,7 +60,7 @@ If later on there will be funding for development (not just covering expenses) that would require a different approach and special communication with the community. -_daniieel_ proposes to put a price to each request in "buglist". + +_daniieel_ proposes to put a price to each request in ``buglist''. + The proposal is discussed and dismissed. @@ -71,7 +71,7 @@ The news in the homepage makes the project look alive. But this is not enough to communicate the state of the Lumiera development. Two solutions are proposed: -* The website needs to be reorganized and made accessible. andrewjames +* The website needs to be reorganized and made accessible. _andrewjames_ volunteers to work on it. * Quarterly development news will be published in the devel section of the website. The devs will post drafts to the mailing list and encourage the diff --git a/doc/devel/meeting_summary/2011-03-09.txt b/doc/devel/meeting_summary/2011-03-09.txt index 34d372a44..6726d9099 100644 --- a/doc/devel/meeting_summary/2011-03-09.txt +++ b/doc/devel/meeting_summary/2011-03-09.txt @@ -25,6 +25,8 @@ The new website is finally online. How do we proceed with the graphical layout? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[caption="☉Transcript☉ "] +---------------------------- 21:37 the template code is not ready yet 21:37 and there are some incorrect uses of tags in the current one 21:37 so i will go on coding a static html layout @@ -32,6 +34,7 @@ How do we proceed with the graphical layout? ... 21:50 fsiddi: I liked the way you provided a slightly larger content area for the tutorial part +---------------------------- image:{img}/meetings/2011-03-09-mockup_dev_1.jpg["Website Proposal Mockup number 3", width=128, link="{img}/meetings/2011-03-09-mockup_dev_1.jpg"] @@ -69,6 +72,9 @@ until the sun burns out. engines will not respect it. Private logs or other logs not publically available are fine though. +.-- Discussion about relevance of IRC logs -- +[caption="☉Transcript☉ "] +---------------------------- 22:40 well ... IRC should *not* be for persistent documentation .. we shall force/educate ourself to document things (and decisions) properly, irc should be volatile @@ -96,11 +102,12 @@ are fine though. 22:50 This means I personally always prefer shorter summaries of a discussion to IRC logs, given that they do not leave anything important out. +---------------------------- VoIP discussions over Mumble? ----------------------------- -There seems to be link:http://kitenet.net/~joey/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux. +There seems to be https://joeyh.name/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux. It was decided that while the idea is nice, it will not be used for developer meetings. We might use it for developer discussions outside meetings if we feel @@ -116,8 +123,11 @@ highly insecure. Version numbering ----------------- -Hermann has written an rfc for version numbers. +_Ichthyo_ has written an link:{rfc}/VersionNumberScheme.html[RfC for version numbers]. +.-- Discussion about a version number scheme for Lumiera -- +[caption="☉Transcript☉ "] +---------------------------- 23:19 so in my words: we will have a usuall major.minor.patch for releases 23:20 and major+1~develtag for devel snapshots 23:20 where develtag is a timestamp @@ -201,6 +211,8 @@ Hermann has written an rfc for version numbers. could be automatized) 23:26 remember in test.sh i reserved the 90-99* area for 'bugs' 23:26 we may put some blocking tests there which prevent staging +---------------------------- + Next meeting ------------ diff --git a/doc/devel/meeting_summary/2011-04-13.txt b/doc/devel/meeting_summary/2011-04-13.txt index 08de58437..21fd0d915 100644 --- a/doc/devel/meeting_summary/2011-04-13.txt +++ b/doc/devel/meeting_summary/2011-04-13.txt @@ -16,9 +16,12 @@ _Protocol written by Ichthyo_ .organisational -- IRC meeting summaries will be moved into the main Git tree, below 'doc/devel' -- mostly shortened and tidied IRC logs, plus summary of conclusions \+ decisions -- ``winter quarterly coding news'': this time just paste _Ichthyo's_ contribution into the website +- IRC meeting summaries will be moved into the main Git tree, + + below 'doc/devel' +- mostly shortened and tidied IRC logs, + + plus summary of conclusions + decisions +- ``winter quarterly coding news'': + + this time just paste _Ichthyo's_ contribution into the website - the next ``coding news'' probably in May? @@ -28,7 +31,7 @@ _Francesco Siddi_ has augmented his Layout proposal and already built up two pag cover most of the layout needs of the Lumiera website and documentation resources. However, some points with the code generated by Asciidoc turned out to be problematic. -In a link:http://permalink.gmane.org/gmane.comp.video.lumiera.general/2330[message preceeding the meeting], +In a https://lists.lumiera.org/pipermail/lumiera/2011-April/002418.html[message preceeding the meeting], today _ichthyo_ highlighted some general concerns which might need further discussion and maybe a decision. @@ -344,17 +347,19 @@ _Cehteh_ points out that this new policy should at least be anounced on the Mail Recurring Topic: Design process entries --------------------------------------- -Discussion of open link:/documentation/devel/rfc.html[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. Since some time, no further discussion happened regarding the currently _pending_ RfC entries. Agreement is that we should again return to the former routine and revisit the relevant design process entries in each developer meeting. +-> link:{rfc}/ApplicationInstall.html[RfC: Application Install] +[[application_install_proposal]] .-- the Application Install proposal -- [caption="☉Transcript☉ "] ---------------------------- -[2011-04-14 00:48:25] link:{ldoc}/devel/rfc_pending/ApplicationInstall.html +[2011-04-14 00:48:25] the pending ApplicationInstall RfC [2011-04-14 00:48:40] maybe only pick out some interestin ones or some which are quick to decide [2011-04-14 00:49:06] well i want to go over all pending .. then we can put notes there "boring for the next meeting" [2011-04-14 00:49:42] for example this application install .. is boring .. you did a lot work, imo you can finalize it @@ -372,7 +377,9 @@ revisit the relevant design process entries in each developer meeting. Delectus Shot Evaluator ~~~~~~~~~~~~~~~~~~~~~~~ -Agreement to _park_ it until someone else comes up to advance this topic further. +Agreement to _park_ +link:{rfc}/DelectusShotEvaluator.html[the »Delectus« RfC], + +until someone else comes up to advance this topic further. Clip Cataloging System ~~~~~~~~~~~~~~~~~~~~~~ @@ -386,6 +393,7 @@ Keep _pending_ -- _ichthyo_ will expand on that Lumiera Forward Iterator ~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/LumieraForwardIterator.html[RfC] [caption="☉Transcript☉ "] ---------------------------- @@ -405,6 +413,7 @@ Lumiera Forward Iterator Design the Render Nodes interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/DesignRenderNodesInterface.html[RfC] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -421,7 +430,8 @@ Design the Render Nodes interface Developer Documentation Structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---> see link:https://issues.lumiera.org/ticket/763[Ticket #763] +- -> link:{rfc}/DeveloperDocumentationStructure.html[RfC] +- -> see link:https://issues.lumiera.org/ticket/763[Ticket #763] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -440,6 +450,7 @@ Developer Documentation Structure Engine Interface Overview ~~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/EngineInterfaceOverview.html[RfC] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -464,12 +475,14 @@ Engine Interface Overview Feature Bundle ~~~~~~~~~~~~~~ -Expected to be very important in the far future, but we don't have the +This link:{rfc}/FeatureBundle_PluggableModules.html[RfC: Reature Bundle] +is expected to be very important in the far future, but we don't have the resources to work on that right now, so _park_ it. Marble Mode ~~~~~~~~~~~ +-> link:{rfc}/MarbleMode.html[RfC: Marble Mode] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -492,7 +505,8 @@ Marble Mode Normalized Device Coordinates ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -still very rough, but basically agreed. + +The proposal for link:{rfc}/NormalizedDeviceCoordinates.html[Normalized Device Coordinates] +is still very rough, but basically agreed upon. While it needs more work, it's a bit out of focus right now, so _park it. @@ -509,6 +523,8 @@ link:{rfc}/ProcPlacementMetaphor.html[Placement] proposal Render Optimizer, Resource Management and Profiling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- -> link:{rfc}/ResourceManagementProfiling.html[RfC: Profiling] +- -> link:{rfc}/ResourceManagementBudgeting.html[RfC: Budgeting] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -545,12 +561,13 @@ Render Optimizer, Resource Management and Profiling Roadmap ~~~~~~~ -The link:{rfc}/rfc/Roadmap-first.html[Roadmap document] +The link:{rfc}/Roadmap-first.html[Roadmap document] was erroneously not marked as final; + Seemingly it was decided upon in 2009 already ... Stream Type System ~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/StreamTypeSystem.html[RfC] [caption="☉Transcript☉ "] ---------------------------- @@ -577,6 +594,8 @@ Stream Type System Threads Signals and important management tasks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/ThreadsSignalsAndImportantManagementTasks.html[RfC] + .-- Discussion of details -- [caption="☉Transcript☉ "] ---------------------------- @@ -620,7 +639,8 @@ in multiple timelines. We pretty much agree on that, thus it counts as _finalise Use Cases ~~~~~~~~~ -This is an heavyweight proposal regarding the high-level design and general handling of the +-> link:{rfc}/UseCases.html[This RfC] +is a heavyweight proposal regarding the high-level design and general handling of the Application. This would be really a topic to be discussed in conjection with the ``Workflow'' -- the idea was to have a working group focussed these topics entirely, but there is no one in charge of that right now. Thus _park_ it for the time being. diff --git a/doc/devel/meeting_summary/2011-05-11.txt b/doc/devel/meeting_summary/2011-05-11.txt index a35a4b0d7..e23695660 100644 --- a/doc/devel/meeting_summary/2011-05-11.txt +++ b/doc/devel/meeting_summary/2011-05-11.txt @@ -20,7 +20,7 @@ Render Engine Interface _Ichthyo_ had prepared a new link:/documentation/devel/rfc_pending/EngineInterfaceSpec.html[RfC] about the actual interface between the -link:/documentation/design/architecture/playRender.html[Player subsystem] +link:/documentation/design/architecture/Playback.html[Player subsystem] and the Renderengine/Scheduler. The following discussion turned into considering several detaled and technical topics regarding the Jobs to be scheduled, how to create and attach new jobs, diff --git a/doc/devel/meeting_summary/2012-09-12.txt b/doc/devel/meeting_summary/2012-09-12.txt index 97d961efa..e266936f3 100644 --- a/doc/devel/meeting_summary/2012-09-12.txt +++ b/doc/devel/meeting_summary/2012-09-12.txt @@ -20,7 +20,7 @@ RFCs ---- It was not clear what state -link:{ldoc}/devel/rfc.html[RFCs] have in our +link:/x/DesignProcess.html[RFCs] have in our documentation structure. The question was if they should, after becoming finalized integrated into some other document or stay first class and be referenced from other documents. @@ -86,7 +86,6 @@ Workflow between the Master and the Documentation repository There was some confusion how the master and the documentation repository relate to each other. - We agreed on merging back and forth between in a bidirectional way, but doing this lazy on demand. @@ -101,10 +100,10 @@ A complete rewrite of Builddrone (a continuous integration system) is now (almost) finished and will be deployed on our build server within the next days. It has numerous improvements over the old one. More information and documentation will appear at -https://builddrone.pipapo.org/ soon. Stay tuned. +https://web.archive.org/web/20221205192908/https://builddrone.pipapo.org/[builddrone.pipapo.org] +soon. Stay tuned. -Thanks to Lenny for helping with the documentation and Simon for the -Logo. +Thanks to Lenny for helping with the documentation and Simon for the Logo. diff --git a/doc/devel/meeting_summary/2013-09-12.txt b/doc/devel/meeting_summary/2013-09-12.txt index ae5ab1243..1130824d7 100644 --- a/doc/devel/meeting_summary/2013-09-12.txt +++ b/doc/devel/meeting_summary/2013-09-12.txt @@ -60,7 +60,7 @@ Scheduler: Interface and requirements ------------------------------------- _Benny_ showed interest to work on that topic. The first step would be to build or use a priority queue textbook implementation as starting point. Some time ago, _cehteh_ included -a suitable implementation in his link:http://git.pipapo.org/?p=cehsrc;a=summary[cehlib],a +a suitable implementation in his https://git.pipapo.org/cehteh/cehsrc[cehlib],a collection of basic C library routines, mostly extracted from Lumiera's library. _ichthyo_ integrates this priority queue into the Lumiera tree. diff --git a/doc/devel/meeting_summary/2023-09-13.txt b/doc/devel/meeting_summary/2023-09-13.txt index e8bdf4178..412ef9e13 100644 --- a/doc/devel/meeting_summary/2023-09-13.txt +++ b/doc/devel/meeting_summary/2023-09-13.txt @@ -92,7 +92,7 @@ integrated into the website infrastructure. Library solutions for Video Display ----------------------------------- _Benny_ conducted some research regarding library solutions for *video display*, notably -ffmpeg, GStreamer and libVLC. It was rather easy to code up an "hello world" example based on +ffmpeg, GStreamer and libVLC. It was rather easy to code up an ``hello world'' example based on GStreamer, while it was difficult to find suitable documentation regarding the ffmpeg based solution. Moreover, GStreamer seems to have a much more active and helpful community. @@ -116,7 +116,7 @@ support framework. Next meeting ------------ -The next meeting will be Wednesday Oct 11, 20:00 UTC. +The next meeting will be Wednesday **Oct 11, 20:00 UTC**. You are welcome to join. '''' diff --git a/doc/devel/meeting_summary/2023-10-11.txt b/doc/devel/meeting_summary/2023-10-11.txt index 45e75a2be..c48b6c95d 100644 --- a/doc/devel/meeting_summary/2023-10-11.txt +++ b/doc/devel/meeting_summary/2023-10-11.txt @@ -65,7 +65,7 @@ but a replacement solution was identified, which still needs to be integrated. Next meeting ------------ -The next meeting will be Wednesday Nov 8, 20:00 UTC. +The next meeting will be Wednesday **Nov 8, 20:00 UTC**. You are welcome to join. '''' diff --git a/doc/devel/meeting_summary/2023-11-08.txt b/doc/devel/meeting_summary/2023-11-08.txt index 4bbde8449..5c6dfed28 100644 --- a/doc/devel/meeting_summary/2023-11-08.txt +++ b/doc/devel/meeting_summary/2023-11-08.txt @@ -35,7 +35,7 @@ https://web.archive.org/web/20090129083001/https://www.linux.com/feature/126441[ and remove a ^[citation needed]^ tag. -> see the reworked -{l}/project/index.html[``About''] and {l}/project/faq.html[``FAQ''] pages + +link:/project/index.html[``About''] and link:/project/faq.html[``FAQ''] pages + -> section in the https://en.wikipedia.org/wiki/Cinelerra#Lumiera[Wikipedia page for Cinelerra]. @@ -93,7 +93,7 @@ able to demonstrate running video display in the GUI. Next meeting ------------ -The next meeting will be Wednesday Dec 13, 20:00 UTC. +The next meeting will be Wednesday **Dec 13, 20:00 UTC**. You are welcome to join. '''' diff --git a/doc/devel/meeting_summary/2024-01-10.txt b/doc/devel/meeting_summary/2024-01-10.txt index 90265a892..aa8626eea 100644 --- a/doc/devel/meeting_summary/2024-01-10.txt +++ b/doc/devel/meeting_summary/2024-01-10.txt @@ -4,7 +4,7 @@ :Date: 2024-01-20 Jan 10, 2024 -on {l}/project/contact.html#_irc[`#lumiera`] +on link:/project/contact.html#_irc[`#lumiera`] 20:00 - 23:00 UTC + __Participants__ @@ -78,7 +78,7 @@ process and resource management within the Lumiera render engine itself. Next meeting ------------ -The next Lumiera meeting is scheduled for Wednesday, Feb 14 at 20:00 UTC. +The next Lumiera meeting is scheduled for Wednesday, **Feb 14 at 20:00 UTC**. Should this be inconvenient for you, please speak up on, for example, link:http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera[lumiera@lists.lumiera.org] and let us know of when you would prefer to attend. diff --git a/doc/devel/meeting_summary/index.txt b/doc/devel/meeting_summary/index.txt index 52c26ee7f..75b137845 100644 --- a/doc/devel/meeting_summary/index.txt +++ b/doc/devel/meeting_summary/index.txt @@ -11,6 +11,17 @@ spending time on the task of writing a summary. Anyone interested in Lumiera development is also encouraged to read mailing list archives and other documentation. +2024-2025 +--------- +All meetings were informal in style; usually _Ichthyo_ gave a summary +of recent achievements and explained some of the problems he was facing. +Usually this leads into a rather detailed and technical discussion. + +Since Spring 2005, _Wouter Verwijlen_ has regularly participated in +renewed discussions for a +of a renewed link:{ldoc}/design/workflow/Verwijlen/[Workflow Concept]. + + 8 May / 12 June 2024 -------------------- Discussion regarding the approach taken towards the next core topic, which @@ -326,8 +337,8 @@ Topics ~~~~~~ * organisational (protocol, agenda, leftovers?) * Logo Contest progress, discussion about how to do the pre selection - * rename "EDL" into "Sequence" - * link:DesignProcess/TimelineSequenceOutput[Project, Timeline(s), Sequence(s) and Output] + * rename »EDL« into »Sequence« + * link:/documentation/devel/rfc/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] * GUI/Proc Interface and collaboration * Threading questions regarding gtk-main and main() @@ -500,7 +511,7 @@ Topics ~~~~~~ * boilerplate (protocol, whats left from last meeting, next meeting) * Go through Ideas and Drafts in design process - * "Call for design" for some features relevant for the whole Application: + * ``Call for design'' for some features relevant for the whole Application: - parameters and automation - render node interface - handling of compound sessions @@ -522,7 +533,7 @@ Summary Topics ~~~~~~ * Who will write the protocol below - * Discuss the open points in link:Lumiera/DesignProcess[] do we need this formalism? + * Discuss the open points in a link:/x/DesignProcess[»Design Process«] -- do we need this formalism? * Who works on what, what are the short term goals, what tasks are open * State of the new-name search for the was-intended-as-cinelerra-3 project (no name discussion, just how we will progress!) * Introduce the development model diff --git a/doc/devel/report.txt b/doc/devel/report.txt index 4d7bca080..1faa55e65 100644 --- a/doc/devel/report.txt +++ b/doc/devel/report.txt @@ -6,29 +6,23 @@ Statistics and Reports ++++++++++++++++++++++++++++++++++++++
- +
++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++
- +

++++++++++++++++++++++++++++++++++++++ '''' -^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://blog.openhub.net/about/[OpenHub]«, +^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://openhub.net[OpenHub]«, formerly known as »Ohloh« is a public directory and networking site for free and open source software (FOSS), offering analytics and search services for evaluating and comparing open source projects.]^ -Mailing List ------------- - -image:http://gmane.org/plot-rate.php?group=gmane.comp.video.lumiera.general[Lumiera Mailinglist activity] + -^activity stats by link:http://dir.gmane.org/gmane.comp.video.lumiera.general[Gmane.org]^ - Tickets ------- diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 2ee7b40ca..f79f4d1b5 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -1,12 +1,12 @@ Design Process : All Plugin Interfaces Are C ============================================ -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2007-06-29_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-06-29_ +|*Proposed by* | ct +|==================================== @@ -39,7 +39,7 @@ Implementation Proposal * first member is a _size_ which will be initialized by the actual implementation * followed by function pointers defining the interface, see: - link:Lumiera/DesignProcess/CCodingStyleGuide[] + link:{rfc}/CCodingStyleGuide.html[C-coding style guide] * everything added is considered immutable for this interface version * new functions are added to the end (thus changing size) @@ -162,7 +162,7 @@ outweigh the drawbacks. ct:: '2007-07-03 05:51:06' -C is the only viable choice here. Perhaps some sort of "test bench" could be +C is the only viable choice here. Perhaps some sort of ``test bench'' could be designed to rigorously test plugins for any problems which may cause Lumiera to become unstable (memory leaks etc). @@ -173,9 +173,9 @@ documented in the repository (tiddlywiki/source) ct:: '2007-07-11 13:10:07' - -Development took another direction over course of the years; -Lumiera is not based on a _generic plug-in Architecture_ and the topic +.State -> Dropped +Development took another direction over the course of the years; +Lumiera is _not_ based on a _generic plug-in Architecture_ and the topic of interfaces for _dedicated plugins_ still needs to be worked out Ichthyostega:: '2023-10-24 22:55:23' @@ -185,17 +185,17 @@ Ichthyostega:: '2023-10-24 22:55:23' Conclusion ---------- Initially there was agreement over the general direction set out by this proposal. -However, _Ichthyo_ was always sceptical regarding the benefits of a generic plug-in +However, _Ichthyo_ was always skeptical regarding the benefits of a generic plug-in Architecture. Experience with high-profile projects based on such a concept seem to show both tremendous possibilities, especially regarding user involvement, but at the same time also indicate serious problems with long-term sustainability. -The practical development -- mostly driven ahead by _Ichthyo_ -- thus never really -embraced that idea; rather structuring by internal interfaces and contracts was +The practical development -- after some point mostly driven ahead by _Ichthyo_ -- never +really embraced that idea; rather structuring by internal interfaces and contracts was preferred. The basic system for loading of Plug-ins, as indicated by this proposal, is still used though to load some dedicated plug-ins, most notably the GUI. -To draw an conclusion: this proposal is now considered as *rejected*. +To draw a conclusion: this proposal is now considered as *rejected*. Instead, Ticket https://issues.lumiera.org/ticket/1212[#1212 »Extension Concept«] was added to the list of relevant https://issues.lumiera.org/report/17[»Focus Topics«] for further development. @@ -205,4 +205,4 @@ https://issues.lumiera.org/report/17[»Focus Topics«] for further development. ......... '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ApplicationInstall.txt b/doc/devel/rfc/ApplicationInstall.txt index 9fcbd62f5..70ea3460e 100644 --- a/doc/devel/rfc/ApplicationInstall.txt +++ b/doc/devel/rfc/ApplicationInstall.txt @@ -3,22 +3,22 @@ ApplicationInstall // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Di 11 Jan 2011 17:00:55 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Di 11 Jan 2011 17:00:55 CET_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ********************************************************************************* -Lumiera should be a _freely relocatable_ application bundle. +Lumiera should be a _freely relocatable_ application bundle. + Relying only on the relative folder structure within this bundle, the application will be fully functional at any location, provided that the external library dependencies are resolvable using the standard mechanisms of the platform. -The setup mechanism must be obvious, self-explanatory and must not rely -on compiled in magic or buildsystem trickery. Yet packaging into a FSH conforming -installation location should be supported by the same mechanisms. +This setup mechanism should be obvious and self-explanatory and must not rely +on compiled-in hidden magic or buildsystem trickery. Yet packaging into a fully +FSH conforming installation location should be supported by the same mechanisms. ********************************************************************************* Description @@ -66,7 +66,7 @@ In former days, it was common habit to compile-in a hard wired absolute policy forbids doing so. This is the result from numerous maintainability problems in the past. On the other hand, the GNU linker and other modern linkers support a relative resolution of shared modules directly accompanying -an specific executable. The Debian policy allows this, if and only if these +a specific executable. The Debian policy allows this, if and only if these shared modules are installed with the same binary package and only used by this specific executable(s). Together, this is exactly what we need to solve our requirement. @@ -76,7 +76,7 @@ and sets the +DT_RUNPATH+ with an value relative to +$ORIGIN+, which resolves to the path of the currently executing binary. Moreover, it is _sufficient_ to set this on the initial executable _only,_ because this creates a common searchpath for all lib resolution events in the scope of that loaded executable. -Besides that, we need to care that our private libraries have a unique +SONAME+, +Besides that, we need to care that our private libraries have an unique +SONAME+, in this case all starting with the prefix +liblumiera*+. Note moreover that this new-style +DT_RUNPATH+ indeed _can_ be overridden by an +LD_LIBRARY_PATH+ in the environment, should there be the need for very special experiments. @@ -121,7 +121,7 @@ Tasks * build the executables in a way to allow relative resolution of the internal shared modules ([green]#✔ done#) * replace the compiled-in path definitions for plugin loading by a - configurable bootstrap ([green]#✔#) + configurable bootstrap ([green]#✔ done#) * add an working library implementation for a config loader ([green]#✔ done#) * add a mechanism for establishing the path of the current execubable. + This is _non-portable_ ([green]#✔ done#) @@ -130,7 +130,7 @@ Tasks * try to extract the path search code from the existing config loader, or build a new solution based on standard libraries ([green]#✔ done#) * introduce an output root directory into the buildsystem, allowing - for package builds ([green]#✔#) + for package builds ([green]#✔ done#) * define a _Debian packaging_ as proof-of-concept ([green]#✔ done#) @@ -172,10 +172,10 @@ up some very specific problems and constraints, which can be a serious threat when discovered late in the development process. The second alternative isn't really applicable IMHO. The original UNIX philosophy -breeds on an academic setup and really excels with small nifty commandline utils +draws from an academic setup and really excels with small nifty commandline utils combined by pipes, each specialised to do a single thing very well. These utils are more like the objects within our implementation. The concept of large -application software bundles and desktop software was always a bit alien +application software bundles and desktop software was always slightly alien within the classic UNIX environment. @@ -191,17 +191,20 @@ trickery, inline code compiled on-the-fly, relying on very specific and un-obvious behaviour of some build script, configuration via environment variables and a lot of similar idioms. These practices might be adequate in a quickly moving Research & Development setup, but turned out to be -not so helpful when it comes to industrial strength development, +not so helpful when it used within large-scale development efforts, as they are known to lead to maintenance problems. -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) +Conclusion +---------- +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: - +All the indicated clean-up was done and the bootstrap sequence could be implemented. + +The link:{ldoc}/devel/meeting_summary/2011-04-13.html#application_install_proposal[Apr.2011 developer meeting] +shortly touched on this proposal without raising any objections. +``... for example this application install .. is boring .. we need it, you did it well'' (_Cehteh_) @@ -219,7 +222,14 @@ which reminded me of several small issues, which seem to become unhealthy when l around unfixed for such a long time. Probably I'll start a clean-up initiative and try to bring these points to discussion separately. - So 13 Feb 2011 20:04:00 CET Ichthyostega +Ichthyostega:: 'So 13 Feb 2011 20:04:00 CET' +.State -> Final +After being established in 2011, this structure was used ever since. There was once +a problem with a bug in `ld.so` related to the transitive use of the `$origin` token; +this bug had been resolved quickly. Other than that, packaging and application start +always worked as intended -- so I consider this topic as settled. + +Ichthyostega:: '2025-09-18' //endof_comments: diff --git a/doc/devel/rfc/ApplicationStructure.txt b/doc/devel/rfc/ApplicationStructure.txt index f01128eb5..f08c94c3e 100644 --- a/doc/devel/rfc/ApplicationStructure.txt +++ b/doc/devel/rfc/ApplicationStructure.txt @@ -1,12 +1,13 @@ Design Process : Application Structure ====================================== -[grid="all"]] -`------------`---------------------- -*State* _Dropped_ -*Date* _2008-11-05_ -*Proposed by* link:ct[] ------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-11-05_ +|*Proposed by* | ct +|==================================== + Application Structure --------------------- @@ -20,8 +21,8 @@ So far we came up with a simplified BACKEND/PROC/GUI structure where each of this entities defines its own sub subcomponents. We agreed to glue that all together with some portable versioned interfaces system, but details where not laid out yet. At the time of this writing the interface system and plugin -loader are reasonable finished to be usable (some small refinements to do). We -recently discussed some details on IRC on how to engage this without a +loader are reasonable finished to be usable (some small refinements to do). +We recently discussed some details on IRC on how to engage this without a definitive decision. The topic of this proposal is to make a detailed description towards how the application components being glued together. @@ -31,12 +32,12 @@ this parts are actually be, except that the GUI should be optional for headless operation. I suggested to make as much as possible pluginable to make it easier to validate our interfaces and try different things out. -Now I introduce 'lumiera' here, this will become a new component in -./src/lumiera being the driver application for bootstraping all the rest: +Now I introduce `"lumiera"` here, this will become a new component in +`./src/lumiera` being the driver application for bootstraping all the rest: Then our application structure looks somewhat like (please refine): - * the 'lumiera' loader + * the Lumiera loader - commandline handling - interface & plugin system - session manager core @@ -60,24 +61,24 @@ Then our application structure looks somewhat like (please refine): - preferences - ... -Furthermore the interface&plugin system is flexible enough to provide things -independently of their origin (if it is build in or a plugin/dynamic library). +Furthermore the interface and plugin system is flexible enough to provide things +independently of their origin (if it is either built-in or a plugin/dynamic library). So deployment (where to link these things) is secondary. -'lumiera' will then be the executable the user starts up, what exactly gets - initialized and booted up is then matter -of configuration and commmandline options (and maybe lua scripting?). +`"lumiera"` will then be the executable the user starts up, +what exactly gets initialized and booted up is then matter +of configuration and commandline options (and maybe Lua scripting?). Tasks ^^^^^ - * create the 'lumiera' directory + * create the `lumiera` directory - setup the build system - move config, plugin and interfaces therein - - lua support can be done later - * write the main() part of the application + - Lua support can be done later + * write the `main()` part of the application - start config system - parse commandline opts * librificate all other components (backend, proc gui) @@ -92,17 +93,17 @@ Pros ^^^^ * flexible plugin based architecture - - later: loads only things which are necessary for a given task + ** later: loads only things which are necessary for a given task * very fast startup - * things which cant be used on a given environment can be left out (no gui on - a headless system, no $DISPLAY set) + * things which can't be used on a given environment can be left out (no gui on + a headless system, no `$DISPLAY` set) * inter dependencies between interfaces and plugins are automatically tracked. Cons ^^^^ -Ichthyo raised concerns that this kind of flexibility might attract other +_Ichthyo_ raised concerns that this kind of flexibility might attract other people to write things which are not in our intention and break future design and compatibility. We need to carefully document and define interfaces that people don't abuse those! @@ -112,7 +113,7 @@ people don't abuse those! Alternatives ^^^^^^^^^^^^ -We discussed the startup/main() through the GUI as it is currently done, it +We discussed the startup / `main()` through the GUI as it is currently done, it would be also possible to produce some more executables (lumigui, luminode, lumiserver, ....). But I think we agreed that a common loader is the best way to go. @@ -122,7 +123,7 @@ Rationale ~~~~~~~~~ I just think this is the best way to ensure a enduring design even for future -changes we can not forsee yet. +changes we can not foresee yet. @@ -139,19 +140,24 @@ agreed on it. From reading the above text, this proposal seems to capture that. But I am somewhat unsure if the purpose of this proposal isn't rather to load just a -micro kernel and the pull up components according to configuration. Because I -wouldn't accept such an architecture, and I clearly stated so right at the +*micro kernel* and then pull up components according to configuration. Because +I wouldn't accept such an architecture, and I clearly stated so right at the beginning of our project. I accepted a very flexible and language neutral -plugin system on the condition the core remains in control, stays -''reasonable'' monolithic and componentization doesn't handicap us in creating +plugin system on the condition that the core remains in control, stays +``reasonable'' monolithic and componentization doesn't handicap us in creating an architecture based on abstractions and exploiting the proven design patterns. +Ichthyo:: '2008-11' ++ +-- It has that flexibility, yes. But that means not that we have to abuse it in -any way. The main() there and thus the bootstrap of the application is under +any way. The `main()` there and thus the bootstrap of the application is under our tight control, if we want to reject scriptable/highly configurable bootstrapping there then we can just do so. Thats more a social than a -technical decision. I personally don't like if a design is 'nannying' and puts +technical decision. + +I personally don't like if a design is ``nannying'' and puts too much constraints into unforeseen areas. If the computer can do some task better than we, it shall do it. This still means that I want to stay very much in control, it should only do some tedious, error-prone managing tasks for me. @@ -161,40 +167,63 @@ define anything. The interface system gets it right and we wont need to care for the order initialization. I added that because I consider such as absolutely important for plugins which might be supplied by third parties where we have no control over. But I now realized that we can nicely use that for our -own internal things too. Imo thats some very valuable service. - -- link:ct[] [[DateTime(2008-11-08T06:26:18Z)]] +own internal things too. IMO thats some very valuable service. + +ct:: '2008-11-08T06:26:18Z' +-- Some further minor details: We didn't finish the discussion about namespaces on the last meeting. (I know I still have to write up a proposal showing the two or three alternatives I see regarding namespace organisation). But probably, -"lumiera::" will be our top level interface namespace and then probably the -lumiera directory will be taken by that. I see no problem also putting some +`"lumiera::"` will be our top level interface namespace and then probably the +`./lumiera` directory will be taken by that. I see no problem also putting some startup facilities in there, but generally, it shouldn't contain implementation code, only headers and abstract classes. If that's going to become a problem, we should consider to use a separate package for the startup, e.g. "src/boot". -Another point is, you need not write a main, because there is already one. +Another point is, you need not write a `main()`, because there is already one. Please have a look at it, especially with regards to the -[wiki:self:../GlobalInitialization global initialisation]. Further, last year +link:{rfc}/GlobalInitialization.html[global initialisation]. Furthermore, last year I've investigated boost::program_options and think it's fine. I use it for my test class runner since then. I don't think there is any reason why we should bother with parsing options (most config is pulled up from the session). I don't think we get much program options, maybe something to set a GUI skin. Moreover, I've written last year a thin wrapper around the commandline and integrated it with the boost options parser such that user code can receive the -remaining options as a vector of std::strings. Please have a look at -link:http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main] +remaining options as a vector of `std::string`s. Please have a look at +https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main] for an usage example. I really want our Lumiera main to be clean and expressive in the way showed there. Probably the most important part of the startup is pulling up the session core; because of that I think most of the startup process falls into the realm of the Proc-Layer. Within Proc, I don't want any significant string manipulations done with C-strings and I don't want raw arrays when we can use std::vector. - -- link:Ichthyostega[] [[DateTime(2008-11-06T19:28:13Z)]] -I 'dropped' this now because we do it somewhat differently now and I dont want -to document this here :P - -- link:ct[] [[DateTime(2009-02-03T17:28:28Z)]] +Ichthyostega:: '2008-11-06T19:28:13Z' + +I _dropped_ this now because we do it somewhat differently now and I don't want +to document this here 😛 + +ct:: '2009-02-03T17:28:28Z' + + +💡 + +[underline]#Historical remark#: this RfC is related to a series of discussions +and controversies during the early stages of the project -- which eventually +helped to establish a style of internal organisation within the application. + +After exploring various angles, Lumiera eventually became a *modularised Monolith* +-- using plug-ins for strictly optional parts of the system. Notably, the GUI +is loaded as a plug-in, and the integration with specific media-handling libraries +will rely on plug-in components as well. On the other hand, the core comprises +a small selection of built-in »Subsystems«, which are started with a formalised +lifecycle and dependency management. Flexibility is not attained by allowing +to totally reconfigure the application structure -- rather we allow for an +unusual degree of flexibility by combination and reconfiguration of +behaviour patterns within the application. + +Ichthyotega:: '2025-09-20' + '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ArchitectureOverview.txt b/doc/devel/rfc/ArchitectureOverview.txt index 4ece11a7c..625060e25 100644 --- a/doc/devel/rfc/ArchitectureOverview.txt +++ b/doc/devel/rfc/ArchitectureOverview.txt @@ -1,12 +1,12 @@ Architecure Overview ==================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Architecure Overview -------------------- @@ -15,7 +15,8 @@ This proposal intends to capture envisioned Architecture of the Application. image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture] ^The SVG source of this drawing is -link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT]^ +https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT(2008)]· +https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=HEAD[(current: 2022)]^ Description @@ -33,18 +34,15 @@ Description * the user/GUI manipulates a high-level model whereas rendering is based on a corresponding low-level model * stored Session (state) is comprised of high-level model, a collection of - Assets and accompaning configuration + Assets and accompanying configuration * (possibly) several storage backends, abstracted out by a common interface Comments -------- - * Alcarinque made link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.html[some - design drafts] for the UI. Here is the - link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.svg[SVG source] (converted - from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just - an idea. + * Alcarinque made link:/x/Proposal.Alcarinque.html[some design drafts] for the UI. + + This is not a technical draft at all, it is just an idea. * Wouldn't the Config Rules (embedded Prolog) also interact with the High Level Model? Or would that be expanding its scope too much? I imagine @@ -55,27 +53,29 @@ Comments the next scene to appear relative to the last scene played. In the first, you want to keep the scenes always synced up against the audio, while in the latter, you just want the scenes to appear one after another. - --- link:PercivalTiglao[] [[DateTime(2008-07-16T05:32:45Z)]] + +PercivalTiglao:: '2008-07-16T05:32:45Z' * Yes, indeed, that is what I am planning. The drawing above just doesn't show every connection. The interaction between high-level model and rules system - mostly goes via the "session defaults", which are facts ''and'' rules. Thus, - in your example, the user would just use the "default placement". My - Intention was to use '''tags''' to quite some extent. The user would be able + mostly goes via the ``session defaults'"'', which are facts _and_ rules. Thus, + in your example, the user would just use the ``default placement'"''. My + Intention was to use *tags* to quite some extent. The user would be able to tag the source footage, and then rules can kick in when a certain tag applies. Incidentally, integrating prolog is immediately on the agenda, because first we want to flesh out the very basic system and get to work - basic rendering. Until then, I use a "mock" implementation of the + basic rendering. Until then, I use a _mock implementation_ of the query/rules system, which just returns some hard wired defaults. - -- link:Ichthyostega[] [[DateTime(2008-09-04T15:38:21Z)]] + +Ichthyostega:: '2008-09-04T15:38:21Z' Conclusion ---------- -Accepted. The drawing was moved into the GIT tree, hopefully it will be -maintained in future. +Accepted. The drawing was moved into the GIT tree. + +It was upgraded and reworked +https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=0b9f2e2c3139cad542013caac593cb5972a2e3f6[in 2022] - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/CCodingStyleGuide.txt b/doc/devel/rfc/CCodingStyleGuide.txt index 7325b3961..55da055a7 100644 --- a/doc/devel/rfc/CCodingStyleGuide.txt +++ b/doc/devel/rfc/CCodingStyleGuide.txt @@ -1,12 +1,12 @@ Design Process : C Coding Style Guide ===================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-07-03_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-07-03_ +|*Proposed by* | ct +|==================================== @@ -23,17 +23,18 @@ Description In the following I'll explain a C coding style I used frequently for other projects. Take this as suggestion for parts written in C (it definitely makes no sense for C++). We probably don't need to enforce this style for normal C -code, but for the related link:Lumiera/DesignProcess/AllPluginInterfacesAreC[] +code, but for the related +link:{rfc}/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«] it really makes sense to have some well defined style. Function names follow the rule: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .`namespace[\_object][\_verb[\_subjects]][\_version]` -* namespace is \'lumiera_\' appended with some subsystem tag +* namespace is `lumiera_` appended with some subsystem tag (`lumiera_plugin_audio_`) -* object is the type of the \'this\' object we are addressing, maybe followed - by the object we are returning +* object is the type of the `this' (or `self') object we are addressing, + maybe followed by the object we are returning * verb is the action to take, (new, copy, free, set, clear,.. etc.) if omitted the action is `get` * subjects is a descriptive list of the arguments which the action takes, this @@ -50,11 +51,11 @@ Prototypes follow the rule: * function is the functionname as above * rettype is sensible to what object and verb define, setters return a pointer to the set'ed element if an allocation could be involved (or NULL on - failure), a int if the setter does some checks over the supplied argument (0 - indicates failure, !0 success), void for procedures and actions which can + failure), a int if the setter does some checks over the supplied argument + (`0` indicates failure, `!0` success), void for procedures and actions which can never fail. -* Object is a pointer to refered object (\'this\' like C++) in rare cases - (_new()) functions may be used without this self pointer, see below +* Object is a pointer to referred object (`this' like C++) in rare cases + (`_new()`) functions may be used without this self pointer, see below * `...` are the types and names of the arguments described in `subjects` of the name. @@ -75,9 +76,9 @@ typedef const namespace_foo ** const_NamespaceFoo_ref; // same for const object Examples: +++++++++ .`lumiera_plugin_audio_sample_normalize_limit_1 (AudioSample self, int limit)` -* namespace is \'lumiera_plugin_audio\' -* operates on a \'sample\' object (and likely returns a pointer) -* operation is \'normalize\' +* namespace is `lumiera_plugin_audio` +* operates on a `sample' object (and likely returns a pointer) +* operation is `normalize` * takes one additional parameter describing the limit for normalization * this is a version 1 interface we later define: @@ -96,9 +97,6 @@ Examples: -Tasks -^^^^^ - Pros ^^^^ @@ -129,20 +127,20 @@ overhead to encode arguments to functionnames. But the intention here is to make code easy readable and memorizeable, when one follows this scheme one does seldom need to lookup the docs about the API. In fact it sometimes even turns out that one wants to use a functionname which isn't defined in the API, which -is a good indicator to add such to to the API. +is a good indicator to add such a missing function to the API. This scheme is not fully unambiguous but suffices for all practical task. It encodes parameters like C++ does for overloading without strange mangling. All names are global in a well defined namespace which is very natural for C (other -OO like C styles involve structs and hand written vtables, with this scheme we -trampoline from this global names to vtables *only* if needed) +OO like C styles involve structs and hand written CTables, with this scheme we +trampoline from this global names to VTables _only if needed_) Conclusion ---------- -Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06 +Finalized at the link:{ldoc}/devel/meeting_summary/2008-03-06.html[2008-03-06 developer meeting] @@ -150,61 +148,96 @@ Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06 Comments -------- -I strongly object promoting such a thing as a general "Style Guide". It can be +I strongly object promoting such a scheme as a general ``Style Guide''. It can be a help or last resort if you are forced to work with improper tools (a situation that's rather frequent in practice though). __As such it is well -chosen and practical__. +chosen and practical__, however. But basically, it shows several things: + * you are using a global namespace * you deal with way to fat interfaces * you mix deployment metadata (a version/compatibility check) with functional code + All of this indicates some design style breakage, so it would be preferable to fix the design if possible. The only part I'd like to support as a Style Guide is the rule of using the "verb+object" pattern for creating function names - -- link:Ichthyostega[] [[DateTime(2007-07-08T11:42:39Z)]] + +Ichthyostega:: '2007-07-08T11:42:39Z' Probably needs little explanation: + * you are using a global namespace -This is only about C for names which get exported, C only has a global + +** This is only about C for names which get exported, C only has a global namespace and we need some way to get unique names. The -link:Lumiera/DesignProcess/AllPluginInterfacesAreC[] already uses -better/smaller namespaces by defining interfaces as C structs. The full blown -long names explained here are technically not needed when we use the plugin -system as proposed, I just shown them here for completeness. Next, when we -decide for alternative linking methods like static builds we would need to +link:{rfc}/AllPluginInterfacesAreC.html[RfC: Plugin Interfaces in C] +already uses better/smaller namespaces by defining interfaces as C structs. +The full blown long names explained here are technically not needed when we use +the plugin system as proposed, I just shown them here for completeness. Next, +when we decide for alternative linking methods like static builds we would need to declare all "verb+object" functions static, else there is a high probability of clashes. * you deal with way to fat interfaces -How can you tell that? This is only a nameing style. No interfaces mentioned + +** How can you tell that? This is only a nameing style. No interfaces mentioned here. I am all after small well defined specialized interfaces. -* you mix deployment metadata (a version/compatibility check) with functional - code -Yes, I cant figure out how to do it better but still lightweight in C. the -_version thing is something I added here after the interfaces proposal. I work +* you mix deployment metadata (a version/compatibility check) with functional code + +** Yes, I cant figure out how to do it better but still lightweight in C. the +`_version` thing is something I added here after the interfaces proposal. I work on a example how this will be used in a more friendly way. -Note again that this is a "nameing system", it is intended to be very verbose +Note again that this is a ``naming system'', it is intended to be very verbose and give unique declarative names. It is not about design! Design is done as usual and only when things have to be exported as C symbols (both, exported and C!!) this applies. This has zero implication for C++ code, zero implication for C functions which are not exported (while I personally still prefer this style) and finally when we do the interfaces thing like I proposed, then the naming can be much simpler, see examples there or in my repository. - -- link:ct[] [[DateTime(2007-07-10T08:03:06Z)]] + +ct:: '2007-07-10T08:03:06Z' Thanks, your explanation together with the example in git made the usage -pattern much more clear. I think the _version postfix is esp. helpful on the +pattern much more clear. I think the `_version` postfix is esp. helpful on the names of the plugin interfaces (structs in C), and probably it will be a good -practice, to have one such common plugin interface on every "plugin extension -point", i.e. every point in the sytem, that can be extended by plugins. - -- 217.110.94.1 [[DateTime(2007-07-10T17:23:33Z)]] +practice, to have one such common plugin interface on every ``plugin extension +point'', i.e. every point in the system, that can be extended by plugins. + +Ichthyostega:: '2007-07-10T17:23:33Z' + + +.State -> Dropped +During the last years, I have read this RfC several times, and I am still +not sure what this proposal wanted to achieve, and what was the intention of +proposing it this way. + +A ``C coding style'', a ``naming system'' meant to be very verbose, +but not intended to be about design, yet ``technically not needed when +using the plugin system'' -- which all together touches at +questions of design for sure. + +In the early stages of the project, there was a debate revolving around the +idea of bootstrapping the application from a tiny core, with pretty much +any functionality assembled from plugins, and internal functions being +callable directly from Lua code. Combined with a low-ceremony, distributed, +collaborative working style, such a setup was linked to the promise of +fluid evolution of ideas in order to try out unconventional solutions +and see what works best. + +Personally, this premise made me feel queasy, because I had a clear vision +in my head, which required to build some rather advanced and challenging +structures. Mastering complexity means to segregate and settle parts of a +problem in order to avoid excess interdependencies. I'd rather attempt +to deflect and redirect flexibility and differentiation towards the +periphery and establish stable yet generic structures in the core. + +Ichthyostega:: '2025-09-16' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ClipCatalogingSystem.txt b/doc/devel/rfc/ClipCatalogingSystem.txt index 232a17ea5..75812f93c 100644 --- a/doc/devel/rfc/ClipCatalogingSystem.txt +++ b/doc/devel/rfc/ClipCatalogingSystem.txt @@ -1,12 +1,12 @@ Design Process : Clip Cataloging System ======================================= -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-07-26_ -*Proposed by* link:JordanN[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-07-26_ +|*Proposed by* | JordanN +|==================================== Clip Cataloging System ----------------------- @@ -22,7 +22,7 @@ Organizations that work with video, and even home users, tend to have massive collections of stock videos and images that they will need to find and use in their projects. A Linux-based system is needed to help them to organize, tag, and retrieve assets from those collections. Being able to find the clips the -user needs and bring them into his timeline, will mean that the user will be +user needs, and to bring them into his timeline, will mean that the user will be able to more rapidly complete his project. This could be implemented as a separate application, but integrated for use in @@ -57,8 +57,6 @@ them correctly. Not clip-based, so the entire video must be imported and the desired portion selected. -Rationale -~~~~~~~~~ Comments @@ -69,40 +67,49 @@ Comments development power to do that now. If someone wants to work on that, please contact me. General idea is to put all kinds of resources (Footage, Clips, Effects, Subprojects, Sounds ....) into a database with then gets - tagged/attributed in different ways (implicit things like 'filename', 'type', - 'length'; automatic deduceable things like 'Exposure', 'Timecode', ...; And - manual tags like: who was on set, location, ....). Then present this all in a + tagged/attributed in different ways (implicit things like `filename', `type', + `length'; automatic deducible things like `Exposure', `Timecode', ...; And + manual tags like: who was on set, location, ...). Then present this all in a *good* GUI (by default just showing filesysten like) but one can define queries on this database and the generated views will then be storeable. -Back to Lumiera, for now we will likely just use 'normal' file open dialogs + +Back to Lumiera, for now we will likely just use ``normal'' file open dialogs until the above system becomes available. - -- link:ct[] [[DateTime(2008-07-26T08:31:42Z)]] -* Yes, it's indeed an important feature we should care for. But cehteh is + +ct:: '2008-07-26T08:31:42Z' + +* Yes, it's indeed an important feature we should care for. But _cehteh_ is right, we have more important things to do first. But feel free to target it. * Also, we'd need integration with production support systems, for example http://celtx.com/[CELTX]. * The interface to the Lumiera App would be to populate the asset manager with the required assets - -- link:Ichthyostega[] [[DateTime(2008-07-27T22:19:38Z)]] + +Ichthyostega:: '2008-07-27T22:19:38Z' -Videos, Audio, Clips and Resources Manager by using plugins for FOSS GPL -"Library & Collections Management" programs. -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The video and audio raw material, clips, etc could be managed using code that -is already available in project that carry out the same tasks. For example as +Connect to existing FOSS applications by plugin +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A Video-, Audio-, Clips and Resources Manager can be built by using plugins +for existing ``Library and Collections Management'' programs available under GPL, +or at least code from such applications could be used to carry out similar tasks. +For example as library managers, or media (video, audio or CD) collections, Integrated Library Systems (ILS). -Examples of a library management program ; +Examples of a library management program: -. Kete - http://kete.net.nz/[] -. Koha - http://www.koha.org/[] -. link:GreenStone[] - http://www.greenstone.org/[] -. Evergreen - http://open-ils.org/faq.php[] +- https://web.archive.org/web/20080514220816/http://www.koha.org/[Koha] + · https://koha-community.org/[2025] + · https://en.wikipedia.org/wiki/Koha_(software)[Wikipedia] + · https://liblime.com/[LibLime (commercial)] +- https://web.archive.org/web/20080613192838/http://kete.net.nz/[Kete] +- https://www.greenstone.org/[GreenStone] +- https://evergreen-ils.org/frequently-anticipated-questions/[Evergreen] -An additional benefit to using "library" managers, is that it can handle -interloans, referencing of "other" (people's/organization's) libraries, +An additional benefit to using ``library'' managers, is that it can handle +interloans, referencing of ``other'' (people's / organization's) libraries, numbering systems, descriptions, and classifications, thousands to millions of items, search systems, review and comment systems, plus the benefits of open source that allow the expansion of features easily. The use of task oriented @@ -113,16 +120,18 @@ working with cataloging systems for a long time is likely to do well. Plus it can be readily improved, by people who do not have to know the first thing about how to design video editing programs. The program also gets improved because of it own community, which adds features or performance to Lumiera, -without even having to "drive" the development.. ---link:Tree[][[DateTime(2008-08-27T20:38:00NZ)]]. +without even having to ``drive'' the development.. + +Tree:: '2008-08-27T20:38:00NZ' '''' Parked until someone cares ~~~~~~~~~~~~~~~~~~~~~~~~~~ -Decided on Developer meeting +Decided in link:{ldoc}/devel/meeting_summary/2011-04-13.html#_clip_cataloging_system[Developer meeting] - Do 14 Apr 2011 02:52:30 CEST Christian Thaeter +Christian Thaeter:: 'Tur 14 Apr 2011 02:52:30 CEST' +'''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/CodingStyle.txt b/doc/devel/rfc/CodingStyle.txt index 73d79ba94..ff79ee1bb 100644 --- a/doc/devel/rfc/CodingStyle.txt +++ b/doc/devel/rfc/CodingStyle.txt @@ -1,12 +1,12 @@ Design Process : Coding Style ============================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-27_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-27_ +|*Proposed by* | ct +|==================================== @@ -23,17 +23,17 @@ Description We need to agree on some coding style, IMHO consistency is the most important part with this, no matter which style we use. -See http://en.wikipedia.org/wiki/Indent_style[] +See https://en.wikipedia.org/wiki/Indentation_style[Wikipedia: Indentation Style] .Notes: * no tabs, use spaces! .Proposed: * K&R by _ichthyo_ -* compact and well known +** compact and well known * GNU by _cehteh_ -* imo the best readability (albeit little strange) -* Lumiera might apply as official GNU project someday +** imo the best readability (albeit little strange) +** Lumiera might apply as official GNU project someday Another question: __how to write identifiers?__ @@ -65,11 +65,11 @@ CT:: '2007-07-03 04:04' Comments -------- -Since link:ct[] called spaces instead of tabs first, we should stick to that. I +Since ct called spaces instead of tabs first, we should stick to that. I think all other reasons will lead us to nowhere! Although I'm used to a BSD/KNF-like coding style I will try the GNU one. After -all, the wikipedia page mentions no disadvantages of that style :) +all, the wikipedia page mentions no disadvantages of that style 😊 MichaelPloujnikov:: '2007-06-27 17:17' @@ -77,12 +77,22 @@ MichaelPloujnikov:: '2007-06-27 17:17' I just proposed K&R because it is widely accepted. Personally, I was never very fond of K&R style, I always preferred putting opening braces to the left. I never used GNU style until now, but it looks somewhat appealing to me. (btw, -ECLIPSE comes with presets for all this styles :-P ). Anyhow, I can adapt to +ECLIPSE comes with presets for all this styles 😛 ). Anyhow, I can adapt to most any style. The only thing I really dislike is using tabs (with the -exception of database DDLs and CSound files, where tab are actually helpful) :) +exception of database DDLs and CSound files, where tab are actually helpful) 😊 Ichthyo:: '2007-06-27 20:55' +Many years later -- we are still using GNU style and over time have developed +a »Lumiera flavour« which plays well with C++, templates and λ-functions. +A striking consequence is that the code looks light, favours short functions, +is rather vertically oriented and is easy to skim while scrolling. + +-> see our link:/x/CodeStyle.html[Style guide]. + +Ichthyo:: '2025-09-05' + + '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ConfigLoader.txt b/doc/devel/rfc/ConfigLoader.txt index 71c7b799b..ca14143a8 100644 --- a/doc/devel/rfc/ConfigLoader.txt +++ b/doc/devel/rfc/ConfigLoader.txt @@ -4,12 +4,12 @@ Config Loader // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-08-07_ -*Proposed by* **ct** -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-08-07_ +|*Proposed by* | **ct** +|==================================== ******************************************************************************** .Abstract @@ -44,8 +44,8 @@ NOTE: (by _Ichthyostega,_ 2023) + -Parked -~~~~~~ + +.State -> Parked While the general idea seams adequate, the topic of Configuration requires a much more in-depth Requirement Analysis. Moreover, considering the state of tooling today (2023), I consider it questionable still to rely @@ -64,13 +64,35 @@ to be addressed _after achieving the first integration_ of the Engine. Ichthyostega:: '2023-10-24' ~~ +.State -> Dropped +Lumiera needs a system for configuration, but it will not work as proposed here. +The reasons for this decision can be traced back to questions of architecture +and the intended use of ``Configuration''. This became first clear in a +discussion between _Cehteh_ and _Ichthyo_, as they were walking together +through the forest north of the Karlsruhe castle in August 2011. -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) -// write some conclusions about its process: +While _Cehteh_ aims at an unified set of configuration data, composed by +layering system-, user- and further local configuration files, to be combined +with textual expansion- and replacement mechanisms -- and the ability to +target a wide array of ``settings'' within the application, the intentions +of _Ichthyo_ go into an almost antithetical direction: He rather wants +to split off a very limited set of ``parametrisation'' and ``installation +configuration'', while handling most of the other possible choices by evaluation +of _configuration rules,_ which are tightly interwoven with the Session and +are actively resolved in the Builder, as opposed to being provided by a global +static _configuration service._ With this model, configuration can be injected +from various sources as a structured set of _facts._ Furthermore, _Ichthyo_ +wants to isolate the behaviour of the application from ad-hoc tweaks through +textual replacements and environment variables, rather looking for ways to +record any application of rules or facts in the global _Event Log._ +Ichthyostega:: '2025-09-20' +.... +​ +​ +.... +~What follows below is extended documentation for _Cehteh_'s Config System proposal...~ '''''''''''''''' @@ -147,7 +169,7 @@ API - lumiera_config_init (const char* searchpath) searchpath is a buildin-default, can be changed via configure and can be appended and overridden by using a flag, e.g. `--config-path-append=""` or `--config-path=""` * `lumiera_config_destroy(...)` - - frees all space allocated by the link:ConfigLoader[]. + - frees all space allocated by the ConfigLoader. * `lumiera_config_load(...)` - reads *one* single configuration file that will include all settings from other files. @@ -205,10 +227,12 @@ API .foo.bar ======================================= `integer_set("foo.bar", 123)` + looks up "foo.bar" -this returns as well file and line -it will be decided whether it's a system file or a user's config file. -if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk + +- this returns as well file and line +- it will be decided whether it's a system file or a user's config file. +- if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk set the value in the line. ======================================= @@ -236,16 +260,15 @@ anchor:anchor_config[]lumiera_configfile anchor:anchor_types[]provided TYPES ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`--------------.--------------------------------------'------------------------------------------------------------ -config type C type semantic (example) -------------------------------------------------------------------------------------------------------------------- -number signed long long also hex and octal (foo.bar = 12345 #comment) -real long double differerent formats as well (foo.bar=1.2345 #comment) -string const char* optionaly quoted string (foo.bar="this string" #this not) -word const char* first optionaly quoted word of the config (foo.bar= first this # not) -bool int common representations for bools (0,1,true,false,yes,no,on,off,set,clear) -------------------------------------------------------------------------------------------------------------------- +[options="header", cols="^,2^m,6"] +|==================================== +|config type | C type | semantic (example) +|number |signed long long | also hex and octal (foo.bar = 12345 #comment) +|real |long double | differerent formats as well (foo.bar=1.2345 #comment) +|string |const char* | optionaly quoted string (foo.bar="this string" #this not) +|word |const char* | first optionaly quoted word of the config (foo.bar= first this # not) +|bool |int |common representations for bools (0,1,true,false,yes,no,on,off,set,clear) +|==================================== ... add more types on demand (ichthyo mentioned a tuple type for color triples etc.) @@ -314,7 +337,7 @@ semantics notes: anchor:anchor_links[]links ~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html[] +https://specifications.freedesktop.org/basedir-spec/0.6/[] anchor:anchor_internals[]internals/implementation sketch @@ -591,7 +614,7 @@ Discussion on irc [02:06] <__nasa__> There should be a callback for a plugin to add a config file for that plugin. [02:06] <__nasa__> Ooh [02:06] <__nasa__> cool idea -[02:06] this is not really complicated to do but would give a big usage experience link:JustWorks[][TM] +[02:06] this is not really complicated to do but would give a big usage experience JustWorks[TM] [02:06] <__nasa__> ~/.lumi/config is the main configuration directory [02:06] <__nasa__> inside, there is a ~/.lumi/config/config.ini which is main configuration [02:07] no callbacks .. the idea is that the config system is independent and nothing else need to register there, that makes it much easier diff --git a/doc/devel/rfc/DataBackend.txt b/doc/devel/rfc/DataBackend.txt index a4710224f..5210a2427 100644 --- a/doc/devel/rfc/DataBackend.txt +++ b/doc/devel/rfc/DataBackend.txt @@ -1,12 +1,12 @@ Design Process : Data Backend ============================= -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2007-06-04_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-06-04_ +|*Proposed by* | ct +|==================================== DataBackend ----------- @@ -17,36 +17,34 @@ Description ~~~~~~~~~~~ This just starts as braindump, I will refine it soon: -. handle all files lumiera uses at runtime (media, edl, temp data) -. manage filehandles, lumiera might use more more files than available - filehandles -. manage temporary data -. do caching -. io will be blocked where the backend tells the core where it can expect the - data (not read()/write() like) -. kindof garbage collector -. do prefetching -. no/low latency for the core the prefetcher and other things ensure that data - is available in time -. translate any input into a format which the lumiera core understands (demux, - decode) -. same for encoding to output formats -. offer a plugin API for encoders/decoders -. maybe network backend for serving data to distributed rendernodes -. can do some load control or management (trigger adaptive rendering if system - is idle etc) -. pull based arch +- handle all files lumiera uses at runtime (media, edl, temp data) +- manage filehandles, lumiera might use more more files than available filehandles +- manage temporary data +- do caching +- IO will be blocked where the backend tells the core where it can expect the data (not `read()`/`write()` like) +- kindof garbage collector +- do prefetching +- no/low latency for the core the prefetcher and other things ensure that data is available in time +- translate any input into a format which the lumiera core understands (demux, decode) +- same for encoding to output formats +- offer a plugin API for encoders/decoders +- maybe network backend for serving data to distributed rendernodes +- can do some load control or management (trigger adaptive rendering if system is idle etc) +- pull based architecture .Notes: -* ichthyo wrote also some ideas on - http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra3/Architecture[Architecture] and a sketch/draft about http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Possibilities_at_hand[things possible in the middle layer] +* ichthyo wrote also some ideas regarding + link:http://localhost:8888/project/background/history/PossibilitiesAtHand.html[things possible in the middle layer]... -Parked -~~~~~~ +Conclusion: Dropped +------------------- The underlying principles remain valid, yet development took another direction during the last years. Special frameworks for high-performance -asynchronous IO will be used for dedicated use cases. +asynchronous IO will be used for dedicated use cases. A garbage collector +is not necessary, since Lumiera relies on deterministic memory management. +Furthermore, decoding, transcoding and encoding is handled as part of the +pipeline and not through a separate service. Ichthyostega:: '2023-10-24' ~~ @@ -56,15 +54,63 @@ Comments -------- Sounds fairly complete to me - -- link:Ichthyostega[] [[DateTime(2007-06-16T23:19:44Z)]] + +Ichthyostega:: '2007-06-16T23:19:44Z' Developement takes place in the repo now - -- link:ct[] [[DateTime(2007-06-27T16:14:56Z)]] +ct:: '2007-06-27T16:14:56Z' + +.State -> Parked Development took another direction over the last years; -the former »Backend« layer is restructured - -- link:Ichthyostega[] [[DateTime(2023-10-24T22:45:55Z)]] +the former »Backend« layer is called »Vault« now and structured differently. + +Ichthyostega:: '2023-10-24T22:45:55Z' + + +.State -> Dropped +The approach to most of the topics listed in this RfC has shifted, and thus +it is time to draw the conclusion that overall Lumiera will not use a »Backend« +as an _adaptation layer,_ in the way envisioned here. Notably the idea of +centralising _any access to resources_ to apply some kind of instrumentation +and regulation is rejected. Rather, the »Vault« (as it is called now), +provides specialised low-level services with deep vertical integration; +this implies rather to establish dedicated control circuits for a small +number of special resources deemed performance critical. + +Most topics touched by this RfC however remain relevant, +yet will be approached differently... + +- while non-blocking, asynchronous I/O is still considered essential, + it is acknowledged that getting a grip at the resource usage of + external libraries and frameworks, integrated via plug-in, is a + non-trivial task, and must be approached at a case-by-case base. + +- the Scheduler provides a much more high-level and specialised + execution service then intended initially; the majority of + resource usage regulation will be achieved by adjusting the + job generation, which is connected to high-level structures, + while relying on generic resource observation facilities + in the Vault. + +- the Cache service will require a deep integration with the Builder + and the media / asset management; _cache invalidation_ will be + based on a _naming and identification scheme,_ which requires + explicit support by the high-level metadata management. + +- the Vault has no connection to media processing whatsoever, + it does not decode / encode data or mark and map parts of + media streams; this topic is coordinated at the level of + the builder and delegated to external facilities, while + the Vault provides some dedicated resource management + (notably handling GPU access and shader code) + +- file handles and generic file access are considered a non-issue, + as is the occasional usage of multithreading -- as long as any + substantial parallelism is organised through the scheduler. + +Ichthyostega:: '2025-09-20' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DelectusShotEvaluator.txt b/doc/devel/rfc/DelectusShotEvaluator.txt index becb61afd..07b9b8290 100644 --- a/doc/devel/rfc/DelectusShotEvaluator.txt +++ b/doc/devel/rfc/DelectusShotEvaluator.txt @@ -1,9 +1,12 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-09-21_ -*Proposed by* link:nasa[] -------------------------------------- +Design Process : Delectus +========================= + +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-09-21_ +|*Proposed by* | nasa +|==================================== Delectus Shot Evaluator @@ -14,16 +17,14 @@ This is a brain dump about the shot evaluator subproject. Description ~~~~~~~~~~~ - -Brainstorm on Delectus -~~~~~~~~~~~~~~~~~~~~~~ +.A collection of Ideas Some (many) of the ideas presented herein come from the various parties -involved in the Lumiera discussion list and IRC channel #lumiera. -http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[] -- the -main discussion thread +involved in the Lumiera Mailing List and IRC channel `#lumiera` -- here is the +http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[main discussion thread]. + Additionally, a lot of great concepts for how to streamline the interface are -derived in part from link:KPhotoAlbum[]. +derived in part from https://www.kphotoalbum.org/[KPhotoAlbum]. I use tags, keywords, and metadata almost interchangeably, with the exception that metadata includes computer generated metadata as well. These are not tags @@ -42,7 +43,7 @@ support (please add more!) is: As such, the tags themselves can have metadata. You can see where this is going... -Also, the tags are applied to "clips" -- which I use interchangeably between +Also, the tags are applied to ``clips'' -- which I use interchangeably between source material imported into the application and slice of that material that tags are applied to. Any section of a video or audio source can have tags applied to it. @@ -68,9 +69,9 @@ Some key points: * Technically flawed footage can be both manual and computer classified. * In some cases (e.g. documentaries, dialog) audio and video clips/footage can follow different section processes. - It is possible to use video from footage with useless audio or use audio - from footage with useless video. - * "Interesting" is designed to be broad and is explained below. + - It is possible to use video from footage with useless audio or use audio + from footage with useless video. + * ``Interesting'' as a category is meant be broad and is explained below. * steps 2-5 can be performed in parallel by numerous people and can span many different individual clips. @@ -106,7 +107,7 @@ The key to adequate expressive power is as follows: * Connection to on site documentation and pre-production documentation. When making decisions about what material to use and how to classify it, it is essential to use any tools and resources available. The two most useful are - onsite documentation (what worked/didn't work, how the weather was, pictures + on-site documentation (what worked/didn't work, how the weather was, pictures of the setup, etc all at the shoot) and pre-production (what the ideal scene would be, what is intended, etc). Anything else that would be useful should be supported as well. @@ -143,7 +144,7 @@ vice-versa. Interesting ^^^^^^^^^^^ -An "interesting" clip is one that has potential -- either as a metadata piece +An _interesting clip_ is one that has potential -- either as a metadata piece (multimedia note, talent briefing, etc) or footage (for the final product OR intermediary step). The main goal of the application is to find and classify interesting clips of various types as quickly as possible. @@ -181,10 +182,10 @@ that by having parts of individual clips, metadata, or other files be specific to one aspect of the overall design. This allows for much more successful use of the related information and a cleaner, streamlined layout. As an example, metadata involving file size has no effect whatsoever on the vast majority of -most major decisions -- the answer is almost always "whatever it takes." Thus, +most major decisions -- the answer is almost always ``whatever it takes''. Thus, it would not appear most of the time. Content narrowing means that it is easy -to add back footage -- "widen the view" one step, add it back, and "narrow the -view" again. +to add back footage -- ``widen the view'' one step, add it back, and ``narrow +the view'' again. Multiple cuts @@ -206,7 +207,7 @@ THE SCENE), take (what is actually going on IN THIS SPECIFIC RUN), and instance (what is actually going on IN THIS CLIP). If editing a situation, the other referenced clips AUTOMATICALLY add metadata and relevant sections. This can be as precise and nested as desired, though rough cuts for level one editing -(first watchthrough after technically well executed clips have been selected) +(first watch-through after technically well executed clips have been selected) and more accurate ones for higher levels is the recommended method. @@ -223,12 +224,12 @@ nasa's Laws of Tagging (reasonable) number of tags. This is OK. All that is needed is the minimum set of unique tags to progress to the next cycle without losing editing intent or the ability to rapidly evaluate many situations. -. Many tags are used many times. "Outdoors" will be a very, very common tag; so - will "redub." If conventional names are decided upon and stuck to, it is +. Many tags are used many times. `Outdoors` will be a very, very common tag; so + will `redub`. If conventional names are decided upon and stuck to, it is significantly easier to map the complex interactions between different content situations. -. Avoid compound tags. Do not have "conversation_jill_joe" as a tag; use - "conversation," "jill," and "joe" instead. It is very easy to search for +. Avoid compound tags. Do not have ``conversation_jill_joe'' as a tag; use + ``conversation'', ``jill'', and ``joe'' instead. It is very easy to search for multiple tags and very hard to link data that doesn't use overlapping tags. @@ -257,15 +258,16 @@ sections are allowed. Prompting Prompting for metadata is a laborious, time-consuming process. There is no truly efficient way to do it. This application uses a method similar to -link:KPhotoAlbum[]. When the space key is held and a letter is pressed, the tag +_KPhotoAlbum_. When the space key is held and a letter is pressed, the tag that corresponds to that letter is assigned to the track for the duration of the press. (If the space is pressed and no other key is pressed at the same time, it stops the track.) For example, suppose that the following mapping is present: -o = outside -x = extra -p = protagonist -c = closeup + + o ⟼ outside + x ⟼ extra + p ⟼ protagonist + c ⟼ closeup Then holding SPACE over a section and pressing one of these keys would assign the tag to the audio AND video of the section over which the space was held. If @@ -277,15 +279,18 @@ If LALT is held down instead of SPACE, the audio is effected instead. If RALT is held, just the video is effected. In order to support scenario/take/clip tagging: - The default is situation. If the keybinding to x is: - x = t:extra ; effect only take - x = ts:extra ; effect take and scenario - x = c:extra ; extra only visible in this clip! - x = tc:extra ; this take and clip show the extra - etc + + - The default is situation. If the keybinding to x is: + + ** x = t:extra ; effect only take + ** x = ts:extra ; effect take and scenario + ** x = c:extra ; extra only visible in this clip! + ** x = tc:extra ; this take and clip show the extra + ** ... Other keyargs (the part in front of the colon) can be added to account for -other uses (e.g. l = all taken on the same location). +other uses + +(e.g. l = all taken on the same location). Tab is pressed to add metadata mappings. Tab is pressed to enter metadata edit mode; this pauses video. Then press any key to map; and type the tag to @@ -306,12 +311,9 @@ defined: If ESC is pressed, all currently ranged tags are ended. Finally, if single_quote is pressed without SPACE or {L,R}ALT down, it marks an -"interesting location." Pressing SHIFT+single_quote goes to the next -"interesting location" and pressing CNTRL+' goes to the previous "interesting -location." This allows for very quick review of footage. - - - +``interesting location''. Pressing SHIFT+single_quote goes to the next +``interesting location'' and pressing CNTRL+' goes to the previous +``interesting location''. This allows for very quick review of footage. @@ -335,28 +337,29 @@ The importance/value of the video for various factors uses, can vary through the video. It would be helpful to have the ability to create continuous ratings over the entire track. Ratings would be numerical. Automatic clip selection/suggestion could be generated by using algorithms to compute the -usefulness of video based on these ratings (aswell as "boolean -operations"/"binary decisions" done with tags). The ratings could be viewed +usefulness of video based on these ratings (as well as ``boolean operations'' +rsp. ``binary decisions'' done with tags). The ratings could be viewed just like levels are - color coded and ovelayed on track thumbnails. -- Tree 2008-10-25 +Tree:: '2008-10-25' -link:MultiView[] - useful for concurrent ratings input -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MultiView - useful for concurrent ratings input +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It would be convenient to have an ability to view the different tracks (of the same scene/time sequence) at once, so the viewer can input their ratings of the -video "on the fly", including a priority parameter that helps decide which +video ``on the fly'', including a priority parameter that helps decide which video is better than what other video.See the GUI brainstorming for a viewer widget, and key combinations that allow both right and left hand input, that could be used for raising/lowing ratings for up to six tracks at once. -- Tree 2008-10-25 +Tree:: 2008-10-25 I like the idea of rating clips (or rather, takes) a lot. It would be cool to -include both "hard," "relative," and "fuzzy" rating. Hard is an exactly defined +include both `hard', `relative', and `fuzzy' rating. Hard is an exactly defined value (scaled 0-1) that puts the clip in an exact location in the queue. Relative means that one is higher or lower rated than another. Fuzzy is a slider which is approximate value, and there is some randomness. The best part @@ -367,7 +370,7 @@ sort of heap (think binary heap, at least for the data structure) which determines the priorities and decides which clips are played. Then the highest rated clips are played first, down to the worst. -- link:NicholasSA[] 2009-01-04 +NicholasSA:: '2009-01-04' Possible Collaboration with the people from Ardour? @@ -376,14 +379,15 @@ Possible Collaboration with the people from Ardour? I guess if the thing can do all the things we talked about here, it would be perfectly suitable for sound classification too, and maybe could fill another gap in FOSS: Audio Archival Software, like this: -http://www.soundminer.com/SM_Site/Home.html[] (which is very expensive)... +https://web.archive.org/web/20100618104752/http://www.soundminer.com/SM_Site/Why_Buy.html[soundminer.com] +(which is very expensive)... maybe the Ardour people would be interested in a collaboration on this? I like the suggestion of sound classification with a similar (or, even better, identical) evaluator. link:SoundMiner[] looks interesting, but like you say very expensive. I'm a sound guy, so I feel your pain... -- link:NicholasSA[] 2009-01-04 +NicholasSA:: '2009-01-04' Parked @@ -391,7 +395,7 @@ Parked Decided on Developer meeting, until someone wants to investigate this further. - Do 14 Apr 2011 02:52:30 CEST Christian Thaeter +ct:: 'Thu 14 Apr 2011 02:52:30 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DesignParamAutomation.txt b/doc/devel/rfc/DesignParamAutomation.txt index 9ed2d9b4a..d7d1f18d1 100644 --- a/doc/devel/rfc/DesignParamAutomation.txt +++ b/doc/devel/rfc/DesignParamAutomation.txt @@ -1,23 +1,22 @@ -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Design the handling of Parameters and Automation ------------------------------------------------ Parameters of Plugin Components and/or Render Nodes play a role at various levels of the application. - + Thus it seems reasonable to do a formal requirements analysis and design prior to coding. Description ~~~~~~~~~~~ -Regarding components directly participating in the render (which may be +Regarding components directly participating in the render (which might be implemented by plugins), we distinguish between *configuration* (static) and *parameters* (dynamic). The point of reference for this distinction is the render process: a plugin configuration may well be variable in some manner, @@ -34,8 +33,7 @@ Tasks * we need to work out an introspection mechanism for parameters - asses what different types of parameters we need - - find out how much structured parameters will be (do simple values - suffice?) + - find out how much structured parameters will be (do simple values suffice?) - define how parameters can be discovered/enumerated - define a naming scheme for parameters, so they can be addressed unambiguously @@ -46,16 +44,16 @@ Tasks So... -. find out to which extend we need these properties +. find out to which extent we need these properties . find out what parts of the App will have what requirements? . chose a best fitting implementation based on this information A closely related issue is the handling of *Automation*. The current draft -calls for an abstract interface "ParamProvider", which just allows the -link:Plugin/RenderComponent[] to pull a current value, without knowing if the -ParamProvider is a GUI widget or an automation data set with interpolation. The -component using the param value should not need to do any interpolation. We -should re-asses and refine this draft as needed. Note: Render Nodes are +calls for an abstract interface `ParamProvider`, which just allows the +Plugin or RenderComponent to pull a current value, without knowing if the +`ParamProvider` is a GUI widget or an automation data set with interpolation. +The component using the param value should not need to do any interpolation. +We should re-asses and refine this draft as needed. Note: Render Nodes are stateless; this creates some tricky situations. @@ -68,17 +66,38 @@ Alternatives ^^^^^^^^^^^^ ?? (any ideas?) +One alternative would be _not to recognise_ that this is a problematic requirement, +and just to hack away and ``solve'' each obstacle in an ad-hoc manner. +Unfortunately I'm unable to take this ``alternative'' seriously. + +Another approach could be to reject the idea of ``parameters'' being _something special_ +and rather to treat them as some kind of _different medium_ -- which would subject +a _parameter stream_ to pull-processing. This seems to be an interesting angle, since +going that route would remove the topic of parameters and automation from the core +render engine altogether. However, I am not _bold enough_ to embrace this approach +as a solution -- since I can not see to what extent such a shift would _actually_ +change anything of the actual functionality to be implemented or remove any overhead. + +Ichthyostega:: '2025-09-10' + Rationale ~~~~~~~~~ - - - +The rationale of this RfC is to conduct some requirement analysis before the +point where the aforementioned features will actually be required to continue +with the coding work. In an ideal world, such analysis would be carried out +in parallel by someone knowledgeable enough to recognise the difficulties. Comments -------- +This seems to be one of those nasty features which do not garner any engagement +nor spur any creativity. At some point you'll just happen to need it, and then, +I'm afraid the analysis and planning work will incur significant delay... -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Ichthyostega:: '2025-09-10' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DesignRenderNodesInterface.txt b/doc/devel/rfc/DesignRenderNodesInterface.txt index b55402ede..0dc00a399 100644 --- a/doc/devel/rfc/DesignRenderNodesInterface.txt +++ b/doc/devel/rfc/DesignRenderNodesInterface.txt @@ -1,17 +1,18 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Design the Render Nodes interface --------------------------------- -In the current design, the low-level model is comprised of "Render Nodes"; -Stean-Layer and Vault carry out some colaboration based on this node network. - + +In the current design, the low-level model is comprised of ``Render Nodes''; +Steam-Layer and Vault carry out some collaboration based on this node network. + Three different interfaces can be identified + * the node wiring interface * the node invocation interface * the processing function interface @@ -22,22 +23,22 @@ Description Render Nodes are created and wired by the Builder in the Steam-Layer. On the other hand, the rendering process is controlled by the vault layer, which also provides the implementation for the individual data processing tasks. To create -a result, output nodes are ''pulled'' via the invocation interface, resulting +a result, output nodes are _pulled_ via the invocation interface, resulting in the affected nodes to recursively pull their predecessor(s). In the course of this call sequence, the nodes activate their processing function to work on a given set of buffers. Moreover, we plan to use the render network also for gathering statistics. -'''Note''': Render Node is an internal interface used by Steam-Layer and - activated by the Vault. Plugins are planned to be added via Adapter nodes. - Thus the Render Node interface needs ''not'' to be exported. +NOTE: Render Node is an internal interface used by Steam-Layer and + activated by the Vault. Plugins are planned to be added via Adaptor nodes. + Thus the Render Node interface needs _not_ to be exported. the wiring interface ^^^^^^^^^^^^^^^^^^^^ This part of the design defines how nodes can be combined and wired up by the builder to form a network usable for rendering. For this purpose, the -link:ProcNode[] is used as a shell / container, which is then configured by a +`ProcNode' is used as a shell / container, which is then configured by a Connectivity descriptor. Thus, the node gets to know its predecessor(s) and is preselected to use a combination of specific working modes: @@ -59,18 +60,18 @@ corner case. the invocation interface ^^^^^^^^^^^^^^^^^^^^^^^^ -this is intended to be a rather simple "call-style" interface, without much -possibilites to influence the way things are happening. You pull a node and +this is intended to be a rather simple ``call-style'' interface, without much +possibilities to influence the way things are happening. You pull a node and will find the results in a provided buffer or the cache, but you can't even change the frame data type type of the result. Besides the node invocation, functions for collecting statistics will be accessible here too (Probably these -functions will be ''implemented'' in a classic-OO fashion by virtual functions, +functions will be _implemented_ in a classic-OO fashion by virtual functions, but that's another story) the processing interface ^^^^^^^^^^^^^^^^^^^^^^^^ -the individual nodes are configured to call a plain-C {{{process()}}} function +the individual nodes are configured to call a plain-C `process()` function and provide an array of buffer pointers to be used within this function. For the purpose of invoking actual data processing, it is irrelevant if this function is implemented somewhere in the vault layer or provided by a plugin. @@ -81,7 +82,7 @@ processing function is supposed to do The Right Thing ^TM^ Tasks ^^^^^ - * What services do we expect from Render Nodes. What do we plan to do with a + * What services do we expect from Render Nodes? What do we plan to do with a render node? * What different kinds (if any) of Render Nodes can be foreseen? * order the required functionality by Steam / Vault. Find out specific @@ -98,13 +99,14 @@ Tasks Rationale ~~~~~~~~~ -The purpose of this Design Entry is to give a summary; the questions and the +The purpose of this Design Entry is to give a summary and to spur the discussion +regarding the responsibilities of Steam vs Vault; the questions and the details of carrying out the operations are much more involved. - + + Please see the -http://www.lumiera.org/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)] +link/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)] and the -http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code] +https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/proc/engine/procnode.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=f9452f654cf39a4abbbeecfd81bef51aa347b321[Draft: ProcNode (src)] for details (and/or contact Ichthyo for in-depth discussion of those technical details) @@ -113,15 +115,12 @@ for details -Comments --------- - - Parked ~~~~~~ We park this until we have time to revisit the details. It is accepted that we need to design this interfaces. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DeveloperDocumentationStructure.txt b/doc/devel/rfc/DeveloperDocumentationStructure.txt index 78640f20c..08270ad25 100644 --- a/doc/devel/rfc/DeveloperDocumentationStructure.txt +++ b/doc/devel/rfc/DeveloperDocumentationStructure.txt @@ -3,12 +3,12 @@ Developer Documentation Structure // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Mon Aug 2 18:03:25 2010_ -*Proposed by* Cehteh + Ichthyo -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Mon Aug 2 18:03:25 2010_ +|*Proposed by* | Cehteh + Ichthyo +|==================================== ******************************************************************************** We describe here how to bring the Lumiera Developer Documentation into an simple @@ -32,7 +32,7 @@ The Lumiera (developer) documentation shall be organised in the following way: link:{ldoc}/user/intro/intro.html[Lumiera from Outer Space], which outlines our vision and the fundamental concepts. . there is a section holding our link:{ldoc}/design/[design documents]. - Deliberately, these are written so to omit any technicalities, + Deliberately, these are written in a way omitting any technicalities, which keeps them valid as the technology evolves. . the entrance to the technical documentation is formed by link:{ldoc}/technical/overview.html[The inner Core] document. @@ -69,14 +69,16 @@ Tasks ~~~~~ // List what would need to be done to implement this Proposal in a few words: - * Go over the existing content and the remainder of the asciidoced tiddlywikis, - integrate this content either in directly into the "Lumiera: The inner Core" + * Go over the existing content and the remainder of the Asciidoced TiddlyWikis, + integrate this content either in directly into the + link:{ldoc}/technical/overview.html[»Lumiera: The inner Core«] document or write separate documentation pages or RFC's. ([green]#✔ done#) - * The 'proc' tiddlywiki is a bit special, we need a plan how to integrate this. - [red yellow-background]#TBD# + * The »Renderengine« TiddlyWiki is a bit special, we need a plan how to integrate this. * Create a facility to support the cross-linking between the various kinds of documents - [yellow-background]#WIP# + [red yellow-background]#TODO# +CAUTION: this issue with stable cross-links + -> link:{rfc}/WebsiteSupportMarkup.html[remains a concern] Pros @@ -121,9 +123,23 @@ developers. //Conclusion //---------- -//conclusion: When approbated (this proposal becomes a Final) +//conclusion: When approvedd (this proposal becomes a Final) // write some conclusions about its process: +This RfC had been started initially by _Cehteh_ to propose a _simple structure_ -- +the ensuing discussion however showed that our documentation is already structured +in a mostly consistent way, which just happens to be not that simple. Some confusing +redundancies could be removed, as result from that discussion. _Ichthyo_ then edited +and extended the original RfC to reflect the existing structure. +A serious problem is posed by the rather tedious procedure to define cross-links in the +Asciidoc based web content. link:{rfc}/WebsiteSupportMarkup.html[Another RfC] was created +to discuss these problems in detail, leading to a solution proposal, which unfortunately +was never implemented (due to lack of developer capacity). This _somehow transitory_ +situation had the (adverse) effect that most detailed technical content was authored +within the Development TiddlyWiki. + +These remaining problems do not seem to be related to the _structure_ of the documentation +however, which seems to fulfil its purpose. So this RfC now counts as de-facto standard. @@ -137,12 +153,12 @@ Comments which includes the documentation. Why should we overthrow these results now and re-start the discussion? Lets just stick to this agreed on structure! * especially I don't like the way this proposal tries to squeeze everything into - an completely uniform structure. It is simply not true that the RFCs are just the + a completely uniform structure. It is simply not true that the RFCs are just the second level, and doxygen would cover the 3^rd^ level. Look at the existing documentation to see why. - - RFCs are a 'kind' of document, not a 'hierarchy level.' Indeed, our existing + - RFCs are a `kind' of document, not a `hierarchy level'. Indeed, our existing RFCs span all three hierarchy levels, and this is OK so and should remain this - way. (And yes, I like the RFCs much and want to retain them) + way. (And, in fact I consider the RFCs relevant and want to retain this formalism) - RFCs are well suited to topics requiring discussion and agreement by the whole core developer team. I see no point in 'pseudo-RFC-ing' the individual design decisions only relevant for an isolated part of the application and without @@ -154,11 +170,11 @@ Comments when asciidocing the content). * so my conclusion is rather having one overview text, and then the split into *conceptual* and *technical* documentation, each of which has a separate sub - structure not necessarily congruent to the structure on the other half. RFCs, + structure not necessarily congruent to the structure at the other half. RFCs, UML model and doxygen are just separate and consistent bodies of documentation and can be referred to from the main documentation. (I agree with the observation regarding permanent links into doxygen. But I can't imagine there isn't some - existing solution to this problem) + existing solution to this problem, waiting to be discovered) Ichthyostega:: '2010-10-15' ~~ @@ -173,4 +189,20 @@ documentation in textual form, which is inherentely structured. Ichthyostega:: 'Mo 09 Sep 2013 01:01:25 CEST' ~~ +.State -> Final +I am using this structure since several years now, without encountering any +serious mismatch or incompatibility. The situation with the cross-linking +generator, which still remains to be implemented, is obviously some kind +of impediment, since it prevents me from migrating more mature content +from the TiddlyWiki into the documentation section of the website. + +Furthermore, I should notice, as a limitation, that I am the _only one_ to +use this structure actively -- so the fact that I feel comfortable with +the arrangement should be taken with a grain of salt. Yet, on the other +hand, we have meanwhile a massive body of information structured +this way, so that it can be considered more than +just a ``proposal for discussion'' + +Ichthyostega:: '2025-09-20' + //endof_comments: diff --git a/doc/devel/rfc/DevelopmentFramework.txt b/doc/devel/rfc/DevelopmentFramework.txt index 76a03255f..0a430d65e 100644 --- a/doc/devel/rfc/DevelopmentFramework.txt +++ b/doc/devel/rfc/DevelopmentFramework.txt @@ -1,12 +1,12 @@ Design Process : Development Framework ====================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-08_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-08_ +|*Proposed by* | Cehteh +|==================================== @@ -22,11 +22,11 @@ needed/required for working on lumiera. Description ~~~~~~~~~~~ .Tools required: -* unix like shell environment with standard tools +* Unix like shell environment with standard tools * we don't require a specific linux distribution -* git 1.5.3 (not out yet, but really soon, we want submodules support) -* GNU toolchain, autoconf/automake (maybe scons or something else?) -* bouml (version case unresolved) +* Git 1.5.3 (not out yet, but really soon, we want submodules support) +* GNU toolchain, autoconf/automake (maybe SCons or something else?) +* Bouml (version case unresolved) .Tools suggested: * doxygen @@ -36,45 +36,44 @@ Description Tasks ^^^^^ -* cehteh will setup a initial repository (see link:RepositorySetup[proposed - structure]) -* ichthyo has setup a debian-APT-depot at http://deb/ichthyostega.de[] and will +* _Cehteh_ will setup a initial repository + (see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure]) +* ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will add backport packages there if necessary so the debian-people can stay near Etch/stable in the next time -* ichthyo volunteers to get the new source into a debian package structure from +* _Ichthyo_ volunteers to get the new source into a debian package structure from start (same as the current cinelerra is) .And for later: -* decide on a Unit Test framework (see link:UnitTests_Python[this Proposal]) +* decide on a Unit Test framework + (see -> link:rfc/UnitTestsPython.html[RfC Unit-Tests]) * can we get some continuous integration running somewhere (nightly builds, testsuite)? * find a viable toolchain for writing more formal documentation. - link:ReStructured[] Text, Docbook etc? + ReStructured Text, Docbook etc? -Pros -^^^^ Cons ^^^^ -* the GIT submodules are just not there atm. we need to come along with one +* Git submodules are just not usable yet; we need to come along with one monolitic large project until they are available. Alternatives ^^^^^^^^^^^^ -* use visual studio and .NET :P +* use visual studio and .NET [big]#😇# Rationale ~~~~~~~~~ -The project will be tied to a distributed infrastructure/git. With recent git -submodules support it should be easy to let contributors only checkpout/work on +The project will be tied to a distributed infrastructure based on Git. With recent +Git submodules support it should be easy to let contributors only checkpout/work on parts of the tree (plugins, documentation, i18n, ...). We want to build up a -set of maintenance scripts in a ./admin dir. +set of maintenance scripts in an `./admin` directory. At the moment we go for rather bleeding edge tools, because we want to stay at a given version to avoid incompatibility problems. Later on a version switch @@ -91,12 +90,13 @@ scripting up and running very early in a project. I would like if the project would take a rather conservative approach on the required Libs and Tools, so that finally, when we get into a beta state, we can run/compile on the major distros without too much pain. I wouldn't completely abandon the idea to target -\*bsd and osx as well later on. +*bsd and osX as well later on. -I would propose to move Doxygen to "required". The Idea to use scons sounds -quite appealing to me at the moment. Besides that, I think it could be moved to -"Draft". - -- link:Ichthyostega[] [[DateTime(2007-06-17T00:18:40Z)]] +I would propose to move Doxygen to ``required''. The Idea to use SCons sounds +quite appealing to me at the moment. Besides that, I think this RfC could be +moved to ``Draft''. + +Ichthyostega:: '2007-06-17T00:18:40Z' Moved to Draft. For Developer documentation I would prefer doxygen. For user documentation we can make a similar/same think like nicolasm did for @@ -106,26 +106,83 @@ current cin2 docs, i say its rather well done. We need to factor out some of the proposals from this page to subpages (scons, documentation, testing,...) - -- link:ct[] [[DateTime(2007-06-17T17:27:59Z)]] -It would really suck if we have to go through the experiences described -http://freshmeat.net/articles/view/889/[here]. I have experienced parts of that +ct:: '2007-06-17T17:27:59Z' + +It would really suck if we have to go through the experiences described in the article +https://web.archive.org/web/20060427005516/http://freshmeat.net/articles/view/889/[»Stop the autoconf insanity!«]. +I have experienced parts of that in the past. I have only some beginner experience with writing autotoolized projects (mostly based on trial-and-error) and no experience in any other build system (such as scons). As such, I still believe that autotools can be manageable (for me personally) once the initial hurdle of learning is overcome. I all for Doxygen documentation. Related to documentation are -http://www.splint.org/[splint] -http://www.splint.org/manual/html/appC.html[annotations] (comments). I suggest -that we consider using such a tool for QA. Like link:ct[] said, this should be +http://splint.org/[Splint: Annotation-Assisted Lightweight Static Checking]. +See also http://splint.org/manual/html/appC.html[descriptions of annotations (in comments)]. +I suggest +that we consider using such a tool for QA. Like ct said, this should be discussed in a subpage. I agree with using currently bleeding-edge tools. + * _historic remark(Ichthyo):_ who wrote that comment? (neither me nor ct) -We have now a \'compatibility wiki\', finalized this proposal - -- link:ct[] [[DateTime(2008-03-26T13:43:26Z)]] + +We have now a ``compatibility wiki'', finalized this proposal + +ct:: '2008-03-26T13:43:26Z' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +.... +​ +​ +​ +.... + +Assessment 2025 +~~~~~~~~~~~~~~~ +[underline]#In hindsight,# this RfC captures the baseline of our project setup. + +We soon settled upon the following toolchain, which is used up to today: + +- One published Git repository per developer, with direct pull / merging; + + history is consolidated eventually into the + link:{rfc}/MasterRepositorySetup.html#historical_remark[»official Lumiera repository«], + which is made accessible at + https://git.lumiera.org/?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`] +- We never used link:{rfc}/GitSubmoduleTransistion.html#_comments[Git submodules]... +- https://www.scons.org/[SCons] became the primary buildsystem soon, + with Autotools discontinued in 2011 +- https://trac.edgewall.org/[Trac] is used as planning- and ticket system. +- API documentation is extracted with https://www.doxygen.nl/[Doxygen] +- Website and documentation pages are generated by + https://asciidoc-py.github.io/[Asciidoc], with source files for + documentation maintained + https://git.lumiera.org/?p=LUMIERA;a=blob;f=doc/index.txt;h=9bc0f11e6fb67588388e7616320b695841571278;hb=20f3252892d5b53a05ecd8aeb571122806baba17[in-tree], + published + https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[automatically on push]. +- A https://classic.tiddlywiki.com/[TiddlyWiki] is used for development notes +- for Unit-Tests, we use our own minimalist + https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/lib/test/run.hpp;h=035633af9bde7a8053bcd304baffc21693dcf031;hb=20f3252892d5b53a05ecd8aeb571122806baba17[Test-runner]. + and a + https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/test.sh;h=8c13810eb475bbacd97c528607e6750f47bb145e;hb=20f3252892d5b53a05ecd8aeb571122806baba17[shell script] + to support definition of test collections. +- A Debian package is maintained with + https://wiki.debian.org/PackagingWithGit[git-buildpackage] and published + in our own DEB depot generated by the + https://wiki.debian.org/DebianRepository/SetupWithReprepro[reprepro tooling]. +- UML plays only a marginal role today -- yet in fact we generated our initial class + hierarchy with https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml], + as proposed by _Cehteh_. Sometimes, UML design sketches are made with + https://uml.sourceforge.io/[Umbrello], while schematic drawings, + Icons and graphic elements for the GUI are maintained + with https://inkscape.org/[Inkscape] +- Test-visualisation relies heavily on + https://graphviz.org/[Graphviz] and + http://www.gnuplot.info/[Gnuplot] + +Ichthyostega:: '2025-09-20' + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DistributedDevelopmentFramework.txt b/doc/devel/rfc/DistributedDevelopmentFramework.txt index 926dc1549..9f8e50592 100644 --- a/doc/devel/rfc/DistributedDevelopmentFramework.txt +++ b/doc/devel/rfc/DistributedDevelopmentFramework.txt @@ -1,12 +1,12 @@ Design Process : Distributed Development Framework ================================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-07_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-06-07_ +|*Proposed by* | ct +|==================================== Distributed Development Framework @@ -29,20 +29,6 @@ Tasks * Serveral (shell?) scripts which ease the use -Pros -~~~~ - - - -Cons -~~~~ - - - -Alternatives -~~~~~~~~~~~~ - - Rationale ~~~~~~~~~ @@ -57,9 +43,64 @@ Rationale Comments -------- -Made this 'final', this proposal got accepted and is already in use without +Made this `final', this proposal got accepted and is already in use without much discussion - -- link:ct[] [[DateTime(2007-06-27T16:07:13Z)]] + +ct:: '2007-06-27T16:07:13Z' +.... +​ +​ +​ +.... +[large]#🌑 ​ 🌒 ​ 🌓 ​ 🌔 ​ 🌕 ​ 🌖 ​ 🌗 ​ 🌘 ​ 🌑# + +[underline]#Historical remark#: This was ultimately the first +_conceptual_ (not process-related) RfC published in this Design-Process +(note the date!). Thus, _in hindsight,_ +the question arises what this RfC was meant to propose; + +During the following months, an ambitious side-project named »**uWiki**« was started, +with the goal to provide a wiki-like web frontend based on completely self-contained +storage in a Git repository, without requiring any kind of data base. This project, +however -- in spite of some compelling prototype implementations -- was abandoned; +it became clear that such a system can not be bootstrapped from a lightweight, +minimalist setup and would require a significant amount of web development +rather -- a task no one was willing to take on. + +Yet the Lumiera project succeeded in building a web presence based on +https://asciidoc-py.github.io/[Asciidoc] sources +https://git.lumiera.org/?p=website;a=summary[checked into Git], +with a lightweight +https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[commit-hook script] +to automatically publish any changes on git-push -- a scheme +which comes close to the gist of this RfC. + +Ichthyostega:: '2025-09-08' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +.State -> Dropped +After reconsidering this RfC, _many years later,_ it seems prudent to mark it as __`Dropped'.__ +The reasons for this decision are manifold. For one, the project never fully embraced this +working style, it was a vision from the early days rather. _Parts_ of that vision became a +practical reality, like the use of a link:{rfc}/MasterRepositorySetup.html[shared master repository], +or the use of Git and Asciidoc to generate and publish our website directly from a hook-script. + +But we did not ``create our own toolset to track issues, tasks, bugs in a distributed manner''. +This idea might seem enticing for a new experimental project, and, when taken further, it leads to +a development style where most questions of coordination, and notably the preparation of releases +and the delivery and roll-out of published code are handled by an automated production line. +Developers can do what they like most: ``code cool things'' -- while all that +``nasty other stuff'' is dealt with by an »Invisible Hand«. + +I do not consider such a setup healthy on the long run, nor can I see how it would be +adequate for a project with liabilities to care for: we should not consider the coordination +of a release cycle as something extraneous, to be ``automated away'' -- it requires the +full attention of the developers rather, to provide a longtime stable version and not to +interfere with the work of creative people, using the software in novel ways, +not foreseeable by the developers. +For this reason, I moved into the opposite direction and have now switched to the +link:/project/background/GitFlow.html[Git-flow branching model]. + +Ichthyostega:: '2025-09-20' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/EDLsAreMetaClips.txt b/doc/devel/rfc/EDLsAreMetaClips.txt index 3c58a3b29..990182b7a 100644 --- a/doc/devel/rfc/EDLsAreMetaClips.txt +++ b/doc/devel/rfc/EDLsAreMetaClips.txt @@ -1,18 +1,18 @@ EDL's Are Meta-Clips ==================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-07-15_ -*Proposed by* link:PercivalTiglao[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-07-15_ +|*Proposed by* | PercivalTiglao +|==================================== EDLs Are Meta-Clips ------------------- -One very useful property of EDLs is the ability to contain other EDLs and treat -these "inner" EDLs as a unit. The most logical implementation of this is to -have EDLs themselves be able to be treated as an Clip-MObject. Recursion is +One very useful property of EDLs is the ability to contain other EDLs and to +__treat these ``inner'' EDLs as an unit__. The most logical implementation of this +is to have EDLs themselves be able to be treated as an Clip-MObject. Recursion is known to be a powerful feature that is relatively simple to understand. By making EDLs recursive, some higher level features can be more easily implemented by taking advantage of this fact. @@ -39,14 +39,13 @@ being forced to render the file to disk first. The usability benefits are obvious. -In all examples, rendering the main EDL implies that all of the "inner EDLs" +In all examples, rendering the main EDL implies that all of the ``inner EDLs'' have to be re-rendered if the inner EDL was modified. That is one of the only requirements. Tasks -~~~~~ - +^^^^^ * Consider usability issues from the current Cinelerra userbase. * Have the EDL Object (or create a proxy class) that extends MObject, Clip, AbstractMO, or some other class that would create this kind of behaviour. @@ -54,21 +53,19 @@ Tasks File2 contains File1. This might produce infinite recursion while attempting to render the EDL. * Implement higher level features in the GUI. - * Create "Compound Tracks" which contain multiple tracks within them. + * Create ``Compound Tracks'' which contain multiple tracks within them. * Create a GUI that can handle multiple open EDLs at the same time. Pros -~~~~ - - * A low level feature that would greatly ease the creation of high level - features. +^^^^ + * A low level feature that would greatly ease the creation of high level features. * Multiple applications. * Eases the use and maintenance of Stock Footage. Cons -~~~~ +^^^^ * Possibly would have to rewrite a lot of code at the Engine level?? * Caching / Efficiency issues arise. - Handling multiple instances of Lumiera running might be difficult. E.g. @@ -77,53 +74,57 @@ Cons - Or maybe even multiple instances of Lumiera across computers that are connected to the same Drive. File1 is opened in Computer1 and File2 is opened in Computer2. - * A corrupted "inner EDL" or Stock Footage would "poison" the whole project. + * A corrupted ``inner EDL'' or Stock Footage would ``poison'' the whole project. Alternatives ~~~~~~~~~~~~ - * Pre-Rendering Clips - - Unlike the current proposal, you would be unable to reedit sock footage on - the mass scale and reapply it to the whole project. + - Unlike the current proposal, you would be unable to re-edit sock footage on + the mass scale and re-apply it to the whole project. - Moreover, rendering either introduces a generation loss or requires huge storage for raw (uncompressed) video. * Loading the resources of the EDL -- This is an alternative way to load EDLs. This should also be supported. It would be an expected feature from the old - Cinelerra2 userbase. + Cinelerra-2 user base. Comments -------- -* I got the inspiration of this idea from an email discussion between Rick777 - discussing the Saya Video Editor. -- link:PercivalTiglao[] - [[DateTime(2008-07-17T13:34:08Z)]] -* Hi Percival, thanks for writing this proposal. This is indeed a feature which - was much discussed in the last months and I consider it to be included almost - for sure. We always used the term '''meta-clip''' for this feature, thus I - edited the headline (I hope you don't mind). -* Regarding the implementation, I choose a slightly different approach for the - ``proc layer'' (actually, it's not yet there, but planned right from start, as I - consider this meta-clip feature to be of uttermost importance): I'd prefer to - add it at the level of the media source which is used by a clip. The - rationale is, that at the level of the clip, there is no (or almost no) - different behaviour if a clip pulls from a media file, from an life input or - from another EDL. Thus, the implementation would be for a meta-clip to use a - special media asset, which represents the output of the other EDL. -* Basically, the implementation is quite simple and doesn't necessiate much - additional code (the power of recursion at work!). Further, I don't see any - caching or efficiency problems. As you already pointed out, there are two - fundamental problems - - We need a cycle detector when building the low-level model. ''But'' we +I got the inspiration of this idea from an email discussion with _Rick777_ +discussing the Saya Video Editor. + +PercivalTiglao:: '2008-07-17T13:34:08Z' + +Hi Percival, thanks for writing this proposal. This is indeed a feature which +was much discussed in the last months and I consider it to be included almost +for sure. We always used the term *meta-clip* for this feature, thus I +edited the headline (I hope you don't mind). + +Regarding the implementation, I choose a slightly different approach for the +``proc layer'' (actually, it's not yet there, but planned right from start, as I +consider this meta-clip feature to be of uttermost importance): I'd prefer to +add it at the level of the media source which is used by a clip. The +rationale is, that at the level of the clip, there is no (or almost no) +different behaviour if a clip pulls from a media file, from an life input or +from another EDL. Thus, the implementation would be for a meta-clip to use a +special media asset, which represents the output of the other EDL. + +Basically, the implementation is quite simple and doesn't necessitate much +additional code (the power of recursion at work!). Further, I don't see any +caching or efficiency problems. As you already pointed out, there are two +fundamental problems + + - We need a cycle detector when building the low-level model. _But_ we don't need it solely because of meta-clips, we also need such a facility the moment we allow relatively free wiring of input-output connections (which we do plan anyway). My proposal is to flag the respective MObjects as erroneous, which should be visualized accordingly in the GUI - - We need a thouroughly complete handling for multichannel video and audio + - We need a thoroughly complete handling for multichannel video and audio throughout the whole application. We need to get rid of the distinction - into "video" and "audio" tracks. ''But'' again, this is not due to + into »video« and »audio« tracks. _But_ again, this is not due to meta-clips solely, we should do so anyway because of multichannel spatial audio, 3D video and other advanced media to come. Thus, when every media is multichannel by default, and the builder can sort and handle connections @@ -131,11 +132,13 @@ Comments to do right from start), putting a meta-clip which pulls output from N channels with various mixed stream types from another EDL is not really a problem. -* The other "cons" listed above actually aren't directly connected or due to - the existence of meta-clips, thus I wouldn't list them here. - - yes, it ''is'' true, concurrent changes to the session files may screw up - things. But is this really an issue the Lumiera App should handle at all?? - - yes, ''any corrupted part'' of the serialized session can mess up things. + +The other »cons« listed above actually aren't directly connected or due to +the existence of meta-clips, thus I wouldn't list them here. + + - yes, it _is_ true, concurrent changes to the session files may screw up things. + But is this really an issue the Lumiera App should handle at all? + - yes, _any corrupted part_ of the serialized session can mess up things. This is a real threat (see Cinelerra), but not limited to meta-clips. It is especially important, as you can expect users to work for months or years with a single session. Thus the integrity of the session is a value to be @@ -143,24 +146,53 @@ Comments layer that all important objects can only be created or re-created by some specialized factory, which in turn has the responsibility of never creating a corrupted object. - -- link:Ichthyostega[] [[DateTime(2008-07-27T22:15:01Z)]] -* I'll think about closures around seralized artefacts, the serialized stream - can then be validated, unsupported or corrupted parts can be tagged as - erroneous (means they become virtually readonly but they must be preserved) - and circumvented. A lot of details have to be worked out here, iirc ichthyo - already planned support for 'erroneous' nodes in the datamodell. I also think - about some debugable plaintext dump format (maybe XML) then real corrupt - things can be fixed manually with some efforts. Otherwise we handle gigabytes - of video data and our most valuable resource is the few MB sized session - file. I really aim to make that as robust as possible. Adding backups and - redundancy there wont hurt. - -- link:ct[] [[DateTime(2008-07-30T16:03:04Z)]] + +Ichthyostega:: '2008-07-27T22:15:01Z' + +I'll think about closures around seralized artifacts, the serialized stream +can then be validated, unsupported or corrupted parts can be tagged as +erroneous (means they become virtually readonly but they must be preserved) +and circumvented. A lot of details have to be worked out here, iirc ichthyo +already planned support for `erroneous' nodes in the data model. I also think +about some debuggable plaintext dump format (maybe XML) then real corrupt +things can be fixed manually with some efforts. Otherwise we handle gigabytes +of video data and our most valuable resource is the few MB sized session +file. I really aim to make that as robust as possible. Adding backups and +redundancy there wont hurt. + +ct:: '2008-07-30T16:03:04Z' Conclusion ---------- -This Design Entry concerns whether to include such a feature and discusses the -general questions when doing so. As we for sure include meta-clip, and so so -exactly in the way described here, this proposal is 'final' now. +This Design Entry deals with the question whether to include such a feature and +it discusses the general questions when doing so. Since we are determined to +include this kind of _meta-clip_ anyway, and will most likely do in a way +similar as described here, this can be considered __`final'__. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +This conclusion was drawn at the +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_edls_as_meta_clips[October.2008 developer meeting]. + +'''' + +[TIP] +=========== +Terminology is somewhat in flux regarding this topic: + +- »EDL« is a technical term from the Cinelerra-2 code base. The acronym actually + stands for **E**dit **D**ecision **L**ist, which is a term from traditional + film making and production organisation -- and does not really map properly + into the usage possible with digital technology. For that reason, the Lumiera + project _dropped_ this notion subsequently. +- close to the ideas presented in this text is the concept of a ``Sequence'', + which in Lumiera designates a ``Fork'' (tree of tracks) with an arrangement + of clips attached. +- as of 2025, we typically use the following terminology: + + ** a _Virtual Clip_ is how such a nested structure is integrated + ** such a clip in turn uses a _Virtual Medium_ + ** which is based on the _Binding_ of a _Nested Sequence_ +=========== + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/EngineInterfaceOverview.txt b/doc/devel/rfc/EngineInterfaceOverview.txt index bc4e190fe..8003acd8c 100644 --- a/doc/devel/rfc/EngineInterfaceOverview.txt +++ b/doc/devel/rfc/EngineInterfaceOverview.txt @@ -4,12 +4,12 @@ Engine Interface Overview // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _2010-04-16_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _2010-04-16_ +|*Proposed by* | Ichthyostega +|==================================== Overview Engine Interface(s) @@ -42,7 +42,7 @@ Render Process The render process brackets an ongoing calculation as a whole. It is not to be confused with a operating system process or thread; rather it is a point of reference for the relevant entities in the Stage and Steam-Layer in need to -connect to such a "rendering", and it holds the specific definitions for this +connect to such a ``rendering'', and it holds the specific definitions for this calculation series. A render process _corresponds to a single data stream_ to be rendered. Thus, when the play controller of some timeline in the model is @@ -51,7 +51,7 @@ processes exist. * there is an displayer- or output slot, which got allocated on creation of the process -* the process disposes calculated data frames "into" this slot +* the process disposes calculated data frames _into this slot_ * the process can be paused/started and stopped (aborted, halted). * some processes allow for changing parameters dynamically (e.g. speed, direction) @@ -60,7 +60,7 @@ processes exist. .Process parameters A process is linked to a single stream data format (a -> -link:StreamTypeSystem.html[stream implementation type]). + +link:{rfc}/StreamTypeSystem.html[stream implementation type]). + It is configured with _frame quantisation_ and _timings_, and a _model port_ identifier and _channel selector_. @@ -246,7 +246,7 @@ Rationale //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -261,11 +261,33 @@ Requirements and details of the design are sufficiently clear meanwhile. Ther seems to be not much room for alternative approaches, given our general planning for the application - Mi 11 Mai 2011 19:27:12 CEST Ichthyostega +Ichthyostega:: 'Wed 11 Mai 2011 19:27:12 CEST' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +[underline]#Historical remark#: In hindsight, it seems I did post that RfC +(and the corresponding link:{rfc}/EngineInterfaceSpec.html[Specification RfC]) not so much +to ask for input and further ideas, rather as a _call for help_. Last year (2024), I had +to revisit the code written in 2010/11, and it looks like I was struggling desperately at +that time to thread a pathway into a void. During the early stages of the project, _Cehteh_ +and myself had agreed to place the boundary between ``Proc'' and ``Backend'' (today designated +as Steam and Vault) at the entrance to the link:/x/Scheduler.html[Scheduler] -- but there was +no scheduler yet, not even a design draft at that time, and the scope of what it was assumed to do +seemed to be ``vanishing'': basically ``the Backend'' wanted a pool of lightweight, stateless, +unconnected requests, which could be treated as a problem of the ``embarrassingly parallel'' +kind (to use computer science parlance). So nothing to serve as an anchor or point of reference +for finding a pathway. + +This RfC is a summary of design work already completed, asking for validation. I could +not see if this path would lead to anywhere at that time -- and subsequently abandoned that +topic in half-finished state. Currently (since 2024) I am picking up that work and it seems +to be durable. However -- it might be worth mentioning that this RfC indeed spurred an +link:{ldoc}/devel/meeting_summary/2011-05-11.html#scheduler[extended technical discussion] +at the May-2011 developer meeting, maybe the last of this kind of inspiring exchanges +on equal terms. + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/EngineInterfaceSpec.txt b/doc/devel/rfc/EngineInterfaceSpec.txt index 2b4be964e..fad4c3041 100644 --- a/doc/devel/rfc/EngineInterfaceSpec.txt +++ b/doc/devel/rfc/EngineInterfaceSpec.txt @@ -3,12 +3,12 @@ Engine Interface Spec // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Mi 11 Mai 2011 17:53:16 CEST_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Mi 11 Mai 2011 17:53:16 CEST_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ******************************************************************************** @@ -54,7 +54,7 @@ Requirements Specification Functionality description in detail ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> see the link:EngineInterfaceOverview.html[Engine/Interface overview] for +-> see the link:{rfc}/EngineInterfaceOverview.html[Engine/Interface overview] for a description of the involved entities and for definitions for common terms. Definitions @@ -173,8 +173,8 @@ Tasks Discussion ~~~~~~~~~~ -Pros -^^^^ +//Pros +//^^^^ // add a fact list/enumeration which make this suitable: // * foo // * bar ... @@ -188,8 +188,8 @@ The requirements placed on life changes are quite high -Alternatives -^^^^^^^^^^^^ +//Alternatives +//^^^^^^^^^^^^ //alternatives: explain alternatives and tell why they are not viable: @@ -206,7 +206,7 @@ and break it down into tangible functionality on the implementation level. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -216,7 +216,9 @@ Comments -------- //comments: append below -Discussed in the May developers meeting. Seems to be basically acceptable. +Discussed in the +link:{ldoc}/devel/meeting_summary/2011-05-11.html#irctranscript[May.2011 developers meeting]. +Seems to be basically acceptable. _Cehteh_ proposed some small adjustments: - making the _QualityOfService_ rather a strategy to be queried @@ -225,10 +227,11 @@ _Cehteh_ proposed some small adjustments: - introducing a separate scheduler/queue for time scheduled tasks, like with rater soft realtime requirements - So 15 Mai 2011 00:55:24 CEST Ichthyostega +Ichthyostega:: 'Sun 15 Mai 2011 00:55:24 CEST' ~~ +TIP: see also the related link:{rfc}/EngineInterfaceOverview.html#_comments[overview RfC] //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/FeatureBundle_PluggableModules.txt b/doc/devel/rfc/FeatureBundle_PluggableModules.txt index 39958ca0d..947370c3d 100644 --- a/doc/devel/rfc/FeatureBundle_PluggableModules.txt +++ b/doc/devel/rfc/FeatureBundle_PluggableModules.txt @@ -1,20 +1,20 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-09-03_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-09-03_ +|*Proposed by* | Ichthyostega +|==================================== -Describe pluggable modules by a "Feature Bundle" +Describe pluggable modules by a »Feature Bundle« ------------------------------------------------ -This proposal builds upon Cehteh's Plugin Loader, which is the fundamental +This proposal builds upon _Cehteh_'s Plugin Loader, which is the fundamental mechanism for integrating variable parts into the application. It targets the special situation when several layers have to cooperate in order to provide some pluggable functionality. The most prominent example are the -"effects plugins" visible for the user. Because, in order to provide such an +``effect plugins'' visible for the user. Because, in order to provide such an effect * the engine needs a processing function @@ -38,8 +38,10 @@ base. Each extension point can be addressed by a fixed textual ID, e.g. Now, to provide a pluggable extension for such an Extension Point, we use a *Feature Bundle* Such a Feature Bundle is comprised of - * a Deployment Descriptor (provided as "structured data" -- TODO: define the - actual data format) + * a Deployment Descriptor (provided as ``structured data'' -- + + + ^[red]#TODO#: define the actual data format)^ + * the corresponding resources mentioned by this Deployment Descriptor The Deployment Descriptor contains @@ -77,7 +79,7 @@ We do _not_ provide a meta-language for defining requirements of an Extension Point, rather, each extension point has hard wired requirements for a Feature Bundle targeted at this extension point. There is an API which allows code within lumiera to access the data found in the Feature Bundle's Deployment -Descriptor. Using this API, the code operating and utilizing the Extension +Descriptor. Using this API, the code operating and utilising the Extension Point has to check if a given feature bundle is usable. It is assumed that these Feature Bundles are created / maintained by a third @@ -85,7 +87,7 @@ party, which we call a *Packager*. This packager may use other resources from different sources and assemble them as a Feature Bundle loadable by Lumiera. Of course, Lumiera will come with some basic Feature Bundles (e.g. for colour correction, sound panning,....) which are maintained by the core dev team. -(please don't confuse the "packager" mentioned here with the packager creating +(please don't confuse the ``packager'' mentioned here with the packager creating RPMs or DEBs or tarballs for installation in a specific distro). Additionally, we may allow for the auto-generation of Feature Bundles for some simple cases, if feasible (e.g. for LADSPA plugins). @@ -97,16 +99,16 @@ In most cases, the resources referred by a Feature Bundle will be Lumiera Plugins. Which means, there is an Interface (with version number), which can be used by the code within lumiera for accessing the functionality. Besides, we allow for a number of further plugin architectures which can be loaded by -specialized loader code found in the core application. E.g. Lumiera will +specialised loader code found in the core application. E.g. Lumiera will probably provide a LADSPA host and a GStreamer host. If such an adapter is applicable depends on the specific Extension point. -The ResourceID is the identifyer by which an Extension point tries to find +The ResourceID is the identifier by which an Extension point tries to find required resources. For example, the Extension Point "Effect" will try to find an ResourceID called "ProcFunction". There may be several Entries for the same ResourceID, but with distinct SubID. This can be used to provide several implementations for different platforms. It is up to the individual Extension -Pont to impose additional semantic requirements to this SubID datafield. (Which +Point to impose additional semantic requirements to this SubID data field. (Which means: define it as we go). Similarly, it is up to the code driving the individual Extension point to define when a Feature Bundle is fully usable, partially usable or to be rejected. For example, an @@ -117,32 +119,19 @@ can't access the properties describing the media stream type this effect is supposed to handle. Besides binary plugins, other types of resources include: + * a set of properties (key/value pairs) * a script, which is executed by the core code using the Extension Point and - which in turn may access certain interfaces provided by the core for "doing - things" + which in turn may access certain interfaces provided by the core for + ``doing things'' Probably there will be some discovery mechanism for finding (new) Feature Bundles similar to what we are planning for the bare plugins. It would be a good idea to store the metadata of Feature Bundles in the same manner as we plan to store the metadata of bare plugins in a plugin registry. - - - -Tasks -^^^^^ - - -Pros -^^^^ - - - -Cons -^^^^ - - +Discussion +~~~~~~~~~~ Alternatives ^^^^^^^^^^^^ @@ -156,7 +145,7 @@ The purpose of this framework is to decouple the core application code from the details of accessing external functionality, while providing a clean implementation with a basic set of sanity checks. Moreover, it allows us to create an unique internal description for each loaded module, and this -description data e.g. is what is stored as an "Asset" into the user session. +description data e.g. is what is stored as an _Asset_ into the user session. Today it is well understood what is necessary to make a real component architecture work. This design proposal deliberately avoids to create a @@ -179,17 +168,19 @@ Comments From a fast reading, I like this, some things might get refined. For example I'd strongly suggest to make the Deployment Descriptor itself an Interface which is offered by a plugin, all data will then be queried by functions on -this interface, not by some 'dataformat'. Also Resource ID's and a lot other -metadata can be boiled down to interfaces: names, versions, uuid of these -instead reiventing another system for storing metadata. My Idea is to make the -link:Plugin/Interface[] system self-describing this will also be used to +this interface, not by some ``dataformat''. Also Resource ID's and a lot other +metadata can be boiled down to interfaces: names, versions, UUID of these +instead reinventing another system for storing metadata. My Idea is to make the +Plugin/Interface system self-describing this will also be used to bootstrap a session on itself (by the serializer which is tightly integrated) - -- link:ct[] [[DateTime(2008-09-04T09:28:37Z)]] 2008-09-04 09:28:37 + +ct:: '2008-09-04T09:28:37Z' Parked ~~~~~~ Needs to ne reviewed some time later. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GitCommitMessageFormat.txt b/doc/devel/rfc/GitCommitMessageFormat.txt index 1d8de328b..0c65edcc1 100644 --- a/doc/devel/rfc/GitCommitMessageFormat.txt +++ b/doc/devel/rfc/GitCommitMessageFormat.txt @@ -3,12 +3,12 @@ Git Commit Message Format // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Fr 31 Aug 2012 03:54:14 CEST_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _Fr 31 Aug 2012 03:54:14 CEST_ +|*Proposed by* | Christian Thaeter +|==================================== ******************************************************************************** .Abstract @@ -20,8 +20,8 @@ Description ----------- //description: add a detailed description: -Git commit messages are almost free form text, the only exception is that git -threats the first line in a commit message specially to form the header one +Git commit messages are almost free form text, the only exception is that Git +treats the first line in a commit message specially to form the header one sees in various outputs. Since we aim to automate some processing we refine the format for commit @@ -156,7 +156,7 @@ confuse the toolchain (builddrone) but this failures shall not be critical. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -174,7 +174,52 @@ We decided on the sept. 2012 devel meeting to finlize this RFC. Christian Thaeter:: 'Do 13 Sep 2012 03:57:23 CEST' ~~ +NOTE: This RfC is now superseded by using the _Git-flow branching scheme._ + +.State -> Dropped + +With the recent move to link:{ldoc}/technical/code/GitBranching.html[Git-flow] +we acknowledge now -- by employing a branch model -- that the project history +is _built_ and _conducted_ consciously, _by us._ In the current stage, +it is not the goal of this project to churn out a stream of commits, +using an automated production line to push some metrics high. + +Since any automation comes at a cost and incurs burdens and limitations, +it should be employed to solve actual problems, but should not +be introduced prematurely: + +- we spend most of our time with finding suitable solutions, not with + coding them up. When a part is completed, some time can be spent + to document it and to consolidate the history. Thus, leaving + formalised WIP and STASH marks is besides the point. + +- releases and even bugfixes require forethought, analysis, verification + and reflection. The extra time required to set a git tag manually, or + even to perform a merge, is negligible in comparison, and does not + justify the weight of automation. + +- documentation is written in the context of solving actual problems; + it is pointless to spot ``documentation commits'' by some markers, + because their relevance is already obvious from a meaningful context. + +- Git bisect is an essential tool when working with a code base which you + do not understand. With a well-crafted yet ambitious system the situation + is quite different: in such a system, the change which caused the breakage + is obvious and easy to spot -- while the actual challenge is to + understand _why_ difficulties arose -- not to mention the amount + of work required to develop a path of escape from a real dilemma. + +This RfC highlights some general considerations however, which remain +valid anyway: to provide a short commit summary in the first line, +and then, after an empty line, to provide a description for +anything that is non-obvious, possibly with cross-references to +tickets, URLs pointing to external sources and anything that might +provide meaningful context for someone looking at this change +years later. And, commit messages should be line-wrapped. + +Ichthyostega:: '2025-09-16' + //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GitSubmoduleTransistion.txt b/doc/devel/rfc/GitSubmoduleTransistion.txt index fdbcd69db..1597105ed 100644 --- a/doc/devel/rfc/GitSubmoduleTransistion.txt +++ b/doc/devel/rfc/GitSubmoduleTransistion.txt @@ -1,9 +1,13 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-04-09_ -*Proposed by* link:ct[] -------------------------------------- +Design Process : Submodules +=========================== + + +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-04-09_ +|*Proposed by* | ct +|==================================== Use Git Submodules to organize the project @@ -14,33 +18,34 @@ work out the details and define a turnover point in time. Description ~~~~~~~~~~~ -There is a git-filter-branch command which helps in doing the dirty work +There is a `git-filter-branch` command which helps in doing the dirty work isolating commits which touch certain dirs. This can moderately easily be used to create a new repository with a rewritten history containing only sub parts of the original history. The basic idea is that one developer who wants to works on a certain subsystem -clones the 'official' master and then updates and tracks only the development +clones the ``official'' master and then updates and tracks only the development state of a certain subsystem. Tasks ^^^^^ * what shall be in the master repository? - * boilerplate files, license, build infrastructure - * the _admin_ dir with supplemental scripts + ** boilerplate files, license, build infrastructure + ** the _admin_ dir with supplemental scripts * define which submodules shall be defined? - * _doc/devel_ - * _doc/user_ - * _wiki_ - * _uml_ - * _src/backend_ - * _src/proc_ - * _src/gui_ - * _src/lib_ + ** _doc/devel_ + ** _doc/user_ + ** _wiki_ + ** _uml_ + ** _src/backend_ + ** _src/proc_ + ** _src/gui_ + ** _src/lib_ Not yet decided: - * _tests_ move them into the _src/$subsystem_ as symlink? + + * _tests_ move them into the `"src/$subsystem"` as symlink? * _src/tool_ @@ -54,8 +59,8 @@ Pros Cons ^^^^ - * needs some more git-fu to be used by the developers - * we will host considerably more git repositories (bigger list in gitweb), + * needs some more Git-fu to be used by the developers + * we will host considerably more Git repositories (bigger list in gitweb), this is not a problem but might look more confusing @@ -74,14 +79,36 @@ When all people get used to it it allows a cleaner more sane work flow and well isolated, less conflicting commits. - +Conclusion: Dropped +------------------- +The extended usage of Git Submodules for parts of the code base is not desirable. Comments -------- +.State -> Parked We concluded that that submodules are not yet needed with exception for the ./doc folder. Parked for now. - -- ct 2008-07-26 09:09:57 -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-07-26 09:09:57' + + +.State -> Dropped +Git Submodules were a highly anticipated feature at the time when the +Lumiera project started -- yet the actual implementation was generally +perceived as a disappointment, since the tooling failed to provide that +kind of seamless integration into everyday Git usage as was desirable. + +There remains one area however, where the Lumiera project might revisit +the idea of using Submodules: our _Website_ -- which might become a portal +to integrate several rather loosely coupled efforts eventually, notably +the public front-end, including some images, a user documentation section, +the technical documentation and possibly a knowledge base maintained +separately. + +Ichthyostega:: '2025-09-25' + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GlobalInitialization.txt b/doc/devel/rfc/GlobalInitialization.txt index 5e5d6a71d..43a73c72b 100644 --- a/doc/devel/rfc/GlobalInitialization.txt +++ b/doc/devel/rfc/GlobalInitialization.txt @@ -3,12 +3,12 @@ GlobalInitialization // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-04-05_ -*Proposed by* CT -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-04-05_ +|*Proposed by* | CT +|==================================== ******************************************************************************** .Abstract @@ -21,7 +21,7 @@ Description Setup a `src/common/lumiera_init.c` file which contains following functions: * `int lumiera_init(s.b.)` initializes the subsystems, global registries, - link:NoBug[] and other things. Must be called once at startup. + NoBug and other things. Must be called once at startup. * `void lumiera_destroy(void)` shuts down, frees resources, cleans up. Calling 'lumiera_init()' twice or more should be a fatal abort, calling @@ -39,7 +39,9 @@ Tasks // * first step ([green]#✔ done#) // * second step [yellow-background]#WIP# // * third step [red yellow-background]#TBD# -Implement this. [red yellow-background]#it was never implemented this way# +Implement this. + +WARNING: [red yellow-background]#it was never implemented this way# Discussion @@ -90,7 +92,7 @@ order and makes debugging easier since it is a serial, well defined sequence. Conclusion ---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: _This RfC was the plan_. We agreed on it, and then we forgot about it. @@ -104,7 +106,8 @@ scheme: - by policy, clean-up and unwinding is always considered _optional_ -- but we care to implement a complete shutdown and memory unwinding for sake of sanity. -This RfC is marked as *dropped*, since it doesn't reflect what the implementation does. + +This RfC is marked as *dropped*, since it doesn't reflect what the implementation does. + Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~~ @@ -129,8 +132,9 @@ there too, so it gets issued automatically. probably after parsing the commandline in main (and either this or the loading of a existing session will bring the proc layer up into fully operational state + - Ichthyo:: 'DateTime(2008-04-09T02:13:02Z' -* About link:NoBug[] initialization: I've seen that you made a `nobugcfg` where + Ichthyo:: '2008-04-09T02:13:02Z' + +* About NoBug initialization: I've seen that you made a `nobugcfg` where you centralized all nobug setup. Problem here is that a change in that file forces a whole application rebuild. I'd like to factor that out that each subsystem and subsubsystem does its own `NOBUG_FLAG_INIT()` initializations, @@ -158,7 +162,7 @@ Backend tests then only call `lumiera_backend_init()` and don't need to do the whole initialization, same could be done for `lumiera_proc_init()` and `lumiera_gui_init()`. Note about the library: I think the lib shall not depend on such an init, but I would add one if really needed. -+ + CT:: '2008-04-09T19:19:17Z' @@ -171,7 +175,7 @@ After reconsidering I think we have several different problems intermixed here. usage pattern of the flags (btw. the idea of making a flag hierarchy is very good!) will be much different in the backend, the proc layer and the gui. - Initialisation of the very basic services is tricky, as always. Seemingly - this includes link:NoBug[]. Of course one wants to use assertions and some + this includes NoBug. Of course one wants to use assertions and some diagnostics logging already in constructor code, and, sadly enough it can't be avoided completely to run such already in the static initialisation phase before entering main(). My current solution (putting `NOBUG_INIT` it in the @@ -180,7 +184,7 @@ After reconsidering I think we have several different problems intermixed here. - Then there is the initialisation of common services. For these, it's just fine to do a dedicated call from main (e.g. to init the backend services and for creating the basic empty session for proc and firing off the event loop - for the GUI). I think it's no problem to ''disallow'' any IO, any accessing + for the GUI). I think it's no problem to __disallow any IO,__ any accessing of services in the other layers prior to this point. - What is with shutdown? personally, I'd like to call a explicit shutdown hook at the end of main and to disallow any IO and usage of services outside each @@ -188,21 +192,21 @@ After reconsidering I think we have several different problems intermixed here. to require every destructor to be called and everything to be deallocated, meaning that quite a lot of code is running after the end of main() -- most of which is library generated. + - Ichthyo:: '2008-04-12T04:56:49Z + Ichthyo:: '2008-04-12T04:56:49Z' Some comments... - Regarding organisation of includes:... agreed - Initialisation of the very... - * I won't hesitate to add some C\++ functionality to give *NoBug* an + * I won't hesitate to add some C\++ functionality to give *NoBug* a singleton initialization in C++ - Then there is the initialisation of common services... _agreed_ - What is with shutdown?... * Mostly agreed, I suggest to make all initialization code once-only, a - second call shall bail out (under link:NoBug[]), all shutdown code shall be + second call shall bail out (under NoBug), all shutdown code shall be callable multiple times where subsequent calls are no-ops, this allows us to register at least some things in atexit() handlers, while we should add an explicit clean shutdown too, whenever that (or the atexit) handlers get @@ -219,7 +223,7 @@ OK. So now I've done the following: - Moved lumiera.h and nobugcfg.h to proc/lumiera.hpp and nobugcfg.hpp (i.e. consider them now as Proc-Layer only) - Changed Appconfig to support simple lifecycle hooks, especially a - `ON_BASIC_INIT`. Rationale is that I don't have a lot of "magic" code in the + `ON_BASIC_INIT`. Rationale is that I do not have a lot of ``magic'' code in the Appconfig ctor, rather each subsystem in need of a basic initialisation can install a small callback. It can do so for other lifecycle events too. - Added the usual magic static ctor to install those callbacks in case they @@ -233,7 +237,7 @@ OK. So now I've done the following: for the backend there too, either directly or by registering an callback, just as it fits in better. - This system is extensible: for example I plan to let the - link:SessionManager[] issue `ON_SESSION_INIT` and `ON_SESSION_CLOSE` events. + SessionManager issue `ON_SESSION_INIT` and `ON_SESSION_CLOSE` events. E.g. AssetManager could now just install his callbacks to clean up the internal Asset registry + Ichthyo:: '2008-04-14T03:40:54Z' @@ -243,8 +247,8 @@ absolutely necessary (like flushing the session file, closing display and network connections, writing a backup or committing to a database). I see no problem with bypassing the standard dtor calls in a release build (they add no value besides diagnostics and even may cause a lot of pages to be swapped -in). We could even make this a policy ("don't rely on destructors or -automatic shutdown code to do any cleanup of permanent importance") +in). We could even make this a policy (``don't rely on destructors or +automatic shutdown code to do any cleanup of permanent importance'') .State -> Final I made this final now, details are still in progress to be worked out, but we @@ -255,28 +259,40 @@ CT:: '2008-07-26T09:08:11Z' .State -> Dropped //add reason -Years later, I'm just stumbling accross this RfC, and it looks somewhat +Years later, I'm just stumbling across this RfC, and it looks somewhat outdated and ``misaligned'' IMHO. * this RfC proposes only one tiny and lightweight feature. * Startup and Shutdown of an application like Lumiera requires way more than this. More specifically, we have to consider modularisation. * in hindsight, I was naiive to agree with this proposal. - It can not be that easy. + _It can not be that easy._ * my comments do indeed indicate the direction the further development did take: today, Lumiera does the _exact opposite_ of this proposal, there is *no central init call* -- we use *modularised hooks* instead and each subsystem is self contained. We even have a subsystem manager - to handle dependencies in startup and shtudown. + to handle dependencies in startup and shutdown. For this reason, I mark this RfC as *dropped* now. + In case there is further need of discussion regarding this topic, we should preferably start a new RfC. - + Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~~ +💡 + +[underline]#Historical remark#: This RfC is closely related to discussions +regarding the link:{rfc}/ApplicationStructure.html[Application Structure] +and possibly using a link:{rfc}/AllPluginInterfacesAreC.html#_conclusion[Plug-in based Achitecture]. + +Investigating and debating these possibilities in a productive way was key +to gain an understanding what is required to build and maintain an Application +of this dimension and scope. + +Ichthyostega:: '2025-09-20' + + //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/HowToProceed.txt b/doc/devel/rfc/HowToProceed.txt index 9efad43e0..16a8a2330 100644 --- a/doc/devel/rfc/HowToProceed.txt +++ b/doc/devel/rfc/HowToProceed.txt @@ -1,12 +1,12 @@ Design Process : How to proceed =============================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-16_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-16_ +|*Proposed by* | ct +|==================================== How To Proceed -------------- @@ -15,7 +15,7 @@ How we start... Description ~~~~~~~~~~~ -. Rewiew this wiki, link:DesignProcess[] .. do we want this formalism?. +. Rewiew this wiki, link:/x/DesignProcess.html[RfCs] ... do we want this formalism?. . Setup git repos. . Each developer makes a design sketch (bouml/wiki) about the subsystem he wants to care that is: @@ -25,32 +25,26 @@ Description Please add yourself above, contact people already working on something when you want to join. -Tasks -~~~~~ - -Pros -~~~~ - -Cons -~~~~ - -Alternatives -~~~~~~~~~~~~ - -Rationale -~~~~~~~~~ Comments -------- -* "Do we want this formalism": this level for formalism seems right at the - moment. It will work only if we agree on it and do it always in this way. - Every important (large scale) Issue, Question and Decision should be noted - here and we need to be sure that nothing gets lost. -* For the time being this formalism is enough. Later on, I fear, we will need a - bit more (and some Tool support) - -- link:Ichthyostega[] [[DateTime(2007-06-17T00:24:14Z)]] -* Accepted, deployed, done ... Final - -- link:ct[] [[DateTime(2007-06-27T16:13:25Z)]] +* ``Do we want this formalism'' -- it feels right at the moment. + + It will work only if we agree on it and do it always in this way. + Every important (large scale) Issue, Question and Decision should be noted + here and we need to be sure that nothing gets lost. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2007-06' + +* For the time being this degree of formalism is enough. + + Later on, I am afraid, we will need a bit more (and some Tool support)... + +Ichthyostega:: '2007-06-17T00:24:14Z' + +* Accepted, deployed, done ... Final + +ct:: '2007-06-27T16:13:25Z' + +'''' + +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/InterfaceNamespaces.txt b/doc/devel/rfc/InterfaceNamespaces.txt index 78e00b0a6..6c0f192a4 100644 --- a/doc/devel/rfc/InterfaceNamespaces.txt +++ b/doc/devel/rfc/InterfaceNamespaces.txt @@ -1,12 +1,12 @@ Design Process : Interface Namespaces ===================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-09-18_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-09-18_ +|*Proposed by* | ct +|==================================== Interface Namespaces -------------------- @@ -18,17 +18,18 @@ Description What are the goals? * We need unique identifiers. - * We dont want anyone to register at us, this shall be a free system. - * There are 2 kinds, one bound to persons and one to projects as whole. - * Uniquenes, not identity is the goal, plugins could even be provided + * We do not require anyone to register with us, this shall be a free system. + * There are two kinds, one bound to persons and one to projects as whole. + * Uniqueness, not identity is the goal, plugins could even be provided anonymously. * This is the lowest level interface stuff, usually you'll deal with a high-level descriptor interface which provides much better (human readable) - metainformation about a plugin. - * The names should follow C identifier rules and either not to hard to deciper - for a human or completely abstracted into a numeric ID like gpg id or uuid - * Conclusion followed some mailinglist and IRC discussion: (see - http://lists.lumiera.org/pipermail/lumiera/2008-September/000054.html)[] + meta information about a plugin. + * The names should follow C identifier rules and either not to hard to decipher + for a human or completely abstracted into a numeric ID like GPG id or UUID + * Conclusion followed some discussion on IRC and in the + https://lists.lumiera.org/pipermail/lumiera/2008-September/000054.html[Mailinglist(2008-09)] + First part: unique prefix ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -36,7 +37,7 @@ First part: unique prefix Domain names and emails names encoding ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Domain names in lowercase, dots and special chars removed, first char must be a -aphphanumeric character (if it is numeric, just write it out): +alphanumeric character (if it is numeric, just write it out): ------------------------------------------------------------ lumiera.org -> lumieraorg @@ -47,7 +48,7 @@ aphphanumeric character (if it is numeric, just write it out): These are used when the provider is a project and not an individual person. If the provider of a interface is a individual person then he encodes his email -address in a similar way The @ sign is encoded as uppercase "AT": +address in a similar way The @ sign is encoded as uppercase `"AT"`: ------------------------------------------------------------ @@ -57,8 +58,8 @@ address in a similar way The @ sign is encoded as uppercase "AT": Abstract identifiers ^^^^^^^^^^^^^^^^^^^^ -As alternative method one can use his gpg (or pgp) key ids or full -fingerprints. These are encoded as uppercase 'PGP' or 'GPG' followed with a +As alternative method one can use his GPG (or PGP) key ids or full +fingerprints. These are encoded as uppercase `"PGP"` or `"GPG"` followed with a sequence of hex digits (both upper and lower case allowed): @@ -67,8 +68,8 @@ sequence of hex digits (both upper and lower case allowed): PGP09FF1387811ADFD4AE84310960DEA1B8AC4F4FF4 ------------------------------------------------------------ -Next completely random identifiers (uuid's) are used by prefixing them with -uppercase "UID" followed by some alphanumeric characters (no underline), no +Next completely random identifiers (UUIDs) are used by prefixing them with +uppercase `"UID"` followed by some alphanumeric characters (no underline), no encoding is specified but must conform to be a C identifier, shall give a entropy of 128 bits: @@ -76,27 +77,28 @@ entropy of 128 bits: UIDd557753400ad4ac6912773b1deb4d99d ------------------------------------------------------------ - Remarks: this are now quite a lot more or less unique encodings, notably we - could allow them all, they dont clash with each other. They would be parseable - if needed, but we never ever need to parse them, they are just taken as whole - and have no other meaning then being unique. +.Remarks +This are now quite a lot more or less unique encoding, notably we +could allow them all, they do not clash with each other. They would be parseable +if needed, but we never ever need to parse them, they are just taken as whole +and have no other meaning then being unique. -Following Parts: hierachic namespace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Lumiera itself will use some hierachic naming scheme for it interface +Following Parts: hierarchic namespace +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Lumiera itself will use some hierarchical naming scheme for it interface declarations and implementations. The details will be layed out next, -genereally thinks look like: +generally thinks look like: ------------------------------------------------------------ lumieraorg_backend_frameprovider lumieraorg_plugin_video ------------------------------------------------------------ -it is suggested that anyone providing plugins for lumiera follows this and +it is suggested that anyone providing plugins for Lumiera follows this and extends it with his own identifier: -for examle joecoder``@freevideo.org writes a ultrablur then its identifier +for example `joecoder@freevideo.org` writes a »ultrablur« then its identifier would look like: ------------------------------------------------------------ @@ -108,7 +110,7 @@ would look like: Tasks ~~~~~ -The above described scheme will be implemented and used by me (cehteh). +The above described scheme will be implemented and used by _cehteh_. @@ -117,26 +119,44 @@ Rationale ~~~~~~~~~ I believe that writing plugins for Lumiera shall be simple. We do not want some central registry or management. Anyone shall be able to just start to write -plugins. But that puts some reponsibility on the namespace so that all plugins +plugins. But that puts some responsibility on the namespace so that all plugins can coexist and their names don't clash. The above describes a very simple and -flexible nameing system which anyone can follow. It produces names which should +flexible naming system which anyone can follow. It produces names which should be sufficiently unique for practical purposes. It leaves alternatives for -providing plugins as institutuion, individual or even anonymously. +providing plugins as institution, individual or even anonymously. Conclusion ---------- -Accepted by October.2008 developer meeting +Accepted by the +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_interface_naming_convention[October.2008 developer meeting] -Addendum Internal Interfaces -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Addendum: Internal Interfaces +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interfaces which are internal and not meant for public use have 2 underscores -after the prefix (eg: `lumieraorg__`). These interfaces must not be used by +after the prefix (eg: `lumieraorg__` ). These interfaces must not be used by third party plugins, they are subject of unannounced changes or removal and make no guarantee about backwards compatibility. When we spot someone using -this interfaces we ''will break'' his plugin ''intentionally''! - -- link:ct[] [[DateTime(2008-10-24T03:43:43Z)]] +this interfaces we will *break this plugin* intentionally! -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-10-24T03:43:43Z' + + +Clarification of relevance +~~~~~~~~~~~~~~~~~~~~~~~~~~ +As this RfC touches on the subject of Plug-ins, it should be stated very clearly +that Lumiera is **not based on a »Plugin Architecture«**. This Architecture Style +was indeed link:{rfc}/AllPluginInterfacesAreC.html[proposed and considered] during +the early stages of the project, but rejected later, based on the ensuing discussion +and experience with existing systems, as well as with our own implementation drafts +going into this direction. + +Lumiera will use Plug-ins however, to add _optional capabilities._ +And thus everything stated in this RfC regarding unique identifiers remains valid. + +Ichthyostega:: '2025-09-20' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/LayerNames.txt b/doc/devel/rfc/LayerNames.txt index 8e8698dd1..63a6152a4 100644 --- a/doc/devel/rfc/LayerNames.txt +++ b/doc/devel/rfc/LayerNames.txt @@ -3,12 +3,12 @@ LayerNames // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Fr 05 Oct 2018 15:05:58 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Fr 05 Oct 2018 15:05:58 CET_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract @@ -139,7 +139,7 @@ to consult anyone, since -- right now -- I am working alone on the code base. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -204,5 +204,5 @@ Ichthyostega:: '2018-11-15 19:38:32 +0100' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/LumieraDesignProcess.txt b/doc/devel/rfc/LumieraDesignProcess.txt index 1c8331e74..ae7313a63 100644 --- a/doc/devel/rfc/LumieraDesignProcess.txt +++ b/doc/devel/rfc/LumieraDesignProcess.txt @@ -1,12 +1,12 @@ Design Process : Lumiera Design Process ======================================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-03_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-03_ +|*Proposed by* | ct +|==================================== Define a Lumiera design process ------------------------------- @@ -17,25 +17,25 @@ Description ~~~~~~~~~~~ Just use this Wiki to make it easy to add proposals in a well defined manner. -I'd like to introduce a slightly formalized process for the ongoing Lumiera -planning: - * Every proposal is instantiated as 'Idea', the author gives other people the +I'd like to introduce a slightly formalized process for the ongoing Lumiera planning: + + * Every proposal is instantiated as `*Idea*', the author gives other people the opportunity to review and comment on it with extreme prejudice, while still working out details. - * When the the 'Idea' in a proper form 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. - * At some point we may decide that a 'Draft' becomes a 'Final' (I leave it - open how this decision shall be done for now). 'Final' Documents will be - imported into repository. + * When the the `Idea' in a proper form and worked out in most details it + becomes a `*Draft*' -- such a `Draft' need to be carefully reviewed, + commented and perhaps corrected and rated by the other Developers. + * At some point we may decide that a `Draft' becomes a `*Final*' (I leave it + open how this decision shall be done for now). `Final' RfC documents will be + imported into the Git repository. * Sometimes proposals will become dropped for some reason, this is indicated - by changing their state to 'Dropped', they still stay in the system for + by changing their state to `*Dropped*', they still stay in the system for further reference. Tasks ~~~~~ - * We need to refine link:Lumiera/DesignProcessTemplate[]. + * We need to build and refine a ``Design Process Template''. Pros ~~~~ @@ -57,8 +57,10 @@ Alternatives ~~~~~~~~~~~~ * We could use some forum, Trac, Mailinglist or whatever instead. - * Just for Design documentation 0I would give http://bouml.free.fr/[Bouml] a - try. For myself, I am not very fond of UML Design tools, while Bouml looks + * Just for Design documentation I would give + https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml] a + try. + + For myself, I am not very fond of UML Design tools, while Bouml looks quite promising and we could maintain the UML model in git repositories which would be more favorable than this centralized wiki. The backside is that this needs even more agreement between the developers, everyone has to @@ -68,17 +70,16 @@ Alternatives Rationale ~~~~~~~~~ -Wiki works it is simple to use and just flexible enough to handle the task. I -don't go to install any other software for such tasks on my server. While the -design progresses I'd propose to move our work into git repositories and +Wiki already works, it is simple to use and just flexible enough to handle the task. +I won't go to install any other software for such tasks on my server. While the +design progresses I'd propose to move our work into Git repositories and eventually phase this wiki pages out anyways. I'd rather like to start out -distributed/git right away .. but git gives us only a fine storage layer, for a -design process we need some good presentation layer (later when using git and +distributed/git right away ... but git gives us only a fine storage layer, for a +design process we need some good presentation layer (later when using Git and starting the implementation everyones favorite editor serves for that) I have no better ideas yet to solve the presentation problem other than using this wiki (or maybe bouml). -Comments --------- +'''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/LumieraForwardIterator.txt b/doc/devel/rfc/LumieraForwardIterator.txt index c3fdee880..3c6c5c28f 100644 --- a/doc/devel/rfc/LumieraForwardIterator.txt +++ b/doc/devel/rfc/LumieraForwardIterator.txt @@ -1,20 +1,20 @@ -Design Process: Lumiera Forward Iterator -======================================== +Design Process: Forward Iterator +================================ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2009-11-01_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2009-11-01_ +|*Proposed by* | Ichthyostega +|==================================== -The situation focussed by this concept is when an API needs to expose a +The situation addressed by this concept is when an API needs to expose a sequence of results, values or objects, instead of just yielding a function -result value. As the naive solution of passing an pointer or array creates -coupling to internals, it was superseded by the GoF +result value. The naive solution of passing an pointer or array creates +coupling to internals, and thus was superseded by the GoF https://en.wikipedia.org/wiki/Iterator[Iterator pattern]. Iteration can be -implemented by convention, polymorphically or by generic programming; we use -the latter approach. +implemented by _convention_, _polymorphism_ or by _generic programming;_ +we use the latter approach. Lumiera Forward Iterator concept @@ -24,18 +24,18 @@ An Iterator is a self-contained token value, representing the promise to pull a sequence of data - rather then deriving from an specific interface, anything behaving - appropriately _is a Lumiera Forward Iterator._ + appropriately _can be used as Lumiera Forward Iterator._ - the client finds a typedef at a suitable, nearby location. Objects of this - type can be created, copied and compared. + iterator type can be created, copied and compared. - any Lumiera forward iterator can be in _exhausted_ (invalid) state, which - can be checked by +bool+ conversion. - - especially, default constructed iterators are fixed to that state. + can be checked by `bool` conversion. + - Notably, all default constructed iterators are fixed to that state. Non-exhausted iterators may only be obtained by API call. - - the exhausted state is final and can't be reset, meaning that any iterator + - the exhausted state is final and can not be reset, implying that any iterator is a disposable one-way-off object. - when an iterator is _not_ in the exhausted state, it may be _dereferenced_ - (+*i+), yielding the ``current'' value - - moreover, iterators may be incremented (+++i+) until exhaustion. + (`*i`) to yield the ``current value'' + - moreover, iterators may be incremented (`++i`) until exhaustion. Discussion @@ -43,26 +43,24 @@ Discussion The Lumiera Forward Iterator concept is a blend of the STL iterators and iterator concepts found in Java, C#, Python and Ruby. The chosen syntax should look familiar to C++ programmers and indeed is compatible to STL containers and -ranges. To the contrary, while a STL iterator can be thought off as being just -a disguised pointer, the semantics of Lumiera Forward Iterators is deliberately -reduced to a single, one-way-off forward iteration, they can't be reset, +ranges. However, while a STL iterator can be thought off as being actually ``just +a disguised pointer'', the semantics of Lumiera Forward Iterators is deliberately +reduced to a single, one-way-off forward iteration, they can't be reset or manipulated by any arithmetic, and the result of assigning to an dereferenced iterator is unspecified, as is the meaning of post-increment and stored copies -in general. You _should not think of an iterator as denoting a position_ -- -just a one-way off promise to yield data. +in general. You _should not think of an iterator as something to describe a position_ -- +rather it is a one-time promise to pull some data. Another notable difference to the STL iterators is the default ctor and the -+bool+ conversion. The latter allows using iterators painlessly within +for+ -and +while+ loops; a default constructed iterator is equivalent to the STL -container's +end()+ value -- indeed any _container-like_ object exposing -Lumiera Forward Iteration is encouraged to provide such an +end()+-function, -additionally enabling iteration by +std::for_each+ (or Lumiera's even more -convenient - +util::for_each()+). +`bool` conversion. The latter allows using iterators painlessly within `for` +and `while` loops; a default constructed iterator is equivalent to the STL +container's `end()` value -- and indeed, any _container-like_ object exposing +Lumiera Forward Iteration is encouraged to provide such an `end()`-function, +additionally enabling iteration by +std::for_each+. Implementation notes ^^^^^^^^^^^^^^^^^^^^ -*iter-adapter.hpp* provides some helper templates for building Lumiera Forward +*`iter-adapter.hpp`* provides some helper templates for building Lumiera Forward Iterators. - _IterAdapter_ is the most flexible variant, intended for use by custom @@ -80,7 +78,7 @@ Implementation notes Similar to the STL habits, Lumiera Forward Iterators should expose typedefs for +pointer+, +reference+ and +value_type+. Additionally, they may be used for -resource management purposes by ``hiding'' a ref-counting facility, e.g. +resource management purposes by ``carrying'' a ref-counting facility, e.g. allowing to keep a snapshot or restult set around until it can't be accessed anymore. @@ -94,7 +92,7 @@ relies on that interface for discovering session contents. Besides that, we need more implementation experience. Some existing iterators or collection-style interfaces should be retro-fitted. -See https://issues.lumiera.org/ticket/349[Ticket #349]. + +See https://issues.lumiera.org/ticket/349[Ticket #349]. Moreover, we need to gain experience about mapping this concept down into a flat C-style API. @@ -111,17 +109,16 @@ Alternatives Rationale ~~~~~~~~~ -APIs should be written such as not tie them to the current implementation. +APIs should be written in a way that avoids to tie them to the current implementation. Exposing iterators is known to create a strong incentive in this direction and thus furthers the creation of clean APIs. -Especially in Steam-Layer we utilise already several iterator implementations, +Especially in Steam-Layer we employ already several iterator implementations, but without an uniform concept, these remain just slightly disguised -implementation types of a specific container. Moreover, the STL defines various -and very elaborate iterator concepts. Ichthyo considers most of these an -overkill and an outdated aproach. Many modern programming languages build with -success on a very simple iterator concept, which allows once to pull a sequence -of values -- and nothing more. +implementation types of a specific container. Furthermore, the STL defines +several quite elaborate iterator concepts. _Ichthyo_ considers most of these an +overkill and an outdated implementation-centric approach. Many modern programming +languages rely on a very simple iterator concept with much success. Thus the idea is to formulate a concept in compliance with STL's forward iterator -- but augmented by an stop-iteration test. This would give us basic @@ -136,15 +133,15 @@ Comments -------- //comments: append below -Now in use since more then a year, without turning up any serious problems. -The only _minor concern_ I can see is that this concept, as such, doesn't solve -the problem with exposing implementation details of the underlying container on the API. +This scheme is now in use since more then a year, without turning up any serious problems. +The only _minor concern_ I can see is that this concept, as such, does not solve the +problem with exposing implementation details of the underlying container on the API. Similar to STL Iterators, the actual implementation representation is only disguised -behind a 'typedef'. But, generally speaking, this is an inevitable consequence of the +behind a `typedef'. But, generally speaking, this is an inevitable consequence of the ``zero overhead'' abstraction. For the cases when an indirection (via VTable) is feasible, -I've created the 'IterSource' template, which sticks to this Lumiera Forward Iterator -concept, but provides an opaque frontend, allowing to decouple completely from the -actual implementation. Besides that, over time I've written several standard adapters +I've created the **`IterSource`** template, which adheres to this Lumiera Forward Iterator +concept, yet provides an opaque frontend, allowing to decouple completely from the +actual implementation. Besides that, over time, I have written several standard adaptors for the most common STL containers, plus Map, key and value extractors. Ichthyostega:: 'Sa 16 Apr 2011 00:20:13 CEST' @@ -155,19 +152,21 @@ would require a ``deep copy'' of any underlying data structures. Ichthyostega:: 'Sa 07 Jan 2012 21:49:09 CET' ~~ -NOTE: Lumiera Forward Iterators can be made to work together with the - 'range for loop', as introduced with C++11. The preferred solution - is to define the necessary free functions `begin` and `end` for ADL. - This is best done on a per implementation base. We consider a generic - solution not worth the effort +NOTE: Lumiera Forward Iterators can be made to work together conveniently + with the »Range-for Loop«, as introduced with C++11. The preferred + solution is to define the necessary free functions `begin` and `end` + for ADL. This is best done on a per implementation base. -This is to say, these two concepts can be made to work together well. While, -at a conceptual level, they are not really compatible, and build on a -different understanding: The standard for-loop assumes ``a container'', -while our Forward Iterator Concept deals with ``abstract data sources''. -The user needs to understand the fine points of that conceptual difference: +Considered at a conceptual level, this may seem surprising, since the +Range-Iteration from the C++ standard and our Forward-Iteration do not mesh +up completely, and build upon a different understanding: The standard Range-`for` +Loop assumes ``a container'', or at least ``a data range'', while our +Forward Iterator Concept deals with ``abstract data sources''. So +these are two concepts operating at a different level of abstraction, +yet able to be stacked upon each other. However, the user needs +to understand the fine points of those conceptual differences: -- if you apply the range-`for` construct on a container, you can iterate +- if you apply the Range-`for` construct on a container, you can iterate as often as you like. Even if the iterators of that container are implemented in compliance with the Lumiera Forward Iterator concept. - but if you apply the range-`for` construct on _a given iterator_, @@ -184,9 +183,17 @@ Ichthyostega:: 'Sa 04 Jul 2015 22:57:51 CEST' ~~ Final ~~~~~ -Accepted on developer meeting +Accepted on +link:{ldoc}/devel/meeting_summary/2011-04-13.html#_lumiera_forward_iterator[developer meeting] - Do 14 Apr 2011 02:52:30 CEST Christian Thaeter +Christian Thaeter:: 'Thur 14 Apr 2011 02:52:30 CEST' +TIP: The Lumiera Forward Iterator became a widely used scheme. + One notable extension built on top is the _filter pipeline_ template `IterExplorer`. + Another point worth mentioning is that such an iterator can not only yield values + (as described in this RfC), but may also expose a reference into an underlying + _State Core_ -- which makes high-performance collaboration protocols possible, + while keeping all participants opaque. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt b/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt index 61be3df3c..3c6cdca8c 100644 --- a/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt +++ b/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt @@ -3,23 +3,24 @@ Make Scons the official build System // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Mi 11 Jan 2012 21:45:58 CET_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Mi 11 Jan 2012 21:45:58 CET_ +|*Proposed by* | Christian Thaeter +|==================================== ******************************************************************************** .Abstract -_Bless SCons the default build system for Lumiera._ +_Bless SCons into the default build system for Lumiera._ ******************************************************************************** Description ----------- //description: add a detailed description: -So far we using autotools and scons in parallel. Over time the need arose to have one +So far we are using Autotools and SCons in parallel. +Over time the need arose to have one reliable supported build system. This shall be SCons. @@ -65,7 +66,7 @@ Rationale Conclusion ---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: result of discussions and evaluation during the last years @@ -84,5 +85,5 @@ Christian Thaeter:: 'Wed 11 Jan 2012 22:28:36 CET' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/Manifest.txt b/doc/devel/rfc/Manifest.txt index 8d27ceeb3..c317694c6 100644 --- a/doc/devel/rfc/Manifest.txt +++ b/doc/devel/rfc/Manifest.txt @@ -1,17 +1,17 @@ Design Process : Manifest ========================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-09_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-09_ +|*Proposed by* | ct +|==================================== -Manifest --------- +A Community Manifest +-------------------- -This Proposal describe the general ideas how the community will work together +This Proposal describes the general ideas how the community will work together to create Lumiera. @@ -27,13 +27,17 @@ Background ~~~~~~~~~~ Cinelerra is quite an old project, there is an original version from -heroinewarrior.com and a community fork link:https://cinelerra-cv.wikidot.com/[Cinelerra-CV]. +https://web.archive.org/web/20070519111115/http://heroinewarrior.com/index.php3[»Heroine Virtual« LTD] +aka »Heroine Warrior« and a community maintained version +https://web.archive.org/web/20070519204838/http://cv.cinelerra.org/[Cinelerra-CV]. ~(http://cinelerra-cv.wikidot.com/[2025])~ + The original author claims that there was no-one producing useable input despite their -requests while cinelerra was in development, and indeed the Cinelerra-CV community only +requests while Cinelerra was in development, and indeed the Cinelerra-CV community only feeds back the source released by the original author into their SVN repository and maintains few fixes. There is not much development going on. Some people -have created new functionality/features from time to time which have rarely -been merged into the main repository and maintained by themselves. +have created new functionality/features from time to time which they need +to maintain by themselves, since extensions have rarely +been merged back into the main repository. The Cinelerra community is a quite loose group of individuals, there is some fluctation on the developer base and almost all developers have day jobs which @@ -49,8 +53,8 @@ But there are some bad things too. Notably there is not much progress on the community development. Users don't benefit from new improvements which other people have made. There is a endlessly growing list of bugs and feature requests, when someone sends a patch to the ML he has to invest quite some time -to maintain it until it might be merged. Finally we don't know what heroine -virtual is working on, until we see his next tarball. +to maintain it until it might be merged. Finally we don't know what ``Heroine +Virtual'' is working on, until we see his next tarball. Solution for Lumiera @@ -62,7 +66,7 @@ without maintaining the bad sides again: . *Make it easy to contribute* Even if it is favorable when we have people which are continously working on -Lumiera, it's a fact that people show up, send a few patches and then +Cinelerra, it is a fact that people show up, send a few patches and then disappear. The development model should be prepared for this by: .. Good documentation .. Well defined design and interfaces @@ -104,9 +108,27 @@ things where they are not profound, help each other, make things right instead of blaming someone. Everyone should rate himself at what he can do best on the project. + Comments -------- +[underline]#This document is among the **earliest RfC**s# published in *Summer 2007*, + +as a new community movement was about to form, with the goal to improve Cinelerra +for real, in a new version Cinelerra-3. +At the beginning of 2008, this initiative had turned into a new project, with the +https://web.archive.org/web/20231026200633/https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-March/013474.html[community chosen] +name »*Lumiera*« -- years later, in 2010, documentation and existing RfC entries +were migrated from _Cehteh_'s `pipapo.org` Wiki to the +https://web.archive.org/web/20110513134311/http://lumiera.org/[new Lumiera website], +thereby mass-renaming all references Cinelerra -> Lumiera +While this »Manifest« captures well the open minded spirit of the new project, +actual development never happened in the ``community driven'' everyone pulls-from +everyone style; rather, there were immediately two, later three _core devs,_ +which integrated sometimes large, yet mostly small contributions by other people. +After 2012, _Ichthyo_ kept the project going as a single developer, backed by +a small group of supporters. +Ichthyostega:: '2025-09-15' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MarbleMode.txt b/doc/devel/rfc/MarbleMode.txt index 1a7be25c4..d00e50e98 100644 --- a/doc/devel/rfc/MarbleMode.txt +++ b/doc/devel/rfc/MarbleMode.txt @@ -1,16 +1,18 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-10-10_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-10-10_ +|*Proposed by* | Ichthyostega +|==================================== the Marble Mode --------------- -''dual working styles -- build up from small pieces of clay or cut away the - unneeded parts from a block of marble'' + +[quote] +``dual working styles -- build up from small pieces of clay + +or cut away the unneeded parts from a block of marble'' While the usual UI of video editors quite well supports a working style assembling the result from small building blocks by relying on clips (media @@ -21,43 +23,44 @@ objects) Description ~~~~~~~~~~~ This proposal stems from an discussion on the Mailinglist starting with the -quote from Walter Murch "Marble and Clay". +quote from Walter Murch »Marble and Clay«. + -It is thought to be in support and to complement nasa's -link:DelectusShotEvaluator.html[Delectus Shot Evaluator] +It is thought to be in support and to complement _nasa_'s +link:/rfc/DelectusShotEvaluator.html[RfC: Delectus Shot Evaluator] -The central Idea is to remove the difference between "viewing", i.e. the media -viewer and the timeline/Sequence on the other hand. Lumiera is designed to -handle multiple Sequences, which can even arbitrarily be embedded in one -another (the so called _meta-clips_ ). Basically, Sequences are a comparatively +The central Idea is to remove the difference between ``viewing'' ⟷ ``editing'', +i.e. the media viewer and the timeline/Sequence on the other hand. +Lumiera is designed to handle multiple Sequences, which can even be embedded +arbitrarily in one another (the so called _virtual clips_ or _meta-clips_). +Basically, Sequences are a comparatively cheap resource, so the idea is to create a new Sequence on-the-fly to do the viewing already based on a complete timeline. It is up to the user finally to -promote one of these workbench-like timelines to become "the" master timeline. +promote one of these workbench-like timelines to become ``the'' master timeline. To make this usable, in the GUI there should be a slightly different representation which aims at reducing vertical screen usage. Also the track heads could be reduced, e.g. we don't need controls for mixing and panning, the effect stacks could be reduced to a simple mark indicating that there is any effect in a given time range, anything concerned with the fine points of -wiring, tweaking effects and controling automation could be left out -deliberately. This would allow us to have several independant timelines +wiring, tweaking effects and controlling automation could be left out +deliberately. This would allow us to have several independent timelines above/below each other. There could be at least two, maybe even three or four -"slots" which could be allocated by a timeline to display. Every time you open +``slots'' which could be allocated by a timeline to display. Every time you open a new media, a new Sequence will be created on the fly and a new timeline display of this Sequence will be available, replacing the least recently used timeline display slot. Of course, re-visiting an already opened media will bring back the corresponding timeline in the state you left it, with markers, notes, maybe even trimmings and added clips. Contrast this GUI mode with the -usual working mode (the "clay mode"), where there is _one_ central timeline, -probably with tabs to switch between multiple independant Sequences (including +usual working mode (the »clay mode«), where there is _one_ central timeline, +probably with tabs to switch between multiple independent Sequences (including the ones which actually are embedded in another timeline as meta-clips) -Basically, each of these timelines has a separate, independant transport, but +Basically, each of these timelines has a separate, independent transport, but transports can be locked together, and in locked state you can displace/offset the locked partners relative to one another. Moreover, there would be at least -two viewer windows which would be automatically connected to recieve the ouput +two viewer windows which would be automatically connected to receive the output of the timelines as new timelines are placed in the visible slots to work with. -To round things up, we need good keybindings for navigtation, and of course you +To round things up, we need good key bindings for navigation, and of course you can liberally mark parts and spill them over to another timeline, either overwriting or shifting existing footage there. @@ -72,7 +75,7 @@ Initially this new Sequence would be anonymous. But the moment you do the first non-trivial modification there (like adding a label, trimming off parts, adding /deleting tracks), the new Sequence would be promoted to be a named and persisted entity, which from then on could itself serve as a new -"pseudo-media". It would appear as an asset on its own (probably in a special +``pseudo-media''. It would appear as an asset on its own (probably in a special sub category), and it could be used as a source to create clips from. This way, you could work with your media, prepare it, augment it even by adding effects like colour correction. And because it's a real Sequence, you could do @@ -80,22 +83,22 @@ non-trivial things there right in-place, like adding new sub-tracks, placing other media on them -- and then later on use this prepared media like a real media captured from camera source. -Finally, there should be the possibility to "play" a clip bin, thereby +Finally, there should be the possibility to ``play'' a clip bin, thereby on-the-fly creating a new Sequence filled with all the clips in the order they were arranged in the bin. This would yield a bridge to the more clip-oriented -working style and also provide a cheap implementation of the "sparse timeline" -or "storyboard mode" +working style and also provide a cheap implementation of the ``sparse timeline'' +or ``storyboard mode'' Tasks ^^^^^ * have several switchable _perspectives_ or working modes in the GUI - * associate a _workflow state_ whith each Sequence, to track when an Sequence + * associate a _workflow state_ with each Sequence, to track when an Sequence is just anonymous, gets a named entity, is a clip-bin-tied Sequence, or finally is the master Sequence connected to the global output pipes section. - * work out the details of the "display slot allocation" - * provide an "opening media" compound function, comprised of + * work out the details of the ``display slot allocation'' + * provide an ``opening media'' compound function, comprised of * creating the clip covering the whole media (./) (already implemented) * creating a new Sequence and populating it with this clip * make locked-together transports work @@ -115,12 +118,12 @@ Tasks Rationale ^^^^^^^^^ Lumiera is not pioneering the video editing by computers. We are sort of -second-generation (or even third generation) of computer based editing systms. +second-generation (or even third generation) of computer based editing systems. The tradition of conventional, film based editing clearly shows us these two quite different working approaches, which obviously can have quite some impact -on the resulting style and rythm of the final movie. The distinguishing -property of the working style to be supported by the "marble mode" is that it -bypasses the state of creating and organizing clips, but rather directly +on the resulting style and rhythm of the final movie. The distinguishing +property of the working style to be supported by the »marble mode«s is that it +bypasses the state of creating and organising clips, but rather directly evolves the footage into the final cut. This working style is dual to the common clip based approach, none of them is superior or inferior, thus we should actively support both working styles. @@ -136,12 +139,13 @@ Comments Final ~~~~~ +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_marble_mode[Apr.2011 developer meeting]. + Everyone likes this and we want to have this. But this is rather a concept which needs a lot more discussion for the implementation. Further details may -follow where these thingsare worked out. +follow where these things are worked out. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MasterRepositorySetup.txt b/doc/devel/rfc/MasterRepositorySetup.txt index 366bd56c5..81d092acc 100644 --- a/doc/devel/rfc/MasterRepositorySetup.txt +++ b/doc/devel/rfc/MasterRepositorySetup.txt @@ -1,12 +1,12 @@ -Design Process : Shared Master Repository -========================================= +Design Process : Master Repository +================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-04-08_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-04-08_ +|*Proposed by* | ct +|==================================== Shared Master Repository setup ------------------------------ @@ -15,42 +15,67 @@ This describes how the shared MASTER is set up and syncronized. Description ~~~~~~~~~~~ -We have now a shared master repository in /git/LUMIERA. The public/anonymous -git url is 'git://git.lumiera.org/LUMIERA', for people with ssh access it is -pushable at 'git.lumiera.org:/git/LUMIERA'. +We have now a shared master repository in +https://git.lumiera.org/?p=LUMIERA;a=summary[/git/LUMIERA]. -The repository is maintained by cehteh. It updates daily by a script. +- The public/anonymous git url is [yellow-background]#`git://git.lumiera.org/LUMIERA`# +- for people with ssh access it is pushable at [purple]#`UID@git.lumiera.org:/git/LUMIERA`#. -There are the following branches updated from their respective maintainer -repositories: +The repository is maintained by _cehteh_. It updates daily by a script. -[grid="all"] -`-------------`----------------------------------------------------`---------------------------- -*BRANCHNAME* *DESCRIPTION* - *Automatic updated from* -'master' Stable branch, use this as generic entry point. cehteh, - ichthyo -'library' Support library development cehteh, - ichthyo -'proc' Render core development ichthyo -'backend' Data backend development, cehteh -'gui' GUI development joel ------------------------------------------------------------------------------------------------- +There are the following branches updated from their respective maintainer repositories: -Automatic syncronization is only done for 'fast-forward' updates, conflicting +[options="header", cols="^m,3<,2e"] +|==================================== +|BRANCHNAME | DESCRIPTION | Updated from... +| master | Stable branch; generic entry point. | cehteh, ichthyo +| library | Support library development | cehteh, ichthyo +| proc | Render core development | ichthyo +| backend | Data backend development, | cehteh +| gui | GUI development | joel +|==================================== + +Automatic syncronization is only done for `fast-forward' updates, conflicting changes are rejected. It is still possible to manually push to this repository to override automatic syncronization. -Please suggest changes for this setup when required (new branches, difefrent -maintainers, ...) - Comments -------- -Instead this polling @daily update maintainers might use git hooks on their +Instead of this polling @daily update, maintainers might use git hooks on their repos to push relevant things, be careful not to push cruft or tags (which tags shall be present here is not yet resolved -> no tags for now) - -- link:ct[] [[DateTime(2008-04-08T21:48:51Z)]] -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-04-08T21:48:51Z' + +'''' + +[[historical_remark]] +[underline]#Historical remark#: This RfC describes the setup we used up to ~2012. + +After that point, I was working alone basically (not counting occasional small contributions), +and consequently the current state could be found in the ``ichthyo'' Git repository +most of the time -- yet the shared master repository is still updated occasionally, +as is a mirror at https://github.com/Ichthyostega/Lumiera/[Github] + +This summer I decided to switch the project over to the +link:{ldoc}/technical/code/GitBranching.html[Git-flow] branching model, +knowing from my own professional background that this scheme is a good fit +for this kind of project. +This has the consequence however that the usage pattern described in this RfC +*becomes obsolete*, as actual development mostly takes place on development or +feature branches now, consolidating all progress into the branch `integration`. +The branch `master` carries only tested and released code going forward. + +That being said -- the shared master at [yellow-background]#`git://git.lumiera.org/LUMIERA`# +still contains the _official_ state of the Lumiera codebase, while +actual development is published first in a repository per developer +(so effectively in +https://git.lumiera.org/?p=lumiera/ichthyo;a=summary[the Ichthyo repository] +for the time being); +development is consolidated intermittently into the +https://git.lumiera.org/?p=LUMIERA;a=summary[LUMIERA Git]. + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MistakestoAvoid.txt b/doc/devel/rfc/MistakestoAvoid.txt index 4c671b8c8..0a6e70084 100644 --- a/doc/devel/rfc/MistakestoAvoid.txt +++ b/doc/devel/rfc/MistakestoAvoid.txt @@ -1,18 +1,17 @@ Design Process : Mistakes to avoid ================================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-04-21_ -*Proposed by* link:rick_777[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-04-21_ +|*Proposed by* | rick_777 +|==================================== Mistakes to avoid in the Lumiera design --------------------------------------- - As a multimedia user and experienced programmer, I've found various flaws present in open source Non Linear Video editors. Here I will list the problems and their proposed (or mandatory) solutions. Please forgive me if some of the @@ -22,10 +21,8 @@ wiki. Description ~~~~~~~~~~~ - - As a multimedia user and experienced programmer, I've found the following flaws -present in open source Non Linear Video editors (your mileage may vary) : +present in open source Non Linear Video editors (your mileage may vary): . Frequent crashes (which most of the time make you lose your work) . Reinventing the wheel for every new project @@ -41,15 +38,14 @@ I will expand on the problems and their proposed (or mandatory) solutions. 1. Frequent crashes ~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Frequent Crashes and unsaved work. -*Severity* CRITICAL. -*Solution* Isolating the UI from the rendering and data handling (also - improves the extensibility) -*Required* Yes -*Workarounds* Auto-save (however it's not a real solution for the problem) --------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Frequent Crashes and unsaved work. +|*Severity* | CRITICAL. +|*Solution* | Isolating the UI from the rendering and data handling (also improves the extensibility) +|*Required* | Yes +|*Workarounds* | Auto-save (however it's not a real solution for the problem) +|==================================== Working with multimedia (video / audio) editing is a magnet for segfaults (crashes) due to the handling of pointers and compression algorithms. A bug in @@ -59,7 +55,7 @@ doesn't go to the root of the problem. My proposal is to move the low-level handling of video to a separate process, which then will do the processing - if it crashes, the UI will only report an -error with a dialog (i.e. "the process crashed. Try again?"), but you work will +error with a dialog (i.e. ``the process crashed. Try again?''), but you work will stay safe. I'm not sure of the implementation difficulties that arise from having a shared memory buffer for rendering / processing, but one thing is certain: Whenever you move the cursor or rewind a part of a clip in your @@ -73,34 +69,42 @@ Comments I am not sure yet about separating things into processes, generally it is clear that this would be more robust but there are some performance impacts and -programming problems (massisve amounts of data in shared memory). But most +programming problems (massive amounts of data in shared memory). But most importantly, when a subprocess gets a job and crashes on it, it won't complete the job, we don't have a choice except gracefully abort it. From a user -perspective "It doesn't work!" there is no much difference to a complete crash. +perspective ``It doesn't work!'' there is no much difference to a complete crash. Well and yes we aim to make it crash proof rather, crashes a bugs and have to -be fixed, point. +be fixed, period. Lumiera will never ever loose work, we don't plan to make a project file, -autosafe way. Lumiera will keep projects in an internal database like format -which consists of a Dumpfile and a contingous written logfile. After a -crash/powerdown whatever, this log just gets replayed. The advantages are +auto-save way. Lumiera will keep projects in an internal database like format +which consists of a Dumpfile and a continuous written logfile. After a +crash/power-down whatever, this log just gets replayed. The advantages are countless, imagine persistent, selective undo and so on. Any other format -(cinelerra2 XML, MXF, ...) will be realized by importer/exporter plugins. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +(Cinelerra2 XML, MXF, ...) will be realized by importer/exporter plugins. +ct:: '2008-04-21T11:27:23Z' + +Hereby I confirm that this comment still represents the stance of the +Lumiera project regarding this crucial issue. We _should not tolerate_ +crashes, rather report them and contribute to improvements or alternatives. + +And all user actions in Lumiera are captured as an _Event Log,_ which can +be replayed any time (and in altered form) to recreate any state of the edit. + +ichthyo:: '2025-09-15' 2. Reinventing the wheel for every new project ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Various projects compete and reinvent the wheel -*Severity* Serious (Slows down development time. A lot) -*Solution* Multi-tier design, turn the data handling into a backend and use - whatever UI you prefer -*Required* Yes. Better now that the project hasn't started ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Various projects compete and reinvent the wheel +|*Severity* | Serious (Slows down development time. A lot) +|*Solution* | Multi-tier design, turn the data handling into a backend and use whatever UI you prefer +|*Required* | Yes. Better now that the project hasn't started +|==================================== Imagine the Linux kernel was tied to the window manager. You would have to stick with KDE or GNOME and you couldn't improve it! Fortunately it's not like @@ -112,7 +116,7 @@ the project and change the UI to one that supports skinning, without having to do the complicated video-processing stuff. Separating the processes has an equivalent for web programming, it's called -"separation of concerns", or multi-tier design. When you suddenly change the +»Separation of Concerns«, or multi-tier design. When you suddenly change the database engine, you don't need to change the whole program, just the database module. Same goes for changing the UI from HTML to XML or Flash. If they're separate modules that only communicate through a clearly defined API. @@ -129,7 +133,7 @@ an engine to do the thinking. So I suggest to split the project into four separate tiers (not necessarily processes): -. User interface - communicates with the "project" tier, handles the user +. User interface - communicates with the ``project tier'', handles the user events and does the calls. . The project tier - the main part of the video editor. This one invokes the renderer and decides which effects to apply, saving them as mere parameters @@ -142,7 +146,7 @@ processes): the background while we keep working on the project (after all the project is just a set of data stating which effects to apply to which tracks, and which files are used for the tracks) - instead of just having a window saying - "Rendering, please wait". Even Adobe Premiere Pro suffered from this problem. + ``Rendering, please wait''. Even Adobe Premiere Pro suffered from this problem. This means that if we put enough effort, we can surpass commercial software in certain areas. Note that the rendering engine uses the same API than the project tier, as it works on a copy of the project when doing the final @@ -161,35 +165,47 @@ Comments ^^^^^^^^ Please look at our design drafts, things will be separated (little different -than you describe here). We reuse things which are benefitful (gavl, ffmpeg, +than you describe here). We reuse things which are beneficial (gavl, ffmpeg, ..) but we are also aware that we reinvent the wheel for some things by -intention. Lumieras goal is not just to glue some existing libraries together -under a new gui, there are already a lot projects trying this way. We rather +intention. Lumiera's goal is not just to glue some existing libraries together +under a new Gui, there are already a lot projects trying this way. We rather aim for a ''Professional'' high performance Video editing solution which does some things in a different (maybe more complex) way. We do not use existing -frameworks like MLT or gstreamer because we believe that these do not fit our -goals (gstreamer will be supported through plugins). We do not produce yet -another multimedia framework library (this only happen by coincidence) to be -used by others. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +frameworks like MLT or GStreamer because we believe that these do not fit our +goals (GStreamer will be supported through plugins). We do not intend to produce +yet another multimedia framework library to be used by others. + +ct:: '2008-04-21T11:27:23Z' + +This entry captures in a succinct way the reason *why we build Lumiera*. + +However, this also touches on a deeper theme: + +Whenever we solve a _substantial problem_, we are tied and bound to our solution, +and we have to stick to it. Thus, by solving such a problem _for real_, +we loose the ability to do ``anything we want, anytime''. +Since we are human, we have to pick one path and forgo all the +other, possible ones. _Doing so is not a ``mistake''._ + +Now one might try to escape from this dilemma, by defining _flexibility_ +or _sovereignty_ as the actual problem. It seems even feasible to address +this by turning it into a schematism -- and then you are bound to that one. + +ichthyo:: '2025-09-15' + 3. Lack of a user-friendly and extensible UI. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Often, editors provide a very poor and buggy interface. - Examples: Jahshaka doesn't even provide tooltips for the various tools, and - the documentation is poor; In Cinelerra I've noticed some bugs when using the - open dialog, I'd rather have the KDE one, thanks. -*Severity* From Annoying to Serious. -*Solution 1* Use a library that allows you to use different widget - libraries, like wxWidgets. -*Required* Recommended, but not obligatory. -*Solution 2* Write different user interfaces, but they'd be hard to maintain. -*Required*, No. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Often, editors provide a very poor and buggy interface. +|*Severity* | From Annoying to Serious. +|*Solution-1* | Use a library that allows you to use different widget libraries, like wxWidgets. +|*Required* | Recommended, but not obligatory. +|*Solution-2* | Write different user interfaces, but they'd be hard to maintain. +|*Required* | No. +|==================================== This problem is complicated, we need a good framework for handling the tracks. Perhaps this could become a separate project. Ideas are welcome. @@ -198,31 +214,49 @@ Perhaps this could become a separate project. Ideas are welcome. Comments ^^^^^^^^ -Joel started working on a GUI recently and making good progress. The UI should -finally be quite flexible as it mostly provides a skeletion where plugins +Joel started working on a GUI recently and makes good progress. The UI should +finally be quite flexible as it mostly provides a skeleton where plugins render to. We have quite a lot ideas about the UI and user input is welcome. The UI is currently the most separate tier in the design, i'd like to make it a -plugin itself which is loaded when lumiera is started in a gui mode, but it is -to early to say how exactlly it will be integrated, except that we all agree +plugin itself which is loaded when Lumiera is started in a Gui mode, but it is +to early to say how exactly it will be integrated, except that we all agree that GUI is optional and Lumiera can also run headless, script driven. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] + +ct:: '2008-04-21T11:27:23Z' + +It is many years later now; we indeed do load our GUI as a plug-in, +yet have not gained much by this move. The reason is, what we actually need +for editing video is hard to implement in _any_ toolkit. Once you start solving +_that_ problem, you are bound in very intricate ways to the specific toolkit +you just happened to choose (in our case, this is GTK). + +In a nutshell, being ``user-friendly and extensible'' is not something to +be solved at an _abstract, generic level_ -- we'll have to face the fact +that _a beginner_ will have quite different demands than a experienced +professional. And Lumiera is a tool for professionals. Being beginner +friendly is certainly desirable, yet it remains a secondary goal, and +we have not even made so much inroads regarding the primary goal. + +ichthyo:: '2025-09-15' + 4. Lack of support for certain video formats or codecs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Lack of support for certain video formats or codecs. -*Severity* Critical. -*Workarounds* 1. Give a help page for the user to do his own conversion, but - this is very inelegant, annoying, and a waste of time. 2. Provide conversion - on the fly, and keep a separate "preprocessed" copy of the imported clip in a - separate directory. This is a nice middle ground, IMHO. -*Solution* Use a wrapper library as stated in problem # 2, having a - plugin-based design is recommended. -*Required* Yes. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Lack of support for certain video formats or codecs. +|*Severity* | Critical. +|*Workarounds* | 1. Give a help page for the user to do his own conversion, but + this is very inelegant, annoying, and a waste of time. + 2. Provide conversion on the fly, and keep a separate + _preprocessed copy_ of the imported clip in a + separate directory. This is a nice middle ground, IMHO. +|*Solution* | Use a wrapper library as stated in problem # 2, having a + plugin-based design is recommended. +|*Required* | Yes. +|==================================== Some editors like Cinelerra are hardwired into using one format, or have a phobia to certain formats / codecs (i.e. DivX AVI's). If we separate the @@ -236,25 +270,33 @@ compatibility for future formats. Comments ^^^^^^^^ -Lumiera is a video editor we don't care (*cough*, not really true) about video +Lumiera is a video editor we don't care (\*cough*, not really true) about video formats. Everything which comes In and goes Out is defined in plugins which -handle video formats. We currently decided to use 'gavl' because it is a nice -small library which does exactly what we want. Later on gstreamer and other -such kinds of decoder/encoder/processing-pipe libs will be realized. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +handle video formats. + +ct:: '2008-04-21T11:27:23Z' + +So this point is not hard to solve (use plugins), yet this obvious +solution creates a lot of much more tricky problems. In Lumiera, +we attempt to actually solve those secondary problems, instead of +just stating ``this can be solved by plug-ins'' (as most other +existing software does). Unfortunately, this makes the project +very complex. The chosen path seems feasible, yet honestly, +I do not know if we'll ever make it. + +ichthyo:: '2025-09-15' 5. Lack of documentation ~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Some video editors have very poor documentation (and that's an - understatement *cough* Jahshaka *cough* ) -*Severity* Critical. -*Solution* Have a team for the documentation. -*Required* Yes. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Some video editors have very poor documentation (and that's an understatement) +|*Severity* | Critical. +|*Solution* | Have a team for the documentation. +|*Required* | Yes. +|==================================== Nuff said. @@ -262,7 +304,7 @@ Nuff said. Comments ^^^^^^^^ -Quote from Ohloh.net: (http://www.ohloh.net/projects/lumiera)[] +Quote from https://openhub.net/p/lumiera/[Openhub.net (formerly »Ohloh«)]: ------------------------------------------------------------ Extremely well-commented source code @@ -274,25 +316,37 @@ projects on Ohloh. ------------------------------------------------------------ -Nuff saied... Oh well, about user docs we like to get that impressive ratings -there too, any helpers? - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +``Nuff said''... + +Oh well, about user docs we like to get that impressive ratings there too, any helpers? + +ct:: '2008-04-21T11:27:23Z' + +Here I'd like to add that writing is hard -- any writing, not only writing code -- +and writing text that other people can understand and which is accurate at +the same time is even harder. It requires a lot of resources, and typically +developers are not good at writing in a way that is understandable by +``average joe'', while people good at writing nice text seem to have quite +some problems with understanding the thinking style pertinent to +software engineering. So, let's say: ``we keep trying'' + +ichthyo:: '2025-09-15' + 6. Lack of cross-platform support ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Where's my Windows version? -*Severity* Blocker -*Solution* Use a cross-platform toolkit for the UI. -*Required* Depends, do you plan to make it Cross-Platform? --------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Where's my Windows version? +|*Severity* | Blocker +|*Solution* | Use a cross-platform toolkit for the UI. +|*Required* | Depends, do you plan to make it Cross-Platform? +|==================================== A good example for this is the Code::Blocks IDE, which was thought of being cross-platform from the beginning. Curiously, at first the project was -Windows-only, and its only F/OSS alternative was Dev-C++ from Bloodshed (eew). +Windows-only, and its only F/OSS alternative was Dev-C\++ from Bloodshed (eew). Otherwise you'd have to stick with proprietary applications like Visual C++. In Linux there were various IDE's, but they were Linux-only. Since Code::Blocks @@ -310,27 +364,44 @@ Comments ^^^^^^^^ We refuse to make it cross platform intentionally. Most things are written -portable, POSIX compatible, some might need platform specific fixes. But our -target is primary Linux (because thats what we use) secondary any other Free OS -(hopefully we find some testers/maintainers for that). Lumiera ''might'' run on +in a portable style, and POSIX compatible; some might need platform specific fixes. +But our target is primary Linux (because that's what we use) secondary any other Free OS +(hopefully we find some testers/maintainers for that). Lumiera _might_ run on OSX and patches will be accepted, but it is not a free platform so we don't -care by ourself. Windows due its diffrent system interfaces will be hard to +care by ourselves. Windows due its different system interfaces will be hard to port, if someone wants to do that, have fun, we will accept patches to, but we -do not support it in *any* way by ourself. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +do not support it in *any* way by ourselves. + +ct:: '2008-04-21T11:27:23Z' + +For a typical ``business'' application, this is largely a problem of the UI; +we tend to solve that problem by using web technology nowadays, of relying +on similar _frameowork solutions_. Doing so however incurs significant cost; +the following point -- scripting languages -- is one of the symptoms. + +However, video processing is still a technology pushing the limits. +We can address this either by aiming at an industrial setup, where the +actual processing is done in a server farm. Or you can limit yourself +to what can be achieved on a personal computer -- which requires to +keep priorities straight and deliberately abandon unnecessary +secondary goals and ``nice to haves'' + +The Lumiera project follows the second path. + +What is _essential_ thus becomes a question of philosophy, or politics. + +ichthyo:: '2025-09-15' 7. Dependency on scripted languages like Python, which make installation a mess ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Installation can be a mess if we depend on scripted languages. -*Severity* Annoying, the end user might just conform with another project - that "just works". -*Solution* Make it in C++ or other easily-compilable language. -*Required* VERY recommended. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Installation can be a mess if we depend on scripted languages. +|*Severity* | Annoying, the end user might just conform with another project that ``just works''. +|*Solution* | Make it in C++ or other easily-compilable language. +|*Required* | VERY recommended. +|==================================== I've had to install several packages for my distro (whose repository is not as large as others like Ubuntu's) from source. Some of them depend on very @@ -342,62 +413,79 @@ work on a common language, like C++. Comments ^^^^^^^^ -At some point a scripting language ''will'' be required, yet to drive the -testsuite, make headless rendering work and so on. We need to provide -installation instructions and/or even bundle this language with Lumiera. This -will likely become a small embedded language like Lua or some kind of forth (or -maybe some scheme?) it should not depend on strange modules which are not part -of the core scripting language distribution (or we shall provide them too), -needs to be worked out. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +At some point a scripting language _will_ be required, be it to drive the +testsuite, make headless rendering work and so on. This +will likely become a small embedded language like Lua... +details need to be worked out. + +ct:: '2008-04-21T11:27:23Z' + +This decision was revised and changed. Lumiera is written in C++ and +will certainly require some special media processing plug-ins, but +it will _not require any scripting language_ for core tasks. + +Yet a script runner and script driven use is on the main agenda, +since that is an essential feature for large scale media editing projects, +where at least some kind of quality render happens on a cloud platform. +Our goal is to stick to widely used and commonly packaged software and +libraries whenever possible. + +ichthyo:: '2025-09-15' -Author's comments -^^^^^^^^^^^^^^^^^ - -Some of the measures stated in this document are optional, but separating the -processes for the rendering engine, editor and User Interface are the optimal -solution and required to avoid common problems. Discussion ---------- +Some of the measures stated in this document are optional, but separating the +processes for the rendering engine, editor and User Interface are the optimal +solution and required to avoid common problems. + +rick_777:: '2008-04' Mostly we agree with the general statements in this Design Entry. But there are some points which don't stand the test of a detailed technical discussion. For -example, you simply can't state it's a 'mistake' not to write code which +example, you simply can't state it's a ``mistake'' not to write code which similarly runs on windows and *nix. Well. You could try to write it in Java. See my point? While today it's quite feasible to write office stuff or banking applications in a cross-platform manner, a video editor still is a different kind of a beast. -A similar argumentation holds true for the question, wether or not to use +A similar argumentation applies to the question, whether or not to use separate processes and IPC. While it certainly is a good idea to have the X server or a database running in a separate process, the situation is really -quite different for editing video. Hopefully it's clear why. - -Could you please rework this Design Entry in a way that we can finalize -(accept) it? +quite different for editing video. Doing that with collaborating processes +and shared memory is anything than trivial, and brings its own set of +difficulties and limitations. So I would not rule it out, yet it +is clearly not the ``only true solution'' +Could you please rework this Design Entry in a way that we can finalise +(accept) it? + +-- * Please remove the section about windows * Please separate out things needing technical discussion and are not just - "mistakes", thus retaining only the big picture statements (on which we all - agree) -* How to secure the application against crashes -* If it is viable/desirable to run the gui in a separate process really needs - in-depth technical discussion (create a new Design Entry for this) -* How to deal with the dependencies problem in combination with - plugins/extensions and script languages - -- link:Ichthyostega[] [[DateTime(2008-10-05T01:51:50Z)]] + ``mistakes'', thus retaining only the big picture statements (to which + the core developers of Lumiera largely agree). Notably... + + ** Securing the application against crashes is a non-trivial task + ** If it is viable/desirable to run the Gui in a separate process really + needs in-depth technical discussion (create a new Design Entry for this) + ** How to deal with the dependencies problem in combination with + plugins/extensions and script languages +-- + +Ichthyostega:: '2008-10-05T01:51:50Z' Conclusion ---------- -The October.2008 dev meeting decided to 'drop' this design proposal as is. +The +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_mistakes_to_avoid[October.2008 dev meeting] +decided to __`drop'__ this design proposal as is. -Basically, this text just tells us "to make Lumiera good", and especially it -contains a mixture of topics +In a nutshell, leaving out all the technicalities, this text just tells us +``to make Lumiera good''. Beyond that, it contains a mixture of topics: * We fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic @@ -407,21 +495,21 @@ contains a mixture of topics which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements. -While it is certainly 'desirable' to be cross-platform as much as possible and -especially '''target Microsoft Windows''', we don't see much possibilities with +While it is certainly _desirable_ to be cross-platform as much as possible and +especially _target Microsoft Windows_, we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform. -While it is certainly 'desirable' to make the application as robust as -possible, we don't see how '''using multiple separate processes''' could help -us with this goal ''without creating major scalability or performance -problems'' due to the use of shared memory. And, yet more important: we don't +While it is certainly _desirable_ to make the application as _robust_ as +possible, we don't see how ``using multiple separate processes'' could help +us with this goal _without creating major scalability or performance +problems_, due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner. '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt b/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt index 68053e908..34f9057f0 100644 --- a/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt +++ b/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt @@ -1,12 +1,12 @@ Design Process : IRC Developer Meeting ====================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-15_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-15_ +|*Proposed by* | ct +|==================================== IRC Developer Meeting @@ -26,26 +26,19 @@ Things like: * Who needs help for something * Make Decisions about pending proposals -We should make small 'to be talked about' list beforehand (on the wiki) and +We should make small ``to be talked about'' list beforehand (on the wiki) and write an also small protocol afterwards about the decisions made. -I'd suggest to do this first Friday of each month at 21:00GMT, thats late +I'd suggest to do this first Friday of each month at 21:00GMT, that's late evening in Europe and afternoon in USA. Details need to be acknowledged. -Tasks -~~~~~ - - -Pros -~~~~ - Cons ~~~~ - * Inflexible - People's lives and schedules can easily change within a few + * Inflexible -- People's lives and schedules can easily change within a few months thus making them unavailable for further meetings @@ -57,41 +50,44 @@ Alternatives resolve scheduling conflicts. -Rationale -~~~~~~~~~ Comments -------- -* A short meeting every week is a must. "meeting" means a fair amount of the +* A short meeting every week is a must; ``meeting'' means a fair amount of the developers involved show up and there is a possibility to point at current problems. We could make a Full Meeting in the way proposed by - link:MichaelPloujnikov[] additionally. But even one week can be dangerousely + MichaelPloujnikov additionally. But even one week can be dangerousely long in software developement, esp. when the dev process is so open and distributed. * Personally, I am OK with Friday 21GMT - -- link:Ichthyostega[] [[DateTime(2007-06-17T00:29:54Z)]] + +Ichthyostega:: '2007-06-17T00:29:54Z' * Friday 21GMT is only good for me starting in two weeks until September. After that it's booked for the Winter. Thursday 21GMT would be better. - -- link:MichaelPloujnikov[] [[DateTime(2007-06-17T03:09:36Z)]] + +MichaelPloujnikov:: '2007-06-17T03:09:36Z' * Also Ok for me - -- link:ct[] [[DateTime(2007-06-17T17:20:37Z)]] + +ct:: '2007-06-17T17:20:37Z' * I think this (monthly) meeting should not be too frequent and address more global project directions, having a more frequent meeting rather makes it more unattractive and time consuming for slightly involved people. This does - not means that we cant meet more often, but this should be acknowledged + not mean that we can't meet more often, but this should be acknowledged between people who work together on some features/subsystems. That would also have the benefit that such small groups are very flexible to meet, even daily on hot phases and able to acknowledge times when all members can attend. And later if timing is not that good only one person of such a subproject/group may attend to the monthly meeting and report/collect information there. Its likely hard enough to get many developers to meet at one time in month (when - we have more devs than now :P) - -- link:ct[] [[DateTime(2007-06-17T17:20:37Z)]] + we have more devs than now 😜) -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2007-06-17T17:20:37Z' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/NoBugFlags.txt b/doc/devel/rfc/NoBugFlags.txt index 753ecd452..e6b4ad19d 100644 --- a/doc/devel/rfc/NoBugFlags.txt +++ b/doc/devel/rfc/NoBugFlags.txt @@ -1,25 +1,24 @@ NoBug logging flag hierachy =========================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-04-05_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-04-05_ +|*Proposed by* | ct +|==================================== -link:NoBug[] logging flag hierachy ----------------------------------- +NoBug logging flag hierachy +--------------------------- -link:NoBug[] allows hierachical organization of logging flags. Propose a -documentation/planning about the setup. +https://nobug.pipapo.org/[NoBug] allows hierachical organization of logging flags. +Propose a documentation/planning about the setup. Description ~~~~~~~~~~~ Take a look at my draft at: -link:http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=doc/devel/nobug_flags.t -t;h=74471e255e6ebfedb642e450bdfd3f79e346c600;hb=backend[NoBug_flags] +https://git.lumiera.org/?p=LUMIERA;a=blob;f=doc/devel/nobug_flags.txt;h=325141acb52a7be7f75425359b6057c74ed30253;hb=a03e3c5e73a4c0be2264ac4e4e0f02eb8749837b[nobug_flags.txt] I've added the things I planning for the backend, others might add their own plans there too. So far this is an early draft, comments welcome. @@ -29,9 +28,8 @@ NOTE: outdated information. Have a look at `include/logging.h` Tasks ~~~~~ * Needs a file.c defining the common root see - link:Lumiera/DesignProcess/GlobalInitialization[] - * Everyone needs to setup this hierachy by NOBUG_DEFINE_FLAG_PARENT (flag, - parent_flag); + link:{rfc}/GlobalInitialization.html[RfC: Global Initialization] + * Everyone needs to setup this hierachy by `NOBUG_DEFINE_FLAG_PARENT (flag, parent_flag);` Pros @@ -63,4 +61,6 @@ Ichthyostega:: 'Di 29 Okt 2013 05:52:34 CET' ~~ //endof_comments: -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/NormalizedDeviceCoordinates.txt b/doc/devel/rfc/NormalizedDeviceCoordinates.txt index b594cc3b2..1ec108230 100644 --- a/doc/devel/rfc/NormalizedDeviceCoordinates.txt +++ b/doc/devel/rfc/NormalizedDeviceCoordinates.txt @@ -1,16 +1,16 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2009-01-14_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2009-01-14_ +|*Proposed by* | ct +|==================================== Normalized Device Coordinates ----------------------------- -AkhIL pointed me out to some blender problem and how renderman fixes that. We -should use this too. +_AkhIL_ pointed out to me some blender problem and how ``renderman'' fixes that. +We should use this too. @@ -54,33 +54,14 @@ Just snippet from IRC log: -Tasks -^^^^^ -Discussion -~~~~~~~~~~ - -Pros -^^^^ - - - -Cons -^^^^ - - - -Alternatives -^^^^^^^^^^^^ - - Rationale ~~~~~~~~~ -TBD +^[red]#to be written#^ @@ -91,22 +72,22 @@ Comments One issue where I always assumed we'd need to define something of this sort is for proxy editing. Especially this is a problem in conjunction with masks. -Basically, this means a bit more of "vector graphics". With film/video editing, +Basically, this means a bit more of ``vector graphics''. With film/video editing, this was rather unusual, but with the advent of more and new digital video/film formats it gets more and more important. Also, our considerations regarding time handling and quantisation to single frames somewhat fit into this line of -thought. Up to now, rather the standard way of thinkin was to use a "project -framerate" and a fixed resolution in pixels. But we certainly can do better. +thought. Up to now, rather the standard way of thinking was to use a ``project +framerate'' and a fixed resolution in pixels. But we certainly can do better. - -- Ichthyostega 18:09:50 +Ichthyostega:: '2009-01-14 18:09:50' Parked ~~~~~~ deferred for later, generally accepted. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/OfficialAssemblyLanguage.txt b/doc/devel/rfc/OfficialAssemblyLanguage.txt index a60444951..43b5b75da 100644 --- a/doc/devel/rfc/OfficialAssemblyLanguage.txt +++ b/doc/devel/rfc/OfficialAssemblyLanguage.txt @@ -1,12 +1,12 @@ Design Process : Official Assembly Language =========================================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-08-01_ -*Proposed by* link:PercivalTiglao[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-08-01_ +|*Proposed by* | PercivalTiglao +|==================================== Official Assembly Language @@ -16,7 +16,7 @@ I describe here an optimization that might have to be be taken into account at the design level. At very least, we should design our code with auto-vectorization in mind. At the most, we can choose to manually write parts of our code in assembly language and manually vectorize it using x86 SSE -Instructions or !PowerPC !AltiVec instructions. By keeping these instructions +Instructions or PowerPC AltiVec instructions. By keeping these instructions in mind, we can easily achieve a large increase in speed. @@ -44,14 +44,14 @@ assembly-level libraries somewhere in our code. Tasks -~~~~~ - -* Choose an "Official" assembly language / platform. +^^^^^ +* Choose an ``Official'' assembly language / platform. * Review the SIMD instructions avaliable for that assembly language. -* For example, the Pentium 2 supports MMX instructions. Pentium 3 supports MMX - and SSE Instructions. Early Pentium4s support MMX, SSE, and SSE2 - instructions. Core Duo supports upto SSE4 instructions. AMD announced SSE5 - instructions to come in 2009. + ** For example, the Pentium 2 supports MMX instructions. + ** Pentium 3 supports MMX and SSE Instructions. + ** Early Pentium4s support MMX, SSE, and SSE2 instructions. + ** Core Duo supports upto SSE4 instructions. + ** AMD announced SSE5 instructions to come in 2009. * Consider SIMD instructions while designing the Render Nodes and Effects architecture. * Write the whole application in C/C++ / Lua while leaving sections to optimize @@ -60,8 +60,7 @@ Tasks Pros -~~~~ - +^^^^ Assuming we go all the way with an official assembly language / platform... * Significantly faster render and previews. (Even when using a high-level @@ -71,10 +70,8 @@ Assuming we go all the way with an official assembly language / platform... Cons -~~~~ - -* Earlier architectures of that family will be significantly slower or - unsupported +^^^^ +* Earlier architectures of that family will be significantly slower or unsupported * Other architectures will rely on C / C++ port instead of optimized assembly * Redundant Code @@ -85,14 +82,14 @@ Alternatives * We only consider auto-vectorization -- GCC is attempting to convert trivial loops into common SSE patterns. Newer or Higher level instructions may not be supported by GCC. This is turned on - http://gcc.gnu.org/projects/tree-ssa/vectorization.html[in GCC4.3 with + https://gcc.gnu.org/projects/tree-ssa/vectorization.html[in GCC4.3 with specific compiler flags] * We can consider assembly but we don't officially support it -- We leave the holes there for people to patch up later. Unofficial ports may come up, and maybe a few years down the line we can reconsider assembly and start to reimplement it down the road. * Find a SIMD library for C/C++ -- Intel's ICC and - http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Vector-Extensions.html[GCC] both + https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Vector-Extensions.html[GCC] both have non-standard extensions to C that roughly translate to these instructions. There is also the http://www.pixelglow.com/macstl/valarray/[macstl valarray library] mentioned @@ -112,50 +109,57 @@ optimization avaliable in the future, then we should be good. Comments -------- -* I have to admit that I don't know too much about SSE instructions aside from - the fact that they can operate on 128-bits at once in parallel and there are - some cache tricks involved when using them. (you can move data in from memory - without bringing in the whole cache line). Nonetheless, keeping these - assembly level instructions in mind will ease optimization of this Video - Editor. Some of the instructions are high-level enough that they may effect - design decisions. Considering them now while we are still in early stages of - development might prove to be advantagous. Optimize early? Definitely not. - However, if we don't consider this means of optimization, we may design - ourselves into a situation where this kind of optimization becomes - impossible. +I have to admit that I don't know too much about SSE instructions aside from +the fact that they can operate on 128-bits at once in parallel and there are +some cache tricks involved when using them. (you can move data in from memory +without bringing in the whole cache line). Nonetheless, keeping these +assembly level instructions in mind will ease optimization of this Video +Editor. Some of the instructions are high-level enough that they may effect +design decisions. Considering them now while we are still in early stages of +development might prove to be advantageous. Optimize early? Definitely not. +However, if we don't consider this means of optimization, we may design +ourselves into a situation where this kind of optimization becomes +impossible. -* I don't think we should change any major design decisions to allow for - vectorization. At most, we design a utility library that can be easily - optimized using SIMD instructions. Render Nodes and Effects can use this - library. When this library is optimized, then all Render Nodes and Effects - can be optimized as well. -- link:PercivalTiglao[] - [[DateTime(2008-08-01T16:12:11Z)]] +I don't think we should change any major design decisions to allow for +vectorization. At most, we design a utility library that can be easily +optimized using SIMD instructions. Render Nodes and Effects can use this +library. When this library is optimized, then all Render Nodes and Effects +can be optimized as well. -* Uhm, the Lumiera core (backend, proc, gui) doesn't do any numbercrunching. - This is all delegated to plugins (libgavl, effects, encoders). I think we - don't need any highly assembler/vector optimized code in the core (well, lets - see). This plugins and libraries are somewhat out of our scope and thats good - so, the people working on it know better than we how to optimize this stuff. - It might be even worthwile to try if when we leave all vectorization out, if - then the plugins can use the vector registers better and we gain overall - performance! - -- link:ct[] [[DateTime(2008-08-03T02:27:14Z)]] +PercivalTiglao:: '2008-08-01T16:12:11Z' -* Another idea about a probably worthwhile optimization: gcc can instumentate - code for profileing and then do arc profileing and build it a second time - with feedback what it learnd from the profile runs, this mostly affects - branch prediction and can give a reasonable performance boost. If somone - likes challenges, prepare the build system to do this: -. build it with -fprofile-arcs -. profile it by running ''carefully'' selected benchmarks and tests. -. rebuild it again this time with -fbranch-probabilities +The Lumiera core (backend, proc, gui) doesn't do any number crunching. +Any actual media processing will be delegated to plugins (lib-Gavl, effects, encoders). +I think we don't need any highly assembler/vector optimized code in the core (well, lets see). +This plugins and libraries are somewhat out of our scope and that's good so, the people working +on it know better than we how to optimize this stuff. + +It might be even worthwhile to try if when we leave all vectorization out, +if then the plugins can use the vector registers better and we gain overall +performance! + +ct:: '2008-08-03T02:27:14Z' + +Another idea about a probably worthwhile optimization: GCC can instrument +code for profiling and then do arc profiling and build it a second time +with feedback what it learned from the profile runs, this mostly affects +branch prediction and can give a reasonable performance boost. If someone +likes challenges, prepare the build system to do this: + +-- +. build it with `-fprofile-arcs` +. profile it by running _carefully selected_ benchmarks and tests. +. rebuild it again this time with `-fbranch-probabilities` . PROFIT - -- link:ct[] [[DateTime(2008-08-03T02:27:14Z)]] +-- -* I've discussed general ideas around, and I agree now that "core Lumiera" is - not the place to think of these kinds of optimizations. So I'll just move - this over to dropped. -- link:PercivalTiglao[] - [[DateTime(2008-08-04T18:33:58Z)]] +ct:: '2008-08-03T02:27:14Z' + +I've discussed general ideas around, and I agree now that ``core Lumiera'' +is not the place to think of these kinds of optimizations. +So I'll just move this RfC to dropped. + +PercivalTiglao:: '2008-08-04T18:33:58Z' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ProcBuilder.txt b/doc/devel/rfc/ProcBuilder.txt index ea8492220..1c6b5c63a 100644 --- a/doc/devel/rfc/ProcBuilder.txt +++ b/doc/devel/rfc/ProcBuilder.txt @@ -1,12 +1,12 @@ -Design Process: Builder within the Steam-Layer -============================================== +Design Process: Builder +======================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Builder within the Steam-Layer ------------------------------ @@ -42,7 +42,7 @@ configuration down into the low-level model using generic rules. Pros ^^^^ * Separation, decoupling - * Architectural approach instead of just hacking away... + * Architectural aproach instead of just hacking away... Cons ^^^^ @@ -55,14 +55,14 @@ This design was chosen as a direct consequence of the problems encountered in the Cinelerra-2 codebase. * Separating this way allows us to take on different viewpoints on what is - "good" and "efficient". + ``good'' and ``efficient''. * In the low-level view simplicity and efficiency of computation is the main criterion. * Whereas in the high-level view a good modeling of the problem domain and maximum flexibility is preferable. * The high-level view is taken out of the critical code path, allowing for advanced and even experimental technologies without endangering the whole - application's usability. In the low-level realm, 'speed' is measured in ms, + application's usability. In the low-level realm, _speed_ is measured in ms, whereas in the high-level domain, speed is rather measured in 100ms. * The separation creates distinct interfaces and allows people with very different skill sets to work in parallel at the various levels of the App. @@ -72,6 +72,8 @@ Conclusion ---------- This proposal reflects a distinct approach taken right from start. -Marked 'final' at October.2008 developer meeting +Marked __`final'__ at the +link:{}/devel/meeting_summary/2008-10-10.html#_the_builder[October.2008 developer meeting] -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ProcHighLevelModel.txt b/doc/devel/rfc/ProcHighLevelModel.txt index f253cf77b..6eb91cb7f 100644 --- a/doc/devel/rfc/ProcHighLevelModel.txt +++ b/doc/devel/rfc/ProcHighLevelModel.txt @@ -1,15 +1,15 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-08-16_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-08-16_ +|*Proposed by* | Ichthyostega +|==================================== High-level model in the Steam-Layer ----------------------------------- -The purpose of this link:DesignProcess[] entry is to collect together +The purpose of this DesignProcess entry is to collect together informations regarding the design and structure of the high-level model of Lumiera's Steam-Layer. Most of the information presented here is already written down somewhere, in the @@ -21,7 +21,7 @@ tracks, which further helped to shape the model as presented here. While the low-level model holds the data used for carrying out the actual media data processing (=rendering), the high-level model is what the user works upon when performing edit operations through the GUI (or script driven in -"headless"). Its building blocks and combination rules determine largely what +``headless''). Its building blocks and combination rules determine largely what structures can be created within the http://www.lumiera.org/wiki/renderengine.html#Session[Session]. On the whole, it is a collection of @@ -68,8 +68,8 @@ possible to create cyclic connections by such arbitrary wiring, which will be detected by the builder and flagged as an error. While pipes have a rather rigid and limited structure, it is allowed to make -several connections to and from any pipe — even connections requiring an -stream type conversion. It is not even necessary to specify ''any'' output +several connections to and from any pipe -- even connections requiring an +stream type conversion. It is not even necessary to specify _any_ output destination, because then the wiring will be figured out automatically by searching the context and finally using some general rule. Connecting multiple outputs to the input of another pipe automatically creates a *mixing step* @@ -96,9 +96,9 @@ sort of a loose clustering of objects: it will derive the position from the placement it is attached to. Note that while the length and the in/out points are a _property of the MObject_ , it's actual location depends on how it is _placed_ and thus can be maintained quite dynamically. Note further that -effects can have an length on their own, thus by using these attachement -mechaics, the wiring and configuration within the high-level model can be quite -time dependant. +effects can have an length on their own, thus by using these attachment +mechanics, the wiring and configuration within the high-level model can be quite +time defendant. image:{imgd}/high-level2.png[] @@ -122,10 +122,10 @@ Example of an complete Session image:{imgd}/high-level3.png[] The Session contains several independent -http://www.lumiera.org/wiki/renderengine.html#EDL[EDL]s plus an output bus -section ( *global Pipes* ). Each EDL holds a collection of MObjects placed +link:/wiki/renderengine.html#EDL[EDL]s plus an output bus +section (**global Pipes**). Each EDL holds a collection of MObjects placed within a *tree of tracks* . Within Lumiera, tracks are a rather passive means -for organizing media objects, but aren't involved into the data processing +for organising media objects, but aren't involved into the data processing themselves. The possibility of nesting tracks allows for easy grouping. Like the other objects, tracks are connected together by placements: A track holds the list of placements of its child tracks. Each EDL holds a single placement @@ -138,7 +138,7 @@ track is anchored to some external entity (label, sync point in sound, etc), all objects placed relatively to this track will adjust and follow automatically. This relation between the track tree and the individual objects is especially important for the wiring, which, if not defined locally within an -MObject's placement, is derived by searching up this track tree and utilizing +MObject's placement, is derived by searching up this track tree and utilising the wiring plug locating pins found there, if applicable. In the default configuration, the placement of an EDL's root track contains a wiring plug for video and another wiring plug for audio. This setup is sufficient for getting @@ -151,7 +151,7 @@ Besides routing to a global pipe, wiring plugs can also connect to the source port of an *meta-clip*. In this example session, the outputs of EDL-2 as defined by locating pins in it's root track's placement, are directed to the source ports of a -http://www.lumiera.org/wiki/renderengine.html#VirtualClip[meta-clip] placed +link:/wiki/renderengine.html#VirtualClip[meta-clip] placed within EDL-1. Thus, within EDL-1, the contents of EDL-2 appear like a pseudo-media, from which the (meta) clip has been taken. They can be adorned with effects and processed further completely similar to a real clip. @@ -159,7 +159,7 @@ with effects and processed further completely similar to a real clip. Finally, this example shows an *automation* data set controlling some parameter of an effect contained in one of the global pipes. From the effect's POV, the automation is simply a -http://www.lumiera.org/wiki/renderengine.html[ParamProvider], i.e a function +link:/wiki/renderengine.html#ParamProvider[ParamProvider], i.e a function yielding a scalar value over time. The automation data set may be implemented as a bézier curve, or by a mathematical function (e.g. sine or fractal pseudo random) or by some captured and interpolated data values. Interestingly, in @@ -186,7 +186,7 @@ Pros ^^^^ * very open and modular, allows for creating quite dynamic object behaviour in - the sessison + the Session * implementation is rather simple, because it relies on a small number of generic building blocks @@ -213,11 +213,11 @@ Alternatives _Use the conventional approach:_ hard-wire a _reasonable simple_ structure and code the behaviour of tracks, clips, effects and automation explicitly, providing separate code to deal with each of them. Use the hard-wired - assumption that a clip consists of "video and audio". Hack in any advanced + assumption that a clip consists of ``video and audio''. Hack in any advanced features (e.g. support multi-camera takes) as GUI macros. Just don't try to support things like 3D video and spatial audio (anything beyond stereo and - 5.1). Instead, add a global "node editor" to make the geeks happy, allowing to - wire everything to everything, just static and global of course. + 5.1). Instead, add a global »node editor« to make the geeks happy, allowing to + wire everything to everything, just static and global of course. 😈 @@ -226,9 +226,9 @@ Rationale Ichthyo developed this design because the goal was to start out with the level of flexibility we know from Cinelerra, but try to do it considering all consequences right from start. Besides, the observation is that the development -of non-mainstream media types like steroscopic (3D) film and really convincing -spatial audio (beyond the ubiquitous "panned mono" sound) is hindered not by -technological limitations, but by pragmatism preferring the "simple" hard wired +of non-mainstream media types like stereoscopic (3D) film and really convincing +spatial audio (beyond the ubiquitous ``panned mono'' sound) is hindered not by +technological limitations, but by pragmatism preferring the ``simple'' hard wired approach. @@ -242,10 +242,11 @@ Comments Final ~~~~~ -Description of the Lumiera high level model as is. +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_proc_high_level_model_and_placement_concept[Apr.2011 developer meeting]. + +This is a description of the Lumiera high level model as-is. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ProcPlacementMetaphor.txt b/doc/devel/rfc/ProcPlacementMetaphor.txt index c89f5faa4..de0d188c0 100644 --- a/doc/devel/rfc/ProcPlacementMetaphor.txt +++ b/doc/devel/rfc/ProcPlacementMetaphor.txt @@ -1,15 +1,19 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process : Placement Metaphor +==================================== + +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Placement Metaphor used within the high-level view of Steam-Layer ----------------------------------------------------------------- -besides the [wiki:self:../ProcBuilder Builder], one of the core ideas of the -``Proc-Layer'' (as being currently implemented by Ichthyo) is to utilize + +besides the link:{rfc}/ProcBuilder.html[Builder], one of the core ideas of +the Lumiera application, as envisioned and implemented currently, is to utilise _Placement_ as a single central metaphor for object association, location and configuration within the high-level model. The intention is to prefer _rules_ over fixed _values._ Instead of ``having'' a property for this and that, we @@ -18,24 +22,24 @@ query for information when it is needed. The proposed use of *Placement* within the steam layer spans several, closely related ideas: - * use the placement as a universal means to stick the "media objects" together + * using the placement as a universal means to stick the ``media objects'' together and put them on some location in the timeline, with the consequence of a unified and simplified processing. - * recognize that various _location-like_ degrees of freedom actually form a + * recognise that various _location-like_ degrees of freedom actually form a single _``configuration space''_ with multiple (more than 3) dimensions. * distinguish between _properties_ of an object and qualities, which are caused by ``placing'' or ``locating'' the object in _configuration space_ - - _propetries_ belong to the object, like the blur value, the media source + - _properties_ belong to the object, like the blur value, the media source file, the sampling/frame rate of a source - _location qualities_ exist only because the object is ``at'' a given location in the graph or space, most notably the start time, the output connection, the layering order, the stereoscopic window depth, the sound pan position, the MIDI instrument * introduce a _way of placement_ independent of properties and location - qualities, describing if the placement _itself_ is _absolute, relative or + qualities, describing if the Placement _itself_ is _absolute, relative or even derived_ - * open especially the possibility to _derive_ parts of the placement from - the context by searching over connected objects and then up the fork (``tree of tracks''); + * open especially the possibility to _derive_ parts of the Placement from + the context by searching over connected objects and then up the _Fork_ (``tree of tracks''); this includes the possibility of having rules for resolving unspecified qualities. @@ -71,7 +75,7 @@ On the contrary, using the *Placement* metaphor has the implication of switching to a query-driven approach. * it gives us one single instrument to express the various kinds of relations - * the _kind of placement_ becomes an internal value of the _placement_ (as + * the _kind of placement_ becomes an internal value of the _Placement_ (as opposed to the object) * some kinds of placement can express rule-like relations in a natural fashion * while there remains only one single mechanism for treating a bunch of @@ -124,7 +128,7 @@ Pros * modular and extensible * allows much more elaborate handling of media objects then the conventional approach, while both the simple standard case and the elaborate special case - are "first class citizens" and completely integrated in all object + are ``first class citizens'' and completely integrated in all object treatment. @@ -133,7 +137,7 @@ Cons ^^^^ * difficult to grasp, breaks with some habits * requires a separate resolution step - * requires to ''query'' for object properties instead of just looking up a + * requires to _query_ for object properties instead of just looking up a fixed value * forces the GUI to invent means for handling object placement which may go beyond the conventional @@ -149,13 +153,12 @@ Use the conventional approach * media objects are assigned with fixed time positions * they are stored directly within a grid (or tree) of tracks * layering and pan are hard wired additional properties - * implement an additional auto-link macro facility to attach sound to video + * implement an additional auto-link macro facility to attach sound to a video clip * implement a magnetic snap-to for attaching clips seamless after each other * implement a splicing/sliding/shuffling mode in the UI * provide a output wiring tool in the GUI - * provide macro features for this and that.... - -^hopefully I made clear by now _why_ I don't want to take the conventional approach^ + * provide macro features for this and that.... + + ^(hopefully I made clear by now _why_ I don't want to take the conventional approach)^ @@ -171,23 +174,23 @@ the conventional approach was dictated by technological limitations. * the ususal layering based on tracks constantly forces the user to place clips in a unnatural and unrelated fashion and tear apart clips which belong closely together - * the conventional approach of having a fixed "pan control" in specialized - "audio tracks" constantly hinders the development of more natural and + * the conventional approach of having a fixed ``pan control'' in specialized + ``audio tracks'' constantly hinders the development of more natural and convincing sound mixing. It favors a single sound system (intensity based stereophony) for no good reason. * handling of stereoscopic (3D) video/film is notoriously difficult within the conventional, hard wired approach - * building more elaborate sound scapes and sound design is notoriously - difficult to maintain, because the user is forced to use hidden "side - chains", magic rules and re-build details in external applications, because - of the lack of flexible integration of control data alongside with the main - data. + * building more elaborate soundscapes and sound design is notoriously + difficult to maintain, because the user is forced to use hidden + ``side chains'', magic rules and re-build details in external applications, + because of the lack of flexible integration of control data alongside + with the main data. The high-level model is close to the problem domain, it should provide means to express the (naturally complex) relationships between media objects. Using an abstract and unified concept is always better then having a bunch of seemingly unrelated features, even if they may be more easy to grasp for beginners. -Moreover, the Placement concept deliberately brings in an rule based approach, +Moreover, the Placement concept deliberately leads to a _rule based approach_, which well fits into the problem domain. Finally, there is sort-of a visionary aspect involved here: _Ichthyo_ thinks that nowadays, after image and sound are no longer bound to physical media, there is potential for new workflows to be @@ -205,7 +208,7 @@ Comments Placement Metaphor ~~~~~~~~~~~~~~~~~~ -Re: +[quote] ``Finally, there is sort-of a visionary aspect involved here: Ichthyo thinks that nowadays, after image and sound are no longer bound to physical media, there is potential for _new workflows_ to be @@ -225,13 +228,15 @@ use, and decision rules based on these parameters. This feature/capability is likely to stamp the Lumiera project as a flagship benchmark in more ways than one, for some time. - . --link:Tree[][[DateTime(2008-08-23T12:54:00NZ)]]. + Tree:: '2008-08-23T12:54:00NZ' Final ~~~~~ - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_proc_high_level_model_and_placement_concept[Apr.2011 developer meeting]. + + +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/RefactorLiblumieraOut.txt b/doc/devel/rfc/RefactorLiblumieraOut.txt index c31fb06a2..6a5d07cea 100644 --- a/doc/devel/rfc/RefactorLiblumieraOut.txt +++ b/doc/devel/rfc/RefactorLiblumieraOut.txt @@ -3,117 +3,111 @@ Refactor Liblumiera Out // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Fr 22 Apr 2011 10:46:50 CEST_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _Fr 22 Apr 2011 10:46:50 CEST_ +|*Proposed by* | Christian Thaeter +|==================================== -[abstract] ******************************************************************************** -liblumiera contains alot useful and reuseable code which is already in use by -other projects +.Abstract +`liblumiera` contains a lot of useful and re-useable code +which is already in use by other projects ******************************************************************************** Description ----------- //description: add a detailed description: -Over the time we've put some efforts into the liblumiera. I've added -some from my code which predates the lumiera project which I am using -on many other projects. This now caused that I maintain this sources in -different unrelated projects and have to cross merge and update stuff -when I do updates and fixes somewhere. I think its time to factor the -reuseable parts out into a independent library (like glib does for -gtk), in fact I had this plan long ago. +Over the time we've put some efforts into the 'liblumiera'. I have added +some from my code which predates the Lumiera project and which I am using +on many other projects. This means that I would have to maintain these +sources in different unrelated projects and have to cross merge and update +several copies of the same code when I do updates and fixes somewhere. +I think its time to factor the re-useable parts out into a independent +library (similar to what Glib does for GTK). In fact, I had this plan long ago. .What parts are eligible for a standalone library - Anything which is something tool alike and useful for other projects and not tied to Lumiera only. This are the algorithms/datastructures, allocators, tool macros. Additionally some of the src/common things should be moved into the library. I give some lists below. .How to name it - -Long time ago my plan was to name it 'ctlib' or 'cehlib' but meanwhile there is +Long time ago my plan was to name it `ctlib' or `cehlib' but meanwhile there is enough code done by others. So I'd propose a more neutral name, still -'lumieralib' or 'lulib' would be approbiate. The only thing we have to account +`lumieralib' or `lulib' would be appropriate. The only thing we have to account for is that some parts which are too specific for Lumiera and should not be integrated into this spinoff need either to stay in a lumiera-internal lib (src/lib/) as currently or being moved to the respective subsystems using them (src/backend, src/proc, src/common, ...), so the names should not clash. .C, C++ ... - -For myself I need the C parts, while there is C++ code which interfaces to the -C implementations and also a lot code which does nice C++ things on its own. +For myself I need the C parts, while there is C\++ code which interfaces to the +C implementations and also a lot code which does nice C\++ things on its own. This possibly means that we should in fact make 2 packages out of this, one C -and one C++ library (where the C++ part is more than just the wrappers, but -also the tools and tricks which are currently in src/lib/ and reuseable). +and one C\++ library (where the C++ part is more than just the wrappers, but +also the tools and tricks which are currently in 'src/lib/' and reusable). .Who maintains it - -Despite a spin of I think we don't want to change anything from our current -practice and maintain it by the Lumiera developers. For many parts I feel -responsible for it, but its really a part of the Lumiera codebase, despite -independently useable. +Despite of being a spin-off I think we don't want to change anything from our +current practice and maintain it by the Lumiera developers. In part I feel +responsible for it, while it is really a part of the Lumiera codebase, +despite of being independently usable. .How to maintain it - We need to decide about build system and documentation system. As build system -we may right start using scons. For documentation the situation is a but +we may right start using SCons. For documentation the situation is somewhat different since some of my code uses pipadoc/asciidoc and other uses doxygen. .What not to do - Some of the code is currently quite specific to Lumiera while it could be made -more generic. This is *NOT* subject of this RFC we may or may not do such a -refactoring but this RFC and any work resulting from this should only restrict +more generic. This is _NOT_ subject of this RfC -- we may or may not do such a +refactoring but this RfC and any work resulting from this should be restricted to simple things like necessary namespace and variable renaming and integration in the build system. C Parts -------- +~~~~~~~ Library -~~~~~~~ +^^^^^^^ What belongs to the library Containers -^^^^^^^^^^ +++++++++++ * cuckoo hashing (cuckoo.c|h) - * linked lists (llist.h slist.h) + * linked lists (llist.h) * cache lists (mrucache.c|h) * splay trees (psplay.c|h) * priority queues (not done yet) Runtime tools -^^^^^^^^^^^^^ ++++++++++++++ * error handling (error.h error.c) used by the other facilities too - * clib convinience wrapers (safeclib.c|h) needs better name, maybe refactor + * clib convenience wrappers (safeclib.c|h) needs better name, maybe refactor into new facilities Multithreading -^^^^^^^^^^^^^^ +++++++++++++++ * locking, condition variables etc. (condition.c|h (rec)mutex.c|h, rwlock ...) Memory management -^^^^^^^^^^^^^^^^^ ++++++++++++++++++ * Memory pools (mpool.c|h) * Temporary buffers (tmpbuf.c|h) Metaprogramming -^^^^^^^^^^^^^^^ - * preprecessor tools (ppmpl.h) move common preprocessor macros here ++++++++++++++++ + * preprocessor tools (ppmpl.h) move common preprocessor macros here * polymorphic call helper for C (vcall.h) Interface system and module loader -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +++++++++++++++++++++++++++++++++++ -except for some hardcoded references to 'lumiera_org' and '.lum' plugin names +except for some hardcoded references to `lumiera_org' and `.lum' plugin names this is quite generic, possibly moving this over could be postponed, but might eventually be done. @@ -124,26 +118,26 @@ interfaceregistry.c interfaceregistry.h plugin.c plugin_dynlib.c plugin.h ------ -The 'config' system could become a candidate too if it ever gets finished and -proved useful, but for the time being its better kept in Lumiera. +The ``config system'' could become a candidate too if it ever gets finished and +proves itself useful, but for the time being it's better kept in Lumiera. Not Library -~~~~~~~~~~~ -Too specific to Lumiera: +^^^^^^^^^^^ +Tied specifically to Lumiera: ----- luid.c luid.h time.h ----- C++ Parts ---------- +~~~~~~~~~ -For most of the C++ parts I am not sure, ichthyo should decided upon these +For most of the C++ parts I am not sure, _ichthyo_ should decide upon these (please edit this here) Library -~~~~~~~ +^^^^^^^ These look 'generic' or wrap the C parts: ------ singleton-factory.hpp singleton.hpp singleton-policies.hpp @@ -154,7 +148,7 @@ util.hpp variant.hpp ------ Not Sure -~~~~~~~~ +^^^^^^^^ ------ access-casted.hpp advice advice.hpp allocation-cluster.cpp allocation-cluster.hpp bool-checkable.hpp cmdline.cpp cmdline.hpp del-stash.hpp @@ -175,19 +169,21 @@ option.hpp query subsys.cpp subsys.hpp subsystem-runner.hpp Not Library -~~~~~~~~~~~ +^^^^^^^^^^^ ------ logging.cpp nobug-init.cpp nobug-init.hpp streamtype.cpp streamtype.hpp test/* time/* time.cpp tree.hpp ----- + + Tasks ~~~~~ // List what needs to be done to implement this Proposal: // * first step ([green]#✔ done#) * decide on name, namespaces [,yellow]#WIP# - * create git repository, setup boilerplace (build system, legalese) + * create git repository, setup boilerplate (build system, legalise) [,yellow]#WIP# * move all code over into the git repos, refactor (namespace renames) () [,yellow]#WIP# @@ -213,17 +209,14 @@ Cons Alternatives ^^^^^^^^^^^^ //alternatives: explain alternatives and tell why they are not viable: +Do nothing and handle fixes on a case by case base. -Rationale ---------- -//rationale: Give a concise summary why it should be done *this* way: - //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -233,8 +226,25 @@ Comments -------- //comments: append below +.State -> Dropped +Ongoing development over the following years (after 2011) helped to clarify the situation +regarding the support library in Lumiera. The improved language standards, most notably C++14, +obsoleted most of the ad-hoc solutions in our library, since many aspects of system +integration are now handled by language and STL facilities in a satisfactory way. +On the other hand, by using the heightened capabilities of the language, some solution +patterns very specific to Lumiera could be established, gradually turning the support +library into some kind of an application framework. + +It is quite common in the field of software development to put great hopes into code +reuse -- yet it is this very tendency towards a framework which prevents that ideal +from playing out as anticipated, in practice. What seems to work best is to look +at some well-made piece of software, understand how it works, and then to copy +and extract parts in order to transform it into _your own solution._ + +Ichthyostega:: '2025-09-16' //endof_comments: + '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/RenderOptimizer.txt b/doc/devel/rfc/RenderOptimizer.txt index d5b28319b..11919b011 100644 --- a/doc/devel/rfc/RenderOptimizer.txt +++ b/doc/devel/rfc/RenderOptimizer.txt @@ -1,14 +1,18 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2007-06-07_ -*Proposed by* link:ct[] -------------------------------------- +Design Process : Optimiser +========================== + + +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2007-06-07_ +|*Proposed by* | ct +|==================================== Render Optimizer ---------------- -Render only parts of a frame which are necessary for the Output; Optimize -render pipeline for efficiency +Render only parts of a frame which are necessary for the Output; +optimize render pipeline for efficiency Description @@ -28,73 +32,64 @@ output as the original sequence of effects. -Tasks -^^^^^ - - - - -Discussion -~~~~~~~~~~ - -Pros -^^^^ - - - -Cons -^^^^ - - - -Alternatives -^^^^^^^^^^^^ - - - -Rationale -~~~~~~~~~ - - - - - - Comments -------- Possible classification for video filters: + 1. The filter only changes the color of each pixel in the same way 2. The filter deforms the image but leaves the color 3. The filter makes complex things. The only additional hint it can export is - the - number of referenced past frames, if such a limit exists (sometimes it + the number of referenced past frames, if such a limit exists (sometimes it doesn't). Filters of type 1 and type 2 never use any previous frames, and are strictly -one frame in - one frame out. Filters of type 1 can always be swapped with +one frame in -- one frame out. Filters of type 1 can always be swapped with filters of type 2, the output is the same. All other filters cannot be swapped in general. The good news is, that: 1. All commonly used filters are either type 1 or type 2 - (type 3 are more the fun effects) + (type 3 are more the fun effects) 2. Filters of type 2 are colormodel agnostic - 3. If a filter of type 1 makes only linear transformations of the color - vectors (new_color = matrix * old_color), - the matrix can be transformed from e.g. RGB to YUV, so these filters can + 3. If a filter of type 1 makes only linear transformations of the color vectors + + (i.e.: new_color ≔ matrix · old_color), + then the matrix can be transformed from e.g. RGB to YUV, so these filters can always work in both colorspaces directly -Parked -~~~~~~ + +.State -> Parked Generally this is accepted but needs some more polishing when we go over it. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' +.Reassessment : remains valid +[underline]#Relevance confirmed 2025.# +This RfC is written narrow enough to just define the goal of an optimised +render pipeline -- which _was_ and _is_ a central goal of the Lumiera project. + +Approaching this topic however _requires much more work_ and notably a detailed +analysis of the possibilities, based on *facts and measurements*. There is the +real danger to get attached to some implementation idea deemed enticing, +leading to very specific tweaks which limit the ability to adapt to +other relevant requirements. + +Furthermore, since Lumiera aims at being library / framework agnostic, +a significant difficulty to overcome first is the build-up of an abstract +framework to describe and engage viable optimisations, which can then be +applied as transformations within the Builder -- quite similar to the +proceedings of an optimising compiler. The description of possible +optimisations likely involves elements of knowledge representation, +combined with heuristical aspects, possibly augmented by +machine learing. + +To summarise: this is a *long-term vision*. + +Ichthyostega:: '2025-09-20' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/RepositorySetup.txt b/doc/devel/rfc/RepositorySetup.txt index e01bfed99..4b2dbb039 100644 --- a/doc/devel/rfc/RepositorySetup.txt +++ b/doc/devel/rfc/RepositorySetup.txt @@ -1,12 +1,12 @@ Design Process: Repository Setup ================================ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-09_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-09_ +|*Proposed by* | ct +|==================================== Repository Setup ---------------- @@ -31,18 +31,15 @@ far incomplete works for this) ------------------------------------------------------------ -The cinelerra2 sources are put into oldsrc on a per-case base. +The Cinelerra-2 sources are put into `oldsrc` on a per-case base. -We want to use the new GIT feature of "Superprojects and Submodules" when it is +We want to use the new GIT feature of ``Superprojects and Submodules'' when it is ready for general use. Then we will transform several subtrees into separate GIT repos which will be linked to from the main Project (then called the -"Superproject") as submodules. +_Superproject_) as _Submodules_. -Tasks -~~~~~ - Pros ^^^^ * Because its a text-like structure, it is partially self-documenting @@ -52,70 +49,79 @@ Pros Cons ^^^^ * Can get large and confusing - * has no real "portal" or entrance point for people wanting to join - -Alternatives -^^^^^^^^^^^^ - + * has no real ``portal'' or entrance point for people wanting to join Rationale ~~~~~~~~~ Every important document, draft, text and code (including) prototypes should be -checked into one SCM (or a set of related SCMs). This repo should be "almost -everything" you need for the project. Because we try to use a distributed -developement model, every dev can/should have his own copy and fed his changes +checked into one SCM (or a set of related SCMs). This Repo should be ``almost +everything'' you need for the project. Because we try to use a distributed +development model, every dev can/should have his own copy and fed his changes back. -This 'Repository aproach' avoids the problems of a central infrastructure and +This ``Repository approach'' avoids the problems of a central infrastructure and helps cut down project management time. Basically, every dev is responsible -himself for getting every important piece of information added into "the -general view of matters" in a consitent way. +himself for getting every important piece of information added into ``the +general view of matters'' in a consistent way. Comments -------- - Basically the structure is just fine. -- Maybe add a "pastebin" somewhere in the dev-documentation area? +- Maybe add a ``pastebin'' somewhere in the dev-documentation area? - I would add the source tree roots at level 2, so we can have several submodules here: - * oldsrc - * cin3 - * prototype - link:Ichthyostega[] -- Draft now. -- Yes I left source dirs out but this sounds fine, note that with git, there is - no problem to reorganize the repo (in contrast to CVS) later. We can fix - things afterward when we find better ways. -- link:ct[] - [[DateTime(2007-06-17T17:36:46Z)]] -- Whats prototype for? won't that be better a branch? -- link:ct[] - [[DateTime(2007-06-17T22:04:39Z)]] -- I just wanted to show there could be additional things beside the main tree - (later to be separete submodules). The example was meant as a classical - throwaway prototype. But I agree, in our case we just start hacking at the - new tree and make feature/tryout/prototype branches... -- The point I wanted to make is: every directory 2 levels deep in the source - tree, e.g. /src/cinelerra3 or /src/oldsrource should be a completely - self-contained tree which can be built without needing anything of the rest - of the repo. Thats an prerequisite for moving to Submodules IMHO. But you - seem rather to put the sourcetree-roots 1 level deep. As we have just two - trees at the moment (and can easily reorganize), I have no objections against - this. The only point I really care is to try to keep the source tree - self-contained without any dependencies to the rest of the "design GIT" - (because of this Superprojects-Submodules thing...) -- link:Ichthyostega[] - [[DateTime(2007-06-17T23:45:06Z)]] -- We could make the trees deeper than one level, I didn't intended 1-level - depth. but also be careful with that not to make it too complex. While I am - not sure if we want a complete oldsrc, that just adds weight and confusion - for now (lets see). Neither I am fully decided about the hierachy in /src - (want /libs /plugins or /src/libs /src/plugins or /src/render/plugins? name - it rather 'effects' than 'plugins'?). While I am quite sure that I want to - separate /oldssrc and /src quite much (in /src should only be new stuff or - stuff which is carefully reviewed, with known license and author). -- - link:ct[] [[DateTime(2007-06-18T08:38:43Z)]] -- I made this proposal 'final' now further details are likely better worked out - in the git repository (and we already started to define things there) see - ./admin/treeinfo.sh -- link:ct[] [[DateTime(2007-06-27T16:01:52Z)]] + ** oldsrc + ** cin3 + ** prototype + +Ichthyostega:: 6/2007 -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Yes I left source dirs out but this sounds fine, note that with git, there is +no problem to reorganize the repo (in contrast to CVS) later. We can fix +things afterward when we find better ways. + +ct:: '2007-06-17T17:36:46Z' + +Whats prototype for? won't that be better a branch? + +ct:: '2007-06-17T22:04:39Z' + +I just wanted to show there could be additional things beside the main tree +(later to be separate submodules). The example was meant as a classical +throwaway prototype. But I agree, in our case we just start hacking at the +new tree and make feature/tryout/prototype branches... + +The point I wanted to make is: every directory 2 levels deep in the source +tree, e.g. /src/cinelerra3 or /src/oldsrource should be a completely +self-contained tree which can be built without needing anything of the rest +of the repo. Thats an prerequisite for moving to Submodules IMHO. But you +seem rather to put the sourcetree-roots 1 level deep. As we have just two +trees at the moment (and can easily reorganize), I have no objections against +this. The only point I really care is to try to keep the source tree +self-contained without any dependencies to the rest of the ``design GIT'' +(because of this Superprojects-Submodules thing...) + +Ichthyostega:: '2007-06-17T23:45:06Z' + +We could make the trees deeper than one level, I didn't intended 1-level +depth. but also be careful with that not to make it too complex. While I am +not sure if we want a complete oldsrc, that just adds weight and confusion +for now (lets see). Neither I am fully decided about the hierarchy in /src +(want /libs /plugins or /src/libs /src/plugins or /src/render/plugins? name +it rather 'effects' than 'plugins'?). While I am quite sure that I want to +separate /oldssrc and /src quite much (in /src should only be new stuff or +stuff which is carefully reviewed, with known license and author). + +ct:: '2007-06-18T08:38:43Z' + +I made this proposal 'final' now further details are likely better worked out +in the Git repository (and we already started to define things there) see +./admin/treeinfo.sh + +ct:: '2007-06-27T16:01:52Z' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ResourceManagementBudgeting.txt b/doc/devel/rfc/ResourceManagementBudgeting.txt index ffa488e5c..e4db5b5a4 100644 --- a/doc/devel/rfc/ResourceManagementBudgeting.txt +++ b/doc/devel/rfc/ResourceManagementBudgeting.txt @@ -3,19 +3,20 @@ Resource Management: Budgeting // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Fri Jul 23 20:33:32 2010_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Fri Jul 23 20:33:32 2010_ +|*Proposed by* | Christian Thaeter +|==================================== [abstract] ****************************************************************************** -The Profiler will give some Idea about how much Resources can me used to +The link:{rfc}/ResourceManagementProfiling.html[Profiler] +will give some Idea about how much Resources can be used to optimally utilize the system. Knowing this number leads to the next challenge, -distributing the resources to different subsystems, jobs and objects. I here -introduce a budgeting system which takes care for this. +distributing the resources to different subsystems, jobs and objects. Here, I +introduce a budgeting system which takes care of this. ****************************************************************************** @@ -33,6 +34,60 @@ available for anyone. +Tasks +~~~~~ +// List what would need to be done to implement this Proposal in a few words: + * define a sufficiently well defined goal first, to describe + what shall and can be achieved through budgeting ... + * then develop a plausible model of suitable control and regulation mechanisms + * very likely, practical tests will be required to show the feasibility of + effective automatic regulation over a significant span of different + use cases! + + + +Discussion +~~~~~~~~~~ + +Pros +^^^^ +// add just a fact list/enumeration which make this suitable: +// * foo +// * bar ... + + + +Cons +^^^^ +// fact list of the known/considered bad implications: + + + +Alternatives +^^^^^^^^^^^^ +//alternatives: if possible explain/link alternatives and tell why they are not viable: + + + +Rationale +--------- +//rationale: Describe why it should be done *this* way: + + + +//Conclusion +//---------- +//conclusion: When approved (this proposal becomes a Final) write some +// conclusions about its process: + + + + +Comments +-------- +//comments: append below + + [source,C] ------------------------------------------------------------------------------ typedef ssize_t budget_count; @@ -64,58 +119,36 @@ struct budget }; ------------------------------------------------------------------------------ +ct:: '2010-07-23 20:55:49 CEST' +.... +​ +​ +​ +.... +[[caveat]] +[underline]#Many years later,# I'd like to confirm that this RfC describes +a part of the *core vision*: + +the engine shall make best use of limited resources. -Tasks -~~~~~ -// List what would need to be done to implement this Proposal in a few words: -// * item ... +CAUTION: The same caveats as for the + link:{rfc}/ResourceManagementProfiling.html#caveat[Profiling] + do apply here as well... +I'd recommend to be extremely cautions to take any achievement for granted +for this topic, which is known to be notoriously difficult and insidious. +With _budgeting alone,_ we may be able to prevent overload of the system, +yet for anything beyond that, we need an actual optimisation strategy. +Ichthyostega:: '2025-09-17' -Discussion -~~~~~~~~~~ - -Pros -^^^^ -// add just a fact list/enumeration which make this suitable: -// * foo -// * bar ... - - - -Cons -^^^^ -// fact list of the known/considered bad implications: - - - -Alternatives -^^^^^^^^^^^^ -//alternatives: if possible explain/link alternatives and tell why they are not - viable: - - - -Rationale ---------- -//rationale: Describe why it should be done *this* way: - - - -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) write some - conclusions about its process: - - - - -Comments --------- -//comments: append below - //endof_comments: + + + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ResourceManagementProfiling.txt b/doc/devel/rfc/ResourceManagementProfiling.txt index bfd1b2731..a2c9c9e02 100644 --- a/doc/devel/rfc/ResourceManagementProfiling.txt +++ b/doc/devel/rfc/ResourceManagementProfiling.txt @@ -3,31 +3,34 @@ Resource Management: Profiling // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Fri Jul 23 19:34:29 2010_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Fri Jul 23 19:34:29 2010_ +|*Proposed by* | Christian Thaeter +|==================================== [abstract] ****************************************************************************** -From the beginning on we planned some kind of 'profiling' to adapt dynamically -to workload and machine capabilities. I describe here how statistic data can be -gathered in a generic way. This will later work together with other components +Right from the beginning of the project we planned some kind of _profiling_ +to adapt dynamically to current workload and machine capabilities. +I describe here how statistic data can be gathered in a generic way. +This will later work together with other components tuning the system automatically. ****************************************************************************** +-> link:{rfc}/ResourceManagementBudgeting.html[RfC: use gathered data for budgeting...] + Description ----------- //description: add a detailed description: I just introduce some ideas about the planned profiling framework here, nothing -is defined/matured yet this is certainly subject for futher discussion and +is defined/matured yet this is certainly subject for further discussion and refinement. -.Requirements/Evaluation generic:: + Requirements/Evaluation generic:: Profiling should be sufficiently abstracted to have a single set of datastructures and algorithms to work on a broad range of subjects being profiled. Moreover the profiling core just offers unitless @@ -49,7 +52,7 @@ refinement. such false alarms. Workload also changes over time we need to find some way to measure the current/recent workload an grand total over the whole application runtime is rather uninteresting. While it is also - important that we adapt slow enough not to get into some osccilating + important that we adapt slow enough not to get into some oscillating cycle. active or passive system:: @@ -59,10 +62,60 @@ refinement. +Tasks +~~~~~ +// List what would need to be done to implement this Proposal in a few words: + * develop a concept to outline what we actually want to observe ... + * refine this into a model to describe the observables + * derive an assessment of the specific requirements and challenges of this measurement + * use _this_ as the starting-point for an implementation draft ... +Discussion +~~~~~~~~~~ + +Pros +^^^^ +// add just a fact list/enumeration which make this suitable: +// * foo +// * bar ... + + + +Cons +^^^^ +// fact list of the known/considered bad implications: + + + +Alternatives +^^^^^^^^^^^^ +//alternatives: if possible explain/link alternatives and tell why they are not viable: + + + +Rationale +--------- +//rationale: Describe why it should be done *this* way: + + + +//Conclusion +//---------- +//conclusion: When approved (this proposal becomes a Final) +// write some conclusions about its process: + + + + +Comments +-------- +//comments: append below + + + .Brainstorming in Code [source,C] ------------------------------------------------------------------------------ @@ -127,56 +180,45 @@ struct profile }; ------------------------------------------------------------------------------ - -Tasks -~~~~~ -// List what would need to be done to implement this Proposal in a few words: -// * item ... +ct:: '2010-07-23 20:33:13 CEST' +.... +​ +​ +​ +.... +[[caveat]] +[underline]#Many years later,# I'd like to confirm that we need and want some +kind of profiling in the engine, for the purpose described in this RfC, which is +to fine-tune our operation parameters dynamically. +We should however be _careful_ not to settle down onto an implementation in our +mind _before_ having conducted a proper *requirement analysis*. Starting from +the valid idea what can be done with profiling and statistic, the first thing +to map out is what we actually want to achieve and to which degree this can +be reasonably achieved. From there we should head towards a model to +describe what we want to observe, and only from there we'll be able +to pick suitable measurement methods. -Discussion -~~~~~~~~~~ +^(I have just added these step to the ``Tasks'' section)^ -Pros -^^^^ -// add just a fact list/enumeration which make this suitable: -// * foo -// * bar ... +WARNING: we should drop the pre-established conception that what we capture + here is simple, and can be squeezed into a single data representation. +If it turns out that we're headed towards high-throughput processing, +we should keep possible solutions at the architecture level in mind, before +focusing on details of the implementation. Messaging systems and lock-free +data structures have made significant progress over the last decade. +-> see also my link:{rfc}/ResourceManagementBudgeting.html#caveat[remark to RfC:Budgeting] -Cons -^^^^ -// fact list of the known/considered bad implications: - - - -Alternatives -^^^^^^^^^^^^ -//alternatives: if possible explain/link alternatives and tell why they are not - viable: - - - -Rationale ---------- -//rationale: Describe why it should be done *this* way: - - - -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) write some - conclusions about its process: - - - - -Comments --------- -//comments: append below - +Ichthyostega:: '2025-09-17' //endof_comments: + + + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/Roadmap-first.txt b/doc/devel/rfc/Roadmap-first.txt index 419d591a8..c2943b4e8 100644 --- a/doc/devel/rfc/Roadmap-first.txt +++ b/doc/devel/rfc/Roadmap-first.txt @@ -1,28 +1,30 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2009-01-30_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process : Roadmap +======================== + +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2009-01-30_ +|*Proposed by* | Ichthyostega +|==================================== -Roadmap up to Lumiera 1.0 -------------------------- +A Roadmap leading to Lumiera 1.0 +-------------------------------- As the very basic architecture questions seem to settle down now, it seems to be time to create a first Roadmap skeleton for the project. A specific approach is proposed: we should define criteria allowing us to judge when we've reached -a certain level plus we should define features to be ''excluded'' at a certain -level. We should -''not'' define ''Features'' to go into a certain level. +a certain level plus we should define features to be _excluded_ at a certain +level. We should _not_ define _Features_ to go into a certain level. -''the following text is copied from the Lumiera - https://issues.lumiera.org/roadmap[Trac]'' +TIP: the following text is copied from the Lumiera + https://issues.lumiera.org/roadmap[Trac] -Description: Milestones up to first Release -------------------------------------------- +Description: Milestones up to the first stable Release +------------------------------------------------------ Milestone integration: cooperating parts to render output @@ -30,16 +32,16 @@ Milestone integration: cooperating parts to render output For this milestone to be reached, the basic subsystems of Lumiera need to be designed, the most important interfaces between the parts of the application exist in a first usable version, and all the facilities on the rendering code -path are provided at least in a dummy version and are '''capable of cooperating -to create output'''. Based on Lumiera's design, this also means that the basic +path are provided at least in a dummy version and are *capable of cooperating +to create output*. Based on Lumiera's design, this also means that the basic frame cache in the vault layer is working. And it means that a media asset and a clip can be added to the internal session representation, which is then handed over to the builder. Probably it's a good idea to include basic playback/display of the rendered frames within the GUI while they are created. -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * no saving and loading of sessions * no manipulation of objects though the GUI (just display of the session) * no adding of arbitrary media or inclusion of arbitrary plugins @@ -50,18 +52,18 @@ Notable features ''not'' included Milestone alpha: operations accessible for users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For this milestone to be reached, the fundamental operations you'd expect from -a video editing software can be '''accessed by a user''' (not a developer!). -This means that the basic distribution/release model is set up, a ''user'' is +a video editing software can be *accessed by a user* (not a developer!). +This means that the basic distribution/release model is set up, a _user_ is able to compile Lumiera or install an existing package. Moreover a user should be able to create/open a session file (without any quirks), add some media (probably only a limited number of media types will be supported), and then perform the most basic operations like positioning, trimming, copying, playing -and finally rendering the timeline integration phase is closed and Lumiera has -reached alpha level. +and finally rendering the timeline. Once this level of functionality is +achieved, the _integration phase_ is closed and Lumiera has reached alpha level. -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * advanced configuration * complex/compound projects * meta-clips, multi-cam, advanced multi channel sound handling @@ -75,23 +77,23 @@ Notable features ''not'' included Milestone beta: usable for real work ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For this milestone to be reached, users should be able to '''get real work done -with Lumiera'''. Especially, a basic asset management should be in place, +For this milestone to be reached, users should be able to *get real work done* +with Lumiera. Especially, a basic asset management should be in place, Lumiera should be able to handle the most common media types, the user should -be able to do common editing tasks (adding, trimming, rolling, splicing -copying, moving) both by direct manipulation within the timeline, as by using +be able to perform common editing tasks (add, move, copy, splice, trim, roll, +slide, slip) both by direct manipulation within the timeline, as by using the conventional two-viewer setup with in/out points. Moreover, it should be possible to attach effects (probably still just some limited kinds of effects), apply simple transitions and control the layering and overlay mode on output. Similarily, the elementary routing capabilities and the handling of multiple sequences should be suported (probably still with limitations). The framework for automation handling should be in place, while there may be still -limitations on automation/keyframe editing. Having about this feature set -indicates, that Lumiera entered the beta phase. +limitations on automation/keyframe editing. Having implemented roughly +this feature set indicates that Lumiera can enter the beta phase. -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * configuration editing through the GUI * advanced routing, full support of virtual clips * arbitrary wiring, macro effects or similar @@ -99,25 +101,25 @@ Notable features ''not'' included * arbitrary nesting and navigation within projects * full multi-cam support, support for non-standard image/sound types * plugin libraries and packaging - * interfaces for plugin authors are not frozen! + * interfaces for plugin authors are _not yet_ frozen! * fully configurable GUI * full support for proxy editing everywhere - * extended workflow features (like "export to DVD") + * extended workflow features (like ``export to DVD'') Milestone release-1.0: usable for productions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For this milestone to be reached, Lumiera should be a '''reliable tool for -productions with a deadline'''. Lumiera 1.0 is not the ''dream machine,'' but -users should be able to do simple productions. We should be able to promote -Lumiera to professionals without remorse. The GUI should be mature, +For this milestone to be reached, Lumiera should be a *reliable tool for +productions with a deadline*. Lumiera 1.0 is not the ``dream machine'', but +users should be able to complete simple productions. We should be able to +promote Lumiera to professionals without remorse. The GUI should be mature, undo/recovery should work airtight, performance should be ok-ish and output quality without any glitches. Plugin authors can rely on stable interfaces and backwards compatibility from now on, up to release 2.0 -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * bangs and whistles * render farm, distributed execution, hardware acceleration * MIDI and adding of non-standard media kinds yet-to-appear @@ -126,17 +128,11 @@ Notable features ''not'' included * foreign session import/export * collaboration features * artificial intelligence + * saving the world -Tasks -+++++ -Please review and discuss this proposal, consider if it's of any use setting it -up this way... - - - Discussion ~~~~~~~~~~ @@ -151,7 +147,7 @@ Pros Cons ^^^^ The contents of the roadmap aren't very specific and thus aren't of much help -for determining ''what has to be done next.'' +for determining _what has to be done next._ @@ -165,18 +161,17 @@ Alternatives Rationale ~~~~~~~~~ -We deliberately don't set any date schedule. Releases happen ''when they are -ready.'' We may decide to do sprints on a short-term timeframe, but it doesn't -help promising things we can't calculate for sure. In an commercial setup, you -have to commit to features and dates, but you also control a certain budget, -which gives you the means to ''make things happen.'' In Open Source -development, we've to be patient and wait for the things to happen ;-) +We deliberately don't set any date schedule. Releases happen ``when they are +ready''. We may decide to do sprints on a short-term timeframe, but it doesn't +help promising things we can't plan and calculate reliably. In an commercial setup, +you have to commit to features and dates, but you also control a certain budget, +which gives you the means to _make things happen._ In Free Software development, +we have to be patient and wait for great things to happen 😇 -Thus the proposal is to set up just a very coarse and almost self-evident -roadmap skeleton, but to discuss and define criteria up-front, which allow us -to determine when we've actually reached a given level. Moreover, the proposal -is to add a list of features which can be savely ''excluded'' from the given -milestone +Thus the proposal aims to set up just a very coarse and almost self-evident +roadmap skeleton, but also to discuss and define criteria up-front, which allow us +to determine when we've actually reached a given level. Furthermore, the proposal +provides a list of features which can be savely _excluded_ from a given milestone. @@ -186,21 +181,34 @@ milestone Comments -------- -Looks ok to me, the dust is settling ad we can now think about such a roadmap. +Looks ok to me, the dust is settling and we can now think about such a roadmap. Some goals might be shifted between Milestones on collaborative decision, but so far I agree. Otherwise I'd like to keep the issue tracker focus on work to be done, it shall not become a wishlist tool for non developers, any such things are deliberately left out. - -- link:ct[] 2009-01-31 -In ticket #4 (debian packaging) i explained that packaging might be optional -for 'alpha' and should be moved to 'beta'. - -- link:ct[] 2009-02-01 +ct:: '2009-01-31' + +In https://issues.lumiera.org/ticket/4[#4 (debian packaging)] i explained that +packaging might be optional for ``alpha'' and should be moved to ``beta''. + +ct:: '2009-02-01' OK, we should make the packaging optional. I think, for alpha the criterion is -"accessability for users". If compiling remains so easy as it is now (compared +``accessability for users''. If compiling remains so easy as it is now (compared with other media related projects), than this shouldn't be a barrier. - -- link:Ichthyostega[] 2009-02-01 + +Ichthyostega:: '2009-02-01' + +[underline]#Many years later# I can confirm that this approach towards a roadmap +and release planning stood well the test of time and looks reasonable still. + +The joke with ``artificial intelligence'' got a nice ring meanwhile, +as many people seem to believe that we're close to the AI miracle. +And since Lumiera might indeed integrate some _tools_ based on +``machine learning'' eventually, it seems adequate to point out +that we can not _save the world_ already in Release 1.0 -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SchedulerRequirements.txt b/doc/devel/rfc/SchedulerRequirements.txt index dd729ff13..e3a90503d 100644 --- a/doc/devel/rfc/SchedulerRequirements.txt +++ b/doc/devel/rfc/SchedulerRequirements.txt @@ -3,19 +3,19 @@ SchedulerRequirements // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Mi 09 Jan 2013 12:04:03 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Mi 09 Jan 2013 12:04:03 CET_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract Define the expected core properties and requirements of the Scheduler service. ******************************************************************************** -The rendering and playback subsystem relies on a Scheduler component to invoke +The rendering and playback subsystem relies on a *Scheduler* component to invoke individual frame rendering and resource fetching jobs. This RfC summarises the general assumptions and requirements other parts of the application are relying on @@ -77,13 +77,14 @@ knowledge of some specific job's termination. More precisely, we need to find ou when a ``stream of calculations'' has left a well defined domain -- and this can be modelled by the activation of specific marker jobs. It is possible to obtain that knowledge with some timing leeway, but in the end, this information needs -to arrive with absolutely reliability (violations leading to segfault). +to arrive with absolutely reliability (memory management will rely on them, +and thus failure might lead to out-of.memory or segfault). job scheduling modes ~~~~~~~~~~~~~~~~~~~~ The scheduler offers various modes of treatment on a per job base. The default is to -handle jobs time based with a moderate latency. Alternatively jobs can be handled as +handle jobs as _time-bound_, with a moderate latency. Alternatively jobs can be handled as _background_ jobs, as _freewheeling_ jobs (maximum usage of performance and bandwidth), or as _low-latency timed_ jobs. @@ -115,9 +116,9 @@ Tasks // List what needs to be done to implement this Proposal: // * first step [yellow-background]#WIP# * define the job interface ([green]#✔ done#) - * define a protocol for job state handling [red yellow-background]#TBD# - * define the representation of dependencies and the notifications in practice [red yellow-background]#TBD# - * verify the proposed requirements by an scheduler implementation sketch [red yellow-background]#TBD# + * define a protocol for job state handling ([green]#✔ done#) + * define the representation of dependencies and the notifications in practice ([green]#✔#) + * verify the proposed requirements by an scheduler implementation sketch ([green]#✔#) @@ -138,7 +139,7 @@ Pros Cons ^^^^ // fact list of the known/considered bad implications: - * there is no ``for-loop'' to base any playback control structures on + * there is no ``while-loop'' to base any playback control structures on * compliance to externally imposed deadlines and memory management are challenging. Alternatives @@ -150,8 +151,8 @@ Alternatives We do not want (1), since it is tied to an obsolete hardware model and lacks the ability to be adapted to the new kinds of hardware available today or to be expected in near future. We do not -want (2) since it essentially doesn't solve any problem, but rather pushes complexity into the -higher layers (Session, Stage), which are lacking the information about individual jobs and timing. +want (2) since it essentially doesn't solve any problem, but rather pushes complexity into the higher +layers (Session, Stage), which however are lacking information about individual jobs and timing. @@ -161,17 +162,20 @@ Rationale We use a scheduler to gain flexibility in controlling various aspects of computation and I/O usage. Moreover, we turn the scheduler into an interface between the Vault and Steam-Layer; while the exact outfitting of the individual jobs highly depends on internals of the Session and Engine models, -the properties of _actual job execution_, closely related to system programming are akin +the properties of _actual job execution_, closely related to system programming, are linked to the Vault. The actual requirements outlined in this RfC are derived from the internals of the player implementation, while _the way_ these requirements are defined, and especially the aspects _omitted_ from specification are derived from knowledge regarding the possible scheduler and vault layer implementation. -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) +Conclusion +---------- +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: +A solution closely following this proposal was implemented and became a +centrepiece of the Lumiera Render Engine. There was no further formal +decision, since _Ichthyo_ worked alone during the past years. @@ -189,8 +193,29 @@ can be developed independently of the scheduler implementation Ichthyostega:: 'Do 19 Sep 2013 21:31:07 CEST' ~~ +.State -> Final +After an extended intermission, where development was focused at GUI topics, the integration +work since 2023 strives at achieving an initial integration of the Render Engine. As part of the +https://issues.lumiera.org/ticket/1221[#1221 »PlaybackVerticalSlice«], an implementation of the +Scheduler, as proposed by this RfC, was +link:/x/imp/Scheduler.html[built from scratch and tested extensively]. Practical experience +during this effort leads to the following refinements: + +- the Scheduler does not invoke Jobs, + + but processes _verbs_ from an _Activity Language_ rather. +- this language in turn embodies a primitive to check a dependency count +- an external event may re-trigger such a chain of Activities within the Scheduler +- an extent-based memory manager can be based on deadlines of these Activities. +- the Scheduler becomes a passive management task, pulled by a active Workers. +- Workers manage their capacity through a statistical distribution of _sleep times._ + +In this form, the proposal can be considered as implemented. + +^(see -> https://git.lumiera.org/?p=LUMIERA;a=commit;h=d71eb37[d71eb37] +and https://issues.lumiera.org/ticket/1344[#1344])^ + +Ichthyostega:: '2024-04-20 01:55 CEST' //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ScriptingLanguage.txt b/doc/devel/rfc/ScriptingLanguage.txt index f1a39c5ae..a33387892 100644 --- a/doc/devel/rfc/ScriptingLanguage.txt +++ b/doc/devel/rfc/ScriptingLanguage.txt @@ -1,13 +1,16 @@ -[grid="all"] -`------------`----------------------- -*State* _Pending_ -*Date* _2008-07-26_ -*Proposed by* link:ct[] -------------------------------------- +Design Process : Scripting Language +=================================== + +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-07-26_ +|*Proposed by* | ct +|==================================== -Scripting Language ------------------- +Required Scripting Language +--------------------------- Add support for the *Lua* scripting language in Lumiera. @@ -21,7 +24,7 @@ as »official« scripting language. Tasks ^^^^^ * Investigate Lua's C bindings and integrate it - * It will attach to the link:Plugin/Interface[] System cehteh is working on + * It will attach to the Plugin/Interface System cehteh is working on Pros @@ -50,7 +53,7 @@ Rationale Wee need scripting yet alone for driving the testsuite soon. Later on scripting might be used to customize workflows and other application internals. Further one might implement a high level / batch interface to lumiera to give it a -scripting interface similar to link:AviSynth[]. +scripting interface similar to the https://en.wikipedia.org/wiki/AviSynth[Frameserver »AviSynth«]. @@ -105,7 +108,7 @@ ct:: '2008-07-30T16:22:32Z' I have no problems using Lua. It is proven in the industry, well supported, -fast, efficient, high level and designed for this purpose. My only "complaint" +fast, efficient, high level and designed for this purpose. My only ``complaint'' is that Lua isn't my pet language (Scheme). And that really isn't a complaint at all. @@ -115,7 +118,7 @@ PercivalTiglao:: '2008-07-28T19:56:25Z' I think Python should be reconsidered: it's given that all languages in this class are powerful at what they do, however python has particularly well developed libraries and is used as the scripting language in the main raster -(GIMP), vector (Inkscape) and 3D (Blender, link:PythonOgre[], PyCrystal) Apps. +(GIMP), vector (Inkscape) and 3D (Blender, PythonOgre, PyCrystal) Apps. Combinations of these Apps are all going to be working in a stack in professional production, so the fact that all the others use python makes a more persuasive case for adoption than any micro-benefit in performance or @@ -126,8 +129,9 @@ get this into professional production houses, then I think having a single language from OS admin the whole way through the stack is a massive gain for the types of users who will be using it. I personally prefer Ruby. Naturally it's your decision to make, all the best, we are looking forward to alphas and -betas in the future + - -- *mytwocents* +betas in the future + +mytwocents:: 'Aug.2008' This proposal is about the _required_ scripting language, i.e. when @@ -197,9 +201,10 @@ Ichthyostega:: '2023-02-04' ~~ Conclusion ---------- -Lua was _accepted_ as the required scripting language by October.2008 dev -meeting. However, Ichthyo _questions and overrules_ this decision in Feb.2023 -and moves this proposal back into the inception stage. +Lua was _accepted_ as the required scripting language by the +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_lua_scripting_language[Oct.2008 dev meeting]. +However, Ichthyo __questions and overrules__ this decision in Feb.2023 +and moves this topic back into the inception stage. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SemanticTags.txt b/doc/devel/rfc/SemanticTags.txt index 1816d7bed..875f1d66b 100644 --- a/doc/devel/rfc/SemanticTags.txt +++ b/doc/devel/rfc/SemanticTags.txt @@ -3,17 +3,17 @@ Semantic tags // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Do 30 Aug 2012 21:06:54 CEST_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _Do 30 Aug 2012 21:06:54 CEST_ +|*Proposed by* | Christian Thaeter +|==================================== ******************************************************************************** .Abstract We have a lot documentation which needs to be cross referenced. Adding well the -known 'tags' concept and extend it slightly with some semantics will aid future +known `tags' concept and extend it slightly with some semantics will aid future automatic processing. ******************************************************************************** @@ -21,15 +21,15 @@ Description ----------- //description: add a detailed description: -Every document (including sourcecode) could extended with some metadata, aka tags -which are then used to build automatic crossreferences. +Every document (including sourcecode) could be extended with some metadata, +aka. ``tags'', which are then used to build automatic crossreferences. -Commonly tags are just 'words' which are picked up and crossreferenceds. I propose +Commonly tags are _just words_ which are picked up and cross referenced. I propose to extend this scheme slightly. Overall this scheme must be very natual and easy to use. A user should not need to -know about the underlying machinery and a tag as in a single lowercase 'word' should -be sufficient in almost all cases. Moreover Tags should be optional. +know about the underlying machinery and a tag as in a single lowercase `"word"` +should be sufficient in almost all cases. Moreover Tags should be optional. .Ontology @@ -39,13 +39,13 @@ To give tags some sematics we introduce a simple ontology: - Tags can have namespaces, delimited by a dot 'foo.bar.baz'. Tags are looked up from right to left 'baz' would suffice as long it is unique. Non unique cases will be handled in context (sometimes non uniqunes is desired) -- We introduce simple "Is a" and "Has a" relationships. These are defined by the - casing of the tag: 'ALL_UPPERCASE' means "Is a" and anything else (including - mixed case) means "Has a". Note that for most cases the "Is a" relation will be - defined implicitly, ín normal cases one doesnt need to care. +- We introduce simple ``is-a'' and ``has-a'' relationships. These are defined by the + casing of the tag: `ALL_UPPERCASE' means ``is-a'' and anything else (including + mixed case) means ``has-a''. Note that for most cases the ``is-a'' relation will + be defined implicitly, in normal cases one does not need to care. - define some tag algebra for lookups (group tags by comma and semicolons, where comma means 'and' and semicolon means 'or'). Used to query the tag database. - regex/globbing might become handy too. + regex / globbing might become handy too. .Implicit Tags @@ -66,7 +66,7 @@ Tags are collected/discovered by some script which creates a tag-database (possibly plaintext asciidoc files) as big project index linking back to the content, details need to be worked out. -We create special asciidoc macros for crossreferencing tags for example: 'RFC:foobar' +We create special Asciidoc macros for cross-referencing tags for example: 'RFC:foobar' 'SOURCE:builder', details need to be worked out later. Note: this Proposal is about including tags in the first place, processing them is only @@ -108,7 +108,7 @@ Cons ^^^^ // fact list of the known/considered bad implications: - * adding tags and developing the tools manging them will take some time + * adding tags and developing the tools to manage them will take some time Alternatives @@ -127,10 +127,13 @@ It is very urgent and important that we make our content much easier accessible. -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) +Conclusion +---------- +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: +⛔ This proposal was never expanded upon. +While containing some interesting ideas, in its current form +it is not deemed helpful for the project. @@ -141,7 +144,7 @@ Comments //edit comment You may recall this proposal created some heated debate at the last developer meeting. -After thinking it over some time, I can see now more clearly what irritated me. +After thinking it over some time, I can _see now more clearly what irritated me._ . for me, the proposal seems somewhat to lack focus. Right now we have some shortcomings at rather basic operations when *authoring content* at the website. This proposal tends to be more @@ -192,8 +195,23 @@ reader will somehow ``get it''. Ichthyostega:: 'Mi 10 Okt 2012 05:36:35 CEST' ~~ +.State -> Dropped +It is now _many years later,_ and no further discussion happened, nor did +anyone care to address the urgent practical needs related to stable cross-links +when authoring the website content. + +- -> link:{rfc}/WebsiteSupportMarkup.html[Cross-links and Website support markup] +- -> link:{rfc}/WebsiteNavigation.html[Website Navigation Menu] + +This proposal contains some intriguing ideas -- yet these ideas require more +dedicated work to transform them into a closed specification, which can be +judged for practicability. I would rather propose to start from the much +more concrete issue with the cross-links and develop a matching algorithm +which is sufficient to generate a ``linkfarm'' entry + +Ichthyostega:: '2025-09-17' //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SkillsCollection.txt b/doc/devel/rfc/SkillsCollection.txt index c2c4f3d68..8a78788f5 100644 --- a/doc/devel/rfc/SkillsCollection.txt +++ b/doc/devel/rfc/SkillsCollection.txt @@ -1,9 +1,13 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2007-06-13_ -*Proposed by* link:ct[] ---------------------------------- +Offering Skills for Help +======================== + + +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-06-13_ +|*Proposed by* | ct +|==================================== Skills Collection @@ -18,7 +22,7 @@ Some Page should list different things needed for working on the project and users should attach themself when they offer support for it. This is meant that people who run into problems know who to ask. In contrast this is not meant like these Skill pages on Sourceforge or such. I don't like this rating and -posing system. We let people assing themself to skill and not skills to people +posing system. We let people assign themself to skill and not skills to people and there is no rating. Skills shall be anything which is needed like the tools we use, the code we @@ -39,12 +43,14 @@ Example .lumiera/renderpipe * ichthyo -... shall this contain emails? + +Question: __shall this contain emails?__ Tasks ^^^^^ - * just set this page up .. either on this wiki or in a tiddlywiki which + * just set this page up ... + + either on this wiki or in a TiddlyWiki which becomes checked into the repo @@ -55,13 +61,13 @@ Pros Cons ^^^^ - * privacy concerns, people might not publish what they know or better what - they ''not'' know + * privacy concerns, people might not publish what they know or, even more, + what they _do not_ know Alternatives ^^^^^^^^^^^^ -...urgs +...urgs 😶 Rationale @@ -76,5 +82,17 @@ community and is absolutely voluntary. Comments -------- +[underline]#Historical remark#: This RfC stems from the very first days of the »Cinelerra-3 movment«, +which turned into the Lumiera project over the course of the following months. The RfC was already +marked as __parked__ when first imported into the Lumiera Documentation in 2010. Early in 2008 however, +at the link:{ldoc}/devel/meeting_summary/2008-03-06.html#_draft_skills_collection[March developer meeting], +it was discussed shortly and deemed ``...only useful if there are more developers working on the project''. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Reading this RfC today gives me some kind of peculiar melancholic feeling -- it has the vibes of »zero hour«, +when all hands on deck are needed and everyone wants to help; people write their names on a blackboard +at the wayside, to get into contact, organise themselves or maybe just to find their beloved ones... + +Ichthyostega:: '2025-09-11' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/StreamTypeSystem.txt b/doc/devel/rfc/StreamTypeSystem.txt index 16347bcc0..4c4baa8b5 100644 --- a/doc/devel/rfc/StreamTypeSystem.txt +++ b/doc/devel/rfc/StreamTypeSystem.txt @@ -3,12 +3,12 @@ Stream Type System // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _2008-10-05_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _2008-10-05_ +|*Proposed by* | Ichthyostega +|==================================== @@ -26,10 +26,17 @@ Description ----------- //description: add a detailed description: The general idea is that we need meta information, and -- more precisely -- -that _we_ need to control the structure of this metadata. Because it has -immediate consequences on the way the code can test and select the appropriate -path to deal with some data or a given case. This brings us in a difficult -situation: +that _we_ need to be in control with regards to the structure of this metadata. +Because this structure of metadata has immediate consequences with respect to the +code's ability to test and select an appropriate path to deal with some data or +a given clause in the high-level-Model.footnote:[To clarify the context of this +problem: the »Builder« works like a _compiler,_ while the high-level-Model is +similar to an attributed syntax tree. And the goal is to generate a low-level +processing description, which implements the given structure in the Session. +Drilling down some levels will yield a descriptor of a _medium_ (e.g. video) +-- and so the actual task becomes to define a formalised processing scheme +to work on something as unspecific as ``a medium''.] +This brings us in a difficult situation: * almost everything regarding media data and media handling is notoriously convoluted @@ -37,13 +44,13 @@ situation: solution * we want to build on existing libraries rather then re-inventing media processing. - * a library well suited for some processing task not necessarily has a type - classification system which fits our needs. + * a library well suited for some processing task does not necessarily have + a type classification scheme which fits our needs. -The proposed solution is to create an internal Stream Type System which acts as -a bridge to the detailed (implementation type) classification provided by the -library(s). Moreover, the approach was chosen especially in a way as to play -well with the rule based configuration, which is envisioned to play a central +The proposed solution is to create an internal *Stream Type System* which acts +as a bridge to the detailed (implementation type) classification provided by the +library(s). Furthermore, the approach was chosen especially in a way as to mesh +up well with the rule based configuration, which is envisioned to play a central role for some of the more advanced things possible within the session. @@ -52,18 +59,18 @@ Terminology * *Media* is comprised of a set of streams or channels * *Stream* denotes a homogeneous flow of media data of a single kind * *Channel* denotes an elementary stream, which -- _in the given context_ -- - can't be decomposed any further + can not be decomposed any further * all of these are delivered and processed in a smallest unit called *Frame*. Each frame corresponds to a time interval. * a *Buffer* is a data structure capable of holding one or multiple Frames of media data. - * the *Stream Type* describes the kind of media data contained in the stream + * the *Stream Type* describes the kind of media data contained in the stream. Concept of a Stream Type ~~~~~~~~~~~~~~~~~~~~~~~~ The Goal of our Stream Type system is to provide a framework for precisely -describing the ``kind'' of a media stream at hand. The central idea is to +describing the ``kind'' of a given media stream. The central idea is to structure the description/classification of streams into several levels. A complete stream type (implemented by a stream type descriptor) contains a tag or selection regarding each of these levels. @@ -75,9 +82,9 @@ Levels of classification Image, Audio, MIDI, Text,..._ This is a simple Enum. * Below the level of distinct kinds of media streams, within every kind we have an open ended collection of *Prototypes*, which, within the high-level - model and for the purpose of wiring, act like the "overall type" of the - media stream. Everything belonging to a given Prototype is considered to be - roughly equivalent and can be linked together by automatic, lossless + model and for the purpose of wiring, act like the ``overall conceptual type'' + of the media stream. Everything belonging to a given Prototype is considered + to be roughly equivalent and can be linked together by automatic, lossless conversions. Examples for Prototypes are: stereoscopic (3D) video versus the common flat video lacking depth information, spatial audio systems (Ambisonics, Wave Field Synthesis), panorama simulating sound systems (5.1, @@ -95,8 +102,8 @@ Working with media stream implementations ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For dealing with media streams of various implementation type, we need _library_ routines, which also yield a _type classification system_ suitable -for their intended use. Most notably, for raw sound and video data we use the -http://gmerlin.sourceforge.net/[GAVL] library, which defines a fairly complete +for their intended use. Notably, for raw sound and video data we use the +https://github.com/bplaum/gavl[GAVL] library, which defines a fairly complete classification system for buffers and streams. For the relevant operations in the Steam-Layer, we access each such library by means of a Façade; it may sound surprising, but actually we just need to access a very limited set of @@ -107,13 +114,13 @@ two streams and get an conversion plugin. Thus, to integrate an external library into Lumiera, we need explicitly to implement such a Lib Façade for this specific case, but the intention is to be able to add this Lib Façade implementation as a plugin (more precisely as a -"Feature Bundle", because it probably includes several plugins and some -additional rules) +link:{rfc}/FeatureBundle_PluggableModules.html[»Feature Bundle«], +because it probably includes several plugins and some additional rules) Link between implementation type and prototype ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -At this point the rules based configuration comes into play. Mostly, to start +At this point the _rules based configuration_ comes into play. Mostly, to start with, determining a suitable prototype for a given implementation type is sort of a tagging operation. But it can be supported by heuristic rules and an flexible configuration of defaults. For example, if confronted with a media @@ -155,10 +162,10 @@ Tasks // List what needs to be done to implement this Proposal: * draft the interfaces ([green]#✔ done#) * define a fall-back and some basic behaviour for the relation between - implementation type and prototypes [,yellow]#WIP# + implementation type and prototypes [orange]#(some draft)# * find out if it is necessary to refer to types in a symbolic manner, or if it is sufficient to have a ref to a descriptor record or Façade object. - * provide a Lib Façade for GAVL [,yellow]#WIP# + * provide a Lib Façade for GAVL * evaluate if it's a good idea to handle (still) images as a separate distinct kind of media @@ -210,7 +217,7 @@ Rationale //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -220,49 +227,74 @@ Comments -------- //comments: append below As usual, see the -http://www.lumiera.org/wiki/renderengine.html#StreamType[Development internal doc] +link:/wiki/renderengine.html#StreamType[Development internal doc] for more information and implementation details. Practical implementation related note: I found I was blocked by this one in further working out the details of the processing nodes wiring, and thus make any advance on the builder and thus to know more precisely how to organize the -objects in the link:EDL/Session[]. Because I need a way to define a viable +objects in the EDL rsp. Session. Because I need a way to define a viable abstraction for getting a buffer and working on frames. The reason is not immediately obvious (because initially you could just use an opaque type). The problem is related to the question what kind of structures I can assume for the -builder to work on for deciding on connections. Because at this point, the -high-level view (pipes) and the low level view (processing functions with a +builder to work on for deciding on routing and connectivity? Because at this point, +the high-level view (pipes) and the low level view (processing functions with a number of inputs and outputs) need in some way to be connected. The fact that we don't have a rule based system for deciding queries currently is not much of a problem. A table with some pre configured default answers for a small number of common query cases is enough to get the first clip rendered. -(Such a solution is already in place and working.) + - -- link:Ichthyostega[] 2008-10-05 +(Such a solution is already in place and working). -Woops fast note, I didn't read this proposal completely yet. Stream types could -or maybe should be coopertatively handled together with the backend. Basically -the backend offers one to access regions of a file in a continous block, this -regions are addressed as "frames" (this are not necessary video frames). The +Ichthyostega:: '2008-10-05' + +Woops fast note, I didn't read this proposal completely yet.... + +Stream types could or maybe should be cooperatively handled together with the backend. +Basically the backend offers one to access regions of a file in a continuous block, this +regions are addressed as ``frames'' (this are not necessary video frames). The backend will keep indices which associate this memory management with the frame -number, plus adding the capabilitiy of per frame metadata. This indices get -abstracted by "indexing engines" it will be possible to have different kinds of -indices over one file (for example, one enumerating single frames, one -enumerating keyframes or gops). Such a indexing engine would be also the place -to attach per media metadata. From the steam layer it can then look like `struct -frameinfo* get_frame(unsigned num)` where `struct frameinfo` (not yet defined) -is something like `{ void* data; size_t size; struct metadata* meta; ...}` + - -- link:ct[] 2008-10-06 +number, plus adding the capability of per frame metadata. This indices get +abstracted by ``indexing engines'' -- it will be possible to have different kinds +of indices over one file (for example, one enumerating single frames, one +enumerating keyframes or GOPs). Such a indexing engine would be also the place +to attach per media metadata. From the steam layer it can then look like + + struct frameinfo* get_frame(unsigned num) + +...where `struct frameinfo` (not yet defined) is something like + +[source, C] +---- + { + void* data; + size_t size; + struct metadata* meta; + ... + } +---- + +ct:: '2008-10-06' + Needs Work ~~~~~~~~~~ +Discussed in the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_stream_type_system[Apr.2011 developer meeting]. There are a lot details to be worked out for an actual implementation but we -agreed that we want this concept as proposed here. +agreed that we basically want some concept as proposed here. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' +I requested to keep it in `pending' state, in hope for more in-depth discussion + +Ichthyostega:: 'Apr 2011' + +[underline]#Many years later#, I still consider such a _type system_ for stream meta data +to be highly relevant and necessary as prerequisite for implementing the Builder. + +Ichthyostega:: '2025-09-18' //endof_comments: + '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SystematicMetadata.txt b/doc/devel/rfc/SystematicMetadata.txt index 1ca83713a..8e6a5b97a 100644 --- a/doc/devel/rfc/SystematicMetadata.txt +++ b/doc/devel/rfc/SystematicMetadata.txt @@ -3,21 +3,23 @@ SystematicMetadata // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Mo 08 Okt 2012 04:39:16 CEST_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Mo 08 Okt 2012 04:39:16 CEST_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract -_give a short summary of this proposal_ +[red]#TODO# _give a short summary of this proposal_ ******************************************************************************** -Lumiera is a metadata processing application: _Data_ is _media data_, and everything +Lumiera is a metadata processing application: the actual _Data_ processed +is the _media data_, used for rendering and playback, while everything else is _metadata_. Since our basic decision is to rely on existing libraries for -handling data, the ``metadata part'' is what _we are building anew._ +handling the data, the ``metadata part'' is what _actually happens_ within the +Lumiera application. This RfC describes a fundamental approach towards metadata handling. @@ -27,7 +29,7 @@ Description //description: add a detailed description: Metadata is conceived as a huge uniform tree. This tree is conceptual -- it is never represented as a whole. In the implemented system, we only ever see parts -of this virtual tree being cast into concrete data representations. These parts +of this virtual tree as being cast into concrete data representations. These parts are like islands of explicitly defined and typed structure, yet they never need to span the whole virtual model, and thus there never needs to be an universal model data structure definition. Data structure becomes implementation detail. @@ -35,11 +37,11 @@ model data structure definition. Data structure becomes implementation detail. Parts of the system talk to each other by _describing_ some subtree of metadata. This description is transferred _in the form of a tree diff:_ the receiver pulls a sequence of diff verbs from a diff iterator, and interpreting these verbs will -walk him down and expand the tree in question. Sub-scopes are ``opened'' and -populated, similar to populating a filesystem. It is up to the receiver to -assemble these information into a suitable representation. Some receiver -might invoke an object factory, while another serialises data into an -external textual or binary representation. +walk him down and expand or transform the tree in question. As part of this +description of model changes, sub-scopes are ``opened'' and populated, similar +to populating a filesystem. It is up to the receiver to assemble these information +into a suitable representation. Some receiver might invoke an object factory, +while another serialises data into an external textual or binary representation. Abstract Metadata Model @@ -85,18 +87,23 @@ Tasks * define the interaction API [yellow-background]#WIP# * scrutinise this concept to find the pitfalls [yellow-background]#WIP# * build a demonstration prototype, where the receiver fabricates an object [red yellow-background]#TBD# - + ** the unit tests related to the _Diff System_ could be counted as such a demonstration + + Ichthyostega:: '2025-09-13' Discussion ~~~~~~~~~~ Pros ^^^^ -- the basic implementation is strikingly simple, much simpler than building - a huge data structure or any kind of serialisation/deserialisation scheme -- parts can be combined in an open fashion, we don't need a final concept up-front -- even complex routing and overlaying strategies become manageable, since they can be - treated in isolation, local for a given scope and apart from the storage representation +- the basic implementation of a meta data structure (a _property tree_) and the + representation of a ``Diff'' is comparatively simple -- much simpler than the + task to define and build a global data model, and get it properly connected + to the various implementation facilities to operate on this data. +- parts can be combined and can evolve in an open ended way, without requiring + a finalised concept up-front, +- even complex routing and overlaying strategies remain manageable, since routing + and data fusion can be treated in isolation, local for a given scope and apart + from the storage representation; - library implementations for textual representations can be integrated. @@ -132,15 +139,17 @@ Basically common (meta) data could take on a lot of shapes between two extremes: - the _precise typed structure_, which also is a contract - the _open dynamic structure_, which leaves the contract implicit -The concept detailed in this RfC tries to reconcile those extremes by avoiding -a global concrete representation; + -this way the actual interaction -- with the necessity -of defining a contract -- is turned into a local problem. +The concept explained in this RfC tries to reconcile those extremes by avoiding +a global concrete representation; instead, several interactions, each local in +scope, can coexist on top of the abstract structure as backdrop. Each of these +actual interactions can have its own specialised standard, which actually is +a collaboration protocol, and is based on a common understanding of the +_structure,_ instead of sharing actual data implementation. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -150,8 +159,32 @@ Comments -------- //comments: append below +This RfC seems to be more like a vision statement; it contains some interesting +ideas, but not much of an actual proposal. At that time, presumably I had hoped +to spur further discussion or provoke some objection, in order to clarify what +we should be aiming at. + +_During the following years,_ many of the ideas spelled out first in this text +found their way into the *Diff System*, now used as a foundation for connecting the +GUI to the Session core in Steam Layer. Especially the discussion of ``Alternatives'' +seem to indicate that an essential motivation for this RfC was to find a viable +alternative to building the whole Application around a _central data model_ -- +which is the naive solution and tends to become a major impediment to +hinder the further evolution within larger software projects. + +- -> see the design page regarding link:{ldoc}/design/architecture/ETD.html[»External Tree Description«] +- -> and the corresponding technical description + regarding the link:{ldoc}/technical/library/DiffFramework.html[Diff Framework] + +[underline]#Bottom line#: not sure what to do with this RfC; concepts explained therein +seem still highly relevant and central to what Lumiera is intended to become -- and they +have already been implemented; hoever, this text does not fit into the format of an RfC, +nor is there a community of developers to discuss such a design vision appropriately. + +Ichthyostega:: '2025-09-13' + //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/TagCloudsOnResources.txt b/doc/devel/rfc/TagCloudsOnResources.txt index 2c36d76dc..8bf5682aa 100644 --- a/doc/devel/rfc/TagCloudsOnResources.txt +++ b/doc/devel/rfc/TagCloudsOnResources.txt @@ -1,81 +1,61 @@ -Design Process : Tag Clouds for Resources -========================================= +Design Process : Tag Clouds +=========================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-07-15_ -*Proposed by* link:PercivalTiglao[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-07-15_ +|*Proposed by* | PercivalTiglao +|==================================== Tag Clouds for Resources ------------------------ -Perhaps a Cloud of tags is unnecessary, but tagging resources similar to +Perhaps a Cloud of Tags is unnecessary, but tagging resources similar to Youtube or like Tag Clouds allows for efficient searching and filtering. Anyone -who uses the web would know how to use them. If a "Cloud of Tags" approach is -used, then organizing the tags by some sort of frequency would be useful. IE: -the more a specific tag is used, the larger it gets, or perhaps the more often -that tag is searched on. - - -Description -~~~~~~~~~~~ +who uses the web would know how to use them. If a ``Cloud of Tags'' approach is +used, then organizing the tags by some sort of frequency would be useful: +the more often a given tag is used, the larger it gets (or perhaps the more often +that tag is searched and referred). -Tasks -~~~~~ - - -Pros -~~~~ - +.Pros * Simple GUI Concept * Eases management of resources with Search * Orthogonal to other resource management schemes like Folders -Cons -~~~~ - - -Alternatives -~~~~~~~~~~~~ - - - -Rationale -~~~~~~~~~ - - - - Comments -------- -* Note: I was inspired with this idea during an email conversation with - Rick777. -- link:PercivalTiglao[] [[DateTime(2008-07-17T14:29:57Z)]] +Note: I was inspired with this idea during an email conversation with _Rick777_. -* Agreed, this is usefull. Also, more advanced config rules can make use of - such tags and wiring can depend on them, for example to route your dialogue - audio to another global bus than the music or ambiance. - -- link:Ichthyostega[] [[DateTime(2008-07-27T22:23:38Z)]] +PercivalTiglao:: '2008-07-17T14:29:57Z' +Agreed, this is useful. Furthermore, advanced config rules can make use of +such tags and wiring can depend on them, for example to route your dialogue +audio to another global bus than the music or ambiance. + +Ichthyostega:: '2008-07-27T22:23:38Z' + +To confirm this point: tagged assets are considered important and kept on the main agenda + +Ichthyostega:: '2025-09-15' Conclusion ---------- -This Design Proposal is 'superseded' by a much more advanced proposal: -link:DelectusShotEvaluator[Delectus] +This Design Proposal is _superseded_ by a much more advanced proposal: +link:/x/Delectus.html[Delectus] -(Dropping it doesn't mean disapproval) +^(Dropping it doesn't mean disapproval)^ '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt b/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt index 00100303a..3fdf41414 100644 --- a/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt +++ b/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt @@ -1,14 +1,17 @@ -Threads, Signals and important management tasks -=============================================== +Design Process: Signal Handlers +=============================== + +//MENU: label Threads, Signals and important management tasks + // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Sat Jul 24 21:59:02 2010_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Sat Jul 24 21:59:02 2010_ +|*Proposed by* | Christian Thaeter +|==================================== [abstract] ****************************************************************************** @@ -110,30 +113,9 @@ Tasks // * item ... We have appstate::maybeWait() which already does such a loop. It needs to be -extended by the proposed things above. +extended to install signal handlers and perform the actions proposed above. - - -Discussion -~~~~~~~~~~ - - -Pros -^^^^ -// add just a fact list/enumeration which make this suitable: -// * foo -// * bar ... - - -Cons -^^^^ -// fact list of the known/considered bad implications: - - - -Alternatives -^^^^^^^^^^^^ -//alternatives: if possible explain/link alternatives and tell why they are not +[red]#TODO# Do we have a ticket for this essential feature already? @@ -144,10 +126,11 @@ Rationale This is rather common practice. I describe this here for Documentation purposes and to point out which details are not yet covered. -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) write some +Conclusion +---------- +//conclusion: When approved (this proposal becomes a Final) write some +Without much ado: we need to care for this... @@ -158,7 +141,8 @@ Comments .State -> Final ichthyo wants this to be a dedicated thread (own subsystem) instead running in the initial thread. Fixed this in the proposal above, this makes this accepted. - Do 14 Apr 2011 03:40:41 CEST Christian Thaeter + +Christian Thaeter:: 'Thu 14 Apr 2011 03:40:41 CEST' ~~ //endof_comments: diff --git a/doc/devel/rfc/TimeHandling.txt b/doc/devel/rfc/TimeHandling.txt index 360f75c83..245f55447 100644 --- a/doc/devel/rfc/TimeHandling.txt +++ b/doc/devel/rfc/TimeHandling.txt @@ -1,17 +1,17 @@ Design Process : Time Handling ============================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-21_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-21_ +|*Proposed by* | Ichthyostega +|==================================== -Time handling -------------- -How to handle time values in the code and which policy to aply to the "current" -position +Handling of Time and Time Quantisation +-------------------------------------- +How to handle time values in the code and which policy to apply +to the ``current'' position Description @@ -24,23 +24,26 @@ Description * We use a set of library routines and convenience-methods to - Get time in different formats (fractional seconds, frame counts) - Calculate with time values (overloaded operators) - * Time measurement is zero based (of course :-? ) + * Time measurement is zero based (of course 😁 ) . *Quantizing to a frame index or similar* * Quantizing/rounding shall happen only once at a defined point in the calculation chain and, if in doubt, be done always as late as possible. * Values needing to be quantized to time (grid) positions are calculated by - half-way rounding, but the result should not depend on the actual - zero-point of the scale (i.e. `floor(0.5+val)`, thus quant(0.5) yields 1, - quant(0.49) yields 0, quant(-0.5) yields 0 ) + applying a suitable rounding scheme uniformly, e.g. half-way rounding, but + the result should not depend on the actual zero-point of the scale + ** `floor(0.5+val)` + ** `quant(0.5)` ⟼ 1 + ** `quant(0.49)` ⟼ 0 + ** `quant(-0.5)` ⟼ 0 . *Position of frames* - * Frame numbers are zero based and Frame 0 starts at time=0 (or whatever the + * Frame numbers are zero based and Frame 0 starts at time≡0 (or whatever the nominal start time is) * Each frame starts when the locator hits its lower border (inclusively) and ends when the locator is on its upper border (exclusively) image:{imgd}/Lumi.FramePositions1.png[] * When the locator snaps to frames this means it can be placed on the start positions of the frames solely - * When the locator is placed on such a start position, this means 'always' + * When the locator is placed on such a start position, this means _always_ displaying the frame starting at this position, irrespective of playback direction. . *Current position for keyframe nodes and automation* @@ -48,7 +51,7 @@ Description frame base (which normally is the case), for each frame there is a well defined 'point of evaluation' time position, irrespective of the playback direction - * There is no single best choice where to put this "POE", thus we provide a + * There is no single best choice where to put this ``POE'', thus we provide a switch image:{imgd}/Lumi.FramePositions2.png[] - 'Point of evaluation' of the automation is in the middle of the timespan @@ -62,17 +65,17 @@ image:{imgd}/Lumi.FramePositions2.png[] Tasks -~~~~~ -* Figure out what has to be done when switching the "current position" policy - on a existing project. +^^^^^ +* Figure out what has to be done when switching the ``current position'' + policy for an existing project. Alternatives -~~~~~~~~~~~~ -Leave everything as in Cinelerra2, i.e. show frames after the locator has +^^^^^^^^^^^^ +Leave everything as in Cinelerra-2, i.e. show frames after the locator has passed over them, behave different when playing backwards and set the keyframes on the position of the locator but use them on the frame actually to be shown -(which differs according to the playback direction but is always "one off"). +(which differs according to the playback direction but is always ``one off''). Why not? because it makes frame-precise working with keyframes a real pain and even creates contradictory situations when you switch back and forward while @@ -87,55 +90,64 @@ long as possible and only quantize for rendering a given frame. Rationale ~~~~~~~~~ The intention is to make time handling and calculations as uniform and -"rational" as possible. We try to stick to the precise mathematical values and -let the calculations just yield an result in an uniform manner, instead of -sticking to "simple" values like frame counts or even a session-wide frame rate +_deterministic_ as possible. We try to stick to the precise mathematical values +and let the calculations just yield an result in an uniform manner, instead of +relying on ``simple'' values like frame counts or even a session-wide frame rate -. Time and interval calculations are tricky. Solve this question once and be - done. -. Rounding is always dangerous, rounded values are not the more "clean" values. +. Time and interval calculations are tricky. Solve this question once and be done. +. Rounding is always dangerous, rounded values are by no means the ``cleaner'' values. The floor-rounding rule is chosen, because the length of an interval after quantisation should not depend on the position in relation to the zero point. - The usual mathematical rounding behaves "symmetrical" to the zero point, + The usual mathematical rounding behaves _symmetrical_ to the zero point, which could yield a different length after quantisation if an interval contains the zero point . This is based on the analogy with real film running through a film projector - (or the usual fencepost problem) -. While using the actual position of the locator as the "current" position for + (or the usual »fence post problem«) +. While using the actual position of the locator as ``the current'' position for keyframes seems more natural at first, it crates problems when mixing footage with different framerate or when using a low-framerate proxy footage. Comments ~~~~~~~~ -* This is the summary of a discussion cehteh, Plouj and ichthyo just had on - irc. - -- link:Ichthyostega[] [[DateTime(2007-06-21T05:12:03Z)]] +* This is the summary of a discussion _cehteh_, _Plouj_ and _ichthyo_ just had on IRC. -* We use GAVL now (needs to be included in the build system) - -- link:ct[] [[DateTime(2008-03-05T16:19:22Z)]] +Ichthyostega:: '2007-06-21T05:12:03Z' -* I've tidied up this old design proposal, we could make it final now. I've +* We use lib GAVL now (needs to be included in the build system) + +ct:: '2008-03-05T16:19:22Z' + +* I have tidied up this old design proposal, we could make it final now. I've changed the rounding rule, please check if it's OK. In the original proposal, we wanted to use the common mathematical rounding rule, i.e. round(-x) = - round(x) . I changed this, because of the danger of interval lengths or - alignment to "jump" dependant on the position in relation to the time zero + alignment to ``jump'' depending on the position in relation to the time zero point. - -- link:Ichthyostega[] [[DateTime(2008-10-04T22:47:54Z)]] -* Looks ok to me, maybe we should wrap up the gavl time handling in a very thin +Ichthyostega:: '2008-10-04T22:47:54Z' + +* Looks ok to me, maybe we should wrap up the Gavl time handling in a very thin layer to unify our time functions and then cast this again into a authoritative testsuite/specification. Anyways I think this can be finalized. - -- link:ct[] [[DateTime(2008-10-06T06:44:21Z)]] + +ct:: '2008-10-06T06:44:21Z' Conclusion ~~~~~~~~~~ -* The adapted form of this proposal was *accepted* by October.2008 developer - meeting. +* The adapted form of this proposal was __`accepted'__ by the + link:{ldoc}/devel/meeting_summary/2008-10-10.html#_time_handling[October.2008 developer meeting]. * The proposed thin library layer to centralize time calculations shall be added on demand. When doing so, we need to add thorough test coverage for time calculations too. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +TIP: this library layer was first implemented as a collection of functions, + but has been transformed into a system of adaptor types meanwhile, + so that any conversion into a _Time Code_ also has to go through + a suitable _quantisation_ into a predefined _time grid_. + -> link:{ldoc}/design/architecture/time/index.html[read more here...] + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/TimelineSequenceOutput.txt b/doc/devel/rfc/TimelineSequenceOutput.txt index 429c2f0f7..d71309a49 100644 --- a/doc/devel/rfc/TimelineSequenceOutput.txt +++ b/doc/devel/rfc/TimelineSequenceOutput.txt @@ -1,9 +1,14 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-11-03_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process : Timelines +========================== + +//MENU: label Timelines and Sequences in the high-level-Model + +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-11-03_ +|*Proposed by* | Ichthyostega +|==================================== .Summary @@ -18,8 +23,9 @@ Relation of Project, Timeline(s), Sequence(s) and Output generation ------------------------------------------------------------------- In the course of our discussions it meanwhile became clear, that Lumiera will -show multiple _timeline-like_ views within one project. Similarly it's clear -now that we will support link:EDLsAreMetaClips.html[nested Sequences as meta-clips]. +show multiple _timeline-like_ views within one project. Furthermore, support +for link:{rfc}/EDLsAreMetaClips.html[nested Sequences as meta-clips] is +considered an essential goal. The purpose of this entry is to try to settle on some definitions and clarify the relationships between these concepts. @@ -33,7 +39,7 @@ Project:: the top-level context in which all edit work is done over an Session:: the current in-memory representation of the Project when opened within an instance of Lumiera. This is an implementation-internal term. For - the GUI and the users POV we should always prefer the term "Project" for the + the GUI and the users POV we should always prefer the term »Project« for the general concept. Timeline:: the top level element within the Project. It is visible within a @@ -41,8 +47,9 @@ Timeline:: the top level element within the Project. It is visible within a arrangement of media objects, resolved to a finite time axis, to be rendered for output or viewed in a Monitor (viewer window). Timeline(s) are top-level and may not be further combined. A timeline is comprised of: - * a time axis in abolute time (WIP: not clear if this is an entity or just a - conceptual definition) + * a time axis in absolute time + + ^([purple]#WIP#: not clear if this is an entity or just a + conceptual definition)^ * a _PlayController_ * a list of global _Pipes_ representing the possible outputs (master busses) @@ -50,8 +57,8 @@ Timeline:: the top level element within the Project. It is visible within a nested Sequences Timeline View:: a view in the GUI featuring a given timeline. There might be - multiple views of the same timeline, all sharing the same !PlayController. A - proposed extension is the ability to _focus_ a timeline view to a + multiple views of the same timeline, all sharing the same `PlayController`. + A proposed extension is the ability to _focus_ a timeline view to a sub-Sequence contained within the top-level sequence of the underlying Timeline. (Intended for editing meta-clips) @@ -81,13 +88,13 @@ PlayController:: coordinating playback, cueing and rewinding of a media data needed for playback. Actually, the implementation of the PlayController(s) is assumed to live in the application core. -RenderTask:: basically a !PlayController, but collecting output - directly, without moving a !PlayheadCursor (maybe a progress indicator) and +RenderTask:: basically a `PlayController`, but collecting output + directly, without moving a `PlayheadCursor` (maybe a progress indicator) and not operating in a timed fashion, but freewheeling or in background mode Monitor/Viewer:: a viewer window to be attached to a timeline. When attached, a - monitor reflects the state of the timeline's PlayController, and it attaches - to the timeline's global pipes by stream-type match, showing video as monitor + monitor reflects the state of the timeline's `PlayController`, and it attaches + to the Timeline's global pipes by stream-type match, showing video as monitor image and sending audio to the system audio port (Alsa or Jack). Possible extensions are for a monitor to be able to attach to probe points within the render network, to show a second stream as (partial) overlay for comparison, @@ -108,36 +115,37 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline, same time we may have multiple views of the same timeline. * all playhead displays within different views linked to the _same_ underlying timeline are effectively linked together, as are all GUI widgets - representing the same !PlayController owned by a single timeline. + representing the same `PlayController` owned by a single timeline. * I am proposing to do it this way per default, because it seems to be a best match to the users expectation (it is well known that multiple playback cursors tend to confuse the user) -* the timeline view is modeled to be a sub-concept of "timeline" and thus can +* the timeline view is modelled to be a sub-concept of ``Timeline'' and thus can stand-in. Thus, to start with, for the GUI it doesn't make any difference if it talks to a timeline view or a timeline. * each timeline _refers_ to a (top-level) sequence. I.e. the sequences - themselves are owned by the project, and theoretically it's possible to refer + themselves are owned by the Project, and theoretically it's possible to refer to the same sequence from multiple timelines directly and indirectly. -* besides, it's also possible to create multiple independent timelines -— in +* besides, it's also possible to create multiple independent timelines -- in an extreme case even so when referring to the same top-level sequence. This configuration gives the ability to play the same arrangement in parallel with multiple independent play controllers (and thus independent playhead positions) -* to complement this possibilities, I'd propose to give the _timeline view_ - the possibility to be focussed (re-linked) to a sub-sequence. This way, it +* to complement this possibilities, I'd propose to give the _Timeline View_ + the possibility to be focused (re-linked) to a sub-sequence. This way, it would stay connected to the main play control, but at the same time show a sub-sequence _in the way it will be treated as embedded within the top-level sequence._ This would be the default operation mode when a meta-clip is opened (and showed in a separate tab with such a linked timeline view). The reason for this proposed handling is again to give the user the least - surprising behaviour. Because, when -— on the contrary -— the + surprising behaviour. Because, when -- on the contrary -- the sub-sequence would be opened as separate timeline, a different absolute time position and a different signal routing may result; doing such should be reserved for advanced use, e.g. when multiple editors cooperate on a single project and a sequence has to be prepared in isolation prior to being integrated in the global sequence (featuring the whole movie). -* one rather unconventional feature to be noted is that the _tracks_ (forks) are - within the _sequences_ and not on the level of the global busses as in most +* one rather unconventional feature to be noted is that the _Tracks_ + (actually a _»Fork«_ ≙ a tree of Tracks) are + within the _Sequences_ and not on the level of the global busses as in most other video and audio editors. The rationale is that this allows for fully exploiting the tree-structure, even when working with large and compound projects, it allows for sequences being local clusters of objects including @@ -149,12 +157,12 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline, Tasks ^^^^^ * Interfaces on the Stage and Steam level need to be fully specified. - Especially, "Timeline" is now promoted to be a new top-level entity within + Especially, »Timeline« is now promoted to be a new top-level entity within the Session * communication between the PlayController(s) and the GUI need to be worked out * the stream type system, which is needed to make this default connection - scheme work, currently is just planned and drafted. Doing a exemplaric + scheme work, currently is just planned and drafted. Doing a exemplarily implementation for GAVL based streams is on my immediate agenda and should help to unveil any lurking detail problems in this design. * with the proposed focusing of the timeline view to a sub-sequence, there are @@ -171,8 +179,7 @@ Pros ^^^^ * this design naturally scales down to behave like the expected simple default case: one timeline, one track, simple video/audio out. - * but at the same time it allows for bewildering complex setups for advanced - use + * but at the same time it allows for bewildering complex setups for advanced use * separating signal flow and making the fork (``track tree'') local to the sequence solves the problem how to combine independent sub-sequences into a compound session @@ -181,9 +188,8 @@ Pros Cons ^^^^ * it is complicated - * it is partially uncommon, but not fully revolutionary, and thus may be - misleading. - * the control handling in GUI can become difficult (focus? key shortcuts?) + * it is partially uncommon, but not fully revolutionary, and thus might be misleading. + * the control handling in the GUI can become difficult (focus? key shortcuts?) * the ability to have both separate timelines and timeline views can be very confusing. We really need to think about suitable UI design * because the signal flow is separated from the tracks, we need to re-design @@ -194,13 +200,13 @@ Cons Alternatives ^^^^^^^^^^^^ - * just one session, a list of tracks and don't cover the organisation of - larger projects at all. - * allow only linear sequences with one track, not cluster-like sequences - * make the tracks synonymous with the global busses as usual. Use an - allocation mechanism when "importing" separate sub-projects + * just one Session, a list of Tracks and do not attempt to cover the organisation + of larger projects at all. + * allow only linear Sequences with one Track, not cluster-like sequences + * make the Tracks synonymous with the global busses as usual. Use an + allocation mechanism when ``importing'' separate sub-projects * rather make compound projects a loosely coupled collection of stand-alone - projects, which are just "played" in sequence. Avoid nested referrals. + projects, which are just ``played'' in sequence. Avoid nested referrals. * don't build nested structures, rather build one large timeline and provide flexible means for hiding and collapsing parts of it. @@ -210,7 +216,7 @@ Rationale Obviously, the usual solution was found to be limiting and difficult to work with in larger projects. On the other hand, the goal is not to rely on external project organisation, rather to make Lumiera support more complicated -structures without complicated "import/export" rules or the need to create a +structures without complicated ``import/export'' rules or the need to create a specific master-document which is different from the standard timeline. The solution presented here seems to be more generic and to require fewer treating of special cases than the conventional approach would be. @@ -224,17 +230,17 @@ Comments -GUI handling could make use of expanded view features like ; +GUI handling could make use of expanded view features like... * drop down view of track, that just covers over what was shown below. This may be used for quick precise looks, or simple editions, or clicking on a subtrack to burrow further down. * show expanded trackview in new tab. This creates another tabbed view which - makes the full window are available for a "magnified" view. It is very easy + makes the full window are available for a ``magnified'' view. It is very easy to jump back to the main track view, or to other view tabs (edit points). -* The main track view could show highlights for "currently created" views/edit +* The main track view could show highlights for ``currently created'' views/edit points, and whether they are currently being used or not (active/inactive). * Each tab view could show a miniature view of the main track view (similar @@ -246,36 +252,38 @@ GUI handling could make use of expanded view features like ; positioned very close to the point on the track that was clicked on to trigger the drop down. This close proximity means that the mouse motion distance to commonly used (next) options, is very minimal. Icons for common - options might include ; remove drop down view, create new tab view (active - edit point), create edit point (but don't open a new tab - just create the - highlight zone on the track), temporarily "maximise" the drop down view to + options might include; remove drop down view, create new tab view (active + edit point), create edit point (but don't open a new tab -- just create the + highlight zone on the track), temporarily ``maximise'' the drop down view to the full window size (ie show the equivalent tab view in the current window). -* some of the "matrix" type view methods commonly used in spreadsheets, like - lock horizontal and vertical positions (above OR Below, left OR Right of - marker) for scrolling - this can also be used for determining limits of +* some of the ``matrix type'' view methods commonly used in spreadsheets, like + lock horizontal and vertical positions (above _or_ below, left _or_ right of + marker) for scrolling -- this can also be used for determining limits of scroll. * monitor view could include a toggle between show raw original track , show zoomed and other camera/projector render, or show full rendering including - effects - this ties in with the idea of being able to link a monitor with - viewing anywhere in the node system - but is able to be swiftly changed + effects -- this ties in with the idea of being able to link a monitor with + viewing anywhere in the node system -- but is able to be swiftly changed within the monitor view by icons mounted somewhere on each of the respective monitors' perimeter. * the trackview itself, could be considered as a subview of a - total-timeline-trackview, or some other method of "mapping out" the full + total-timeline-trackview, or some other method of ``mapping out'' the full project (more than one way of mapping it out may be made as optional/default views). -* this set of features are going to be very exciting and convenient to work - with - a sort of google earth feature for global sized projects. +This set of features is going to be very exciting and convenient to work +with -- a sort of google earth feature for global sized projects. + +Tree:: '2008-12-19 22:58:30' -Tree 2008-12-19 22:58:30 Final ~~~~~ - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/TodoLists.txt b/doc/devel/rfc/TodoLists.txt index 1d3b987ac..e83eab89f 100644 --- a/doc/devel/rfc/TodoLists.txt +++ b/doc/devel/rfc/TodoLists.txt @@ -1,9 +1,12 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-03-05_ -*Proposed by* link:ct[] -------------------------------------- +How to organize work? +===================== + +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-03-05_ +|*Proposed by* | ct +|==================================== Todo Lists ---------- @@ -12,30 +15,12 @@ We need some way to organize tasks to be done (tiddlywiki, testsuite, ...?) Description ~~~~~~~~~~~ +Cehteh:: +``I want something which doesn’t need much human care and I want one big `milestones' thing +and a small `mini-task' thing'' - -Tasks -^^^^^ - - -Pros -^^^^ - - - -Cons -^^^^ - - - -Alternatives -^^^^^^^^^^^^ - - - -Rationale -^^^^^^^^^ - +Ichthyo:: +could be refined as as `Roadmap' and `Near time task list' @@ -43,7 +28,51 @@ Rationale Comments -------- -We decided to use a Tiddlywiki for now until this is further worked out - -- link:ct[] [[DateTime(2008-03-08T03:38:50Z)]] +Discussed in the link:{ldoc}/devel/meeting_summary/2008-03-06.html#_idea_todo_lists[March.2008 developer meeting]. + +We decided to use a TiddlyWiki for now until this is further worked out -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-03-08T03:38:50Z' + +.... +​ +​ +​ +​ +​ +.... + +.looking back at another era... +What shall I say, just Whew! 😖 + +For context, I can recall that _Cehteh_ had a very pronounced aversion against bugtrackers +(and especially Bugzilla), because they are just plain confusing, filled with obsolete +information and last but not least, they create spurious work without being helpful +for the developer. Wouldn't it be much better to put everything into the code or +close to the code (as markup in comments)? Git would propagate this information +to the community of other contributors, which would decide about what is viable, +just simply by merging or not merging -- and some clever tool could watch the +resulting commit stream and extract the minimum necessary accounting to +supply the developers with that amount of information + they need to be actually productive.... + +.State -> Dropped +Lumiera is quite another kind of project today. There _is_ a https://issues.lumiera.org/[Bugtracker], +and I need all kinds of meta-tickets, tags, overview lists, the content in documentation pages plus +my own personal notes in several mindmaps just to cope with the sheer amount of information and not +to forget about matters already decided and settled. + +_All this meta-work takes a considerable amount of effort,_ for sure. + +Yet the question remains, how can I ``keep track'' without keeping track? +How can I judge and decide, without actually performing the judgement to arrive at a decision? +Would it make any difference to this dilemma, if ``someone else'' were to perform that work?? + +Can this kind of immaterial mental work be conditioned and commodified into an industrial process, +so that the individual person might side-step the effort, yet sill remain a sovereign? + +[purple]#I do not know the answer to this question.# + +Ichthyostega:: '2025-09-18' + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/UnitTests_Python.txt b/doc/devel/rfc/UnitTests_Python.txt index 9d71205e6..0ab60931f 100644 --- a/doc/devel/rfc/UnitTests_Python.txt +++ b/doc/devel/rfc/UnitTests_Python.txt @@ -2,12 +2,12 @@ Design Process : Unit Tests Python ================================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2007-06-17_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-06-17_ +|*Proposed by* | Ichthyostega +|==================================== UnitTests in Python @@ -20,7 +20,7 @@ Cinelerra Code via SWIG Description ~~~~~~~~~~~ -Define Test classes in Python, using e.g. the link:PyUnit[] framework of the +Define Test classes in Python, using e.g. the PyUnit framework of the Python Standard lib. The SWIG compiler can generate wrapper code automatically, so we can access the C++ Classes and Facilities of Cinelerra as Python Modules and Classes. The Classes to be tested in Cinelerra need to provide some @@ -29,8 +29,7 @@ the whole Test driven aproach). Tasks -~~~~~ - +^^^^^ * Find out how the SWIG generated wrappers play together with Python's List and Map types. Without the ability to use the latter in the tests, this whole proposal is rather pointless. @@ -39,9 +38,8 @@ Tasks Pros -~~~~ - -Programming Unit and Self tests in a Scripting language facillates this task. +^^^^ +Programming Unit and Self tests in a Scripting language facilitates this task. The X-Language bindings are quite usable today. As a side effect, it helps to get a clean program structure, because the tests need some Interface and/or some object factories to create the test candidates. Python is proposed, @@ -49,14 +47,11 @@ because it is fairly mainstream, has a flat learning curve and but is moderately modern and functional-style at the same time. Cons -~~~~ - +^^^^ * Adds to the complexity * Some old-style hackers have a quite distinct aversion against Python -Alternatives -~~~~~~~~~~~~ Rationale ~~~~~~~~~ @@ -64,19 +59,26 @@ Rationale Why am I proposing this? Out of lazyness. Python is there, many devs (on linux) have some Python skills, SWIG is not overly complicated to use. -And last but not least: just to get the discussion going... ;-) +And last but not least: just to get the discussion going... 😉 Comments -------- -* I'd rather consider to use some embedded language in cinelerra which we can - use to drive tests, should be something smaller and more sane than python. - Needs certainly more discussion. For simple unit tests some C/C++ harness and - bit shell scripting would suffice, I really want to integrate this with - link:NoBug[]. - -- link:ct[] [[DateTime(2007-06-17T17:32:27Z)]] +I'd rather consider to use some embedded language in cinelerra which we can +use to drive tests, should be something smaller and more sane than python. +needs certainly more discussion. For simple unit tests some C/C++ harness and +bit shell scripting would suffice, I really want to integrate this with +https://nobug.pipapo.org/[NoBug]. +ct:: '2007-06-17T17:32:27Z' + +Since Lumiera is a separate project now, we do no longer need to ``hook'' +into existing code ``from the outside''. Rather, we have created our own +lightweight unit testing framework in C++. +This RfC was link:{ldoc}/devel/meeting_summary/2008-03-06.html#_idea_unit_tests_in_python[dropped 3/08] + +ichthyo:: '2008-03-06' '''' -Back to link:../DesignProcess[] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/UseCases.txt b/doc/devel/rfc/UseCases.txt index d4580413b..7c05a7485 100644 --- a/doc/devel/rfc/UseCases.txt +++ b/doc/devel/rfc/UseCases.txt @@ -1,15 +1,18 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-10-31_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process: Use Cases +========================= + +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-10-31_ +|*Proposed by* | Ichthyostega +|==================================== Use Case analysis ----------------- -The only way to defeat "featuritis" is to build upon a coherent design -- +The only way to defeat ``featuritis'' is to build upon a coherent design -- + which in turn relies upon a more or less explicit understanding what the application should be like, and the way the prospective user is thought to work @@ -287,24 +290,24 @@ Comments .Template e.g. for regular TV series Constraints to fit all contents within fixed timeline, cover topic, select collage of iconic scenes from archived and collected footage. Update intro and -credit roll for each episode. Add in stopmotion, and 3D model animations with -vocal commentaries. Gather together separate items from "outworkers". +credit roll for each episode. Add in stop motion, and 3D model animations with +vocal commentaries. Gather together separate items from ``outworkers''. Tree:: '2008-12-27 08:36:36' +.State -> Parked +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_use_cases[April.2011 developer meeting]. +We have to revisit this, possibly someone (or a group) who wants to work on the workflow. + +For now it is __parked__ until revisited. + +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' + + //endof_comments: -Parked -~~~~~~ -We have to revisit this, possibly someone (or a group) who wants to work on -the workflow. For now its parked until revisited. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter - - - - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/VersionNumberScheme.txt b/doc/devel/rfc/VersionNumberScheme.txt index 228462b6b..ef6cb6914 100644 --- a/doc/devel/rfc/VersionNumberScheme.txt +++ b/doc/devel/rfc/VersionNumberScheme.txt @@ -3,12 +3,12 @@ VersionNumberScheme // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Mi 09 Mär 2011 02:00:41 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Mi 09 Mär 2011 02:00:41 CET_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ******************************************************************************** @@ -142,7 +142,7 @@ when to use what version number. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -155,11 +155,27 @@ Comments .State -> Final considered common practice - Do 14 Apr 2011 03:46:07 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:46:07 CEST' ~~ + + +💡 + +[underline]#Please Note#: our Git branching model has been switched to +link:{ldoc}/technical/code/GitBranching.html[Git-flow] recently. On occasion +of that change, I wrote two helper scripts + +- 'admin/buildVersion.py' extracts version info from the latest preceding + Git tag, and additionally allows to _bump some component_ of the version-ID +- 'admin/setVersion' edits a hard-wired small selection of known documents + in the tree with `sed` to update a version-ID + +These are both related to version numbers, and also our conventions +for Git-flow refer directly to this RfC. + +Ichthyostega:: '2025-09-15' //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/WebsiteNavigation.txt b/doc/devel/rfc/WebsiteNavigation.txt index 144c41a79..a5e7385a7 100644 --- a/doc/devel/rfc/WebsiteNavigation.txt +++ b/doc/devel/rfc/WebsiteNavigation.txt @@ -3,12 +3,12 @@ WebsiteNavigation // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Mi 08 Dez 2010 11:32:32 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _Mi 08 Dez 2010 11:32:32 CET_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ******************************************************************************** @@ -131,7 +131,7 @@ these issues. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -150,4 +150,17 @@ This is covered by another RfC. Ichthyostega:: 'So 07 Okt 2012 07:30:17 CEST' ~~ +This RfC is in the same state as _many years ago_ -- and frankly, I do not know +what to do with it. One part (the Menu generator script) was implemented. +The other parts, which are tagging and cross-link resolution were proposed +and found general agreement at that time, but no-one did care for expanding +them into an implementation concept. + +Meanwhile, I am working alone and can thus afford to keep the infrastructure +at the bare minimum, just enough for me to cope. Similar as with the +link:{rfc}/WebsiteSupportMarkup.html#_comments[cross-links and support markup]. +However, I consider those topics still something for a group of people to decide. + +Ichthyostega:: '2025-09-18' + //endof_comments: diff --git a/doc/devel/rfc/WebsiteSupportMarkup.txt b/doc/devel/rfc/WebsiteSupportMarkup.txt index 04529a788..6bff1347b 100644 --- a/doc/devel/rfc/WebsiteSupportMarkup.txt +++ b/doc/devel/rfc/WebsiteSupportMarkup.txt @@ -3,12 +3,12 @@ WebsiteSupportMarkup // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Sa 06 Okt 2012 16:47:44 CEST_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _Sa 06 Okt 2012 16:47:44 CEST_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract @@ -221,7 +221,7 @@ can be considered a one-time investment. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -246,7 +246,17 @@ those stuff which matters in practice. Ichthyostega:: 'So 07 Okt 2012 07:31:25 CEST' ~~ +.State -> Draft +Unfortunately, nothing has happened with this RfC ever since; the reason is +lack of developer capacity. Since this RfC is already fairly detailed, and +no significant objections were pointed out, I am promoting this RfC to +a __"Draft"__ now, yet leave it pending. Same as with the +link:{rfc}/WebsiteNavigation.html#_comments[RfC: Website Navigation]. + +Ichthyostega:: '2025-09-18' + + //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc_final/CCodingStyleGuide.txt b/doc/devel/rfc_dropped/CCodingStyleGuide.txt similarity index 100% rename from doc/devel/rfc_final/CCodingStyleGuide.txt rename to doc/devel/rfc_dropped/CCodingStyleGuide.txt diff --git a/doc/devel/rfc_parked/ConfigLoader.txt b/doc/devel/rfc_dropped/ConfigLoader.txt similarity index 100% rename from doc/devel/rfc_parked/ConfigLoader.txt rename to doc/devel/rfc_dropped/ConfigLoader.txt diff --git a/doc/devel/rfc_parked/DataBackend.txt b/doc/devel/rfc_dropped/DataBackend.txt similarity index 100% rename from doc/devel/rfc_parked/DataBackend.txt rename to doc/devel/rfc_dropped/DataBackend.txt diff --git a/doc/devel/rfc_final/DistributedDevelopmentFramework.txt b/doc/devel/rfc_dropped/DistributedDevelopmentFramework.txt similarity index 100% rename from doc/devel/rfc_final/DistributedDevelopmentFramework.txt rename to doc/devel/rfc_dropped/DistributedDevelopmentFramework.txt diff --git a/doc/devel/rfc_final/GitCommitMessageFormat.txt b/doc/devel/rfc_dropped/GitCommitMessageFormat.txt similarity index 100% rename from doc/devel/rfc_final/GitCommitMessageFormat.txt rename to doc/devel/rfc_dropped/GitCommitMessageFormat.txt diff --git a/doc/devel/rfc_parked/GitSubmoduleTransistion.txt b/doc/devel/rfc_dropped/GitSubmoduleTransistion.txt similarity index 100% rename from doc/devel/rfc_parked/GitSubmoduleTransistion.txt rename to doc/devel/rfc_dropped/GitSubmoduleTransistion.txt diff --git a/doc/devel/rfc_pending/RefactorLiblumieraOut.txt b/doc/devel/rfc_dropped/RefactorLiblumieraOut.txt similarity index 100% rename from doc/devel/rfc_pending/RefactorLiblumieraOut.txt rename to doc/devel/rfc_dropped/RefactorLiblumieraOut.txt diff --git a/doc/devel/rfc_pending/ScriptingLanguage.txt b/doc/devel/rfc_dropped/ScriptingLanguage.txt similarity index 100% rename from doc/devel/rfc_pending/ScriptingLanguage.txt rename to doc/devel/rfc_dropped/ScriptingLanguage.txt diff --git a/doc/devel/rfc_pending/SemanticTags.txt b/doc/devel/rfc_dropped/SemanticTags.txt similarity index 100% rename from doc/devel/rfc_pending/SemanticTags.txt rename to doc/devel/rfc_dropped/SemanticTags.txt diff --git a/doc/devel/rfc_parked/SkillsCollection.txt b/doc/devel/rfc_dropped/SkillsCollection.txt similarity index 100% rename from doc/devel/rfc_parked/SkillsCollection.txt rename to doc/devel/rfc_dropped/SkillsCollection.txt diff --git a/doc/devel/rfc_parked/TodoLists.txt b/doc/devel/rfc_dropped/TodoLists.txt similarity index 100% rename from doc/devel/rfc_parked/TodoLists.txt rename to doc/devel/rfc_dropped/TodoLists.txt diff --git a/doc/devel/rfc_pending/ApplicationInstall.txt b/doc/devel/rfc_final/ApplicationInstall.txt similarity index 100% rename from doc/devel/rfc_pending/ApplicationInstall.txt rename to doc/devel/rfc_final/ApplicationInstall.txt diff --git a/doc/devel/rfc_pending/DeveloperDocumentationStructure.txt b/doc/devel/rfc_final/DeveloperDocumentationStructure.txt similarity index 100% rename from doc/devel/rfc_pending/DeveloperDocumentationStructure.txt rename to doc/devel/rfc_final/DeveloperDocumentationStructure.txt diff --git a/doc/devel/rfc_pending/SchedulerRequirements.txt b/doc/devel/rfc_final/SchedulerRequirements.txt similarity index 100% rename from doc/devel/rfc_pending/SchedulerRequirements.txt rename to doc/devel/rfc_final/SchedulerRequirements.txt diff --git a/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt b/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt index 7e11a3596..f0a81802c 100644 --- a/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt +++ b/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt @@ -17,12 +17,14 @@ _Summary written by XXXXX_ Recurring Topics ---------------- -Discussion of open link:{ldoc}/devel/rfc.html[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. Prop1 ~~~~~ +//// link:{rfc}/SomeProposal[descriptive name] +//// Summary what issues are discussed ..Details.. diff --git a/doc/devel/template/new_rfc.sh b/doc/devel/template/new_rfc.sh index a78af057b..4ef34a4c7 100644 --- a/doc/devel/template/new_rfc.sh +++ b/doc/devel/template/new_rfc.sh @@ -62,7 +62,7 @@ Rationale //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: diff --git a/doc/index.txt b/doc/index.txt index 9bc0f11e6..676804e85 100644 --- a/doc/index.txt +++ b/doc/index.txt @@ -51,7 +51,7 @@ the hierarchy, ==== The Uppermost Layer At the highest, uppermost layer is the document -https://lumiera.org/documentation/user/intro/intro.html[Lumiera (as seen) from Outer Space]. This is the node +link:user/intro/intro.html[Lumiera (as seen) from Outer Space]. This is the node on the left in the illustration above. All new to Lumiera should read this document. You can always return to this document later if you are entirely lost and wish to find your bearings before navigating into the deeper documentation dungeons. @@ -76,15 +76,15 @@ section has two main sections: [width="90%",frame="topbot",options="header",cols="^,2<"] |================================================================================================ |Sub-System|Remarks -|https://lumiera.org/documentation/design/architecture/index.html[Architecture]|Structure of Lumiera -|https://lumiera.org/documentation/design/gui/index.html[GUI]|The Lumiera ⟷ user interaction layer -|https://lumiera.org/documentation/design/model/index.html[Model]|Low-level and high-level models -|https://lumiera.org/documentation/design/engine/index.html[Engine]|Renderer, output generation, ... -|https://lumiera.org/documentation/design/lowlevel/index.html[Low-level]|Low-level and system services -|https://lumiera.org/documentation/design/application/index.html[Application]|Application framework -|https://lumiera.org/documentation/design/plugins/index.html[Plugins]|Dynamically loaded Extensions -|https://lumiera.org/documentation/design/workflow/index.html[Workflow]|Workflow and Interaction Design -|https://lumiera.org/documentation/design/governance/index.html[Governance]|Meta project concerns +|link:design/architecture/[Architecture]|Structure of Lumiera +|link:design/gui/[GUI]|The Lumiera ⟷ user interaction layer +|link:design/model/[Model]|Low-level and high-level models +|link:design/engine/[Engine]|Renderer, output generation, ... +|link:design/lowlevel/[Low-level]|Low-level and system services +|link:design/application/[Application]|Application framework +|link:design/plugins/[Plugins]|Dynamically loaded Extensions +|link:design/workflow/[Workflow]|Workflow and Interaction Design +|link:design/governance/[Governance]|Meta project concerns |================================================================================================ @@ -94,15 +94,15 @@ section has two main sections: [width="90%",frame="topbot",options="header",cols="^,2<"] |================================================================================================ |Sub-System|Remarks -|https://lumiera.org/documentation/technical/build/index.html[Build System]|Build, Packaging and CI -|https://lumiera.org/documentation/technical/stage/index.html[Stage]|GUI (technical aspects) -|https://lumiera.org/documentation/technical/steam/index.html[Steam]|Session and processing coordination -|https://lumiera.org/documentation/technical/vault/index.html[Vault]|Low-level operations -|https://lumiera.org/documentation/technical/library/index.html[Support lib]|Interface and support libraries -|https://lumiera.org/documentation/technical/code/index.html[Code base]|Code management, organisation, ... -|https://lumiera.org/documentation/technical/infra/index.html[Infrastructure]|Website and developer tooling ... -|https://lumiera.org/documentation/technical/howto/index.html[Developer HowTos]|Instructions and guides for developers -|link:/doxy/index.html[API Doc]|Using link:http://doxygen.org[Doxygen] to generate doc from code +|link:technical/build/[Build System]|Build, Packaging and CI +|link:technical/stage/[Stage]|GUI (technical aspects) +|link:technical/steam/[Steam]|Session and processing coordination +|link:technical/vault/[Vault]|Low-level operations +|link:technical/library/[Support lib]|Interface and support libraries +|link:technical/code/[Code base]|Code management, organisation, ... +|link:technical/infra/[Infrastructure]|Website and developer tooling ... +|link:technical/howto/[Developer HowTos]|Instructions and guides for developers +|link:/doxy/[API Doc]|Using https://www.doxygen.nl/[Doxygen] to generate doc from code |================================================================================================ @@ -113,13 +113,13 @@ mostly used as design notebook, featuring day-to-day design sketches, notes but quite some more persistent planning. Finished documentation text is constantly moved over to the documentation section(s) of the Lumiera website. --> access the Development link:{l}/wiki/renderengine.html[TiddlyWiki online here] +-> access the Development link:/wiki/renderengine.html[TiddlyWiki online here] == Media and Presentations == This section holds documents and materials used to present and promote Lumiera, articles, summaries and whitepapers - -> link:/media/index.html[Index] + -> link:/media/[Index] diff --git a/doc/technical/build/BuildDependencies.txt b/doc/technical/build/BuildDependencies.txt index 20ca64f97..f841c1583 100644 --- a/doc/technical/build/BuildDependencies.txt +++ b/doc/technical/build/BuildDependencies.txt @@ -1,7 +1,7 @@ Build Dependencies ================== :Author: core-devs -:Date: 2/2020 +:Date: 11/2025 :toc: @@ -10,26 +10,52 @@ We try to get the best out of modern system programming techniques to reach a solid performance and good throughput. Lumiera shall scale with the provided Hardware, the more RAM and the more/faster CPU's you have the better. -Nevertheless lower end 32bit machines are supported too. +Nevertheless lower end 64bit machines are supported too. Secondary targets will be other free operating systems which offer a decent Posix API. Porting to other more or less similar platforms will be possible, if -- by coincidence -- Someone(TM) helps with porting. -Having said that -- for the time being, the core team won't spend much effort on porting. +Having said that -- for the time being, the core team won't spend much effort on porting, +be it to special hardware or some other popular OS. + Platform -------- -We develop and test on standard PC hardware, 32 and 64 bit. +We develop and test on standard PC hardware, 64 bit.footnote:[ + We attempt to write code mostly in a portable way, yet we have encountered + several aspects now where our solution effectively assumes 64bit layout -- + and thus the code might compile on 32bit, but then not perform as expected. + A notorious example are _hash values_, which are typed as `size_t` following + the C++ idiom. We now use a hash function that is clearly optimised for 64bit, + and we know that a 32bit hash would produce collisions on a regular base, while + our solution assumes that collisions can be ruled out effectively. This is just + one example, which shows that handling such aspects in a portable fashion, while + certainly possibly, requires a significant amount of design work and incurs + additional complexity. + For the time being, we are content to document such cases as tickets. +] It is intended to target other platforms running GNU/Linux eventually. -Lumiera expects a `standard' desktop installation running a XServer. +Lumiera expects a ``standard'' desktop installation running a XServer.footnote:[ + Wayland is ``just around the corner'' since 10 years now. Well, recently it + seems it is _really_ just around the corner. We are aware of the necessary + changes, which are not very complicated to implement (since we are using + GTK-3). However, as long as Wayland simply crashes or hands in our + everyday work setup with XFCE, we will not consider this topic + a priority. In the meantime, please report any problems + you encounter with Lumiera running on XWayland. +] Graphics:: - There are no special requirements for the graphic system. - Hardware acceleration will likely be added later through extensions, - but will remain strictly optional.footnote:[For the time being, we'll watch - the evolution in that area and might revisit that topic when there are more - compelling and widely supported solutions available] + There are no special requirements for the graphic system, other than + some GPU supported for common desktop display in the standard setup. + Hardware acceleration for video processing will likely be added later + through extensions, but will remain strictly optional.footnote:[ + For the time being, we'll watch the evolution in that area + and might revisit that topic when there are more compelling + and widely supported solutions available. Support for 32bit + floating point data formats is considered more important. + ] Disks:: No special requirements. Video editing requires decent disk speed though, @@ -42,6 +68,7 @@ Special Hardware:: * Specs and APIs must be open. * someone to do the actual interfacing and support needs to join the team + Compatibility ~~~~~~~~~~~~~ We try to keep our depdendencies close to Debian/stable and the most recent Ubuntu LTS. @@ -54,55 +81,101 @@ Languages and Tools * C / C++ - - a C99 / C++17 compatible compiler footnote:[in practice, we build using GCC and - occasionally we check using Clang] - - GCC *7* or Clang *6* should be fine footnote:[basically we try to use just the stock language. - On rare occasions in the past, we _did_ use some GCC extensions, like `typeof()`, but we care for - workarounds, in case this becomes a problem. Incidentally, `typeof()` is obsoleted by the new - C++ standard, which provides `decltype()` for this purpose.]. + - A C\+\+23 compatible compiler is required.footnote:[ + In practice, we build using GCC and occasionally we check using Clang. + Right now (7/2025) Clang has fallen behind regarding support of type dependent + name resolution in templates and does not even comply with C++20 in this respect. + We have dropped most usages of the `typename` keyword recently, and as long as + Clang can not cope with that, we have to postpone further tests with Clang. + ] + - GCC-**14** or better should be fine.footnote:[ + Basically we try to use just the stock language. + But we actually compile with the GNU extensions, i.e. `-std=gnu++23` / `-std=gnu99`. + And any language feature is used to the degree that it is available and stable + in this build environment. + ] * BOOST (listed below are the Debian package names) - - libboost-dev (at least *1.67*) - - libboost-program-options-dev + - libboost-dev (at least *1.83*) - libboost-program-options-dev * Script languages - - Python (*2.x*) might still be handy for build scripts.footnote:[SCons supports both Python 2.x - and Python 3.x transparently. Basically there is no reason to stick to Python 2.x -- just the standard - python is not yet switched on Debian/stable, and so we might miss out on some scripts.] + - Python (*3.10*) required for building (->SCons) - bash (some test scripts use bash specific extensions) Build Tools ~~~~~~~~~~~ -* Git -* SCons *2.0* footnote:[we build with SCons >= 3.0 since a long time. However, since the times of 2.0, - there are no major breaking improvements we rely on -- so chances are that the Build works fine with - older versions. In addition, we use some SCons plug-ins, which are all shipped in-tree (`admin/scons`)] +* https://www.scons.org/[SCons build system] v**4.8** footnote:[ + Unfortunately, SCons still sets the conceptual standard how a modern build system should be: + It is declarative, defines the _what_ and not the _how_ and uses build scripts written in + a clean and modern language (Python). + Autotools should be considered legacy, and CMake turned out to be rather disappointing and + lacks adequate conceptual grounding. Meson has a somewhat more modern appeal, yet seems to + require us to do much more work to get even remotely to that level of clarity and flexibility + which we enjoy every day when working with SCons. + + We are aware of the shortcomings of SCons in practice however, notably that it is not widely + known and thus requires additional learning effort, and that it could become prohibitively + slow on very large projects. At the current project size, the delay on incremental builds + does not really seem relevant in practice, given that C++ compilation as such is slow anyway. + We are not aware of using any notable features of SCons beyond v2.0, and we use some SCons + plug-ins, which are all shipped in-tree (directory 'admin/scons')] * pkg-config -* Doxygen +* Doxygen (optional) +* Asciidoc (optional) +* Git -> https://git.lumiera.org/?p=LUMIERA;a=summary[git://git.lumiera.org/LUMIERA] + footnote:[ + _Ichthyo_ maintains a repo at https://github.com/Ichthyostega/Lumiera/[Github ^~Ichthyostega/Lumiera^] + ] -We maintain a link:/documentation/technical/infra/debianDepot.html[Debian/Ubuntu package] (relying on debhelper, CDBS, git-buildpackage) +💡 We maintain a link:{ldoc}/technical/infra/debianDepot.html[Debian/Ubuntu package] (based on `git-buildpackage`) Libraries ~~~~~~~~~ -* BOOST -* link:http://nobug.pipapo.org/[NoBug] -* http://gmerlin.sourceforge.net/gavl.html[GAVL] (for raw media support) -* ALSA: libasound2-dev -* for the GUI: (*GTK-3*) gtkmm-3.0 gdlmm-3.0 glibmm-2.4 cairomm-1.0 xv - - libgtkmm-3.0-dev - - libcairomm-1.0-dev - - libglibmm-2.4-dev, requiring at least glib2.0 (2.40 or better) and gthread-2.0 - - libxv-dev footnote:[for the XV viewer widget `gui/output/xvdisplayer.cpp` - -- currently obsolete as of [yellow-background]#5/2015#][yellow-background]#TODO 5/2015# and X-lib - - librsvg-2.0 and librsvg2-dev for rendering Icons - - libgdl-3 (3.12 or better) through libgdlmm-3 -- the »Gnome Docking Library«footnote:[GDL isn't directly related to GNOME any more. - We contributed to the improvement of this library in the past. These improvements went upstream - with GDL-2.27. At times, we used to ship our own GDL package. Right now, a recent upstream version - together with the corresponding *mm-bindings will do. We provide a debian package for the latter, - until they will be available in the official Debian/Ubuntu/Mint repos. But we don't have any - special requirements on these `gdlmm` bindings.] +* https://www.boost.org/[Boost libraries] +* https://nobug.pipapo.org/[NoBug library] +* https://github.com/bplaum/gavl[GAVL] (for raw media support) +* https://www.alsa-project.org/[ALSA (libasound2-dev)] +* for the GUI: (*GTK-3*) gtkmm, glibmm-2.4, cairomm-1, gdlmm-3, Xv + - libgtkmm-3.0-dev (`>=3.20`) + - libglibmm-2.4-dev (`>= 2.66`), requiring at least glib2.0 (`>=2.80`) + - libcairomm-1.0-dev (`>= 1.14`) + - librsvg2-dev (`>=2.40`) for rendering Icons + - libxv-dev footnote:[ + For the time being, this is a placeholder and fallback to integrate + any technology for displaying video frames on the dektop. It is now used in the + XV viewer widget 'stage/output/xv-displayer.hpp|cpp' -- currently expected + to be obsolete soon, but it is yet [yellow-background]#undecided as of 11/2025# + what we use as starting point for video output from the Lumiera Render Engine. + XV might be retained as a fall-back solution, the libraries GLX or EGL might be used... + ] + and X-lib ^[yellow-background]#TODO 11/2025#^ + - libgdl-3-dev (`>= 3.40`) through libgdlmm-3 -- the »Gnome Docking Library«footnote:[ + https://gitlab.gnome.org/Archive/gdl.git[lib GDL] isn't directly related to GNOME any more. + We use this library for docking panels in the GUI with GTK-3. This solution was maintained + for some time by the »Anjuta« project -- we also contributed to the improvement of this library + in the past, and these improvements went upstream with GDL-2.27. Unfortunately, GDL was abandoned + meanwhile. and we do not see a clear pathway for the future here, short of upgrading to GTK-4, + which is possible, but would require some considerable effort. As of 2025, GDL is still usable, + but no longer available through the standard distribution channels. + + We provide a Git repository at our Website for + https://git.lumiera.org/?p=debian/gdl;a=summary[libGDL (3.40) +git://git.lumiera.org/debian/gdl+] + and the + https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL C++ bindings (3.7.3) +git://git.lumiera.org/debian/gdlmm+] + and we maintain custom Debian packages for both in our + link:/debian/[Debian DEB depot]. + ] +'''' +.Documentation and Resources +[TIP] +-- +* Tutorial link:{ldoc}/user/tutorials/building.html[Building Lumiera from source] +* Tutorial link:{ldoc}/user/tutorials/DebianBuilding.html[Building the »Debian Way«] +* About the link:{ldoc}/technical/build/LumieraDebianPackage.html[Lumiera Debian Package] +* About the link:{ldoc}/technical/build/SCons.html[SCons Build-System of Lumiera] +* About the link:{ldoc}/technical/code/index.html[Code Base Organisation] +* link:/debian/[Lumiera Debian DEB depot] +-- diff --git a/doc/technical/build/BuildDroneDraft.txt b/doc/technical/build/BuildDroneDraft.txt deleted file mode 100644 index b3da2fddd..000000000 --- a/doc/technical/build/BuildDroneDraft.txt +++ /dev/null @@ -1,200 +0,0 @@ -A Build Drone for Lumiera -========================= -:Author: Christian Thäter -:Date: 2008 - - -This is a brainstorming page for what a build system on the server would need. -First of all, it should be simple and extensible, preferably by simple shell -scripts (note that *anything* else is a subset of a shell script!). We should -use existing good ol' unix utilities when applicable (batch, mail,...). -In my opinion this all can be a lot shell code glued together. Things should be -isolated to single tasks and well refactored to make it maintainable. - -Lets go: - - -Whats needed? -------------- - - * A description/configuration what needs to be done, these may be recursive. - * a batch/scheduling system (batch) - * triggers/events which are passed along (initiate a build by a git commit, ...) - * actions to perform - * handlers for success and failure cases which act on the outcome of a action - (scp, mail, rsync, filters to produce asciidoc output...) - * maybe some dependency handing (only build lumiera after installing the recent nobug version successfully) - - -Top Down scratch ----------------- - -Lets say the configs are shell scripts. - -first a verbose one: - ------------------------------------------------------------- -cd project_dir -if git pull; then - # call handlers for success case - sendmail foo@bar.com <>,build_drone_report -} - -function link:GitPull[]() -{ - local dir="$1" - local repo="${2:-origin}" - local branch="${3:-master}" - ACTION="GitPull $*" - RESULT=FAILURE - cd "$dir" 2>&1 | link:AddToReport[] , return 1 - git pull "$repo" "$branch" 2>&1 | link:AddToReport[] , return 1 - RESULT=SUCCESS - return 0 -} - -function link:SendMail[] -{ - cat ,build_drone_mail <>,build_drone_mail - - for i in "$@"; do - sendmail "$i" <,build_drone_mail - done -} ------------------------------------------------------------- - - -now we can do following: (looks much nicer or?) - ------------------------------------------------------------- -if link:GitPull[] project_dir; then - link:SendMail[] foo@bar.com other@blah.net -else - link:SendMail[] boss@bar.com -fi ------------------------------------------------------------- - -the above snippet can be a file in some config dir and will be processed by sourcing it with proper setup -lets place it in /build_drone/project/10GitPull - ------------------------------------------------------------- -for i in "/build_drone/project/*"; do - ( - source "$i" - ) - link:CallTrigger[] -done ------------------------------------------------------------- - -... ok enough for now, whats needed is the link:CallTrigger[] implementation, -stopping processes waiting (either reading on a pipe or wait for signal (-CONT -for success, -TERM for failure)) - -setup of the function scriptlets: - for i in link:/usr/local/lib/BuildDrone/[]*; do source $i; done ... -and so on -.. - - -Conventions ------------ - -. one drone runs always in a well defined directory, if commands have to go into subdirs, use subshells (good idea anyways) -. all jobs need to run in serial order, nothing parallel. What the job then does itself (make -j3 ..) can be parallelized. -. we need a well defined environment and some file where it is registered ,bd_env or so -. all jobs append write their output to some well defined logfile (logfiles ..) -. the status must be recorded in a file too - -Example: - - ------------------------------------------------------------- -function link:BatchJob[]() -{ - batch <&log -echo $? >,bd_exitcode - -kill -CONT $$ -EOF - - # wait for signal - suspend - return $(<,bd_exitcode) -} ------------------------------------------------------------- - -This of course needs some more work, trap handlers for signals etc. I am not -sure if the idea with signals is good, maybe better use a pipe, lets see. - - - - -Actions and Handlers Brainstorming ----------------------------------- - -Ideas, not in order - -link:SendMail[]:: - send report as email -link:GitPull[]:: - updates a git checkout + - Split this in - * link:GitFetch[] - fetch from remote - * link:GitHasChanges[] - are there changes between HEAD and remote? - * link:GitCheckout[] - reset to the remote head and checkout -Bootstrap:: - autoreconf and configure -Make:: - runs 'make' -Check:: - runs 'make check' -Distcheck:: - runs 'make distcheck' -Doxygen:: - runs doxygen -link:StyleCheck[]:: - checks if files violate the style rules, something like: - 'astyle --style=gnu <$FILE.c | diff -u FILE.c - ...' -link:ToDos[]:: - greps for TODO (with some -A context) and produces a report - * beautify (asciidoc) reports - * publish reports, packages etc to the webserver (scp, rsync) - diff --git a/doc/technical/build/LumieraDebianPackage.txt b/doc/technical/build/LumieraDebianPackage.txt index 88f95a228..9d374613f 100644 --- a/doc/technical/build/LumieraDebianPackage.txt +++ b/doc/technical/build/LumieraDebianPackage.txt @@ -1,107 +1,151 @@ The Lumiera Debian Package ========================== :Author: Hermann Voßeler deb@ichthyostega.de -:Date: 11/2011 +:Date: 11/2011 · 11/2025 //Menu: label Debian Package Since several of the Lumiera core developers run a Debian flavour as their primary development platform, -it seems natural to care for the debian packaging of Lumiera ourselves. Moreover, we've declared -Debian/Stable to be our *reference platform* -- we'll provide any additionally required, more recent -packages through our own link:http://Lumiera.org/debian[Debian Apt-Repository] (Debian depot). +it seems obvious also to care for the Debian packaging of Lumiera. Furthermore, we have declared +Debian/Stable to be our *reference platform* -- and we will provide any required additional +packages through our own link:/debian[Debian DEB depot] (for the Apt package manager). TIP: readers new to Debian packages may want to have a look into our - link:{ldoc}/user/tutorials/DebianBuilding.html[Debian build tutorial], + link:{ldoc}/user/tutorials/DebianBuilding.html[Debian Build Tutorial], where we describe the commands for building and explain the structure of a Debian (source) package in general Package build process --------------------- -As our whole infrastructure relies heavily on the Git version management tool, it's only natural -also to organise the (debian) packaging with the help of Git. Fortunately, there is a nifty tool +As our whole infrastructure relies heavily on the Git version management tool, it seems natural +to organise also the (Debian) packaging with the help of Git. Fortunately, there is a nifty tool called link:https://honk.sigxcpu.org/piki/projects/git-buildpackage/[git-buildpackage], written by Guido Günther exactly for this purpose: It treats the _debianisation_ as a branch in the Git repository, forking off the mainline at the release point. +~ -> see also https://wiki.debian.org/PackagingWithGit[Debian packaging with Git (Debian Wiki)]~ -For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the -link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git:/git.lumiera.org/debian/lumiera] repository. +For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the Repository +https://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git://git.lumiera.org/debian/lumiera]. Installing Lumiera ~~~~~~~~~~~~~~~~~~ -The link:SCons.html[SCons build] generates a relocatable distribution directory structure, -holding the main executable, additional tools and utilities, plus the core libraries and resources. +The link:SCons.html[SCons build] generates a distribution directory structure, which is relocatable, +comprising the main executable, additional tools and utilities, plus the core libraries and resources. Here _relocatable_ means that this subtree can be moved and placed anywhere on the system. As long as the relative directory layout remains intact, the executables will be able to find -and load the accompanying libraries and resources. By invoking the `scons install` target, -this directory structure is placed into the installation target directory. +and load the accompanying libraries and resources. By invoking the `install` target, this +directory structure is placed into the target installation directory, with an layout +conforming to the Filesystem Hierarchy Standard. Actually, this lookup process at application startup is performed in two phases -- in the first phase the main application locates the explicitly linked shared libraries. - footnote:[generally speaking, we have to distinguish between dynamic libraries explicitly - linked as part of the application, libraries linked as direct library dependencies, other - transitive library dependencies, and finally shared objects, which are loaded at runtime - through the `dlopen()` call.] - Especially those libraries belonging first class to the Lumiera application are built - with a relative search path ('rpath' with `$ORIGIN` token). These libraries are placed - into the +modules/+ subfolder +- in the first phase the main application locates the explicitly linked shared libraries.footnote:[ + Generally speaking, we have to distinguish between dynamic libraries explicitly + linked as part of the application, libraries marked and linked as direct library dependencies, + other transitive library dependencies, and finally shared objects, which are loaded at runtime + as »plug-in« through the `dlopen()` call. + ] + Some parts of the Lumiera code are built as shared library, but are non the less considered + a mandatory part of the application. Especially those libraries are built with a relative + search path ('rpath' with `$ORIGIN` token), and will be placed into the 'modules/' subfolder + This implies that the dynamic linker will look for this subfolder in the same directory as + the `lumiera` executable and will fail to launch the application unless all those further + mandatory application components can be located. -- after successfully launching the executable, the second phase performs a lookup programmatically, - starting from the path location of the executable. The goal is to find a +setup.ini+ which defines - additional plug-ins and resources to load. Notably, the GUI to launch is loaded as a - plug-in through this mechanism. Moreover, this *bootstrap configuration* defines the +- after successfully launching the executable, the second start-up phase performs a programmatic + lookup, starting again from the path location of the executable. The goal is to find a file 'setup.ini' + which defines additional plug-ins and resources to load. Notably, the GUI to launch is loaded as + a plug-in through this mechanism. Moreover, this *bootstrap configuration* defines the additional platform and user configuration to load for further outfitting of the system. -LSB Installation Layout + +FHS Installation Layout ~~~~~~~~~~~~~~~~~~~~~~~ -This organisation is used as foundation for packaging and installing. The primary application -distribution structure will be located into a subfolder below +/usr/lib/+. Only the main application -executable will be symlinked into +/usr/bin/+. The LSB explicitly allows for such a layout, which is -typically used by large application bundles (OpenOffice, Gimp, Eclipse). Since the application -startup encompasses two phases, loading the extended configuration programmatically after -launching the application, extended resources from the application bundle can easily be -relocated into a separate folder below `/usr/share/`, as required by LSB. +So this organisation of the application executables and resources into an installation bundle in a +subdirectory tree is used as foundation for packaging and installing. The primary application +distribution structure with all the executable code will be placed into a sub-tree below +'/usr/lib/lumiera'. Only the main application executable `lumiera` will then be symlinked into '/usr/bin/'. +This pattern is in accordance with the +https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard[Filesystem Hierarchy Standard (FHS)], +and it is typically used by large application bundles (e.g. Libreoffice, Firefox-esr). +Since the application startup of Lumiera encompasses two phases, where loading the extended configuration +happens programmatically after launching the main application, all extended (platform-independent) +resources from the application bundle can easily be relocated into a separate folder +below `/usr/share/lumiera`, as required by FHS. + +How the Lumiera Debian package works +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Since we maintain both the Debian package and our build system, we can always try to do +_the heavy lifting_ in our link:{ldoc}/technical/build/SCons.html[SCons build system], +as this helps to keep the Debian packaging as simple as possible. Please have a look at the +-> https://git.lumiera.org/?p=debian/lumiera;a=blob;hb=refs/heads/deb;f=debian/control[control file] +· https://git.lumiera.org/?p=debian/lumiera;a=blob;hb=refs/heads/deb;f=debian/rules[debian/rules] + +- we rely on the _Debhelper Sequencer_ "`dh_*`" in our 'debian/rules' + + -> https://manpages.debian.org/trixie/debhelper/dh.1.en.html[Manpage] + · https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules[Debian-Policy §4.9] + +- but we define three _override targets_ in order to invoke SCons explicitly, + so that it is immediately clear what configuration is passed to the build. + +- we configure SCons with `INSTALLDIR=debian/lumiera PREFIX=usr`, and thus + the installation will happen below 'debian/lumiera', which is the location + expected by the following DEB building steps + Releases, Branches and Conventions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Official releases are marked by a tag on the master branch. At that point, master should be -in good shape, release documentation is polished; experimental features are removed or disabled. -Usually, we'll also fork a *release branch* at that point, featuring bugfixes only. -From here we'll merge to the **debian branch**footnote:[the 'release' branch will be merged back at -times, while the 'debian' branch won't. This 'debian' branch is published through a separate -link:git://git.lumiera.org/debian/lumiera[debian/lumiera git repository] and not merged back, -since all tweaks here are strictly for debian packaging. There might be other packaging related -repositories in the future. Yet still, the 'debian' branch is based on the same common tree -and can in therory kept in the same git repository. Contrast this to the branch 'depot', which -is also published through our 'debian/lumiera' git repository. This latter branch corresponds -to a completely separate tree and holds the administrative part of our -link:http://Lumiera.org/debian[Debian package depot] (Repository) on Lumiera.org.] +Lumiera uses the link:{ldoc}/technical/code/GitBranching.html[Git-flow branching pattern] +to organise releases and patches in the Git history. All official releases are marked by +_a tag on the master_ branch. This tag is published in the primary Lumiera repository at +`git://git.lumiera.org/LUMIERA` at the time of the release. Bugfixes are also merged +into `master` and marked with a tag there. -Typically the release will lead to the discovery of more or less serious bugs, which are -fixed on the release branch and backported to master. The result is a sequence of point -releases. At the end of a stable release series, the release branch will be upgraded -with a single merge commit to the level of the next major release. +For the actual packaging, we use these release tags as _upstream tag_ and perform a merge +from that tag into the **debian branch**.footnote:[ + This _debian branch_ is called `deb` by convention. As mentioned above, it is published through + a separate https://git.lumiera.org/?p=debian/lumiera;a=summary[Git repository `git://git.lumiera.org/debian/lumiera`], + which is kept separate, since packaging is considered a ``downstream process''. +] +This branch carries only the additions and tweaks done for debian packaging. Yet still, this `deb` +branch is based on the common tree of the codebase and could in theory be kept within the same Git +repository as the `master` branch. When the packaging process is complete, the published +DEB version is marked with a tag `debian/` + +Note however that there is another branch in the aforementioned `debian/lumiera` repository, +which is called https://git.lumiera.org/?p=debian/lumiera;a=shortlog;h=refs/heads/depot[depot] +and is related to our link:/debian[DEB package depot] on Lumiera.org. This branch carries a completely +different directory structure, since it is used with the +https://wiki.debian.org/DebianRepository/SetupWithReprepro[»reprepro« tool from Debian] +to manage the contents of that depot. Package build commands ~~~~~~~~~~~~~~~~~~~~~~ To (re)build the debian package -. +git clone git:/git.lumiera.org/lumiera/debian+ -. +mkdir pack.deb+ -. +cd debian+ -. +git-buildpackage --git-upstream-branch=+ _RELEASE-TAG_ +. step into a packaging work directory +. `git clone git://git.lumiera.org/debian/lumiera -b deb` +. `cd lumiera` +. `gbp buildpackage` + +Typically you will have to install some _build dependencies_ before you can +build the package. This can be checked by invoking `dpkg-checkbuilddeps` from +within the package directory (here 'lumiera'). These dependencies can be +managed automatically with the Debian tooling, by using one of the following +two alternative solutions + +- `apt-get build-dep lumiera` (requires Lumiera DEB depot in the apt sources) +- invoking `mk-build-deps` from within the package directory (requires `equivs` package) --- here _RELEASE-TAG_ denotes the point in the Git history, which should become -the reference source and be packaged into the *.orig.tar.gz. Usually, it's just -sufficient to use branch 'release' for that purpose. Debian-Depot for installation via Apt ------------------------------------- In addition to the packaging, we maintain a dedicated Apt-Repository for automated installation and upgrades. We try to build the package for several Debian derived -distributions (like Ubuntu). -> link:../infra/debianDepot.html[more on the repository organisation] +distributions (like Ubuntu). +-> link:{ldoc}/technical/infra/debianDepot.html[more on the repository organisation] diff --git a/doc/technical/build/SCons.txt b/doc/technical/build/SCons.txt index 150fcdeb8..cd4acb7e2 100644 --- a/doc/technical/build/SCons.txt +++ b/doc/technical/build/SCons.txt @@ -1,36 +1,66 @@ SCons Build-System ================== :author: Ichthyo -:date: 2012 +:date: 2012 · 2025 +:toc: //MENU: label SCons Build -Lumiera uses a build system based on link:http://scons.org[SCons] +Lumiera uses a build system based on https://scons.org/[SCons] -SCons is an open source software construction tool based on Python build definition scripts. -Within these build scripts, we define a data structure to describe the parts and dependencies -of our software. When executed, SCons evaluates those definitions and the actual files in -the source tree to derive a build strategy, which is then performed. +SCons is an open source software construction tool based on build definition scripts +written in Python. Within these build scripts, we define a data structure to describe +the parts and dependencies of our software. When executed, SCons evaluates those +definitions and the actual files in the source tree to derive a build strategy, +which is then performed to actually (re)build the software. + +Synopsis +-------- +[cols=">, see 'target/,testlog' +| development build: | scons -j# testcode | -> `target/test-suite ` +| install: | scons -j# install | installs below '/usr/local/', ⚠ sudo +| see possible config:| scons -h | ⚠ settings are *sticky* -> see './optcache' +|===================== + + + +.Known shortcomings of SCons +[NOTE] +-- +* No one knows it +* It is written in Python +* It is _declarative_ not _imperative_ + + Thus people hate that they can not just figure out some script +* A SCons build can not be manipulated by setting environment variables +* SCons has no default interface for package managers. + + Each project has to solve that individually... +* SCons is not a platform-, package- and dependency manager. +-- SCons core concepts ------------------- -^_this section is based on the introductory pages on the link:http://www.scons.org/wiki/BasicConcepts[SCons Wiki]_^ +^_this section is based on the introductory pages on the https://github.com/SCons/scons/wiki/BasicConcepts[SCons Wiki]_^ .SCons Environment When SCons starts building the project, it creates its own environment with dependency trees, -helper functions, builders and other stuff. The SCons environment is created in memory and some parts of it +helper functions, builders and other stuff. The SCons environment is built in memory and some parts of it are saved to disk to speed up things on the next start. The definition of the build happens within this -artificial build environment. This often confuses people who used Makefiles, where environment is actually +abstracted build environment. This often confuses people who used Makefiles, where ``environment'' is actually the System Environment. .System Environment the familiar operating system container with environment variables such as PATH, HOME etc. It is usually accessible via os.environ mapping in Python and therefore in SCons too. -SCons doesn't import any settings from System Environment automatically (like flags for compilers, -or paths for tools), because it's designed to be a cross platform tool with _predictable behaviour._ -That's why, if you rely on any system PATHs or environment variables -- you need to extract +SCons does not automatically import any settings from System Environment automatically +(like flags for compilers, or paths for tools), because it's designed to be a cross platform tool +with _predictable behaviour._ +If you rely on any system PATHs or environment variables -- you need to extract those settings explicitly in your build definition. + .SConstruct when SCons executes, it performs a build definition python script written by the user. By convention, this main script is called 'SConstruct' and is located in the root of the source tree. @@ -44,10 +74,22 @@ the sub-trees of the project. .Builder The SCons buildsystem revolves around the metaphor of a _Builder_. This is a SCons object that you explicitly -invoke from the scripts to _define_ that there is something to build, transforming a _source_ into a _target_. +invoke from the scripts to _define_ that there is something to build, thereby transforming a _source_ into a _target_. So the target depends on the sources, and typically those _source nodes_ were created by previous builder invocations. -The power of SCons is in the fact that dependencies are tracked automatically. When source files change, the system -is able to derive which targets to rebuild. +The use of Builders is _declarative:_ it is a statement _that_ a transformation (build step) has to happen, while +the knowledge _how_ this can be achieved is kept implicit within the buildsystem. + +.Action +These are are functors that perform something (execute an external command or call a python function, for instance). +A Builder retains a list of Actions needed to update its targets; those Actions are run when needed. + +.Node +This is the basic building block of the dependency graph, while the arcs are created by using Builders: +a Node represents a filesystem object, such as a file or directory which can also be a build result and +as such does not exist yet. There are also Alias nodes and Value nodes which represent setting values. +The power of SCons is in the fact that dependencies can be tracked and a build strategy can be derived, +automatically, based on the structure of this dependency graph. And because the building blocks of that +graph are _abstract,_ users can _represent the specifics of their build_ in an uniform way. .Scanner when defining a builder, SCons relies on modular scanner components to ``understand'' the source of the build step. @@ -58,26 +100,46 @@ through plug-ins. .Tool any further, external component that adds Builders, Scanners and other helpers to SCons environments for use within scripts. There are special tools for _configuring the platform_ to detect libraries and -further requirements. Relying on those tools. the build environment will be outfitted to reflect the -needs of the specific build. Sub-environments with special configuration may be created. +further requirements. Tools do not operate themselves, rather they will configure the build environment +to reflect the needs of the specific build. + +.Construction Variable +All key-value settings within a Construction Environment which are used to instruct SCons about builds. +Construction Variables can describe compiler flags, locations of commands to execute, and many other characteristics. +They are used for _text substitution_ in command template strings for invocation of external commands, relying on +the usual `$VARIABLE` syntax. Since the configuration of a SCons environment is defined by its +Construction Variables, sub-environments with special configuration may be created. + +.Signature +SCons computes a signature for elements on the dependency graph using a cryptographic hash function which +has the property that the same input repeatably leads to the same signature. The default function is MD5. +Signatures are used throughout SCons to identify file contents, build command lines, or to identify cached +build artefacts. Signatures are chained to determine if something needs to be re-built. .Target -any _node_ or ``build step'' encountered through the definition of the build is a _target_. The actual build +any _Node_ or ``build result'' encountered through the definition of the build is a _target_. The actual build will be triggered by requesting a target, which typically might be just an executable known to reside at some -location in the tree. Special _alias targets_ may be defined, based on other targets, to trigger off standard -build situations. Especially, a _default_ target may be defined. +location in the tree, or a _target directory_ where the build is assumed to place build results. +Special _alias targets_ may be defined, based on other targets, to set off standard +build sequences. Notably, a _default_ target can be defined for the build. '''' +.... +​ +​ +​ +.... + Organisation of the Lumiera SCons build --------------------------------------- -Within our build system, we build upon the power of the Python programming language to create abstractions -tailored to the needs of our project. Located in the `admin/scons` subdirectory, you'll find a collection +Within our build system, we leverage the power of the Python programming language to create abstractions +tailored to the needs of our project. Located in the 'admin/scons' subdirectory, you'll find a collection of Python modules to provide these building blocks. - the *LumieraEnvironment* is created as a subclass of the standard SCons build environment; it is - outfitted with pre-configured custom builders for executables, libraries, extension module, Lumiera plug-in - and icon resources. + outfitted with pre-configured custom builders for executables, libraries, extension modules, + Lumiera plug-ins and icon resources. - all these *custom builders* implement a set of conventions and directory locations within the tree. These are defined (and can be adjusted) in the *Setup.py* module. This way, each builder automatically places the generated artefacts at standard build and installation locations. @@ -89,15 +151,15 @@ Sub-trees ~~~~~~~~~ .the source tree All sourcecode of the core application resides below `src/`. Building these components is controlled by -the SConscript residing in this application source root. By convention, this is also the root for header +the SConscript located within this application source root. By convention, this is also the root for header includes -- _all headers should be included relative_ to `src/`. .the three layers Within this application core tree, there are sub-trees for the main layers comprising the application. Each of these sub-trees will be built into a shared library and then linked against the application framework -and common services residing in `src/common`. These common services in turn are also built into a shared +and common services residing in 'src/common'. These common services in turn are also built into a shared library `liblumieracommon.so`, as is the collection of helper classes and support facilities, known as -our 'support library' `liblumierasupport.so`. Besides, there is a sub-tree for core plug-ins and helper tools. +our `support library' `liblumierasupport.so`. Besides, there is a sub-tree for core plug-ins and helper tools. .the GTK Gui one of the sub-trees, residing in `src/stage` forms the _upper layer_ or _user-interaction layer_. Contrary to @@ -106,51 +168,68 @@ Thus, the GTK Gui is built and loaded as Lumiera a plug-in. .unit tests Since our development is test-driven, about half of the overall code can be found in unit- and integration -tests, residing below `test/`. There is a separate SConscript file, to define the various +tests, arranged below 'test/'. There is a separate SConscript file, to define the various link:{ldoc}/technical/infra/TestSupport.html[kinds of test artefacts] to be created. -- plain-C tests are defined in _test-collections_, grouped thematically into several subdirectories. - Here, each translation unit provides a separate +main()+ function and is linked into a stand-alone - executable (yet still linked against the appropriate shared libraries of the main application layers) -- the tests covering C++ components are organised into test-suites, residing in separate sub-trees. - Currently (as of 5/2015), we link each sub-tree into a shared test library. Here - individual translation units define individual test case classes. At the end, all these unit tests +- the tests to cover C++ components are organised into test-suites, residing in separate sub-trees. + Currently (as of 11/2025), we link each sub-tree into a shared test library. Here, individual + translation units define individual test case classes. At the end, all these test units are linked together with a testrunner `main()` into the `test-suite` executable. +- plain-C tests are defined in _test-collections_, grouped thematically into several subdirectories. + Here, each translation unit provides a separate `main()` function and is linked into a stand-alone + executable (yet still linked against the appropriate shared libraries of the main application layers) .research -There is a separate subtree for research and experiments. The rationale being to avoid re-building most -of the core application when it comes to experimenting and trying out new technologies. +There is a separate subtree for research and experiments. The rationale is to provide a simplified +and flexible dependency structure for investigating fundamental problems and to try out new technologies. +Notably there is a source file 'try.cpp', which is linked against all of the core libraries and is re-used +any time some language features need further investigation or when new implementation techniques are pioneered. .icons and resources -the +data/+ subtree holds resources, configuration files and icons for the GUI. Most of our icons -are defined as SVG graphics. The build process creates a helper executable (+rsvg_convert+) to render +the 'data/' subtree holds resources, configuration files and icons for the GUI. Most of our icons +are defined as SVG graphics. The build process creates a helper executable (`rsvg_convert`) to render these vector graphics with the help of lib Cairo into icon collections of various sizes. .documentation -Largely, the documentation is written in Asciidoc and provided online at link:{ldoc}[the documentation section] -of our website. The plain-text sources of this documentation tree is shipped alongside with the code. -Besides, we build *Doxygen* API documentation there, and we create design and technical specs and drawings -in SVG and in UML. +Largely, the documentation is written in Asciidoc and provided online in the link:{ldoc}/[documentation section] +of our website. The plain-text sources of this documentation tree are shipped alongside with the code. +Besides, we build *Doxygen* link:/doxy/[API documentation] there, and we create design and +technical specs and drawings in SVG and in UML. .the target directory This is where the results of the build process are created. Lumiera is organised into a -_self contained folder structure_. As long as the relative locations, as found within +target/+, +_self contained folder structure_. As long as the relative locations, as found within 'target/', are kept intact, the Application will be able to start up and find all its resources. Consequently, -there is no need to ``install'' Lumiera (and the ``install'' target just copies this folder structure -into the standard installation locations of a typical Unix system) +there is no need to ``install'' Lumiera -- in can always be launched from a package bundle placed +into some directory. In fact, the ``install'' target just copies this folder structure into the +standard installation locations in accordance with the Filesystem Hierarchy Standard for Unix systems -Unfortunately SCons is a bit weird regarding the object files created during the build process. -So, for the time being, we're just building in-tree. Apologies for that. +WARNING: Unfortunately SCons is a bit weird regarding the object files created during the build process. + So, for the time being, we're building in-tree. Apologies for that. + + [underline]#2025#: this aspect has been improved _upstream,_ yet we did not find the time + to rework our build system accordingly. Apologies for that... + +.installation +As described xref:_organisation_of_the_lumiera_scons_build[above], a custom environment +baseclass `LumieraEnvironment` is used to configure preconfigured builders, which always define +an installation target alongside with the build target. These installation targets are arranged +into a subtree with a _prefix,_ which is by default 'usr/local' -- following the conventions of +the Filesystem Hierarchy Standard. As long as you just build stuff, you won't notice these +installation targets, since by default they are located outside of the project tree. However, +by customising the build options `PREFIX` and `INSTALLDIR`, this installation tree can be relocated. +For example, our DEB package uses `PREFIX=usr INSTALLDIR=debian/lumiera` +(please note that such settings are cached in './optcache' and that +changing them causes a full rebuild) Invoking the Build ~~~~~~~~~~~~~~~~~~ -All of the build process is launched through the `scons` python script, usually installed into -`/usr/bin` when installing the SCons package onto the system. Just invoking +All of the build processing is launched through the `scons` python script, usually installed into +`/usr/bin` when installing the SCons package onto the system. And by just invoking scons -h -prints a summary of all custom options, targets and toggles defined for our build. +a summary of all custom options is printed, with targets and toggles defined for our build. Targets ^^^^^^^ @@ -162,15 +241,19 @@ Targets - *all* builds the Application, test-suites and documentation - *install* builds and installs the Lumiera Application -By convention, invoking `scons -c` will _clean up_ everything the given target _would_ build. +Cleaning +^^^^^^^^ +By convention, an invocation of `scons -c` will _clean up_ everything the given target _would_ build. Thus, invoking `scons -c /` is the most global clean operation: it will clean up al build artefacts and will un-install Lumiera (recall: every defined node, or directory is also a target). Configure checks ^^^^^^^^^^^^^^^^ -SCons does not support the concept of a separate ``configure'' step. The necessary dependency detection is -performed before each build. Currently, we expect _all dependencies to be installed first-class_ into -the system. We do not (yet) support custom libraries in strange locations. Please use your package manager. +By deliberate choice, SCons does not support the concept of a separate ``configure'' stage. +The necessary dependency detection is performed before each build, but with effective caching +of detected settings. Currently, we expect _all dependencies to be installed first-class_ into +the system. Custom packages can be installed at '/usr/local' -- however, we do not (yet) support +custom libraries in arbitrary locations, passed as configuration. Please use your package manager. Caching and MD5 sums ^^^^^^^^^^^^^^^^^^^^ @@ -191,3 +274,84 @@ We provide several custom configuration options (run `scons -h` to get a summary options are *sticky*: once set, the build system will recall them in a file '.optcache' and apply them the same way in subsequent builds. It is fine to edit '.optcache' with a text editor. + +Technical Details +~~~~~~~~~~~~~~~~~ +The following sections provide additional information helpful when adapting the build system. +It should be noted that the SCons scripts are _Python modules_, invoked within a special setup. +Python has a host of specific tweaks and kinks, notably regarding visibility, definition order, +imports and the use of standard data types like lists, dictionaries and generator functions. +Python knowledge is widespread nowadays, yet we had ample opportunity to notice that, for +people not familiar with the Python idiom, the SCons scripts may seem arcane and confusing. + +Invocation +^^^^^^^^^^ +After some basic checks of setup and the given command line, the SCons builder immediately +loads the 'SConstruct' as module -- and expects that this python DSL code builds a project +model data structure. The actual build is then driven by evaluating the dependency graph +as implied by that model. + +The individual 'SConscript' definitions for each subfolder must be activated explicitly +from the 'SConstruct', using the `SConscript(dirs=[...])` builder function. Note furthermore +that the order of the dirs mentioned in this invocation matters, since each 'SCconscript' +usually _imports_ some global variables at the beginning and _exports_ other settings +at the end. Before evaluating a 'SConscript', the working directory is changed. + +TIP: you can launch `scons` with a python debugger, using the Lumiera directory as + working location and set breakpoints in 'SConstruct' or in any of our custom + python modules to investigate problems with some build definition not taking effect + as expected. Inspect the dictionary of the `Environment` with the debugger to + find out what has actually been configured... + +Start-up sequence +^^^^^^^^^^^^^^^^^ +The Lumiera build system engages in a specific start-up sequence, which is explicitly +coded and expands beyond the standards of the SCons build system. + +- first we add our _tool directory_ below 'admin/scons' to the search path, + so that tools and python modules defined there become visible. + You _must familiarise yourself_ with the contents of this directory! +- next we create our custom root `LumieraEnvironment` instance, which is stored + and exported in the global variable `env`. This environment setup is done by + the python module 'admin/scons/Setup.py' +- this module has some module-level definitions for standard path locations, + and all these settings are imported into a dictionary and placed into the + member field `env.path` of the `LumieraEnvironment`. All our custom builders + use these central settings as shared configuration. +- once the base constructor of the SCons `Environment` class is invoked, + the command line is evaluated to populate the Construction Variables. +- next, the constructor of our custom `LumieraEnvironment` installs + our custom tools and builder functions. +- the last step in the start-up sequence is to invoke the `Platform.configure(env)` + function, which performs all the library and platform checks. This function + also configures the default compiler flags. + +Nested Build Environment +^^^^^^^^^^^^^^^^^^^^^^^^ +Several of the 'SConscript' in subdirectories will create a nested build environment, +which obviously derives from `LumieraEnvironment`. This way we can configure +additional link dependencies and build configurations for some subtrees, like +building the GUI against GTK or handling plug-in modules specifically. + +The custom ELF builders +^^^^^^^^^^^^^^^^^^^^^^^ +These custom builders like `env.Program`, `env.SharedLibrary`, `env.LoadableModule` +and `env.LumieraPlugin` are also defined in the `LumieraEnvironment.py` module. +All these classes inherit from the SCons `Environment` through the common baseclass +`WrappedStandardExeBuilder` -- which defines a special arrangement where an _install target_ +is always defined alongside the build target. This install target is ``dropped off'' as +a side-effect, while _the build target will be returned._ + +Composite targets +^^^^^^^^^^^^^^^^^ +In SCons, a builder returns a list of target nodes, and these can be passed in a flexible +way to further builders. At several places in our 'SConscript' definitions, we use +Python functions defined within that script to manipulate and aggregate such +target lists. Notably, specific sets of targets can be combined into a +shared object (dynamic library), which is then again a SCons target +and can be passed to other executable builders as library dependency +for compilation and linking. Look into 'src/SConscript' or 'test/SConscript' +to see examples of that technique -- which we also use to define that +global compound target variables like `core`, `app_lib`, `core_lib`, +`vault_lib`, and `support_lib`. These in turn are essential for +building the layered dependency hierarchy in our code. diff --git a/doc/technical/build/index.txt b/doc/technical/build/index.txt index a6a2437b8..cd8ef9424 100644 --- a/doc/technical/build/index.txt +++ b/doc/technical/build/index.txt @@ -8,12 +8,11 @@ As work progresses, we will add more information on the Lumiera build system. //Menu: prepend child 'SCons' -build -- continuous integration -- packaging +Topics: build -- continuous integration -- packaging -* link:SCons.html[Buildsystem] +* link:SCons.html[SCons Buildsystem] * link:BuildDependencies.html[Lumiera Build Dependencies] -* link:BuildDroneDraft.html[»Builddrone« concept from 2008] -* Packaging: link:LumieraDebianPackage.html[Debian] RPM -* Lumiera link:../infra/debianDepot.html/[debian depot] +* Packaging: link:LumieraDebianPackage.html[Debian] (⌛ RPM) +* Lumiera link:{ldoc}/technical/infra/debianDepot.html[debian depot] diff --git a/doc/technical/code/CodingGuidelines.txt b/doc/technical/code/CodingGuidelines.txt index f63b96361..c399c91ab 100644 --- a/doc/technical/code/CodingGuidelines.txt +++ b/doc/technical/code/CodingGuidelines.txt @@ -52,9 +52,11 @@ The Lumiera project uses GNU indentation style with slight adaptations. beyond just a short list of names -- especially when including initialisers -- they are preferably written on a separate line, directly above the argument list in parenthesis * the opening brace of namespaces is placed on the same line. Optionally, the namespace - body may be indented, as long as this helps underpinning the nesting structure. But - there is no need to use 3 indents on a 3 level nested namespace. One level is enough - to highlight the presence of a nesting. + body may be indented (by one half-indent), as long as this helps underpinning the + nesting structure. But there is no need to use three indents on a 3-level deep + nested namespace. One step is enough to highlight the presence of a nesting. + Effectively this implies that the majority of code is set apart from the + left border by two spaces. - the shorthand type names `uint`, `ulong`, `uchar`, `short`, `ushort`, `llong`, `ullong` are preferred, as it is clearer to write the fundamental type in a single word. Index @@ -71,12 +73,12 @@ The Lumiera project uses GNU indentation style with slight adaptations. to define a type alias for the _function signature_ first. - in a similar vein, we distinguish between an ```const object`'' which _is really in-itself_ unmodifiable, as opposed to _taking a const-reference,_ which is always spelled out - post-fix as `object const&`, or a constant-pointer spelled as `const*`. + post-fix as `SomeType const&`, or a constant-pointer spelled as `SomeType const*`. - we use the textual form of the boolean operators `and`, `or` and `not`, because this allows to make the code resemble complete meaningful sentences in human language. We _do use_ the »line noise« variant however for all low-level bit manipulation, `&`,`|`, `^`, sometimes also for `!` -- using those is taken as an indication of - entering the ``danger zone''... + having entered the ``danger zone''... Spelling @@ -133,7 +135,7 @@ General Code Arrangement and Layout code size. Avoid unnecessary includes. Use forward declarations where applicable. Yet still, _all immediately required direct dependencies should be mentioned_, even if already included by another dependency. See the extensive discussion of these - link:{ldoc}/technical/code/linkingStructure.html#_imports_and_import_order[issues of code organisation] + link:{ldoc}/technical/code/LinkingStructure.html#_imports_and_import_order[issues of code organisation] - The include block starts with our own dependencies, followed by a second block with the library dependencies. After that, optionally some symbols may be brought into scope (through +using+ clauses). Avoid cluttering top-level namespaces. Never import full namespaces.footnote:[No `using namespace gtk;` diff --git a/doc/technical/code/GitBranching.txt b/doc/technical/code/GitBranching.txt index aee0135d0..9d565c33d 100644 --- a/doc/technical/code/GitBranching.txt +++ b/doc/technical/code/GitBranching.txt @@ -16,7 +16,7 @@ releases and bugfixes directly as structure in the Git history, without much nee release planning, coordination and management. TIP: The principles and procedures of *Git-flow* are explained in this - ->{nbsp}{l}/project/background/GitFlow.html[Background Article]. First + -> link:/project/background/GitFlow.html[Background Article]. First link:https://nvie.com/posts/a-successful-git-branching-model/[published in 2010] by _Vincent Driessen_, meanwhile it is widely applied in projects with regular releases and external liabilities -- and often seen as the counterpoint to trunk centred @@ -32,6 +32,11 @@ extended line into their _personal repository._ However, the _normative state_ o is represented by the link:https://git.lumiera.org/gitweb?p=LUMIERA[»Lumiera Repository«] `git://git.lumiera.org/LUMIERA` +*************************************************** +image:{img}/pub/GitFlow-branches.svg[ +"Illustration Git-flow branching pattern"] +*************************************************** + The Core Developer(s) can _push_ to this repository, thereby acting as _Gateway._ Automated builds will listen to this repository, and any further _downstream processes,_ like e.g. packaging, are always based on this state. What is described in the following sections however is a diff --git a/doc/technical/code/LinkingStructure.txt b/doc/technical/code/LinkingStructure.txt index 54e3c8971..c1ab3700a 100644 --- a/doc/technical/code/LinkingStructure.txt +++ b/doc/technical/code/LinkingStructure.txt @@ -351,7 +351,7 @@ actively step by step Gui.resourcepath:: the place where the GTK-UI looks for further resources, most notably... Gui.stylesheet:: the name of the CSS-stylesheet for GTK-3, which defines the - application specific look, link:{ldoc}/technical/stage/style[styling and theme]. + application specific look, link:{ldoc}/technical/stage/style/[styling and theme]. While the first two steps, the relative locations `$ORIGIN/modules` and `$ORIGIN/setup.ini` are hard-wired, the further resolution steps rely on the contents of 'setup.ini' and are @@ -426,8 +426,8 @@ https://wiki.debian.org/RpathIssue[this Debian page] ] -- with the exception of intended for usage by the given executable or other libraries within the same source package. In the new system, the precedence order is as follows footnote:[see -http://linux.die.net/man/8/ld.so[ld.so manpage on die.net] or -http://manpages.ubuntu.com/manpages/lucid/man8/ld.so.8.html[ld.so manpage ubuntu.com (more recent)] ] +https://linux.die.net/man/8/ld.so[ld.so manpage on die.net] or +https://manpages.ubuntu.com/manpages/jammy/man8/ld.so.8.html[ld.so manpage ubuntu.com (more recent)] ] . `LD_LIBRARY_PATH` entries, unless the executable is `setuid`/`setgid` . `DT_RUNPATH` from the `.dynamic` section of that ELF binary, library or executable @@ -444,9 +444,9 @@ NOTE: The new-style `DT_RUNPATH` is not extended recursively when resolving tran visit _only_ the `RUNPATH` given in 'libB.so', but _not_ the `RUNPATH` given in 'libA.so' (to the contrary, the old `RPATH` used to visit all these locations). + This behaviour was chosen deliberately, in compliance with the ELF spec, as can be seen in this - link:https://sourceware.org/bugzilla/show_bug.cgi?id=13945[glibc bug #13945] and the + https://sourceware.org/bugzilla/show_bug.cgi?id=13945[glibc bug #13945] and the developer comment by - link:https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html[Roland McGrath from 2002] + https://sourceware.org/legacy-ml/libc-hacker/2002-11/msg00011.html[Roland McGrath from 2002] mentioned therein. diff --git a/doc/technical/code/c++11.txt b/doc/technical/code/c++11.txt index 50755c1ae..d6f59a47b 100644 --- a/doc/technical/code/c++11.txt +++ b/doc/technical/code/c++11.txt @@ -225,6 +225,11 @@ February 2020:: * still running into problems with perfect forwarding in combination with overload resolution; not clear if this is a shortcoming of current compilers, or the current shape of the language +May 2025:: + We did the big leap and are now on C\+\+23, with Debian/Trixie as the »reference system«. + The new language features, notably the **Concepts** will be adopted gradually and we + will certainly have to face some new challenges... + @@ -321,3 +326,4 @@ impose some challenging effort to retrofit existing structures. much cleaner and high-level than most ``mainstream'' usage of other common build systems out there.footnote:[ ``hello CMake'', ``hello Autotools'', anyone else? Meson, Ninja? Maven? should maybe consider a switch to WAF?] +NOTE: in May 2025, we achieved that switch and require now C\+\+23 and at least GCC-14. diff --git a/doc/technical/code/index.txt b/doc/technical/code/index.txt index eaaffa3e4..30161021e 100644 --- a/doc/technical/code/index.txt +++ b/doc/technical/code/index.txt @@ -7,46 +7,53 @@ Code Base Organisation //Menu: put child GitBranching after LinkingStructure -This section of Lumiera's technical documentation deals with the code base as such, -not so much with the internals of the Lumiera application. It is targeted towards -people participating in Lumiera development. +This section of the Lumiera technical documentation deals with the code base itself, +and is less concerned with the internals of the Lumiera application. It is primarily +aimed at people who want to participate in Lumiera development. -The Lumiera source base is huge and expected to grow for some time to come. Just -judging by the _lines of code_, Lumiera can be considered as a *medium sized system*, -which gives us some hints towards the adequate practices, conventions and the -degree of formalism to apply. +The Lumiera source base is huge already, and expected to grow for some time to come. +Judging based on the _lines of code_ metric, Lumiera can be considered a +*medium sized system* -- which gives us some hints towards the adequate practices, +conventions and the degree of formalism to apply. Generally speaking, a *small system* doesn't exceed the mental capacity of a single -knowledgeable human. A single person can know everything and understand everything -in such a code base. Thus, any formalism and organisational overhead is detrimental; -we're best off doing away with ``Methods'' and just rely on taste and craftsmanship. +knowledgeable human person. A single developer can reasonably know everything and +understand everything in such a code base. Thus, any further formalism and organisational +overhead is detrimental; we're best off doing away with any kind of ``Method'' and just +rely on our taste and craftsmanship. -But there is a hard limit for this approach, kind of a _sonic wall_ -- usually somewhere -around a size of 60000 LoC. At that point, the adequate value system flips around as a -whole. Since beyond that point, no single person can understand and know everything about -such a system, _communication and understanding become the primary concerns_ of the -development process. Suddenly, we _do need_ some organisation, some rituals and -a methodical approach. Yet still we don't need a high degree of formalism, since -at least we can easily _know and recall everyone involved_. +Yet this approach reaches a hard limit, a kind of sonic barrier -- usually somewhere +at a size of about 60000 LoC. From this point on, the appropriate value system is +completely reversed: since no single person can _understand and know everything_ about +such a system, _communication and understanding become the primary concerns_ +of the development process. Suddenly, we _do need_ some organisation, some rituals +and a methodical approach. Yet still we don't need a high degree of formalism -- +as long as we can at least easily _know and recall everyone involved_. -To give a delineation to the other side, a constantly growing project might eventually +To create a distinction from the other side, a constantly growing project might eventually reach the point where the actual coding of new functionality makes up less than 25% -of the overall work required. More people might be involved than anyone can recall or -overlook reasonably. A code size of 1 Million LoC seems to exceed any kind of sufficiently +of the overall work required. More people might be involved than anyone can reasonably +recall or survey. A code size of 1 Million LoC seems to exceed any kind of sufficiently precise imagination. From that point on, a rigorously formalised organisation is vital to keep such a *large scale project* from floundering. -//// Conventions ----------- -_to be written_ +- link:/project/legal/legal.html[Lumiera is **Free Software**] (GPL-2+) +- link:CodingGuidelines.html[Lumiera code uses]: *GNU style*, 4-space indent, CamelCase and British spelling +- link:GitBranching.html[Branches and Releases] are organised according to *Git-flow* +//// Guidelines ---------- //// '''' - * also see the link:{ldoc}/devel/rfc.html[Design Process] for ongoing discussions +[TIP] +-- + * link:{ldoc}/devel/meeting_summary/index.html[Developers Meetings] and protocols + * also see the link:/x/DesignProcess.html[Design Process] for ongoing discussions * see the link:/devs-vault/[Developers Vault] for frequently used developer's resources +-- diff --git a/doc/technical/howto/DebugGdbPretty.txt b/doc/technical/howto/DebugGdbPretty.txt index f26d09315..9f10f5661 100644 --- a/doc/technical/howto/DebugGdbPretty.txt +++ b/doc/technical/howto/DebugGdbPretty.txt @@ -38,7 +38,7 @@ from libstdcxx.v6.printers import register_libstdcxx_printers register_libstdcxx_printers (None) end ---- -For more informations link:http://sourceware.org/gdb/wiki/STLSupport[see here..] +For more informations https://sourceware.org/gdb/wiki/STLSupport[see here..] .Hello World [source,C] diff --git a/doc/technical/howto/UsingBoost.txt b/doc/technical/howto/UsingBoost.txt index 6e68963c8..76a06869b 100644 --- a/doc/technical/howto/UsingBoost.txt +++ b/doc/technical/howto/UsingBoost.txt @@ -3,7 +3,7 @@ Using Boost Libraries //Menu: label using Boost -_some arbitrary hints and notes regarding the use of link::http://www.boost.org[Boost Libraries] in Lumiera_ +_some arbitrary hints and notes regarding the use of https://www.boost.org/[Boost Libraries] in Lumiera_ Notable Features ---------------- diff --git a/doc/technical/howto/index.txt b/doc/technical/howto/index.txt index 6a32b998f..0f06aaf60 100644 --- a/doc/technical/howto/index.txt +++ b/doc/technical/howto/index.txt @@ -8,12 +8,14 @@ Developer HOWTOs This section contains a loose collection of instructions, recipes, tutorials and similar usefull pieces of information targeted at Lumiera developers. See also -- the general link:{l}/project/faq.html[Lumiera FAQ] +- the general link:/project/faq.html[Lumiera FAQ] - the link:{ldoc}/user/index.html[User documentation] - link::{ldoc}/technical/code/index.html[Codebase organisation] == Notepad - a link:crackNuts.html[collection] of solution ideas - link:DebugGdbPretty.html[Python pretty printers for GDB] +- link:IdeSetup.html[hints for using some IDE(s)] +- link:UsingBoost.html[some remarks regarding libBoost] - link:HashFunctions.html[Notes regarding standard hash functions] diff --git a/doc/technical/index.txt b/doc/technical/index.txt index aa1452023..f3ace95bd 100644 --- a/doc/technical/index.txt +++ b/doc/technical/index.txt @@ -17,7 +17,7 @@ link:overview.html[Lumiera the Inner Core] The technical documentation is split in three parts, one for each of the three main layers of Lumiera. You may want to read the -link:../design/index.html[Design Documents] first to get an overview of all the +link:{ldoc}/design/index.html[Design Documents] first to get an overview of all the components. * link:stage/index.html[*Stage Layer*] : Documents related to the GTK based Lumiera GUI @@ -30,13 +30,13 @@ components. == Tools .Development -* link:http://www.lumiera.org/doxy/[*Doxygen generated documentation*] : API documentation of the Lumiera code. +* link:/doxy/[*Doxygen* generated documentation] : API documentation of the Lumiera code. * organisation of the link:code/index.html[Code Base] in general -* link:code/codingGuidelines.html[Coding Style] and further guidelines +* link:/x/CodingGuidelines.html[Coding Style] and further guidelines .Building -* link:build/index.html[*Buildsystem*] : Installation & compilation tools, dependencies and packaging. +* link:build/index.html[Buildsystem] : Installation & compilation tools, dependencies and packaging. .HOWTO -* link:howto/index.html[*Developer HOWTOs*] : Collection of instructions, recipes, hints and similar +* link:/x/DevHowto.html[Developer *HOWTOs*] : Collection of instructions, recipes, hints and similar materials intended for developers diff --git a/doc/technical/infra/MenuGen.txt b/doc/technical/infra/MenuGen.txt index baa6b6f88..82523c07b 100644 --- a/doc/technical/infra/MenuGen.txt +++ b/doc/technical/infra/MenuGen.txt @@ -178,27 +178,27 @@ supported placement directives -[options="header", width="70%",cols="^m,) -- discover `id.txt` -- create new node or retrieve existing node - linkChild(id) basic function for attaching child node - linkParent(id) basic function to attach below parent - putChildLast(id) [attach] child move child to current end of list - appendChild(id) [append] child - putChildFirst(id) move child to current list start - prependChild(id) prepend [child] - putChildAfter(id,ref) [attach|put] child after move child after the given ref entry - link(url[,id][,label]) [child ] link ::[

+ Entwerfe auf theoretischer Ebene ein schlüssiges Konzept, wähle aber zugleich einen Zugang der dieses von den Fundementen her aufrollt +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ siehe Blender! +

+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ In der Tat, daran kann ich mich erinnern, Wouter hat diese naheliegende Konsequenz sofort gesehen. Das sollte in die Zusammenfassung rein +

+ + +
+ +
+ + + + + + + + + + + + + + + + + + + + + +
You might want to rephrase "We also do not support translations that require a re-ordering of the UI" to something like "As of now, we have no plans to support translations that require... ", just to indicate that you're not opposed to the idea itself.
+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
I've also watched your FrOSCon presentation last week. Very interesting topic and well presented! I enjoyed watching it and learned a few things about GPU's and Linux that I had no clue about.
+ + +
+ +
+
+
+
+ + + + + + + +

+ Vorschlag von mir mit möglichen Themen... +

+ + +
+ +
+ + +
+ + + + + + + + + + + + + + + +

+ ich sehe das als Günstige Gelegenheit +

+ +
+ + + + + +

+ derzeit (2025) konzentriere ich die Arbeit auf die Integration der Kern-Applikation +

+ +
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Commands operate at a current position +

+ + +
+
+ + + + + + +

+ commands establish parameters and qualifications from current context and previous use +

+ + +
+
+ + + + + + +

+ parameters and qualifications can be adjusted immediately +

+ + +
+
+ + + + + + +

+ Every command structure must map-down to common mouse-based handling standards; however, this down-grade can involve using specific bindings and profiles +

+ + +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Mail-Thread "Workflow and Structure" +

+ +
+ +
+ + + + +

+ Mail-Thread "Workflow document update" +

+ +
+ +
+ + + + + + +

+ Mail-Thread "Workflow document update", direkt nach unserem Treffen auf der FrOSCon +

+ + +
+ + + + + + + + +

+ minimale Abweichungen: Wouter hat das Handle der Overlay-Bar schmaler gemacht +

+ + +
+ +
+ + + + + + +

+ das Bild hatte ich lediglich stärker komprimiert, um Platz zu sparen +

+ + +
+ +
+ + + + + + +

+ hier hat Wouter einen neuen Screenshot gemacht (vermutlich war im alten Screenshot die Position des Cursors falsch) +

+ + +
+ +
+
+
+
+ + + + + + + + + + + + + + + + + + + +

+ desen Bilder liegen im Website-Repository +

+ +
+ + + +

+ {imgg} = /media/img/design.gui +

+ +
+
+ + + + + + + + + +

+ Noch vor der ersten wirklichen Veröffentlichung, so daß die Bilder sich nicht im Core-Git niederschlagen. +

+ +
+ + + + + + +

+ In v1 hatte Wouter Bilder in kleinerer Auflösung eingebaut, die auch noch manuell in Gimp beschnitten werden mußten; jetzt könnte ich diese allesamt durch die besseren Bilder aus v2 substituieren (und damit ein paar 110k Storage sparen) +

+ +
+ +
+ + + + +

+ In design/gui/GuiDiscussion/TimelineDiscussion.txt ... der zeigt immer noch auf eine externe Adresse +

+ +
+ +
+
+
+ + + + + + +

+ überprüft, das gilt für alle (es sind bisher nur ganz wenige, in den GUI-Proposals); ich hatte mich einfach darum nie gekümmert +

+
    +
  • + design/gui/GuiDiscussion/ConceptProposals/RichardSpindler.txt +
  • +
  • + design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt +
  • +
  • + design/gui/GuiDiscussion/ConceptProposals/AkhiL.txt +
  • +
  • + design/gui/GuiDiscussion/TimelineDiscussion.txt +
  • +
  • + design/workflow/Verwijlen/WorkflowProposals.txt +
  • +
+ +
+
+ + + + +

+ Zeile 297: +

+

+ +

+

+ /* -------- Image -------- */ +

+

+ span.image img { +

+

+     border-style: none; +

+

+ } +

+

+ +

+

+ div.imageblock img { +

+

+     padding-left: 13%;  +

+

+     border: 0px solid silver; +

+

+ } +

+ +
+ + + + +

+ commit 694ade36042c420efdeface2c80c0906ea3f5fa6 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Mon Feb 21 01:38:15 2011 +0100 +

+

+ +

+

+     small CSS tweaks/fixes +

+

+ +

+

+ +

+

+ commit ed7a397aecb0c5b3b284663bb09e08494adb087d +

+

+ Author: raffa <raffaella.traniello@livecom.it> +

+

+ Date:   Sun May 25 17:51:31 2008 +0200 +

+

+ +

+

+     Added tools for building a web page with asciidoc +

+ +
+
+ + + + +

+ commit 8ee898954a38d9d68ef6fac0a93ceb5ffa587a6e +

+

+ Author: raffa <raffaella.traniello@livecom.it> +

+

+ Date:   Sat Jan 3 18:41:09 2009 +0100 +

+

+ +

+

+     Added 13% padding to images +

+ +
+ + + + +
+ + + + +

+ ...denn diese würden eine Angabe direkt im <img...>-Tag übersteuern — und damit gäbe es keine Möglichkeit mehr, direkt aus dem Asciidoc heraus das Layout von Bildern zu steuern +

+ +
+ +
+
+
+
+
+
+ diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 6147644af..7f0e3c9dc 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -36349,6 +36349,10 @@
+ + + + @@ -130540,9 +130544,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + - + @@ -130557,6 +130562,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + @@ -130592,7 +130601,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -130602,12 +130611,518 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + + + + + + + + + + + +

+ wenn man beispielsweise zwar einen XV_COLORKEY setzen kann, aber kein XV_AUTOPAINT_COLORKEY +

+ +
+
+ + + + +
+
+ + + + + + + + + + + + + + + + + +

+ ...dann kann ich das ganze Fenster füllen, durchaus auch mit beliebigen Farben (wobei hier eine Falle wartet, da die Farbtiefe unterschiedlich sein könnte). +

+ +
+ + + + +

+ dixplay_x11.c, line 623 +

+

+ +

+
+
+

+ static inline void  xv_draw_colorkey(void) { +

+

+ XSetForeground( xj_dpy, xj_gc,  0 ); +

+

+ if (xj_box[1] >  0 ) { +

+

+ XFillRectangle( xj_dpy, xj_win,  xj_gc, 0, 0,  xj_box[2], xj_box[1]); +

+

+ XFillRectangle( xj_dpy, xj_win,  xj_gc, 0, xj_box[1]+xj_box[3],  xj_box[2], xj_box[1]+xj_box[3]+xj_box[1]); +

+

+ } /* else */ +

+

+ if (xj_box[0] >  0 ) { +

+

+ XFillRectangle( xj_dpy, xj_win,  xj_gc, 0, 0,  xj_box[0], xj_box[3]); +

+

+ XFillRectangle( xj_dpy, xj_win,  xj_gc, xj_box[0]+xj_box[2],  0, xj_box[0]+xj_box[2]+xj_box[0],  xj_box[3]); +

+

+ } +

+

+ } +

+

+ +

+
+
+

+ +

+

+ ... verwende dann in XSetForeground ggfs eine andere Farbe, wie 0x00FF00 für Grün +

+ +
+ +
+ + + + + + + + + + + + + + + + + +

+     number of attributes: 7 +

+

+       "XV_SET_DEFAULTS" (range 0 to 0) +

+

+               client settable attribute +

+

+       "XV_ITURBT_709" (range 0 to 1) +

+

+               client settable attribute +

+

+               client gettable attribute (current value is 0) +

+

+       "XV_SYNC_TO_VBLANK" (range 0 to 1) +

+

+               client settable attribute +

+

+               client gettable attribute (current value is 1) +

+

+       "XV_BRIGHTNESS" (range -1000 to 1000) +

+

+               client settable attribute +

+

+               client gettable attribute (current value is 0) +

+

+       "XV_CONTRAST" (range -1000 to 1000) +

+

+               client settable attribute +

+

+               client gettable attribute (current value is 0) +

+

+       "XV_SATURATION" (range -1000 to 1000) +

+

+               client settable attribute +

+

+               client gettable attribute (current value is 0) +

+

+       "XV_HUE" (range -1000 to 1000) +

+

+               client settable attribute +

+

+               client gettable attribute (current value is 0) +

+

+     maximum XvImage size: 16384 x 16384 +

+

+     Number of image formats: 4 +

+

+       id: 0x32595559 (YUY2) +

+

+         guid: 59555932-0000-0010-8000-00aa00389b71 +

+

+         bits per pixel: 16 +

+

+         number of planes: 1 +

+

+         type: YUV (packed) +

+

+       id: 0x32315659 (YV12) +

+

+         guid: 59563132-0000-0010-8000-00aa00389b71 +

+

+         bits per pixel: 12 +

+

+         number of planes: 3 +

+

+         type: YUV (planar) +

+

+       id: 0x59565955 (UYVY) +

+

+         guid: 55595659-0000-0010-8000-00aa00389b71 +

+

+         bits per pixel: 16 +

+

+         number of planes: 1 +

+

+         type: YUV (packed) +

+

+       id: 0x30323449 (I420) +

+

+         guid: 49343230-0000-0010-8000-00aa00389b71 +

+

+         bits per pixel: 12 +

+

+         number of planes: 3 +

+

+         type: YUV (planar) +

+ +
+
+ + + + +

+ number of attributes: 5 +

+

+ "XV_COLORKEY" (range 0 to 16777215) +

+

+ client settable attribute +

+

+ client gettable attribute (current value is 2110) +

+

+ "XV_BRIGHTNESS" (range -128 to 127) +

+

+ client settable attribute +

+

+ client gettable attribute (current value is 0) +

+

+ "XV_CONTRAST" (range 0 to 255) +

+

+ client settable attribute +

+

+ client gettable attribute (current value is 128) +

+

+ "XV_SATURATION" (range 0 to 255) +

+

+ client settable attribute +

+

+ client gettable attribute (current value is 128) +

+

+ "XV_HUE" (range -180 to 180) +

+

+ client settable attribute +

+

+ client gettable attribute (current value is 0) +

+

+ maximum XvImage size: 1024 x 1024 +

+

+ Number of image formats: 7 +

+

+ id: 0x32595559 (YUY2) +

+

+ guid: 59555932-0000-0010-8000-00aa00389b71 +

+

+ bits per pixel: 16 +

+

+ number of planes: 1 +

+

+ type: YUV (packed) +

+

+ id: 0x32315659 (YV12) +

+

+ guid: 59563132-0000-0010-8000-00aa00389b71 +

+

+ bits per pixel: 12 +

+

+ number of planes: 3 +

+

+ type: YUV (planar) +

+

+ id: 0x30323449 (I420) +

+

+ guid: 49343230-0000-0010-8000-00aa00389b71 +

+

+ bits per pixel: 12 +

+

+ number of planes: 3 +

+

+ type: YUV (planar) +

+

+ id: 0x36315652 (RV16) +

+

+ guid: 52563135-0000-0000-0000-000000000000 +

+

+ bits per pixel: 16 +

+

+ number of planes: 1 +

+

+ type: RGB (packed) +

+

+ depth: 0 +

+

+ red, green, blue masks: 0x1f, 0x3e0, 0x7c00 +

+

+ id: 0x35315652 (RV15) +

+

+ guid: 52563136-0000-0000-0000-000000000000 +

+

+ bits per pixel: 16 +

+

+ number of planes: 1 +

+

+ type: RGB (packed) +

+

+ depth: 0 +

+

+ red, green, blue masks: 0x1f, 0x7e0, 0xf800 +

+

+ id: 0x31313259 (Y211) +

+

+ 222 +

+

+ guid: 59323131-0000-0010-8000-00aa00389b71 +

+

+ bits per pixel: 6 +

+

+ number of planes: 3 +

+

+ type: YUV (packed) +

+

+ id: 0x0 +

+

+ guid: 00000000-0000-0000-0000-000000000000 +

+

+ bits per pixel: 0 +

+

+ number of planes: 0 +

+

+ type: RGB (packed) +

+

+ depth: 1 +

+

+ red, green, blue masks: 0x0, 0x0, 0x0 +

+ +
+
+
+
+ + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...was aber normalerweise passiert bei der Behandlung des »Expose«-Events von X +

+ +
+
+ + + + + + +
@@ -130617,7 +131132,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -130641,7 +131156,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -130819,7 +131334,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + @@ -130866,6 +131382,32 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + + + + + + + + + + + +

+ Es ist ein sehr alter Standard, durchaus komplex und detailiertere Doku ist kaum noch zu finden (-> Einzelfragen auf Stackoverflow). Manpages sind, wie üblich, nur dann sinnvoll, wenn man schon weiß, worum es geht). Hinzu kommt, daß es wohl erhebliche Streubreite gibt bzgl. der Implementierung. »Beispielsweise« unterstützt meine uralt-Nvidia-Karte nicht das automatische Keying (Attribut XV_COLORKEY und XV_AUTOPAINT_COLORKEY sind nicht definiert, aber der X-Treiber macht ein Auto-Keying auf dem gesamten X-Window und das ist problematisch mit den Dockingpanels, die das gleiche XWindow verwenden) +

+ +
+ + +
@@ -151771,7 +152313,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -152023,8 +152565,22 @@ std::cout << tmpl.render({"what", "World"}) << s - + + + + + +

+ was ich hier angebe, ist eine Grenz-Version; viele der Unterseiten wurden schon länger nicht geändert, und der letzte Capture in Archive.org liegt schon mehrere Jahre zurück; daher wird dann die nächst-neuere Version geliefert, die typischerweise aus 2021 stammt und bereits auf GTK-4 bezogen ist +

+ +
+ +
+ + +
@@ -153199,7 +153755,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -153229,6 +153785,101 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + + +

+ #include <gtkmm.h> +

+

+ #include <iostream> +

+

+ +

+

+ class MyApp +

+

+   : public Gtk::Application +

+

+   { +

+

+   protected: +

+

+     // install into the default startup handler +

+

+     void +

+

+     on_startup()  override +

+

+       { +

+

+         Gtk::Application::on_startup (); +

+

+         Glib::signal_timeout ().connect (sigc::ptr_fun (&MyApp::on_timeout), 1000); +

+

+       } +

+

+     +

+

+     static bool +

+

+     on_timeout() +

+

+       { +

+

+         std::cout << "Periodic task executed" << std::endl; +

+

+         return true; // Return true to continue calling this function +

+

+       } +

+

+   }; +

+

+ +

+

+ int main (int argc, char *argv[]) +

+

+   { +

+

+     auto app = MyApp::create (); +

+

+     return app->run (argc, argv); +

+

+   } +

+ +
+ + +
+
@@ -155656,6 +156307,15 @@ std::cout << tmpl.render({"what", "World"}) << s
+ + + + + + + + +
@@ -156308,7 +156968,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -158867,8 +159527,81 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + + + @@ -158940,7 +159673,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -158978,6 +159711,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + @@ -158987,7 +159726,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -158997,10 +159736,58 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + + + + + + + +

+ {date} : eine lokale Konvention nur für Lumiera +

+ +
+ + + +

+ ...einfach weil wir dieses Attribut explizit in unserer page.conf verwenden — und wenn es nicht definiert ist, fällt die ganze Zeile mit dem umschließenden <span>-Element weg! +

+ +
+ +
+
+ + + + + + + + + +
- + @@ -159146,7 +159933,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -159562,6 +160349,71 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + +

+ in Debian: linkchecker +

+ +
+
+ + + + +
    +
  • + man verwendet eine lokale Instanz der Website (mit einem micro-httpd) +
  • +
  • + man excluded Lumiera.org und läßt externe URLs checken +
  • +
+

+ +

+

+ Beispielaufruf: +

+

+ linkchecker http://localhost:8888/ --check-extern --timeout=30 --ignore-url='.*lumiera.org' +

+ +
+ +
+
+ + + + + + + + + + + + +

+ Vorsicht mit dem user agent +

+ +
+
+ + +
+
+ + +
@@ -159646,9 +160498,21 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + + +

+ Für Lumiera habe ich das letztlich so gemacht, und ich halte es für sinnvoll, denn so ist in debian/rules unmittelbar ersichtlich, wie konfiguriert wird ... generell sind implizite Default-Regeln nur dann sinnvoll, wenn der Default einfach und allgegenwärtig ist +

+ +
+ +
@@ -159668,6 +160532,42 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
+ + + + + + +

+ ...wie .svn, .git, Autotools-Müll... +

+

+ Man sieht den Default mit dpkg-source --help +

+

+   -i, --diff-ignore[=<regex>] +

+

+                            filter out files to ignore diffs of +

+

+                              (defaults to: '(?:^|/).*~$|(?:^|/)\.#.*$|(?:^|/)\..*\.sw.$|(?:^|/),,.*(?:$|/.*$)|(?:^|/)(?:DEADJOE|\.arch-inventory|\.(?:bzr|cvs|hg|git|mtn-)ignore)$|(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg(?:tags|sigs)?|_darcs|\.git(?:attributes|modules|review)?|\.mailmap|\.shelf|_MTN|\.be|\.bzr(?:\.backup|tags)?)(?:$|/.*$)'). +

+

+   -I, --tar-ignore[=<pattern>] +

+

+                            filter out files when building tarballs +

+

+                              (defaults to: -I*.a -I*.la -I*.o -I*.so -I.*.sw? -I*/*~ -I,,* -I.[#~]* -I.arch-ids -I.arch-inventory -I.be -I.bzr -I.bzr.backup -I.bzr.tags -I.bzrignore -I.cvsignore -I.deps -I.git -I.gitattributes -I.gitignore -I.gitmodules -I.gitreview -I.hg -I.hgignore -I.hgsigs -I.hgtags -I.mailmap -I.mtn-ignore -I.shelf -I.svn -ICVS -IDEADJOE -IRCS -I_MTN -I_darcs -I{arch}). +

+ +
+ +
+ +
@@ -159708,9 +160608,35 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
+ + + + + + + + + + + + + + +

+ wichtiger Hinweis: OpenColorIO LUT statt ICC-Profilen  verwenden! +

+ +
+
+
+
+ + +
+
- + @@ -159723,7 +160649,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -159774,6 +160700,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + @@ -159791,13 +160721,36 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + + + + +

+ ...er ist inzwischen sehr tief in Ardour eingestiegen; xjadeo hat er schon „viele Jahre nicht mehr angeschaut“ — da hatte er vor langer Zeit mal beim konsolidieren geholfen; viel von dem Wissen ist dann in Ardour's video-Anzeige in der Timeline eingeflossen. +

+

+ +

+

+ Nach dem letzten Event, im »le Sucre« an der confluence  von Rhône und Saône, sind dann Frank Neumeier, ich, Robin und Jörg Nettingsmeyer zusammen spät nachts quer durch Lyon zurück ins Hotel gewandert +

+ +
+
+
- + + + + @@ -159809,6 +160762,14 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + @@ -159822,6 +160783,187 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + + + +

+ Das ist der virale Mechanismus. +

+

+ Er gilt nicht für die Hinzufügungen allein, denn diese können auch sonstwie unter beliebigen Bedingungen lizenziert werden (das heißt, man verliert nicht sein Copyright an seinem eigenen Werk, aber man erwirbt auch keine Rechte an den Werken andere Leute, jenseits dieser LIzenz) +

+ +
+ +
+ + + + + + +

+ ...schließt den Fall ein daß man lediglich ein Compilat bereitstellt (auch das gilt als abgeleitetes Werk) +

+ +
+ + + + +

+ im Besonderen: klarstellen daß das Werk unter diese Lizenz fällt +

+ +
+
+ + + + +

+ Hier gibt es diverse Varianten in der Lizenz, denn die Software kann auch Teil eines Produktes sein, sogar Teil einer Hardware. In diesem Fall muß ein Service für mindestens 3 Jahre geboten werden (oder so lange wie man Wartung und Reparatur bietet), über den man erfahren kann, wie man an den Quellcode kommt. Der Quellcode kann auch duch jemand Anderes bereitgestellt werden, aber man selber hat sicherzustellen, daß dies der Fall ist, solange man das Produkt anbietet oder wartet +

+ +
+
+
+
+
+ + + + + + +

+ Aber die Einzel-Statements sind wichtig für den Fall, daß jemand einzelne Files aus der Distribution herausnimmt und separat weiterverbreitet. Solange die Files in der Gesamtdistribution bleiben, genügt ein einziges zentrales Lizenz-Statement, das jedoch mit allen Einzel-Lizenzen kompatibel sein muß. +

+ +
+
+ + + + +

+ Der Copyright-Claim weist auf das Urheberrecht hin, das man gemäß Konvention von Bern automatisch erlangt, für typischerweise 70Jahre nach dem Tod. Dieses Recht bildet das Fundament, warum der Code überhaupt unter eine Lizenz fallen kann. Deshalb muß mindestens ein tragfähriger Copyritght-Claim gegeben sein +

+ +
+
+ + + + + + + + + +

+ Diese Regelung zielt erkenntlich auf die »industriselle Praxis«: dort ist den Leuten alles egal,  wofür sie nicht bezahlt und wozu sie nicht geprügelt wurden. Da bekommt man dann (ist mir selbst oft genug passiert) irdend ein Zip-File hingerotzt, und weiß nicht einmal, ob das Executable, das auf dem Server installiert wurde, wirklich aus diesem Quellcode stammt. Die GPL bietet in diesem Fall einen zusätzlichen Hebel, nicht zuletzt auch um die Reputation einer Quelle aus FreeSoftware zu schützen. +

+ +
+
+
+ + + + + + + + + + + + + +

+ Man muß jederzeit erkennen können... +

+
    +
  • + auf welchem Ursprungsrecht (Copyright-Claim) die Lizenz fußt +
  • +
  • + welche Lizenz nun effektiv gültig ist +
  • +
  • + wer sonst noch Änderungen vorgenommen hat und damit Copyright haben könnte +
  • +
  • + Datum der Änderungen summarisch (⟹ verlängert Gültigkeit der LIzenz 70Jahre nach dem Tod) +
  • +
+ +
+
+
+
+ + + + + + +

+ Jede Verletzung einer Pflicht terminiert die Lizenz, zunächst vorläufig. Allerdings handelt es sich um Vertragsrecht, und desshalb müßte die Aktion von einem Upstream-Rechteinhaber ausgehen... +

+ +
+ + + + + +

+ Vorrausseztung ist, daß man schnellstmöglich die Versäumnisse nachholt (in weniger als 30 Tagen nach Bekanntwerden des Mißstandes). Dennoch können binnen 60 Tagen nach dem Start des Heilversuchs beliebige Upstream-Copyright-Holder ihre Lizenz terminieren und haben dann allerdings nur ihren eigenen Anteil am Werk als Hebel zur Verfügung. Sofern sie dies nicht (binnen 60 Tagen) von sich aus tun, wird die Lizenz durch den Heilungsversuch automatisch wiederhergestellt +

+ +
+
+ + + + +

+ selbst wenn ich Fehler mache, und dadurch meine Lizenz verliere, können die Copyright-Holder sich nur bei mir bedienen, aber nicht weitere User in die Pflicht nehmen, die ihre Lizenz durch mich erlangt haben, solange sie im Glauben waren, diese Lizenz sei gültig. +

+ +
+
+
+ + + + + +

+ Das gilt nur für die GPL-3 und auch nur für Patent-Claims, die ein Nutzer oder Contributor geltend machen könnte; die Lizenz schützt im Besonderen nicht vor Patent-Claims Dritter +

+ +
+
+
+
@@ -160108,6 +161250,40 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo

+ + + + + + +

+ In die Pipeline gehören im Besonderen auch Operationen, die spezifisch sind für ein bestimmtes Ausgabe-System... +

+
    +
  • + für XV: das Skalieren und Umrechnen in den Ausgabe-Farbraum +
  • +
  • + für XGL: die Matrix-Operationen um die Textur für die Ausgabe aufzubereiten +
  • +
+

+ Allerdings gibt es Schritte, die sind dann an die konkrete Ausgabe-Verbindung gebunden und insofern Zustands-behaftet: +

+
    +
  • + XV: die shared-memory operationen und Kommunikation mit dem X-Server und flush +
  • +
  • + XGL auch hier erzeugt man ja einen Grafix-Kontext +
  • +
+ +
+ + +
+
@@ -161029,7 +162205,35 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + +

+ Das war eine Richtlinien-Entscheidung, nachdem wir den Vortrag »Video-Output« auf der FrOSCon gehalten haben. +

+

+ Dazu gibt es mehrere Gründe +

+
    +
  • + wir sind massiv zurückgefallen und haben noch sehr viel zu tun für eine minimal funktionsfähige Applikation +
  • +
  • + das Thema »Shader-Programmierung« ist ein dicker Brocken, und erfordert zusätzliche Infrastruktur; ja das wird relevant +
  • +
  • + Wayland ist »um die Ecke« (und dann müssen wir sowiso nochmal 'ran) +
  • +
+ +
+ + + +
+
@@ -161218,7 +162422,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
- + @@ -161269,12 +162473,178 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
- + - + + + + + + + + + + + + + + + + + +

+ git://git.lumiera.org/extra/froscon.git +

+

+ Subdir: ichthyo +

+ +
+ +
+ + + + + + + + + + + + + + + +

+ XSync leert die Event-Queue. Wenn sie leer ist, wird per IO nach weiteren Events gesucht. Was so gesammelt wurde, wird als Batch an den XServer gegeben und blockend gewartet, bis dieser diese Events abgearbeitet hat. Zwischenzeitlich können weitere Events aufgelaufen sein; diese kann man dann einfach wegwerfen (discard = true) oder in der Queue lassen (discard = false) ohne sie zu bearbeiten +

+ +
+ +
+
+ + + + + + + + + + + + + + + + + +

+ war verlinkt von einer Stackoverflow-Antwort zum Thema "redraw unter X" +

+

+ https://stackoverflow.com/a/17035752/444796 +

+ +
+
+ + + + + + + + + + + + + +

+ heute ist OpenGL ein Zugang zu einem computation device +

+ +
+
+ + + + + + + + + + + +

+ EGL verwendet ein Extension-Modell: es wird für die jeweilige Plattform eine passende Extension installiert. Diese ist nicht komplett neutral, d.h. der Client-Code hängt noch von einem allgemeinen Zugriffschema ab: man bekommt irgendwie eine »Surface« — die dann aber an verschiedene moderne APIs gebunden werden kann: OpenGL core-profile, OpenGL ES, OpenVG (2D -Grafik), Vulkan +

+ +
+
+
+
+ + + + + + + + + + + +
    +
  • + Eine GTK-3 - Applikation — alles noch unter X11 +
  • +
  • + drei Callbacks, in denen die eigentliche Logik demonstriert wird +
  • +
  • + eine Commons-Lib mit einfachen Abstraktionen für RGB-Daten +
  • +
+ +
+
+ + + + +

+ Zusätzlich gibt es eine Skizze für SDL, die ich aber auf dem Legacy-Level belassen habe (aus Zeitgründen). Also SDL 1.x (weithin gebräuchlich ist SDL v2, aktuell 2025 ist sogar v3 erschienen) +

+ +
+ + + + + + + + + + + + + + + + + + + @@ -161294,7 +162664,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161406,11 +162776,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + - + @@ -161430,6 +162800,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + @@ -161441,6 +162812,25 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + +

+ Das erachte ich als dringend, denn wer schreibt, der bleibt:  der typische, durchschnittliche »Techie« hat keine Ahnung vom Arbeiten mit Medien und auch keine Ahnung von Interaction-Design; die typsichen Feature-Requests, mit denen wir geflutet werden, kann man weitgehend ignorieren, es wäre schädlich für die Applikation, sie umzusetzen, bevor ein vollständiges GUI/Workflow-Konzept mit strikten Richtlinien da ist. Und ein solches Konzept auszuarbeiten, kostet Zeit und Kraft. Es ist strategisch sinnvoll, diesen Aufwand von der laufenden Entwicklungstätigkeit abzuzweigen, hoffentlich bevor das Thema allgemein bemerkt wird.  Wenn man »die Leute« machen läßt, dann wird Lumiera die ursprüngliche Vision verfehlen. Denn man kennt heut nur, worauf einen der industrielle Prozeß konditioniert, und man will dann bloß das Gleiche, aber umsonst. +

+ +
+ +
+
@@ -161549,12 +162939,3971 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + - + + + + + + + +

+ und zwar für zwei Dinge +

+
    +
  • + warum eine vollständige Lösung etwa 10 mal so viel Aufwand ist, wie mal eben runterhacken +
  • +
  • + für die Begriffsunterscheidung akzidentell vs essentiell, die Brooks in diesem Buch in den 70ern eingeführt hat (Essay »There is no Silver Bullet«) +
  • +
+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ nenne es »can be solved« +

+ +
+
+ + + + +

+ deute es als ein Festhalten an einer »einfachen« Lösung +

+ +
+
+ + + + + + + +

+ dahinter steckt eine Form des Verfallens +

+ +
+
+ + + + + + + + + + + + +

+ ⟹ auf Frederick Brooks zurückgreifen +

+ +
+ + + + + + + + + + +

+ Recherche: das war ja noch alles viel dramatischer +

+ +
+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + +

+ ...und darin liegt der Wirkmechanismus: da die Plug-ins von jemandem Anderes geschrieben werden, kann ich jetzt bereits die komplette Lösung deklarieren (und alle Einwände werden pariert mit "can be solved as a Plug-in") +

+ +
+
+
+
+ + + + + + + + + +

+ Das meine ich auf mehreren Ebenen +

+
    +
  • + zunächst das „natürliche“ (das heißt zwanghaft verfallende Coden) +
  • +
  • + ich markiere aber durchaus bewußt den Anspruch, daß der Entwickler gestaltet und entscheidet was er baut (und nicht ein Entscheidungsträger in einem industriellen Prozeß) +
  • +
+ +
+
+ + +
+ + + + + + + + + + +

+ Warnung: gefühlte Realität +

+ +
+ + + +

+ ...sinnlos dagegen zu argumentieren, man darf sie aber auch nicht einfach vom Tisch wischen und für „unreal“ erklären +

+ +
+
+ + + + +

+ Ich fand meinen Entwurf nicht sonderlich visionär, ehr naheliegend, und der Sache angemessen. Mein Entwurf wurde mit Begeisterung aufgenommen — sonst hatte nämlich niemand überhaupt einen Plan, oder auch nur einen Horizont, im HInblick auf Film, Medien und freie Software. Ich habe die Idee ernst genommen, daß man selber gestaltend handeln kann und sollte. Ich hatte mir erhofft, mit anderen zusammen gestaltend zu handeln +

+ +
+
+ + + + +

+ Ich fand mich in einer Bewegung und Gruppendynamik, die ich als widerwärtig und pupertär empfunden habe. Das was ich vorgeschlagen habe, wurde allerdings von den Filmemachern und Medien-Leuten sofort verstanden, nicht aber von all diesen »Techies«, auf deren Beitrag ich gerechnet hatte. +

+ +
+
+ + + + +

+ Aufgrund meiner auch damals schon erheblichen Erfahrung habe ich gesehen, daß mein Entwurf nicht mit allgemeinen Wünschen harmoniert (zumindest nicht anfangs, man muß einen Fokus setzen für ein derart großes Projekt). Ich habe daraufhin geschickt navigiert, und tatsächlich die anderen beteiligten Interessen ausmanövriert. Ich ging davon aus, daß mein Entwurf für das Projekt so offensichtlich ist, daß sich schon brauchbare Unterstützer finden werden. Dann hat sich aber das Klima gedreht, und jetzt sitze ich seit mehr als 10 Jahren allein in dem Projekt, und mußte mich jahrelang mit den Folgen dieser Manöver plagen. Es gab keine Möglichkeit mehr, den Konflikt auszutragen (und das Projekt ist sowiso niemals allein zu bewältigen, ich allein kann grade verhindern, daß es ganz untergeht) +

+ +
+
+ + + + +

+ Auseinandersetzung mit der Historie  ⟹  habe Liberalismus  dahinter entdeckt +

+ +
+ + + +

+ Vor dem Hintergrund der veränderten Situation (Plan einer Stiftung) habe ich begonnen, Altlasten aufzuräumen; damit sind all diese lang begrabenen Themen wieder hochgekommen. Ich habe die aufgehobenen Dokumente und Protokolle durchgesehen, und die Erzählung zur Historie von Lumiera weiter geschrieben. Erst in dem Zusammenhang wurde mir klar, daß hinter dieser Spinnerei mit den Plug-ins eine konsistente Ideologie steckt, welche sich bei näherer Betrachtung als eine Spielart des liberalistischen Glaubens an unsichtbare Heilkräfte herausstellt. Im Rückblick erscheint das plausibel, das war (und ist) der Zeitgeist. Das kann ich aber nicht als Lösung akzeptieren, sondern empfinde es als ungerecht. +

+ +
+
+
+ + + + + +

+ Darin steckt mein Verlangen nach Rache: ich habe zig mal die Erfahrung gemacht, daß ich meine Haltung und meinen Entwurf überhaupt nicht formulieren kann, weil man mir gar nicht zuhört, sonder wie verblödet immer nur seinem Aberglauben an die magischen Kräfte des Kollektivs frönt. Nun schaffe ich mir eine Konstellation, in der alle diese Kollektiv-Schafe ihr blödes Maul zu halten haben. +

+ +
+
+ + + + +

+ Meine Haltung war bisher — ehrlicherweise eingestanden — auch nur eine intuitive Einschätzung „das kann so nicht funktionieren was ihr euch da so vorstellt“. Damit allein werde ich keine Debatte bestehen können, und schon gar nicht gegen einen »Zeitgeist«. Also brauche ich eine bessere Position, die die Frage nach der konkreten Architektur und der Rolle von Plug-ins auf einen Boden stellt, auf dem überhaupt argumentiert werden kann. Wenn überhaupt, dann ist die Gelegenheit für strategische Weichenstellungen jetzt (auch bezüglich dessen, was ich für später offen lasse) +

+ +
+
+ + + + +

+ Das ist ein strategischer Ansatz +

+
    +
  • + ich steige bewußt nicht in eine Argumentation ein +
  • +
  • + ich setzte einen Rahmen, der die Handelnden mit einbezieht und auf Reflexion verpflichtet +
  • +
  • + ich rücke ein betontes Verständnis der Architektur in den Mittelpunkt und mache es zur Aufgabe +
  • +
  • + damit entziehe ich eventuellen Diskussionen über Technologien und ihre Wirkungen bereits im Vorhinein den Boden (ich denke da auch an die sogenannte »künstliche Intelligenz«) +
  • +
+ +
+
+
+
+ + + + +

+ ...das war am Ende eine erhebliche Schwierigkeit, und hat mich fast eine Woche Arbeit gekostet. Denn zunächst einmal bin ich induktiv vorgegangen, und damit meine ich, aus einem Verständnis des Stoffes — der Text ist nun sehr lang und mühsam zu lesen. Zwar geht es mir um das, was zwischen den Zeilen steht. Aber beim Lesen muß man dennoch das Gefühl haben, daß der Text wohin führt. Und zwar, da es sich um einen Essay handelt, und nicht um einen wissenschaftlichen Artikel, sollte der Text zum Anfang zurückführen. +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ habe nun alle RfC durchgesehen und verstehe einige Zusammenhänge besser +

+ +
+
+ + + + + + + + + + + +

+ Erste Mail: Oktober 2006. +

+

+ Diese Mail war versehentlich auf die Mailingliste geraten, und zeigte, daß damals Cehteh und Johannes Sixt (vom Cinnelerra-CV-Team) zusammen ein Git-Repo aufgesetzt hatten +

+ +
+
+ + + + + + + + +

+ zunächst bezogen auf ein Independent-Film Project, für das versucht wurde, auf Cinelerra zu editieren, weil Cinelerra damals die erste leicht zugängliche Methode war, HDV-Video zu editieren. +

+ +
+
+ + + + + + + +

+ war aber bereits etwas skeptisch, da er Cinelerra länger kannte als Cehteh +

+ +
+
+ + + + +

+ Und zwar lediglich, weil er davon nichts wußte. Diese Initiative war nämlich nirgends angekündigt; man mußte viel auf IRC sein, um mitzubekommen, daß da was lief. Ichthyo hatte sogar Cehteh und Johannes Sixt chatten gesehen, und nicht recht verstanden, worum es ging: sie haben nämlich versucht, die neueste Version Cinelerra v2.1 mithilfe von Git nochmal gemerged zu bekommen. Cehteh und Ichthyo sind erst im Mai direkt ins Gespräch gekommen, und dann hat Cehteh sofort Ichthyo eingeladen, sich auf pipapo.org einzubringen (d.h. Ichthyo bekam Schreibrecht auf das Wiki). Allerdings hatte Cehteh bereits ein halbes Jahr vorher für Ichthyo ein Git-Repo auf pipapo.org eingerichtet (mit Schreibrecht), welches Ichthyo genutzt hat, um weitere Patches für Cinelerra vorzubereiten und mit Johannes Sixt abzustimmen. Ichthyo hat aber damals noch nicht verstanden, daß da eine Initiative entstand, die unabhängig von Cinelerra-CV war. Er dachte zunächst, dieses Git-Repo wäre eine neue Einrichtung von Jonannes Sixt, für Cinelerra-CV +

+ +
+
+
+ + + + + + + + + +

+ ...und zwar, im Bezug auf Änderungen, die sich von der Heroine-Version von Cinelerra wegbewegen. Der Grund war offensichtich, daß der die Situation kannte, und keine Möglichkeit sah, sie zu ändern. Johannes hatte einen full-time Job als Entwickler, und ohnehin wenig Freizeit, die er nicht komplett nur für Cinelerra verbraten wollte. Er war es auch, der die Merges überhaupt zustandegebracht hat, und damit eine ganz kleine Möglichkeit geschaffen hatte, neue Patches zu akzeptieren; aber jeder Patch hat ihm persönlich Probleme bereitet (weil er dann den nächsten Merge „ausbaaden“ durfte). +

+ +
+
+ + + + + + + + + +

+ Und zwar, obwohl (oder weil) er ein extrem erfahrener Programmierer und Project-Lead war. Er wußte einfach, daß er keinen Code mehr anfassen würde. +

+

+ Dahinter verbirgt sich eine tragische Geschichte: er hatte ADHS, war mit Ritalin behandelt worden, und Ritalin-süchtig geworden, hatte einen kompletten Zusammenbruch mit Burnout durchgemacht, und war von Opera in Frührente geschickt worden (mit 40 Jahren). Er war bereits mit bedrohlichen Nebenwirkungen vom Ritalin-Abusus konfrontiert, und die Ärzte hatten ihm vorhergesagt, daß er vermutlich in wenigen Jahren in eine Art Demenz gleiten würde. +

+ +
+
+ + + + + + + + + + +

+ hat aber — mangels Erfahrung — sich nicht getraut, viel Code beizutragen; er hat den Code gelesen, Typos in Kommentaren korrigiert, Formulierungen in den Wikis verbessert und viele (sehr gute!) Fragen gestellt. +

+ +
+
+ + + + + +

+ ...und hat dabei sehr viel gelernt, was im Umkehrschluß bedeutet, daß Cehteh ihn intensiv gementored hat, und ihm viele Programmiertechniken beibringen mußte, die auf der Uni nicht gelehrt wurden. Er hatte nur ein Semester "systemnahe Programmierung" gehabt, und Spaß daran gefunden, aber die Uni hat nicht mehr geboten, als ein paar Programmieraufgaben in C. +

+ +
+
+ + + + +

+ die C++ - Strukturen von Ichthyo hat er bewundert, +

+

+ vieles aber nicht verstanden und wollte dort keine Last sein. +

+ +
+
+
+ + + + + + + +

+ Und zwar überwiegend in der Rolle eines »Bewunderers«: er war bei allen Diskussionen dabei, hat sich oft nichteinmal getraut, Fragen gestellt, und dann anschließend in langen Chat-Sitzungen sich alles im Detail von Ichthyo erklären lassen. Er sagte damals immer wieder, daß er so gerne mit dabei sein wolle, aber was hier gemacht würde, sei um „mehrere Stockwerke zu hoch“ für ihn +

+ +
+
+ + + + + +

+ Das war von Cehteh als „eigentlich ein Anfänger-Job“ eingestuft. Daher hat Cehteh ihn angehauen, „Siemon, das packst Du!“. Tatsächlich hat Simeon den größten Teil der Implementierung geschrieben, so wie sie dann viele Jahre in der Codebasis verblieb. Allerdings brauchte er permanente Hilfe von Cehteh; die beiden waren beinah täglich zusammen im Chat und Cehteh hat den Code von SimAV reviewed +

+ +
+
+
+ + + + + + +

+ Und zwar handelte es sich um Code von hoher Qualittät, rein als Library konzipiert, sauber strukturiert, gründlich getestet +

+ +
+
+ + + + + +

+ ...er ist aber nie selber eingestiegen, sondern hat darauf gewartet, daß Cehteh die entsprechenden Teile im Backend implementiert, in denen seine Library eingebunden würde; die Developer-Gruppe hate Anfangs in aller Form beschlossen, daß Lumiera auf dem Gmerlin/Gavl-Framework von Burkhard aufbauen sollte. Burkhard hat immer klar gemacht, daß er nicht direkt in das Lumiera-Projekt einsteigt, weil sein eigenes Projekt (der Gmerlin Videoplayer) bereits seine volle Kapazität braucht. Und da Christian kaum je etwas für das Backend getan hat, sondern Plugins und Frameworks gebaut hat, kam auch Burkhard nie weiter in das Projekt und verschwand irgendwann von der Bildfläche +

+ +
+
+
+ + + + + + + + + + + + + + + Richard Spindler found his way through Parma thanks to the great + +

+ OpenStreetMap project. +

+ +
+
+ + +
+ + + + +

+ Hatte damals die Idee, +

+

+ die verschiedensten Video-Entwickler +

+

+ in einem Meta-Projekt »Open Video« +

+

+ zusammenzubringen +

+ +
+ + + +

+ Die Mailingliste dazu hat Cehteh auf der Infrastruktur von pipapo.org und später von Lumiera gehostet; leider ist diese Initiative relativ schnell ausgetrocknet (es gab wenig zu besprechen, jeder hat sein Ding gemacht) +

+ +
+
+ + + + + + + + + + + + + +

+ Fazit: es hat sich erübrigt +

+ +
+
+
+ + + + + + + +

+ commit 13b963ba5bc39603c1d425752f07d8b3941f01ba +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Mon Jun 18 01:14:12 2007 +0200 +

+

+ +

+

+     initial commit, just tiddlywiki tests +

+ +
+
+ + + + +

+ commit 0a9c2599dd49990b8ccf779a44abdaba626bdd86 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Tue Jul 3 00:13:12 2007 +0200 +

+

+ +

+

+     some cleanup. Set Version=3+alpha.01, add a helloworld-main to make it compile +

+ +
+
+ + + + +

+ commit 0a9c2599dd49990b8ccf779a44abdaba626bdd86 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Tue Jul 3 00:13:12 2007 +0200 +

+

+ +

+

+     some cleanup. Set Version=3+alpha.01, add a helloworld-main to make it compile +

+ +
+
+ + + + +

+ commit a313ea87a588241a1db72b6cac6e2aee2b512fc7 +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Sun Jul 15 02:23:37 2007 +0200 +

+

+ +

+

+     Work in progress, just for review +

+

+ src/lib/plugin.c +

+

+ src/lib/plugin.h +

+ +
+
+ + + + +

+ commit 471148b7db2e41f2c081760cc367710ce6999da9 +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Thu Jul 19 05:10:14 2007 +0200 +

+

+ +

+

+     basic automake setup +

+ +
+
+ + + + +

+ commit ebb4da6cc738392c015c7d66c54c6483331459f4 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Wed Aug 8 04:50:02 2007 +0200 +

+

+ +

+

+     ** Start Coding ** Renderengine sources generated, reformatted and made compilable. +

+ +
+
+ + + + +

+ commit ed4decb5de9c6c22bb0f9173e3d239fefe9453e7 +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Sun Aug 12 04:10:10 2007 +0200 +

+

+ +

+

+     added notes from yesterday irc discussion +

+ +
+ + + + + + +

+ commit 45c21677009dfc733d0ecd6f26d783c99b2818d5 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Mon Aug 13 09:55:32 2007 +0200 +

+

+ +

+

+     wrote a very simple Test-Suite runner and provided a Tests source tree +

+ +
+
+ + + + +

+ commit ce3eb42131b0f8f809b00ef9a7759eb885e684d3 +

+

+ Author: Christian Thaeter <ct@pipapo.org> +

+

+ Date:   Mon Aug 13 17:22:07 2007 +0200 +

+

+ +

+

+     test suite works now basically +

+ +
+ + + + +

+ Die Git-Historie der ersten Wochen ist im Rückblick durchaus aufschlußreich. In der offiziellen Kommunikation haben Cehteh und Ichthyo über eine gemeinsame prototypsiche Applikation geredet, während gleichzeitig jeder auf seinem Branch »Fakten geschaffen« hat, die nicht koordiniert waren, und sich konzeptionell widersprechen. Das hier ist ein gutes Beispiel... +

+
    +
  • + plötzlich schreibt Cehteh einen "ganz einfachen" Test in C, mit einem shellscript zum Starten. Jedwedes schaffolding muß man selber machen +
  • +
  • + vermutlich daraufhin arbeitet Ichthyo die ganze Nacht durch, und kippt am nächsten Morgen ein komplettes, in C++ geschriebenes Unit-Test-Framework ab. +
  • +
+

+ Jeder integriert „seine“ Tests natürlich in „das“ Buildsystem (was auch bereits disjunkt war, Autotools für Cehteh, SCons für Ichthyo). Es ist definitiv klar daß man Unit-Tests wollte. So klar, daß seinerzeit nicht weiter darüber geredet wurde +

+ +
+ + +
+
+
+ + + + + + + + + + +

+ Ein Rant von einem User aus Argentinien. Das "Cinelerra-3"-Projekt war offenbar nur wenigen bekannt. Christian und Hermann Robak haben irgendwann im Thread geantwortet +

+ +
+ + + + + + + On Tue, 14 Aug 2007 23:32:01 +0200, Edouard Chalaron + +

+ <e.chalaron@xtra.co.nz> wrote:

+

+
+ Well I am sorry, but the way icons look is of the last relevance

I + don't work better because icons look better. They could look better
but + I could not care less either.
+
+
+  Same here.  But people _will_ complain about the things + they see,
perceive or understand.  So we will keep hearing complaints + about
the colours and the icons until they become more in style with the
flavour + of the month.

 The developers don't feel strongly motivated by that, + though.
I am not shaming the developers for not caring about the end
users' + complaints.  Nor am I shaming end users for complaining
about + things that the developers never will consider urgent.
I am just + pointing it out.  If you want to vent here anyway,
I don't + mind. ��


 In light of this, I think Christian + Thäter's protocols for
work on Cin3 are clever.  You have to hang + around on IRC and
poke around with the git repositories, regularily.  + If you
don't, you are out of the loop.
 People who are "talkers" and + not "doers" will have to spend
a lot of energy just to stay + in the loop.  They will either
get a more intimate insight + into which ways things are going,
and why, or they will get fed up and + leave.
 It makes trolling much more expensive, and it makes the
"doers" + stand more clearly out.

 These are interesting times ��

+
+ -- 
Herman Robak
+
+

+

+ +

+ +
+ + + + + + +
+
marquitux caballero wrote:
+
+
in the comunity very cool people tried to explain me thos things, but
+they seems to be very focused in specific issues, and those BASIC
+things, are not important  in this part of the coding process, and they
+told me those things are BUGs... really? bugs? or bad plannig, or even
+no global vision?
+
+
Few people from IRC gathered together to plan a rewrite/redesign of what
+ought to become 'Cinelerra 3'.
+
+Please take a look at:
+http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/Manifest
+http://www.pipapo.org/pipawiki/Cinelerra3
+
+So far we have very cool ideas about a new design which allows a lot of
+things which are currently not possible, some coding has started but
+this is rather in a experimental, preparation phase.
+
+The downside is that we massively lack developers, unfortunally many
+previous contributors fallen away because they finished university, got
+new jobs or whatever. We aim to make cinelerra3 a open project where
+anyone can join and help as much as possible! If you are coder and
+interested, just join us.
+
+I've send a http://www.pipapo.org/pipawiki/Cinelerra3/Announcement about
+this 'cinelerra 3' project to all developers, so far the responses where
+very sparse but postive.
+
+A note to all 'users' reading this: Please refrain from sending feature
+request and ideas to us, its way to early and only costs our time to
+explain that we consider this things later. Ichthyo and me decided to
+design cin3 from ground up. Interested people should start by checking
+out the git repositories and review what is there. If you know how to do
+things better ask the responsive author of the current thing on IRC or
+via mail and do a discussion with the involved people about it. Speaking
+for me, I would like to see improvements and new ideas, but I don't want
+to become overthrown by people just dropping ideas and then disappear.
+
+Further note about HV's involvement: I informed him at first about this
+ideas, but his responses are sparse as usual. It is clear that this may
+only become Cinelerra 3 if he acknowledge on this project at some time
+and he is invited to join and contribute whenever and as much he wants
+to do (we aim to reuse code and ideas from cin2 anyways). Cinelerra is a
+heroinewarrior project, Cinelerra CV is a (friendly) fork of it, we
+don't want to take over the project, our goal is just to make the best
+free Linux Video editor in existence ��.
+
+	Christian
+
+_______________________________________________
+Cinelerra mailing list
+Cinelerra@skolelinux.no
+https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
+
+
+

+ +

+ +
+ + + + + + + + + +
This my maybe arguable view how to hive Cinelerra CV out of its
+develoment stall:
+
+1) Change the focus of CinelerraCV
+Currently CVs goal is repackaging the HV version and fixing bugs.
+But a real community version should acknowledge progress and new
+features which are contributed by the community.
+
+2) Stop using SVN
+Even if commit access is generously handled to people who ask, it's
+still a big blocker as I explained earlier. As long we have only one
+linear history everything has global impact and there is no easy way to
+add new features without running in troubles. There is no easy way that
+small groups of people try and review new features, no easy way to get
+good but intrusive new ideas back into CV.
+
+3) Make releases
+Cinelerra CV has only this SVN there is no release schedule and no
+defined point when the source is called to be stable (well we can't
+define in a lack of testsuite and presense of many bugs anyways). This
+yields the result that anyone (including distributors and packagers)
+build on some (maybe recent?) svn revision. There are packages from many
+different versions out there which makes it not really easy to track
+reported bugs down. Users have doubts which is the best version for them
+already just because this linear revision history without release
+statements, which is imo more worse than a magnitude of git branches
+with defined releases (and maybe bugfix revisions on them)
+
+4) Make tracking HV less important
+We want some branch which tracks heroines versions and refactors it into
+smaller commits as we are doing now, but this should be considered as
+tool and foundation of any work which is done on our releases. This
+means the CV version should be maintained in another branch and new
+features should be added on our development (or release) branches.
+Finally we may provide a backporting branch where imminent bugfixes are
+prepared to be mergeable with the hv-tracking version. So this becomes a
+way how we can contribute back to HV which is currently not a easy case.
+Maybe Adam once speaks about what he wants, so far he complained that
+the community didn't provide much useable feedback .. and admitably he
+was right, takeing HV less important will actually allow us to do more
+work and thus may provide more benefits for HV getting some
+contributions feed back.
+
+
+	Christian
+
+_______________________________________________
+Cinelerra mailing list
+Cinelerra@skolelinux.no
+https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
+
+ +
+ + +
+ + + + + + + +

+ ...also der ganze Kreis an einführenden Seiten, die bis heute in meinem Renderengine-TiddlyWiki herumhängen. Und alle wesentlichen UML-Diagramme. Sogar über die Builder-Entities habe ich mir bereits ausführlich Gedanken gemacht +

+ +
+
+ + + + +
    +
  • + für die Renderengine (Hermann): ein Durchgang von EDL mit Placements, ExplicitPlacements, dem Builder und einem Render-Graphen +
  • +
  • + für das Backend (Christian): der komplette Inhalt des späteren RfC: Data Bakend. Plus eine Implementierungsskizze als Sammlung von Tiddlern, die man jeweils direkt runtercoden könnte +
  • +
+ +
+
+ + + + + + + + + + + + + + +

+ Error, Locking, Plugin und eine Linked List +

+ +
+
+ + + + +

+ Zunächst einmal, ich wußte mit UML umzugehen, Christian hat nach einem ersten Gehversuch aufgegeben. Daher habe ich per Generierung bereits einen großen Haufen Klassen angelegt, d.h. der C++ - Code dominierte absolut. Aber für Christian war das einfach durchschaubar (und ich habe das auch betont). +

+

+ +

+

+ Abgesehen davon hatte ich ein Asset + MObject-Framework angelegt und Tests für CRUD-Operationen in der Session. Wobei die Session damals ein kompletter Mock war. Außerdem hatte ich eine Reihe von Test-Skeletten für den Builder und den Aufruf von Nodes, aber dort war alles praktisch nur Platzhalter-Code, und ich kam bereits nur noch langsam voran. +

+

+ +

+

+ Im Vergleich hat Christian nur sehr wenig gebaut, und das waren elementare Sachen, die aber vollsändig und routiniert. Ich habe eine weit ausgreifende Struktur skizziert, die fast nur aus Dummies besteht +

+ +
+
+
+ + + + + +

+ In diversen Diskussionen, die ich heute gelesen habe, ist immer nur von "CT" die Rede. Auch Herman Robak rehted immer nur von Christians Initiative. Ich sehe Antworten von mir, die wie "5. Rad am Wagen" rüberkommen, oder wie jemand, der sich wichtig machen möchte, und sehr akademisch redet. Meine wenigen Aussagen wurden in Diskussionen in diesem ersten Herbst praktisch nicht aufgegriffen. Allerdings bin ich in die Threads mit den Usern auch wenig eingestiegen, deren Argumente waren mir zu blöd, um darauf einzugehen. Das war ganz anders als sonst, ich finde viele Beiträge von mir, in denen ich Usern mit Cinelerra geholfen habe, und daraus ist ein Gespräch entstanden. +

+ +
+
+ + + + +

+ ich erinnere mich, daß andere Leute von "Deinem neuen Projekt" geredet haben, und Christian dann immer darauf hingewiesen hat, daß das nicht "sein" Projekt ist. Er wollte es auch nicht auf pipapo.org hosten. +

+ +
+
+
+
+ + + + + + +

+ Ich erinnere mich, argumentativ auf die Leute einzugehen, und zwar vor allem auf die Anfänger. Ich kann mich erinnern, daß Christian grade den Anfängern gegenüber oft von oben herab kam, und schnoddrig war. Ich erinnere mich auch, in Debatten auf IRC stark präsent gewesen zu sein, und sehr für unser Projekt geworben zuhaben. Ich hatte auch lange, lange Gespräche mit Raffa und Co. über allgemeine Themen und Film. Chistian dagegen hing auf dutzenden anderen Channels herum, und hat dem Cinelerra-Channel nur begrenzte Aufmerksamkeit gewidmet. Er war auf anderen Channels oft in routiniertes Ping-Pong mit unendlich vielen anderen Leuten involviert, die sich alle kannten. Demgegenüber war ich dort ein kompletter Außenseiter, und hab mich auf diesen anderen Channels (z.B. Debian, Free Software) auch tunlichst rausgehalten. +

+ +
+
+ + + + +

+ Also das Gefühl, daß das alles dermaßen gut aufgeht, und wir so unglaublich produktiv sind, daß sich ein laufendes System in ein paar Monaten hinstellen läßt, wenn man nur wirklich hart arbeitet.  Es bringt mir auch die Erinnerung zurück, daß ich nicht hinterfragt habe, wie das Verhältnis zu Cinelerra ist. Das hier war »Cinelerra-3« und im übrigen gab es ja meinen Projektplan, mit dem man das irgendwie den ersten Meilensteinen zuordnen könnte. Auch das Gefühl: wie wir dann weiter vorgehen und das in Cinelerra einbauen, überleg ich mir, wenn die Engine läuft. Denn eine laufende Engine kann ja schon mal nicht falsch sein. +

+ +
+
+ + + + +

+ Diese Erinnerung bringt erstmals das Gefühl einer auszehrenden Schwere. Ich bin einen ganzen Tag dagesessen, draußen regenete es. Von Zeit zu Zeit war ein rätselhaftes "Tuuut" auf 1kHz draußen zu hören, das ich nicht verstanden habe, nicht klar ob eine Glocke oder ein Signal. Währenddessen habe ich mit mit der Asset- und MObject-Hierarchie herumgeplagt, die Struktur und die Logik wollte nicht aufgehen, ich sah keine Möglichkeit, einen Test zu schreiben, und ich habe vergeblich nach einem Ankerpunkt gesucht, von dem her ich den Code aufrollen konnte. Es war ja letztlich eine Sammlung von UML-generierten Klassen-Skeletten, die ich nun versuchte, zusamenzuhängen. +

+

+ +

+

+ Später, als es schon dämmerig wurde, bin ich in den Supermarkt gegangen (war damals noch nicht einmal der Rewe). Vor dem Eingang hab ich wieder das rätselhafte "Tuuut" gehört, bin dann im Regen die Aberlestraße entlanggefahren und durch den Park im Südbad. Auch dort war es zu hören, und ich konnte nicht orten, von woher es kam, oder was es war. Erst einige Tage später habe ich oben, hinter der Margarethen-Kirche eine Baustelle an der S-Bahn entdeckt. Es war also ein ganz banaler 1kHz-Sinuston aus Lautsprechern, die an der Strecke entlang standen. +

+ +
+
+
+ + + + + + + + + + + + +

+ Und zwar in den ersten dokumentierten Diskussionen, auf der Cinelerra-Mailingliste mitte August. (Beachte, Adam konnte das lesen — das zeigt, daß Christian unreflektiert gehandelt hat). +

+

+ +

+

+ Des genaueren sagte Christian, er habe versucht, die Cinelerra-Codebasis zu refactorn und verbessern, und habe es aufgegeben, da "bottomless pit". Ich weiß aber definitiv, daß er das nicht im Sommer getan haben kann. Also muß er bereits im Frühjahr zu diesem Schluß gekommen sein, hat aber andererseits meinen Umbau-Plan zumindest verbal unterstützt (aber schon solche kommentare reingeschrieben, wie "wäre es nicht besser allses neu zu bauen?" +

+

+ +

+

+ De facto hat Christian nur an seiner Applikations-Basis gearbeitet: das erste war der Plugin-Loader v1, dann kam das Errorhandling und die Tests. Es war alles von Anfang an ausschließlich auf C angelegt. Auch hat er nur kurz etwas mit SCons gespielt und dann nur noch mit seinem Autotools gearbeitet. +

+ +
+
+ + + + +

+ Ich weiß ganz sicher, daß ich niemals einem Projekt beigetreten wäre, einen Video-Editor komplett neu zu schreiben. Da hätte ich eine ganz andere Organisation vorausgesetzt, und eine echte Design-Phase. Ich kann mich auch erinnern, daß ich Christian's Glaube an die "Community" als naiv empfunden habe. Ich sah das, was wir machen, als ein alternatives Basissystem, mit dem man sich in eine bestehende, große Applikation einklinkt. +

+

+ +

+

+ De facto habe ich an einer naiv objektorientierten Klassenhierarchie gearbeitet, und erst mal versucht, als Java-Entwickler mit C++ klar zu kommen. Um den C-Code von Christian habe ich mich kaum gekümmert, und mir gedacht, wird man dann schon irgendwie aufrufen können, schließlich kann C++ ja auch C. Ich erinnere mich auch, daß ich Angst vor der Systemprogrammierung hatte, und froh war, daß mir Christian das abnehmen wird. Ich dachte, die Beiträge von Christian werden schon noch kommen. Das was er anfangs gemacht hat, habe ich gar nicht erst genommen, und für Experimente gehalten. +

+ +
+
+
+ + + + +

+ die Plug-in-Kontroverse war bereits damals, in den ersten Wochen +

+ +
+ + +
+
+
+ + + + +

+ wie kam es daß wir neu gebaut haben? +

+ +
+ + + + + + + + + + +
    +
  • + Erste Hypothese: diesen »Intent« habe bloß ich mir ausgedacht / eingebildet + +
      +
    • + ich war der einzige, der explizit einen Umbau-Plan durchdacht und ausformuliert hatte +
    • +
    • + die anderen „fanden das irgendwie gut“ — aber auch mühsam +
    • +
    • + Christian hatte vielleicht schon vorher insgeheim aufgegeben, und wollte was Neues bauen (dafür gibt es Hinweise) +
    • +
    • + es wurde die Resonanz durch eine Bewegung gerne aufgegriffen, verschiedene Akteure hatten aber ihre eigenen Interessen +
    • +
    +
  • +
  • + Es war tatsächlich eine Gemeinschaft-stiftende Idee, blieb aber abstrakt + +
      +
    • + das Mission-Statement „we want a better Cinelerra“ hat sich auf der Ebene der Plausibilität festgesetzt +
    • +
    • + man hatte dadurch — gefühlt — ein Mandat und konnte loslegen +
    • +
    +
  • +
  • + Es war der tatsächliche Plan — und man ist davon weggedriftet + +
      +
    • + der von mir konkret ausformulierte Plan hatte eine katalysierende Wirkung +
    • +
    • + der Plan sieht überraschenderweise tatsächlich (Milestone-2) gewisse Prototyping-Aktivitäten vor +
    • +
    • + der Plan ließ Spielräume offen (was an sich gut ist), und beide Haupt-Akteure haben ihn ein Stück weit in ihrem Sinn verstanden +
    • +
    • + sobald man an der Arbeit war, hat jeder getan, was er gut konnte und (auch nur ein ganz kleines Bisschen) was ihm wichtig war +
    • +
    • + es ist etwas Unerwartetes geschehen, wodurch das Projekt festgefahren ist....? +
    • +
    • + es blieb nur noch die äußere Form übrig, und dummerweise war einer der Akteure (das Reptil nämlich) ein hartnäckiges Arbeitstier +
    • +
    +
  • +
+ +
+
+ + + + + + + + + + + + + + +

+ Einsicht: der Plugin-Streit war bereits in den ersten Wochen +

+ +
+ + + +

+ ...das habe ich in der Erinnerung komplett anders angebunden: mein Bild war, daß das erst Jahre später passiert ist, und sich langsam hochgeschaukelt hat +

+ +
+ +
+ + + + +

+ schon die erste lange Antwortmail ("how to proceed?") erscheint latent-feindselig. Und die zweite, grundsätzliche Mail ist eine Kriegserklärung. +

+
    +
  • + war mir das nicht klar damals? +
  • +
  • + warum habe ich plötzlich so scharf reagiert? +
  • +
+ +
+
+ + + + + + +

+ Im Rückblick waren dafür die Anzeichen schon viel länger da, aber ich habe sie übersehen, bzw. als Joke abgetan. Hätte Christian gleich von Anfang klar gesagt, daß er sich gegen moderne Methoden definiert, und nur die Imperative Pogrammierung alten Schlages für sinnvoll hält, dann hätte ich mich vermutlich überhaupt nicht näher auf ihn eingelassen, und das gesamte Projekt wäre nie zustandegekommen. Christian aber war locker-eschmeidig, und ich war ebenso stets aufgeschlossen und interessiert und habe ebenso nicht gesagt, daß ich einen solchen Ansatz als "oldschool" komplett ablehnen würde. Hinzu kommt, daß Chistian selbstbewußt auftritt, und ich dagegen sehr stark meine eigenen Schwächen sehe, und daher stets vorsichtig bin und meine Position absichere. +

+ +
+
+ + + + +

+ Und das hat mehrere Quellen +

+
    +
  • + er war/ist sehr gut vernetzt und wird von seinen Buddies geschätzt und bestätigt +
  • +
  • + er weiß um sein Geschick und die Fähigkeit, extrem pfiffige Lösungen in kurzer Zeit zum Fliegen zu bringen (siehe die Drohnen einige Jahre später) +
  • +
  • + er hatte diese Vision, die ihn über Details hinwegblicken ließ: man fängt halt mal an, und wenn nur genügend Vernetzung da ist, biegt das die Gruppe schon hin. Es ist stets wichtiger, irgendetwas in Bewegung zu setzen +
  • +
+ +
+
+ + + + +

+ Und zwar in zweierlei möglichen Richtungen (ich erinnere mich jetzt, nach Lektüre der ganzen Dokumente, daß ich das damals bereits so gesehen habe) +

+
    +
  • + wenn ich Christian und seine Buddies »machen lasse«, entsteht eine Umgebung, in der ich mein anspruchsvolles Konzept ganz sicher nicht realisieren kann. Das wird ein Kampf gegen Windmühlen, und ich weiß, daß ich kein Power-Coder bin, sondern langsam, vorsichtig und vorbedenklich. Meine Beiträge werden dann alsbald nur noch lächerlich gemacht, und sind es dann auch, weil sie in einer solchen flachen Code-Suppe nicht in den Griff zu bekommen sind. +
  • +
  • + Wenn ich mich dagegen auf das Experiment einlasse, und Christian mit dem Anspruch meines Projektvorschlags zusammenspanne, dann wird daraus eine Quälerei, die schnell in persönliche Vorwürfe ausartet. Selbst wenn ich das durchfechte, wird am Ende Christian lediglich davonlaufen und mir die Schuld geben, und ich habe viel Lebenszeit vertan +
  • +
+ +
+ + +
+
+ + + + + + + + +

+ Deshalb ist die Beurteilung dieser Kontroverse so schwierig +

+
    +
  • + Christian wollte "iregendwie eine Plugin-Architektur" weil das cool ist, und er hielt das für sehr wichtig, und war der Meinung, er bekommt das mit seinem Ansatz schon gebacken. Christian war zu Konzessionen bereit, wie z.B. nur C++ Interfaces, oder dann eben keine Microkernel+Plugin-Architektur. Es ging ihm eigentlich nur um sein Visions-Ding, aber er hat sich damals noch nicht als "reiner C-Entwickler" definiert +
  • +
  • + Ich kannte mich damals noch nicht näher mit C++ aus. Ich sah potentielle Einschränkungen, aber ich wußte weder, wie bedeutsam Plug-ins wirklich werden, noch wußte ich welche Rolle moderne C++ - Features spielen könnten +
  • +
+

+ Bedingt durch diese Diffusität, hat sich das Thema plötzlich in eine Debatte entladen, wurde aber nicht geklärt. Infolgedessen konnte Christian seine Vision nicht realisieren und hat letztlich mit Lumiera gefremdelt, aber jahrelang noch versucht, Elemente seiner Vision doch noch unterzubringen. Und ich habe jahrelang versucht, mit seinen Beiträgen zurecht zu kommen, die aber nicht wirklich mit der Applikation zusammenpassen, die real entstanden ist +

+ +
+ +
+ + + + + +

+ 8.7. +

+ +
+
+ + + + +

+ 9.7. +

+ +
+
+ + + + +

+ Ersichtlich erst schon in den Mails, aber ganz schlagend in der einzigen Debatte, die ein direktes Gespräch war (auf IRC am 10.7): +

+
    +
  • + Christian hat nie zugehört und immer nur auf einzelne Stichpunkte mit technologischen Lösungen oder Dementi reagiert +
  • +
  • + Ich habe Christian so behandelt, als wüßte er nicht, was er will. Ich habe nicht gesehen, warum ihm das so wichtig war +
  • +
+ +
+
+ + + + +
    +
  • + Ich habe zwar im Gespräch meine Punkte vorgegracht und versucht festzumachen, doch Christian hat zwar zugestimmt, aber offensichtlich gar nicht zugehört +
  • +
  • + mein Standpunkt war eigentlich: laßt uns das später klären. Ich war nicht gegen plug-Ins und deshalb konnte Christian glauben, meine Argumente widerlegt zu haben +
  • +
  • + es gab sowohl einen »Punktsieg« für Christian, insofern er pro forma sein Konzept akzeptiert bekommen hat. Aber es gab auch eine Nebenabrede, die er (zu mindest pro forma) zugesagt hat +
  • +
+ +
+
+
+
+ + + + + + +

+ Christian blieb im Projekt, das Projekt lief weiter, und ich habe von seinem Netzwerk profitiert +

+ +
+
+ + + + +

+ das eigentliche Projekt, das grade so hoffnungsvoll begonnen hatte, und das für mich so beglückend aussah, war mit einer Explosion untergegangen. Ich hatte gehofft, als einer von Gleichen, aufgrund meiner Fähigkeiten anerkannt zu werden, und gemeinsam etwas zu schaffen. Das war nun nicht mehr möglich; stattdessen mußte ich nun taktieren, lavieren und manipulieren. +

+ +
+ +
+ + + +
+
+ + + + + + +
Wow Du hast hast mächtig vorgelegtb mit deiner uml/wiki doc.
+
+Wie Du vllt siehst hab ich ausser bisschen wiki kosmetik noch nicht viel
+gemacht, ich schreib gerade mal was zum backend was ich hoffentlich
+nacher noch einchecken werde. Deine sachen hab ich alle bei mir gemerged
+und alles auch in den mob geschoben.
+
+Ich hab noch ein paar fragen/vorschläge:
+
+* Beim wiki mergen hatte ich den ersten conflikt der von hand aufgelöst
+werden musste. Beim schreiben von tiddern sollten wir drauf achten das
+sie mit einer 'newline' enden, damit das abschliessende <\pre> auf eine
+eigene zeile kommt, das sollte wesentlich besser zu mergen sein.
+
+* sollten wir nicht ein gemeinsames UML modell machen, dann kann man
+komponenten des andern mitbenutzen und wir sehen gleich wie das mit
+mergen der projectfiles klappt. Ausserdem muss man dann die
+konfiguration nur einmal pflegen.
+
+* Dein wiki-draft ist klasse (auch wenn ich noch nicht alles blicke,
+unfertig), aber wie stellst du dir das vor das man die daten pflegt? Ich
+wollte anfangs eigentlich nur 'source' files im git tracken und alles
+andere inklusive dokumentation wird dann vom build system gebaut. Jetzt
+wo ich dein wiki gesehn hab, bin ich aber überzeugt, das wir ruhig
+einige generierte sachen mit versioniern sollten. das problem ist nur,
+das so hinzubekommen das es sich immer noch einfach pflegen lässt.
+
+Vorschlag währe das man Bouml nach doc/uml/ generiern lässt
+....
+

+ (es flogt nur eine Diskussion wohin man Bilder und HTML generiert, und was man in Git eincheckt) +

+

+ +

+ +
+
+
+ + + + +
Voßeler Hermann wrote:
+
+
Hallo Christian,
+
+gestern hab ich zum ersten mal aus den bisher im UML angelgten Klassen
+Code generiert. Dazu bin ich erst mal auf einen eigenen Zweig
+"prototype" gegangen, den Du auch auf cinelerra3/ichthyo findest.
+
+
Check generierten code bitte nicht ein solange er 'nur' generiert ist,
+bzw bouml noch alles parsen kann (hatten wir schon mal drüber geredet).
+Ansonsten wollte ich mir das auch mal anschauen. Nebenbei hab ich noch
+einige probleme mich mit UML und Bouml anzufreunden.
+
+
+
+
Natürlich sind da jetzt jede Menge Fragen offen, so z.B. den 
+Einrückungsstil betreffend, die Paketstruktur, wie wir die 
+Namespaces handhaben etc. Kann man glaub ich alles besser 
+anhand von einem konkreten Beispiel diskutieren ��
+
+
Sollte im pipapo wiki passieren, damit zumindest Plouj und auch andere
+interessierte davon was mitbekommen anstatt privater mails.
+
+
+

+ (es flogt eine lange Diskussion über Details in meiner Mail...) +

+ +
+ + + + + + + +

+ Bis dahin war Christian immer sehr ermutigend, fand alles Toll, hat zu allem weitere (sehr sinnvolle) Vorschläge gemacht.... +

+ +
+
+ + + + +

+ das war mir damals zwar unbewußt aufgefallen, +

+

+ ich hatte es aber schnell wieder verdrängt +

+ +
+ + + +

+ Woher weiß ich das? +

+

+ Ganz einfach, ich hatte diese gesammte Mail-Kommunikation komplett und restlos vergessen; ich hatte vielmehr die Vorstellung, der Streit über Plug-Ins sei erst ein Jahr später ausgebrochen, als wir schon im Lumiera-Projket waren, und wir hätten dann den Streit "ausgeräumt" bei meinem ersten Besuch in Karlsruhe. +

+

+ +

+

+ Nun sehe ich diese Mails, und mir kommt sofort das Lebensgefühl von damals wieder, und ich kann mich an einzelne Details wieder erinnern, sogar was ich beim Schreiben einzelner Zeilen gedacht habe +

+ +
+ +
+ + + + +

+    
+
Vorhin hab ich gesehen, daß Du auch grade die ersten Schritte
+in UML gemacht hast; bin schon gespannt...
+
+
bin am fluchen, verdammt lange her das ich UML das letzte mal angeschaut
+hab, das war 1.0 und da hat sich einiges getan, ausserdem fehlen mir
+oder bouml einfach ein paar sachen um bestimmte dinge zu modelliern.
+
+	Christian
+
+
+ +
+ +
+
+ + + + + + + + + + + +

+ Er hat auf einem separaten 'prototype' branch anscheinend damit schon einen UML-generierten Satz an Klassen gebaut. Von diesem Prototype-Branch gibt es keine Spur mehr (wichtig! denn das zeigt, daß bereits vor Ende Juni mit Experimenten zur Klassengenerierung begonnen wurde) +

+ +
+
+ + + + +
Ichthyostega wrote:
+
+
So, could you please have a look at this prototype buildsystem? I pushed out to cinelerra3/ichthyo
+ #scons     - just the buildsystem
+ #prototype - contains the same code plus the files of my experimental/prototype branch to compile
+
+
morning, trying it out now ��, next i'll write some DesignProcess
+proposals about C nameing rules, plugins and interfaces. (i am back ;))
+
+note about gnu style: (how I/emacs interpret it)
+

+ .... +

+ +
+ + + + + + +

+ ganz klar eine Anspielung an "Terminator" +

+

+ ... wir hatten uns eingehend über die Filme unterhalten +

+ +
+
+
+
+ + + + +
+

+ After a talk on IRC ichthyo and me agreed on making lumiera a multi language project where each part can be written in the language which will fit it best. Language purists might disagree on such a mix, but I believe the benefits outweigh the drawbacks. +

+
+
+
+
+ ct +
+
+

+ 2007-07-03 05:51:06 +

+
+
+
+ +
+ + + + +

+ angeblich hätte er sich mir mir auf ein Multi-Language-Projekt geeinigt +

+ +
+
+ + + + + + + +

+ ist das möglich oder eine dreiste Lüge? +

+ +
+ + + + + + +

+ Der 3.7 war ein Sonntag, das heißt, ich mußte am nächsten Tag ins Büro, bin jedoch in diesen Jahren in der Regel erst Mittags dort gewesen. Es war sehr typisch für mich, in der Nacht Sonntag ⟶ Montag noch (zu) lange wach zu sein... +

+ +
+
+ + + + +

+ Also eindeutig mit Smily, und ich habe entsprechend witzelnd (und wie ich denke, deutlich) geantwortet; Christian hat daraufhin sofort einen Rückzieher gemacht. Mir erscheint es allerings plausibel, daß eine solche Diskussion in einer früheren, lockereren Phase stattfand, nicht in diesem bereits angespannten Moment.... +

+

+ Beachte dazu auch folgendes: der erste (wichtigere) RfC »All Plugin Interfaces are C« ist datiert auf 26.9. Nur dieser erste Kommentar trägt den Timestamp 3.7. — außerdem steht dort im Pro/Contra-Teil unter "Alternatives" +

+
+
    +
  • +

    + Just only use C++ +

    +
  • +
  • +

    + Maybe SWIG? +

    +
  • +
  • +

    + Implement lumiera in C instead C++ +

    +
  • +
+
+

+ Das würde dazu passen, daß Christian vorher schon mal vorgefühlt hat +

+ +
+
+ + + + +

+ Und zwar in mehrerlei Hinsicht. Zum einen, Christian hat den wichtigeren + grundsätzlichen RfC gar nicht erwähnt! (Ich hatte ihn + wahrscheinlich trotzdem schon bemerkt, ich war und bin in entscheidenden + Phasen immer sehr aufmerksam). Er hat im Mail-Austausch an eben jenem + Morgen geschrieben: +

+
morning, trying it out now ��, next i'll write some DesignProcess
+proposals about C nameing rules, plugins and interfaces. (i am back ;))
+

+ Natürlich könnte diese Mail für mich der Anlaß gewesen sein, nochmal + eben in den IRC zu schauen (es war 3 Uhr früh) und dann mit Christian + locker zu chatten. Warum hätte ich dann aber die Diskussion über den + GNU-Stil per Mail weitergeführt? Vielleicht, damit Plouj das auch + mitbekommt? Wäre nicht meine Art gewesen (typischerweise habe ich + wichtige Diskusionen explizit in einer Mail an alle zusammengefaßt). Und + es wäre total unplausibel, daß ich in einem Thread über GNU-Stil mich + ausbreite, aber das Thema »Multi-Language« überhaupt nicht erwähne, + obwohl es ein Punkt in einer dazwischenliegenden IRC-Diskusion gewesen + war. +

+

+ +

+

+ Was aber überhaupt sehr gegen einen möglichen mündlichen Beschluß am + frühen morgen auf IRC spricht: am nächsten Abend gehe ich auf das + gesamte Thema mit einer eMail ein, und erwähne explizit die + Einschränkungen durch plain-C als Bullet-point, mit einer grundsätzlich + reservierten bis ablehnenden Haltung. Ebenso spricht dagegen, daß ich + mir nur drei IRC-Logs aufgehoben habe, von denen das erste am 8.7. + zwischen Herman Robak und Christian stattfand (aus den IRC-Logs geht + auch hervor, daß ich zu der Zeit massiv unter Zeitdruck stand und grade + ein Orgel-Tonaufnahme-Projekt lief) +

+ +
+
+ + + + +

+ ich habe C-Funktionen stets nur als eine Konzession betrachtet +

+ +
+ + + +

+ Denn ich war bereits in den 90er Jahren ziemlich ablehnend gegenüber C (nicht C++). Ich hab die C-Kultur als eine Kultur der Schlaumeier und Taschenspieler betrachtet. Wenn ich also vor diesem Hintergrund nun sage, "es macht nicht Sinn, alles zwingend in Objekte zu packen", dann war das von mir als Ausdruck von Offenheit und Konzillianz gemeint. Ich wollte ausdrücken, daß ich kein OO-Fanatiker bin. Ich weiß auch sehr genau, daß meine Vorstellung ehr dain ging, daß man zwar ein *.cpp-File hat, in diesem aber nur Funktionen schreibt, die imperativ mit For-Schleifen etc. implementiert sind. Genau deshalb hat mich dann auch Christian's Versuch, reines C zu etablieren (später, wie es um main() und das Start-up ging), ziemlich empört. Ich fühlte mich ausgenutzt und betrogen, denn in meinem Verständnis hatte ich eben nur konzediert, daß man auch rein imperativen Code schreiben kann. +

+ +
+
+ + + + +

+ Nach dieser Leseart hätte es also zu dem Zeitpunkt keine entsprechende Diskussion auf IRC gegeben, aber Christian hat sich daran erinnert, daß ich einige Woche früher mal gesagt habe, es müsse ja nicht alles in Klassen gepackt werden, und für reine Video-Berechnung würde auch C gehen. Er hat das dann als Zustimmung aufgefaßt, und wollte jetzt ehr versuchen, das Gewicht insgesamt Richtung C zu verschieben, weil er sich eigentlich erhofft hatte, ein reines C-Projekt starten zu können, in das auch seine ganzen C-Tools gut reinpassen. Diese Lesart halte ich im Moment für die plausibelste Deutung. Insofern war es keine Lüge, sondern nur ein Manipulationsversuch, der mir zu dem Zeitpunkt sogar entgangen ist +

+ +
+
+
+
+ + + + + + +
Btw: seen my Interface / CStyleGuide proposal in the pipapo wiki? please
+review it carefully if it looks ok, I straight go into make a referene
+implementation, since this is a very low level building block.
+
+	Christian
+
+
+ +
+ + + + + +

+ "review it carefully if it looks ok, I straight go into make a referene implementation...." +

+

+ Ich lese das zwischen den Zeilen so +

+
    +
  • + bitte segnet mir das möglichst gestern so ab wie es ist +
  • +
  • + schaut besser gar nicht so genau hin, ich scharre bereits mit den Hufen +
  • +
  • + macht das Faß bloß nicht später noch mal auf!!!! +
  • +
+ +
+
+ + + + +

+ "since this is a very low level building block." +

+

+ Normalerweise verwendet Christian viel "very important". Hier verwendet er "very lowlevel", das klingt, als würde er die Sache herunterpspielen wollen. Hier könnte das noch ein Zufall sein, aber in dem nachfolgenden, sehr hitzingen Streit verwendet er exakt diesen Ansatz als Hauptverteidungunslinie (Ist ja nur ein Experiment, ist ja nur optional, ich will halt bloß keine Möglichkeiten abschneiden, wir können das alles noch diskutieren, es gilt ja nicht für das C++ Zeug) +

+ +
+ +
+
+ + + + +
+
Am Dienstag, den 03.07.2007, 20:51 +0200 schrieb Christian Thaeter:
+
+
+
+
Btw: seen my Interface / CStyleGuide proposal in the pipapo wiki? please
+review it carefully if it looks ok, I straight go into make a referene
+implementation, since this is a very low level building block.
+
+
+
+
yes, I have seen it this morning. I have to look at it more carefull
+tonight, when at home. Basically, it looks OK for all external
+interfaces, i.e. interfaces other external apps or components will use
+to call to cinelerra or to embed within cinelerra. Good examples for 
+this type of things are LADSPA plugins or some video codec interface
+
+For use /within/ the application we should consider the following
+questions first:
+* how much "plugin architecture" do we want? Does a "micro
+  kernel/plugin" aproach help? how then do we handle extension points?
+* why should we constrain ourselfs to just C linkage? For example for
+  the effects plugins it's just natural to require each plugin to define
+  a GUI object as well and then proxy the communication (Cinelerra2
+  basically does the same, just does it create two instances of each
+  plugin class, one for the processing and one for the gui). Same for
+  exceptions: they wouldn't be used so commonly if they weren't 
+  helpfull ��. On the other hand: for a data storage plugin/interface
+  I don't see much use in using classes at all because this is
+  procedural by nature. (Thats the point where people start intventing
+  all those silly singleton classes...)
+* the internal interfaces shouldn't be fixed this much, because this
+  hinders refacturing. Well, at least until we reach beta 0.98 ��
+
+Hermann
+
+
+
+
+

+ +

+ +
+ + + + +

+ effektiv ist das eine freundlich verpackte Ablehnung +

+ +
+
+ + + + +

+ hier sage ich explizit, und mir Argument, +

+

+ daß ich C als Einschränkung empfinde +

+ +
+
+ + + + +
    +
  • + als ein Wink mit dem Zaunpfahl („Junge, ich sehe was Du vorhast“) +
  • +
  • + zugleich als Einladung für eine fachliche Debatte mit Argumenten +
  • +
  • + ich mache hier explizit die Tür noch nicht zu, mache aber klar, daß ich seinen Ansatz nicht einfach durchwinken werde +
  • +
+ +
+
+ + + + +

+ Das meine ich als echte Frage, und die ist wichtig, zum Verständnis dessen, was dann geschah. +

+
    +
  • + ich war damals bereits seit mindestens 8 Jahren in einem Business-Kontext tätig und hatte jeden Tag diplomatischen E-Mail-Verkehr zu führen +
  • +
  • + ich ging aber naiver Weise davon aus, daß Christian (da er in meinem Alter ist), so etwas versteht +
  • +
  • + aus späteren Erfahrungen weiß ich inzwischen, daß viele Leute diese Sprachebene nur generell als bedrohlich empfinden, aber nicht verstehen +
  • +
+ +
+
+
+ + + + +

+ Christian antwortet am selben Abend völlig naiv und macht klar was er will +

+ +
+ + + +
Voßeler Hermann wrote:
+
+
Am Dienstag, den 03.07.2007, 20:51 +0200 schrieb Christian Thaeter:
+
+
+
+
Btw: seen my Interface / CStyleGuide proposal in the pipapo wiki? please
+review it carefully if it looks ok, I straight go into make a referene
+implementation, since this is a very low level building block.
+
+
+
+
yes, I have seen it this morning. I have to look at it more carefull
+tonight, when at home. Basically, it looks OK for all external
+interfaces, i.e. interfaces other external apps or components will use
+to call to cinelerra or to embed within cinelerra. Good examples for 
+this type of things are LADSPA plugins or some video codec interface
+
+For use /within/ the application we should consider the following
+questions first:
+* how much "plugin architecture" do we want? Does a "micro
+  kernel/plugin" aproach help? how then do we handle extension points?
+
+
imo as much as possible, I stated that the cinelerra main app should be
+only a skeleton using plugins. (do we want to start more monolithic and
+then factor plugins out, or plugins from start on?)
+
+Extensions shall be considered when designing this interfaces. I also
+considered to make the plugin interface extensible without breaking
+compatibility (naturally it will turn out whats needed during
+development of new features)
+
+consider my favorite example
+ (based on cin2, cin3 might be little diffrent):
+Cinelerra has tracks on the timeline, these tracks shall be plugins (we
+provide plugins for audio and video tracks, but someone might provide
+tracks for midi, 3D animation or such)
+
+Tracks have some gui components
+ 1. patchbay
+ 2. timline drawing (thumbs for video, waveform for audio, notes for
+midi, ...)
+
+some internal components:
+ 1. list of clips on the track
+ 2. attached effects container
+
+(and some more)
+
+we now need to define/collect what interfaces are needed to implement
+tracks. There will be not a single interface but a group of related
+interfaces which in sum define the behaviour and gui rendering of a track.
+ * cinelerra_track_gui_patchbay_interface
+  defines the patchbay gui
+ * cinelerra_track_gui_timeline_interface
+  how timeline is rendered
+ * cinelerra_track_effects_container_interface
+  manage effects on the track
+ * cinelerra_track_clips_interface
+  manages clips (add/remove, order, ...)
+
+
+these 'tracks' use in turn other interfaces we define, effects, codecs, ...
+
+
+for effects plugins this is quite similar, we need at least a interface
+for the gui component and one for the internal workings.
+
+
+
+
+
* why should we constrain ourselfs to just C linkage? For example for
+  the effects plugins it's just natural to require each plugin to define
+  a GUI object as well and then proxy the communication (Cinelerra2
+  basically does the same, just does it create two instances of each
+  plugin class, one for the processing and one for the gui). Same for
+  exceptions: they wouldn't be used so commonly if they weren't 
+  helpfull ��. On the other hand: for a data storage plugin/interface
+  I don't see much use in using classes at all because this is
+  procedural by nature. (Thats the point where people start intventing
+  all those silly singleton classes...)
+
+
The Idea is here to make it possible to write plugins in any other
+language, C bindings are the best thing to make this possible. The
+downside is that glueing C++ is not effortless. I think it's still worth
+it, but this is just a proposal.
+
+
+
+
* the internal interfaces shouldn't be fixed this much, because this
+  hinders refacturing. Well, at least until we reach beta 0.98 ��
+
+
yes, my proposal only applies to 'external' interfaces. Unfortunally many
+interfaces are considered external by this plugin architecture (whatever
+we provide for us, we provide for people extenting it too)
+
+
+

+ +

+ +
+ + + + +

+ Das geht mir jetzt so, und das ging mir vermutlich damals nicht anders. +

+

+ Wenn ich darauf eingehen müßte: ich wüßte nicht, wo ich anfangen soll mit dem Argumentieren... +

+ +
+
+ + + + +

+ Und damit meine ich eine Applikation, nicht OS-level Code. +

+
    +
  • + Man hat ein GUI-Framework, mit Widgets. Die muß man beim Start gemäß ganz bestimmten Regeln einhängen, danch gibt es nur noch Event-Handling +
  • +
  • + In einem Track liegt eine Datenstruktur, die mit der Engine/Core und (bei naiver Herangehensweise) auch mit dem GUI geteilt wird. Wie soll man das "mal eben" in ein Plugin packen? Und dann sollen andere Leute im Stande sein, das durch ihre Lösung zu ersetzen??? +
  • +
+ +
+
+ + + + +

+ Er skizziert ja, wie er sich das vorstellt: +

+
we now need to define/collect what interfaces are needed to implement tracks.
+

+ Das ist das gefürchtete "dann kann man" ... und andere Leute sollen sich gefälligst mal den Arsch aufreißen, ich hab euch jetzt das Prinzip gezeigt. +

+

+ +

+

+ Chistians Vorschlag operiert auf einer formal-strukturellen Ebene: er definiert ein Schema der Machbarkeit, und da dieses offensichtlich aufgeht, ist er zufrieden und hält das für eine gute Idee — alles Weitere sind die "lots of details are still in progress to be worked out" wie er typischerweise schreibt. Dazu kommt bei Christian stets dieses Bild von der Community, die letztlich entscheidet, wohin es gehen soll, und insofern kommt es erst mal nur darauf an, etwas angefangen zu haben, was unfertig genug ist, damit andere Leute da einsteigen können. (Achtung: mir erscheint diese Haltung komplett unplausibel — und deshalb muß ich sehr vorsichtig sein, Christian nicht falsch zu „lesen“: er meint das Ernst und sieht seinen Beitrag als einen ordentlichen Schritt in die richtige Richtung) +

+ +
+
+ + + + +

+ Das macht diesen Vorschlag so »entwaffnend«: +

+

+ +

+

+ Wenn Du gesehen hast, wie eine Code-Basis degeneriert und kaum noch zu handhaben ist, dann stellst Du einen Bezug her zu gefährlichen Methoden und Ansätzen. Das läßt sich aber niemals belegen. So jemand wie Christian kann das immer einfach vom Tisch wischen, und behaupten, das läge nur an XYZ (zum Beispiel, weil man C++ verwendet hat). +

+

+ +

+

+ Wenn man einen Anfänger hat, der mit solchen Ideen um die Ecke gebogen kommt, dann sagt man (wenn man Zeit hat und freundlich ist): "setzt Dich mal hin und mach das so, und wir schauen uns das Ergebnis zusammen an...."  Dann läßt man den Junior rudern, bis er völlig verzweifelt ist, und reitet ihn immer tiefer rein. Und dann zeigt man ihm, wo er falsch abgebogen ist. +

+

+ +

+

+ Aber das Problem ist, ein 40-jähriger Mann mit robustem Selbstbewußtsein, der sich selbst als "Coder" definiert, wird sich niemals auf ein solches Setting einlassen. Das war mir klar (und leider ließ sich nicht vermeiden, daß wir diese unapetittliche Erfahrung dann später auch noch konkret durchbuchstabieren mußten, als es um Thread-Wrapper, Lock-Checker und den MPool ging) +

+ +
+ +
+ + + + +

+ Fazit: ich stecke nun bis über die Ohren in der Scheiße +

+ +
+ +
+
+
+ + + + + + + +

+ Er findet Macros gut, ist stolz auf sein Programmierschema mit "goto" und besteht darauf, daß man auf einem gemeinsamen Datenmodell arbeiten muß, weil was anderes mit C ja nicht geht. (Die beiden letztgenannten Punkte ergänze ich aus der Erinnerung, sie gehen nicht aus den Mails hervor. Es könnte auch sein, daß Christian diese Punkte erst später ausgeführt hat — aber es war zu diesem Zeitpunkt mit wünschenswerter Klarheit deutlich, daß er alle die Argumente gegen das imperative Programmieren entweder nicht kennt, oder nicht gelten läßt. +

+ +
+
+ + + + +

+ C++ Klassen sind immer "fett", C-Interfaces sind immer schlank und klar. Abstraktionen und Interfaces werden mit C++ assoziiert und als kompliziert und schwierig dargestellt +

+ +
+
+
+ + + + + + + + + + + + + + + + +

+ Wenn man diese Mail unvermittelt liest, kann man nur den Kopf schütteln. Ich greife mir einen Widerspruch in Christians Aussagen heraus, und leite daraus die Forderung nach Entscheidung ab; aber diese Entscheidung treffe ich sofort selber, auf argumentativer Ebene: Etwa so: Es gibt bei diesem Thema hier nur einen Ansatz, der nicht Unfug ist, und der ist sehr aufwendig und komplex. Spielraum für Abwägungen und Auslegungen lasse ich keinen. +

+

+ In der Sache ist das tatsächlch zutreffend, aber weder gibt es einen allgemeinen Konsens in der Richtung (damals noch viel weniger als heute), noch ist es angemessen, ein solches Thema der Haltung und Präferenzen derart kagetorial zu behandeln.... +

+

+ Im Rückblick deute ich das wie folgt +

+
    +
  • + tatsächlich sah ich dahinter eine Haltung, die mir zuwiderläuft, die ich aber nicht argumentativ zu fassen bekomme +
  • +
  • + ich wollte eine sich abzeichnende Tendenz mit einem Überraschungs-Schlag abschneiden, weil ich sonst keine Möglichkeit sah, das grade noch so hoffnungsvoll begonnene Projekt fortzusetzen +
  • +
+

+ Das bedeutet: mein Handeln war aus meiner Sicht ein Befreiungsschlag, und zielte darauf, das ansonsten Unvermeidliche doch noch überraschend wenden zu können: daß ich nämlich das Projekt aufgeben muß, mit dem ich mich grade eben sehr stark identifiziert hatte (denn in 2007 gabe es mehrere dieser atmosphärischen Umschläge, auch in meinem eigenen Leben; zudem tauchte ein sehr ähnlich gelagerter Konflikt bereits sehr bedrohlich mit meinen Kollegen und meinem Chef auf) +

+ +
+ + + + + +

+ Christian war einfach nicht zu stoppen. Er labert und labert und labert und hört nicht zu. Er hat mich auch etwas von oben herab behandelt, in dem Sinn "hehe, der Typ mit Java und der Bank, die arbeiten doch nur mit bloatware, also sind seine Urteile mit Vorsicht zu genießen..." +

+

+ +

+

+ Dazu kam, daß Cehristian immer im IRC war und viel mit dutzenden Leuten geredet hat, während ich under Mehrfachbelastung stand, und auch generell nicht arbeiten konnte, während ich ein IRC-Log beobachte; Christian konnte das sehr gut, aber er hat nicht genau gelesen und selten wirklich mitgedacht, sondern nur auf Stichworte reagiert. Deshalb: ich mußte mir Gehör verschaffen. +

+

+ +

+

+ Mein Argument war differenziert, Christian hatte eigentlich gar kein Argument, sondern eine Überzeugung. +

+ +
+
+
+
+ + + + + + +

+ Es könnte sein, daß Christian verstanden hat, daß ich angreife, daß er aber meiner Argumentation überhaupt nicht folgen kann, weil er gedanklich „anders abbiegt“ (z.B. weil er gewisse Argumentationsschritte von mir nicht versteht, weil ihm der Kontext fehlt, und er sie dann als „unverständlich“ abtut, und meinen Gedankengang anders „interpoliert“). Er macht in dieser Diskussion Statements, die man eigentlich gar nicht mehr so machen kann, wenn man auch nur einen Teil der Disussion der vorausgegangenen 10 Jahre zum Thema Architektur und Methoden bewußt gelesen und nachvollzogen hat. Diese Beobachtung ist mir damals komplett entgangen. +

+ +
+ +
+
+ + + + + + + +
    +
  • + Du hast das in die falsche Kehle bekommen +
  • +
  • + Du unterstellst mir etwas, was ich niemals wollte (was eine dreiste Lüge ist) +
  • +
  • + geziehltes opportunistisches Mißverstehen +
  • +
  • + behaupten, das Argument des Gegeners wäre nicht schlüssig +
  • +
  • + ein Argument des Gegners konntern mit "kannst Du das mal erklären?" +
  • +
+ +
+
+ + + + + +

+ Ich deutet das so, daß ich durch meinen Angriff einer Vision den Boden entzogen habe, die tatsächlich für Christian sehr bedeutend war. Im Rückblick gibt es dutzende Belege dafür in den Dokumenten. Mir war das damals jedoch nicht klar, und ich dachte, es würde helfen, das Thema nachzuschärfen; meine vorgetragene Problemanalyse war ja weithin bekannt und diskutiert worden in den vorausgegangenen Jahren. Vermutlich hatte ich sogar damit gerechnet, daß sich eine Diskussion über eine Plugin-Architektur besser führen läßt, als eine Diskussion um die grundlegende Haltung zum Programmieren. +

+ +
+ +
+
+ + + + +

+ Bei der Lektüre jetzt bekomme ich den Eindruck, daß das passiert, weil ich vor der Konsequenz ausgewichen bin, den dahinter liegenden Grundsatz-Streit direkt auszutragen. Ich habe mich stattdessen auf die Frage nach einer Plugin-Architektur konzentriert, was Christian damit gekonntert hat, daß er das ja gar nicht will — wobei jede seiner sachlichen Ausführungen dem explizit widerspricht. Dadurch war ich durch ein Double-Bind gefesselt (und das war nicht das erste Mal, daß mir das in meinem Leben passiert ist). +

+

+ In den folgenden Jahren bin ich, in vielen ähnlich gelagerten Debatten-Situationen (vor allem in meiner Tätigkeit bei der Bank) graduell zu der Einsicht gekommen, daß es darauf ankommt, wer als erster die gemeinen Tricks anwendet, sobald eine Debattensituation eigentlich entschieden ist, aber keiner der Gegner aufgeben möchte. +

+

+ +

+

+ Auf die Situation hier übertragen, würde dieser Ansatz etwa so funktionieren: (Christian): "Aber das will ich ja gar nicht" (Ich): OK, dann war dieses Proposal ein Irrtum und wir können es in aller Form verwerfen. Um es gleich in aller Form festzustellen, eine Plugin-Architektur geht nur »ganz oder gar nicht«, jede Lösung darunter ist gefährlich, und wir schließen das daher explzit aus. Plugins für einzelne Fälle werden wir später brauchen, und wir vertagen die gesamte Techologie bis auf diesen späteren Zeitpunkt" (ich weiß aus praktischer Erfahrung, daß man leider einen solchen Satz in einer persölichen Diskussion dem Gegenüber ins Gesicht brüllen muß, sonst gibt er nicht auf). Mit hoher Wahrscheinlichkeit ist eine konstruktive Zusammenarbeit danach aber nicht mehr möglich +

+ +
+ +
+ + + + +

+ Ich bin jetzt erstaunt, welche bedeutende, und auch besonnene Rolle dieser Mann in den ersten Wochen gespielt hat. Das war mir komplett entfallen. +

+ +
+ + + + +

+ Sein Vorschlag +

+
    +
  • + Christian entwickelt tatsächlich mal seinen Plugin-Loader fertig und implementiert einige Beispiel-Plugins +
  • +
  • + Hermann baut eine Struktur mit Modulen + Abstraktionen +
  • +
  • + dann versucht man, diese mit Christian's System in Plug-ins zu verwandeln +
  • +
+ +
+
+ + + + +

+ Und (daran erinnere ich mich jetzt sogar wieder) das habe ich nicht als Taktik oder Heimtücke empfunden, denn ich hatte doch meine Argumente in der grundsätzlichen Mail komplett offen dargelegt; diesen Argumenten zufolge wird dieses Experiment vorhersagbar scheitern. +

+ +
+
+ + + + +

+ Sehr aufschlußreich wie Christian pariert: das wäre Zeitverschwendung. Er will die Grundsatz-Entscheidung jetzt (zu dem Zeitpunkt, wo wir, in gemeinsamen Verständnis, tatsächlich zu coden anfangen) +

+ +
+
+
+ + + + +

+ Christian will das System jetzt öffnen und die Entscheidung darüber fixieren +

+ +
+
+
+ + + + +

+ 11.7 : Christian erklärt den Plugin-RfC einseitig für anerkannt +

+ +
+ + + +
+

+ after a talk on irc, we decided to do it this way, further work will be documented in the repository (tiddlywiki/source) +

+
+
+
+
+ ct +
+
+

+ 2007-07-11 13:10:07 +

+
+
+
+ +
+ + + + +

+ Der Grund ist aus den IRC-Logs ersichtlich: Christian und ich hatten uns wiederholt auf IRC nicht getroffen (ich war extrem mit Arbeit überlastet in der Zeit, Orgel + Cin-2 + Baaderbank). Ich hatte am 10.7. eine Diskussion mit Plouj + Hermanr (aber Christian schlief um die Zeit). Plouj hat das IRC-Log an Christian weitergeleitet, der es dann selektiv in seiner Mail gequotet hat, aber nicht auf meine Argumente eingegangen ist +

+ +
+
+ + + + +

+ Chistian nimmt Auszüge aus IRC, gequotet in der Mail, und setzt darunter jeweils ein Statement, das das Gegenteil von dem argumentativen Stand einfach affirmiert. +

+

+ +

+

+ Die Diskussion scheint allerdings in einem versönlichen Tonfall zu enden — ohne jedoch den Dissens auszuräumen +

+ +
+
+ + + + + + +

+ Das Log dazu habe ich aufgehoben in meinem privaten Trac. +

+

+ Daraus geht auch klar hervor: das war die einzige Debatte mit Christian auf IRC. Somint ist das Bild vollständig. +

+ +
+ +
+ + + + +

+ Er hat mich selten überhaupt ausreden lassen. Er hat permanennt auf einzelne Stichworte reaagiert, und diese nach seiner Sicht »entkräftet«: +

+
    +
  • + Gegenargument-A : ich will das ja gar nicht was Du mir unterstellst, aber wenn wir alles in Plugins verwandeln und jeder alles aufrufen kann, dann wird das System so toll +
  • +
  • + Gegenargument-B : aber das ist doch eine Trivialität, die kann man technisch lösen. Ich bau Dir das alles ein, nur mußt Du jetzt erst mal meiner Vision zustimmen +
  • +
+ +
+
+ + + + +

+ Nicht wirklich, aber im Zusammenhang war das der Eindruck +

+
    +
  • + es gibt nie und nirgends ein Statement von Christian, in dem er einen Kompromiß bestätigt oder in seinen Worten affirmiert +
  • +
  • + aber er sagt permanennt, er wolle das ja alles gar nicht, und wir können das immer noch entscheiden +
  • +
  • + er schlägt stets technologische Lösungen vor gegen meine grundsätzlichen Einwände. Er verspricht dann sogar, das zu bauen (was er nie getan hat) +
  • +
+ +
+
+ + + + + +

+ Christian hat wohl geglaubt, mit ein paar mündlichen Zusagen hat der diesen ängstlichen Typen jetzt ruhiggestellt, und sein Ding ist durch. Und es ging ihm vermutlich darum, Code vorlegen zu dürfen. Er glaubte wohl, wenn man erst mal seinen Code sieht, dann wären alle Mißverständnisse ausgeräumt, und es würden dann alsbald die Wunder geschehen, von denen er überzeugt war; daher war vermutlich das sein einziges Ziel, und deshalb war er auch mündlich bereit, so viele Zugeständnisse wie möglich zu machen, bis zu dem Punkt, daß er sich selber komplett widerspricht. Er dachte vermutlich, er muß dieses Ding jetzt nur reinbekommen, und alles wird gut, alles weitere wird sich dann schon von selber zeigen, Leute werden Plugins in Massen schreiben, die Creativität pur bricht aus, und dieser komische Bank-Mensch, wer redet dann noch über den...? +

+ +
+
+
+ + + + + + + + + + + + + + +

+ ich kann mich jetzt wieder erinnern, +

+

+ das als eine Niederlage empfunden zu haben. +

+

+ Ich hab mich elend gefühlt. +

+ +
+ + + + +

+ Im Rückblick halte ich es für wahrscheinlich, daß ich dieses ziemlich dreiste Vorgehen von Christian nicht sofort und auch (bis jetzt nicht) in vollem Umfang realisiert habe. Den Status des RfC als "final" habe ich natürlich irgendwann gesehen, möglicherweise hat mich Christian sogar darauf hingewiesen. Und ich habe dann wohl geschluckt, und gemerkt, daß mir nach all dem Streit jetzt praktisch nichts anderes übrig bleibt, als so zu tun, als wäre das belanglos +

+ +
+
+ + + + +

+ im Rückblick nicht klar: warum habe ich den Kompromiß nicht explizit klargestellt? +

+ +
+ + + + + + +

+ Ich hätte sofort eine Mail rumschicken können, in dem ich den Kompromiß aus meiner Sicht zusammenfasse, und die von Christian zugesagten Punkte festnagle. +

+ +
+
+ + + + +

+ ...nachdem Christian den RfC unqualifiziert für angenommen erklärt hat, hätte ich entweder ihm gegenüber daruf bestehen können, daß er die Einschränkungen im Text aufführt (das wäre ein direkter Affront und Chistian würde dann weiter versuchen, zu manipulieren) oder ich hätte den RfC einfach editieren können, die Einschränkungen im Text vermerken, und das mit einem Kommentar bestätigen "ich habe diesem Vorschlag nur unter den genannten Bedingungen zugestimmt) +

+ +
+
+
+ + + + +

+ Das ist ausschließlich Spekulation bzw. Interpolation. +

+

+ Meine Erinnerung hat sich überlagert mit den späteren Erfahrungen +

+ +
+ + + + +

+ ...allein schon von dem Umstand, daß wir nun plötzlich diese Diskussion haben; möglicherweise war ich noch voller Begeisterung und Drive und habe das Verhältnis zu Christian als kollegial und wohlgesonnen empfunden (was es bis vor kurzem war). Dieser Hypothese zufolge habe ich den Streit aus Notwehr vom Zaun gebrochen und war bloß froh, daß der Tonfall am Ende versöhnlich war, und es weiterging. Ich wollte zu dem angenehmen Zustand zurück +

+ +
+
+ + + + +

+ Dieser Hypothese zufolge wäre es mir unangenehm gewesen, daß dieser Streit plötzlich so eskaliert ist. Ich wäre dann bloß froh gewesen, daß es nochmal "mit einem blauen Auge" abgegagen ist und kein Bruch daraus entstanden ist. Ich wäre froh gewesen, daß das Thema jetzt vom Tisch ist und wir uns mündlich auf einen vernünftigen Kompromiß geeinigt haben. Es hätte mich dann zwar gewurmt, daß Christian den RfC unqualifiziert als "angenommen" markiert, aber ich hätte dann gegen mich selber argumentiert, das solle man mal nicht zu wörtlich nehmen und darauf herumreiten, eigentlich hat er ja nix falsches gesagt. Insgesamt hätte ich damit geglaubt, wir hätten einen Dissens gehabt, und uns dann "unter Männern" geeinigt, und beide würden sich selbstverständlich an die Absprache halten. +

+ +
+
+ + + + +

+ Für diese Hypothese habe ich keinerlei Anhaltspunkt, sie wäre aber durchaus plausibel, gemessen an meinem allgemeinen Verhalten: wenn mir Wertschätzung entgegengebracht wird und wenn ersichtlich auf meinen Beitrag geachtet wird, dann erzeugt das bei mir ein starkes Verpflichtungsgefühl und eine starke emotionale Bindung (weil es mir in meinem Leben bis damels ehr selten zuteil geworden ist, jenseits der Familie). Demnach wäre mir emotional vor allem daran gelegen gewesen, den angenehmen Zustand aufrecht zu erhalten, und ich war froh, den (notwendigerweise gestarteteten) Konfilkt einigermaßen gut wieder losgeworden zu sein. (dafür würde auch sprechen, daß ich grade zu der Zeit von mehreren anderen Seiten erheblich unter Druck stand) +

+ +
+
+ + + + +

+ Dieser Hypothese zufolge hätte ich die Situation strategisch eingeschätzt, und mich auf mein professionelles Urteil verlassen, dem zufolge die Versprechungen von Christian zwangsläufig an der Wirklichkeit scheitern würden. Es wäre mir demnach lediglich darum gegeangen, genügend »Bremse« gegeben zu haben, so daß Christian nicht unmittelbar loslegt und ein Kettensägenmassaker anrichtet. Für den Rest hätte ich mich darauf verlassen, daß er nicht viel zustande bringen wird und daß ich eventuelle Restprobleme später schon noch abgebogen bekomme, z.B. indem ich dann im Einzelfall eben ekelhaft auf Qualitätsmerkmalen bestehe (die er mit seinem Plan niemals wird erfüllen können). Ich habe keinerlei Anhaltspunkt ob diese Hypothese irgendwie gerechtfertigt ist, und ich damals so gedacht haben könnte; jedenfalls im Rückblick wäre das eine realistische Einschätzung gewesen. Es ist ja exakt so gekommen, wie ich in meinem Einwand vorhergesagt habe: es werden immer Wunder versprochen, aber praktisch bleiben diese Art "leichtgewichtigen" Plug-ins praktisch bedeutungslos. +

+ +
+
+ + + + +

+ Dieser Hypothese zufolge hatte ich mich plötzlich in einem spannenden Projekt gefunden (was ich als Glücksfall betrachte) und hatte schon Ideen, mit denen ich mich identifiziere und die ich realisieren möchte. Daher wollte ich bloß diese sich plötzlich auftuhenden Hindernisse aus dem Weg haben, und nachdem das "nach Bauchgefühl" der Fall war, war mir alles egal, solange ich mit dem Zeug weiter machen konnte, was ich wollte. Dieser Hypothese zufolge hätte ich mich rein opportunistisch verhalten (interesssanterweise exakt genauso wie Christian, wenn man eine ähnlich gelagerte Leseart anwendet, was heißen würde, wir waren uns insgeheim einig) und hätte keinerlei Bewußtsein dafür gehabt, was eine solche Haltung für die Zukunft bedeutet. Mein Verhalten im nächsten halben Jahr würde ziemlich gut zu dieser Hypothese passen +

+ +
+
+ + + + +

+ dieser Hypothese zufolge wäre ich zu der Einschätzung gelangt, daß es unmöglich ist, im Augenblick mehr zu bekommen, als ich konkret hatte: nämlich die Möglichkeit, ungestört weiterzumachen plus eine mündliche Zusage von Christian, daß er jetzt nicht durchmarschiert und sich an die Einschränkungen hält. Im Besonderen wäre meine Einschätzung dieser Hypothese zufolge gewesen, daß Christian ein »Festnageln« als ungeheuerlichen Affront versteht, und mich entweder sofort vor die Tür setzt (er hatte die technische Hoheit über die ganze Infrastruktur), oder aber sich dann der Streit endlos fortsetzt, mit dem Ergebnis, daß wir anschließend auseinandergehen, und das schöne Projekt gestorben wäre, bevor es begonnen hat +

+ +
+
+
+
+ + + + + + + + + +

+ ich kann jetzt den Zusammenhang gedanklich fassen +

+ +
+ +
+
+
+
+ + + + + + +

+ Einige erfahrene Männer, die allesamt ihr Handwerk verstehen, gehen mit einem gemeinsamen Werk vorran und leiten eine Bewegung ein. +

+ +
+ +
+ + + + + + +

+ allerdings nie irgend etwas zum DataBackend +

+ +
+
+ + + + + + + + + + + +

+ er hat sich dann zu 150% auf das uWiki geworfen +

+ +
+
+
+
+ + + + + + + + +

+ und zwar passiert hier bereits der Streit über die Plug-in-zentrische Architektur +

+ +
+ +
+ + + + +

+ Ich hatte mir gemerkt, daß wir auf der Terrasse in Karlsruhe saßen, und das Thema angesprochen haben. Das war aber mindestens ein Jahr später. Außerdem habe ich mir gemerkt, daß es irgendwie mit dem Thema Application start-Up zusammenhing. Das wäre sogar zwei Jahre später.....

Wie sich nun eindeutig aus den Quellen ergibt, sind alle diese Erinnerungen zwar korrekt, ich habe aber die falschen Schlüsse gezogen. Der eigentliche Streit ist sofort ausgebrochen, nachdem wir begonnen haben, ernsthaft zusammezuarbeiten. Das ist auch plausibel so. Die späteren Erinnerungen hängen damit zusammen, daß wir wohl beide (Christian und ich) dem Streit ausgewichen sind, weil wir das Bauchgefühl hatten, daß er nicht lösbar ist. Auch diese Einschätzung ist wohl korrekt, es stehen Fragen der Weltanschauung dahinter. +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ....und hab auch tatsächlich Fortschritte gemacht, wenngleich die auch komplett im Mißverhältnis standen zu der Absicht, die ursprünglich hinter diesem Prototypen stand: +

+
    +
  • + eine funktionale Skizze für eine Render-Engine zustande zu bekommen +
  • +
  • + beispielhaft einen neuen Coding- und Kollaborationsstil zu etablieren +
  • +
  • + dieses dann zu verwenden, um den Umbau von Cinelerra anzugehen +
  • +
+ +
+
+ + + + + + +
mark carter schrieb:
+
+
Maybe a lot of my problem is that I'm new to the code. Coming in from
+fresh on such a big project is bound to be daunting,....
+
+
well, but my personal experience was that, contrary to other projects,
+things get worse when you get accustomed. Trying to work with the
+current codebase is just plain frustrating, you find yourself
+fighting against windmills all the time.
+
+
+
+
Looking at the codebase, I realise that there's quite a lot of it, and
+think that a ground-up rewrite is likely to be doomed. I think that we
+must find a way of remoulding the existing code into a more stable form.
+
+
This indeed /is/ a big problem.
+At the moment I just choose to ignore it and picked me one region, namely
+the render engine / render pipeline and rewrite that one. Christian concentrates
+on some aspects of file handling media loading.
+ +
+
+ + + + +
At the moment I just choose to ignore it and picked me one region, ...
+ +
+
+
+ + + + +

+ gemeint war, Lumiera ist ein Projekt, das auch heroischen Einsatz einfach spurlos aufsaugt, wie ein trockener Schwamm +

+ +
+
+ + + + +

+ »Weihnachten« ist insofern wichtig, als ich im Sommer das Gefühl hatte, bis Weinachten zusammen mit Christian eine laufähige Renderengine „auf die Beine stellen“ zu können. Ab August wurde die Arbeit bei mir „zäh“, jeodoch habe ich diese zeitliche Vorstellung immer noch irgendwie im Kopf gehabt, Stichwort »hart arbeiten«. Das war das Muster: wenn ich wirklich alle Kraft und Entschlossenheit einsetze, dann kann ich (toller Hecht) das doch nageln. Das war in früheren Projekten, seit meiner Studienzeit, immer wieder die Situation gewesen, und es war dann auch jeweils (mit gewissen Einschränkungen) erfolgreich; dieses Muster war Teil meines Selbstverständnisses, damals. +

+

+ +

+

+ Insofern gibt der »Visitor« einen wichtigen Hinweis: der sollte ja ultimativ das Grundgerüst für den Builder sein — ein Thema, an dem ich laut offizieller Verlautbarung den ganzen Herbst gearbeitet habe. Tatsächlich hatte ich nur Objektmodell über Objektmodell geschichtet und getestet, und versucht, im Design Mechanismen und Primitive zu entwerfen, mit denen sich das Thema packen ließe (die Builder-Mould, der Operation-Point). Kurz vor Weihnachten habe ich mich dann gewissermaßen auf die Framework-Ebene geflüchtet, und dort eine Ersatz-Schlacht  geschlagen und „gewonnen“: ich habe das (bekanntermaßen problematische) GoF-Pattern (das mich immer schon fasziniert hatte) durch eine techologische Lösung ersetzt, die ich nach einiger Recherche im Internet aus bestehenden Ansätzen entwickelt habe: einen Tabellen-getriebenen Visitor, der „azyklisch“ ist, Subklassen-Semantik unterstützt (»is-a«) und durch Template-Metaprogramming realisiert wird. Das hat dann doch bis in den Januar gebraucht, ich hab meinen gesamten Feitertags-Urlaub pausenlos durchgecodet, das Ergebnis ist wohl tatsächlich eine Leistung (nach der bloß niemand gefragt hat) — und am Ende stellte sich heraus, daß ich damit den »Builder« nicht „packen“ kann, da die Objekte eingepackt in Smart-Pointer daherkommen. Danach habe ich den Sarg mit dem WrapperPtr zugenagelt und mich Scheiße gefühlt. +

+ +
+ +
+
+
+ + + + + + +

+ z.B. wir sollten doch alles in QT bauen, weil es dadurch viel einfacher wird, und obendrein auch gleich noch portabel +

+ +
+
+ + + + + + + + + +

+ Wichtig: er hat sich nie in dieser Rolle „gesonnt“ — sondern sets die festgelegten Formeln wiederholt und auf meinen Beitrag eigens hingewiesen +

+ +
+
+ + + + + +

+ Bis zum Frühjahr 2008 hat Christian absolut nichts mehr zum eigentlichen Coding beigetragen, sondern immer mehr seine Vision betont, daß durch distributed Tooling und ein offenes Projekt-Setup die Probleme von Open-Source (die sich damals schon sehr deutlich zeigten) aufgebrochen und gelöst werden könnten. Man muß nur „die Community enablen“, damit diese „als Benevolent Dicatator agieren kann“ +

+ +
+
+
+ + + + + +

+ Ich bekam Reichweite, die ich mir selber niemals hätte aufbauen können: denn bedingt durch den sonderbaren Zustand, daß ich allein weiter gecodet habe, wurde mir regelmäßig das Wort erteilt und ich konnte mich als Experte bewundern lassen +

+ +
+
+ + + + + +

+ ...das in diesen Monaten im Herbst vor allem dadurch getragen war, daß man nur hart genug arbeiten muß, dann kann man es nageln. Niemand hat mehr nach einem Projektplan gefragt, niemand wollte erklärt haben, wie das überhaupt zusammenpaßt (mit Cinelerra). Außerdem habe ich in der Zeit überhaupt erst C++ gelernt (das geht bei mir üblicherweise sehr schnell), viele neue Paradigmen aufgegriffen und mich bis Dezember sogar in das (damals total esoterische) Thema »Template-Metaprogramming« hineingebissen. Ich hatte nun in kurzer Zeit einen anderen Horizont gewonnen, und fand meine Ansätze aus dem Herbst (mit den Assets und MObjects) bereits problematisch, hab davon aber niemanden was gesagt (und es bisweilsen sogar vor mir selbst verborgen) +

+ +
+
+
+
+ + + + + + +
    +
  • + für Christian: einfache Lösungen + distributed Tooling wird es richten +
  • +
  • + für mich: man muß nur moderne Methoden einsetzen und hart arbeiten. +
  • +
+ +
+
+ + + + +

+ Zunächst einmal sogar die Frage, ob das noch Cinelerra ist, oder schon eine neue Applikation; auch die Frage, warum man überhaupt ein solches Projekt starten sollte („the world needs Lumiera“). Aber auch auf technischer Ebene, wurden Mystifikationen eingesetzt und durch stetige Wiederholung affirmiert: Da ist zum einen das DataBackend (für das, so muß man jetzt im Rückblick sagen, fast überhaupt nichts jemals implementiert wurde, mit Ausnahme der Memory-mapped Files), des Weiteren sind da die Placements, die auf viele Jahre hinaus aus „da kann man“ bestanden, die Config-Rules waren (für mich offensichtlich) ein Fernziel, das ich aber sehr oft in der öffentlichen Diskussion als Pluspunkt aufgeführt habe; ganz ähnlich steht es mit den Plug-ins: Christian hat über ein Jahr lang nichts Konkretes mehr zu dem Thema gesagt oder getan, aber die flexiblen Plugins waren weiterhin einer der immer wiederkehrenden Bullet-points. Und den Builder habe ich nach Januar 2008 erst mal liegen gelassen, und das auf verschiedene Weise plausibel gemacht. Damit war effektiv der Prototyp aufgegeben, und es wurde stattdessen die große Architektur gebaut. +

+ +
+
+
+ + + + + + + + + +

+ Raffaella und Odin haben dieses Moment aufgegriffen — +

+

+ und in die Naming- / Logo-Contests übersetzt +

+ +
+
+ + + + + + + + + + + + +

+ ...das heißt, ich habe dazu keinen Beschluß gefaßt, das weiß ich ganz genau; vielmehr brauchte Joel nund einen Gegenpart, und ich hab mir sofort dafür den Arsch aufgerissen und geliefert. +

+ +
+
+ + + + + + +

+ August 2008 war ich zum ersten Mal in Karlsruhe (für mich ganz besonders magisch, denn ich hat aus meinem früheren Leben eine sehr tiefe Beziehung zu Karlsruhe), habe bei Christian übernachtet, und wir haben so manche Streitigkeiten auf der Terasse sitzend geregelt, „von Mann zu Mann“. Das hatte dann auch in vieler Hinsicht den Charakter eines Vertrages, wir haben Claims abgesteckt. Anschließend sind wir zusammen zur FrOSCon gefahren, für mich das erste Mal. Und anschließend habe ich den Kontakt mit meiner Verwandtschaft in Hagen wieder aufgenommen (Hagen hat für mich eine ähnlich tiefe Bedeutung, auch da reichen die Bezüge in meine Schulzeit zurück) +

+ +
+
+
+
+
+ + + + + +

+ ohne sie explizit breitzutreten! +

+ +
+ + + + +
    +
  • + durch Kurzschließen entstehen Kräfte ... und mit modernen Tools verstärken sich diese Kräfte +
  • +
  • + da ist eine große Codebasis, die bereits was taugt und zu dem gemacht werden könnte, was sie immer schon sein wollte +
  • +
+ +
+ + + + +

+ Wir hatten den »Drive« und wir hatten ein Konzept, das in überschaubarer Zeit machbar erschien +

+ +
+
+ + + + +

+ Denn die beiden Elemente stammen aus einem komplett unterschiedlichen, und inkompatiblen Hintergrund; das Konzept, das (wenn ungefähr betrachtet) so plausibel erschien, läßt sich zwar realisieren, aber nur durch sorgfältiges, planvolles Vorgehen und Festhalten an einem Ziel. Also eine extrem lange Zeit ohne »Begeisterung« und »Inspiration« +

+ +
+
+ + + + +

+ Damit meine ich: ein »Mission Statement« und ein »Projektkonzept«, das plausibel und machbar erscheint, und nicht „völlig durchgeknallt“ +

+ +
+ + + + +

+ ...und anfangs auch tatsächlich plausibel war +

+ +
+
+ + + + + +

+ hier meine ich mit normaler Dynamik: Man geht in einer freien Community auf Nahziele zu, baut, was man sich leicht vorstellen kann und was kurzfristig Spaß machen kann. All das konnte sich in der festgefahrenen Projektstruktur nicht entfalten. Das Projekt war „langweilig“ und hatte keine Drive +

+ +
+
+ + +
+ + + + +

+ man hat sich auf einen Weg gemacht, +

+

+ auf den man sich vernünftigerweise +

+

+ niemals gemacht hätte +

+ +
+ + + + + + + + + + + + + +

+ Erzählen auf dem Grundton: das kann doch nicht gutgehen... +

+ +
+ + + + + + + +
+ + + + + + +

+ das Thema der Flexibilität +

+ +
+ +
+ + + + + + +

+ ...das ist tatsächlich die Vision, die sich jetzt abzeichnet; mit »vertikal« meine ich, daß sie von low-level bis high-level integriert sind und kohärent bleiben ⟹ »medium level of abstraction« ⟹ wir schaffen kein Wunderding, sondern ein Werkzeug mit Kraftverstärkung +

+ +
+
+
+
+ + + + + + + + + + + + + + + + +

+ Benny hatte schon vor Monaten gesagt, +

+

+ ich möge ihn da einbeziehen +

+ +
+ + + +

+ ...und zwar hatte ich angedeutet, daß ich irgendwann den Disput über Plug-ins irgendwo als Text fassen muß; Benny sagte dann, es erscheine ihm plausibel, daß ich das möchte, aber ich solle bitte den Text von ihm gegenlesen lassen, bevor er irgendwo veröffentlicht wird; ich halte das auch für angemessen, und war/bin Benny sehr dankbar... +

+ +
+ +
+ + + + + +

+ Damit meine ich: soweit der Impetus im Moment trägt, also bis in das 1.Jahr. Insgesamt möchte ich den Text noch weiter führen, kann das aber im Moment sicher nicht stemmen. Nun habe ich also den Text erst mal entworfen, dann die Quellen ausgearbeitet und dann den Text ausgefeilt. Er soll schließlich mit einem einzigen Commit online gestellt werden, ohne viel Aufhebens. +

+ +
+
+ + + + + + + + + +

+ danke Benny! +

+ +
+ +
+ + + + + + + + + +

+ we don't say this in this context. Does transliterate refer to 'meaning', +

+
'spelling', ... but not 'format'. I'm not entirely sure; but it is not
+
_generally_ used like this. But I am nearly certain you will find it
+
as a special process in, for example, a group of Archeologists where
+
transliterate has a special meaning only to this group.
+ +
+ + + + + + + + + + + + + + + + + + + + + + + +

+ Fix because 'properly' is here coloquial because, again, it is +

+
    ambiguous. Does 'properly' refer to the process of providing the
+
    credit, i.e., it was only written on a piece of paper, .. i.e.,
+
    'how' the credit was down; or is the creditation inappropriate?
+
    
+
    This kind of error is something similar to the many errors Trump
+
    makes and upsets many jurnalists, as the ambiguity is often
+
    critical and is much discussed on the BBC
+ +
+ +
+ + + + + + + +

+ also ist Benny's Vorschlag inhaltlich viel bessern +

+ +
+
+
+ + + + + + + +
Lately i had almost no time to hack on cinelerra and it doesn't seem
+that situation will improve in forseeable future.
+ +
+
+ + + + + + + + + + +

+ ich muß hier eine Deutung machen, um den Sachverhalt klar zu fassen +

+ +
+ + + +

+ Andraz hat es in seiner Mail "durch die Blume" gesagt, und die Community (oder zumindest die aufmerksamen Leser, hehe) haben verstanden, in welche Richtung das geht, ohne konkreter zu werden. +

+ +
+
+ + + + + + + + +

+ insofern: Benny's Formulierung ist sogar sehr gut, sie ist nämlich dezent +

+ +
+
+
+ + + + +
+ + + + + + + + + + + + +

+ Christian hat nicht bloß mal ein Git-Repo eingerichtet, sondern er hat sich, so meine Deutung, davon erhofft, daß die Kombination von Technik und "kurzgeschlossener" Community von selber Heilungskräfte entfaltet. Das würde auch erklären, warum er... +

+
    +
  • + grade eben keine Initiative vorschlägt +
  • +
  • + auch später sich stets weigert, "Cinelerra-3" als seine Initiative zu bezeichnen +
  • +
  • + "Cinelerra-3" nicht auf seinem Server hosten möchte, sondern alles in Git-Repos haben möchte +
  • +
  • + andauernd sagt: "the community shall be the benevolent dictator" +
  • +
+ +
+
+ + + + +

+ es sind jetzt ein paar Wochen vergangen; und ehrlich, für diese Einschätzung brauche ich Benny nicht. Es wäre nur schön gewesen, ihn mitzunehmen... +

+ +
+ + +
+
+ + + + + + + +

+ Andraz: "Leute, ich kann nicht mehr!" +

+

+ User-1 sagt, "ich hab da mal nen Patch" +

+

+ Cehteh: "und übrigens ich bastel an meinem Git-Branch, aber ich trage nix bei, sondern baue eine andere Infrastruktur" +

+ +
+
+
+ + + + +

+ auch die zweite Korrektur ist wohl stilistischer Natur (wäre interessant, Benny dazu zu befragen! Möglicherweise wieder so ein Fall, in dem sich Pidgin-English breit gemacht hat....) +

+ +
+ + + + +

+ ich kann nicht einschätzen, +

+

+ ob Benny hier nur auf "gutem Englisch" herumreitet +

+ +
+ + + +

+ Ich bin immer wieder am Zweifeln, inwiefern Benny mit verschiedenen Sprachebenen umgehen kann. Selbstverständlich kennt er das Konzept, er hat mir oft Beispiele genannt, wie ein Adeliger reden würde. Dann macht er mir aber anderseits immer wieder Vorschläge, die für mein Ohr sehr "literarisch" klingen, und auch sehr "brittisch". Er korrigiert auch Redewendungen, die in der gedruckten Fachliteratur weit verbreitet sind. Außerdem habe ich immer wieder gemerkt, daß Benny keinerlei Sinn für das Verkürzen von Formulierungen hat, und sachen klarstellen möchte, die ich bewußt zweideutig gehalten habe. Er sagt dann auch immer, das sei grammatikalisch, ist es aber nicht (in dem Sinn, daß es einem in der Schule als Fehler angestrichen würde, man aber durchaus so reden und schreiben kann) +

+ +
+
+ + + + + + + + + + +

+ eine Qualifikation ist m.E. hier komplett überflüssig, aber es sollte gesagt werden, daß es sich um Git Repos handelt, und nicht um Subversion +

+ +
+
+
+
+ + + + + + + + +

+ Please check: i think you mean 'general' here +

+
    
+
'Common', here means 'working class' or cheap (and bad).
+
    But please check
+ +
+
+ + + + + + + +

+ Create our own toolset to track issues, tasks, bugs in a distributed manner. +

+ +
+
+ + + + +

+ Und mir fällt auf, daß dies sein erster inhaltlicher RfC war +

+ +
+
+ + + + +

+ Er "mag keine Mailinglisten", er mag keine Foren, er findet Bugtracker eine einzige Müllhalde und sagt, er will nicht damit arbeiten. Er lästert bei jeder Gelegenheit über Spreadsheets, er kotzt über Projektplanungstools ab, er findet Wikis nur eine Krücke und will sie schnell wieder loswerden, er findet die typischen Buildserver total daneben (Cruise-Control damals, dann Hudson, Jenkins). Und, was mich völlig von den Socken gehauen hat: vor zwei Jahren wurde er plötzlich ganz leidenschaftlich wegen Ethereum, er fand das System sowas von verkünstelt und overengineered, und gradezu gegen den "spirit" von Blockchain. Auch gegen Bitcoin ist er ehr negativ eingestellt, denn es wäre ja bloß "Kapitalismus pur" ... und dann fängt er leidenschaftlich an, seine Vision von einem Geld zu entwickeln, das auf Community-Tasks beruht und Austausch von Hilfe. +

+ +
+
+
+
+ + + + + + + + + +

+ wäre schön wenn man das noch dikutieren könnte, aber eigentlich geht es nur um Nuancen in der Bedeutung. Ich bin mir ziemlich sicher, daß Christian nicht "Microsoct Projects" durch Git-Magic ablösen wollte, sonder ehr der Meinung war, wer MS Projects verwendet, ist sowiso krank +

+ +
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +

+ versuche die grammatikalische Verbesserung aufzunehmen, +

+

+ bleibe aber bei meiner Formulierung "without a clear Resolution" +

+ +
+ + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + +

+ Benny hat sich jetzt 3 Wochen nicht mehr gemeldet, daher konzentriere ich mich nun auf das Wesentliche und räume solche Nebenthemen einfach ab +

+ +
+ +
+ + + + +

+ There appears to be widespread consensus that simple building blocks should be provided as free software, that “can be used to combine new functionality” +

+ +
+
+
+ + + + + + + + + + + + + + +

+ Die Frage ist: gehe ich mit dieser Mutmaßung zu weit? Es ist schon starker Tobak +

+ +
+ +
+ + + + + + + + + + + + + + + + +
+
+ + + + +

+ Die Umstände sind nicht ganz klar — seinem Nachbarn (Fritz) geht es schlecht, und die Heizung ist (jetzt wohl endgültig) kaputt, und was sonst noch so durch den Wind is... +

+ +
+ + +
+ + + + + + + + + + +

+ ...denn ich habe sie ganz bewußt in eine größere Aufräum-Aktion mit eingebunden; die Texte müssen also in der Git-Historie in diesem Kontext stehen, weil dadurch auch meine Entscheidungen in den RfCs mit in den Kontext gestellt sind. Außerdem habe ich den sehr gewichtigen Essay zur Komplexität geschrieben, der die adäqate Antwort auf den Streit zur Plugin-Architektur darstellt. Und all das zusammen ist jetzt »dezent versteckt« in einem riesigen Schall an genereller Aufräum-Arbeit, die ich nunmehr gut zuende gebracht habe. +

+ +
+ +
+ + + + +
+
+ + + + + + + + + + + +

+ Ohne ein solches Verzeichnis sieht man nur eine endlose Historie von Git-Commits über mehr als 10 Jahre, und kaum ein Thema „führt zu Ergebnissen“. Erst in den letzten Jahren ist durch die »Vertical Slices« soetwas wie eine Fürhungslinie gegeben +

+ +
+
+ + + + + + +

+ Vorausgegangen war Cehteh's letzter Vorstoß in Richtung einer Plug-in-Architektur, der damit endete, daß Ichthyo sein Konzept der Applikations-Struktur mit den Subsystemen durchgeprügelt hat. Das mündete in eine allgemeine Integrationsphase, in der die Code-Struktur und die Build-Systeme glattgezogen wurden, und das GUI als Plug-in integriert +

+ +
+
+ + + + + +

+ und hat begonnen, dicke Bretter zu bohren: +

+
    +
  • + Command-Handling Framework +
  • +
  • + Node-Wiring / Factory +
  • +
  • + Placement-Index +
  • +
  • + Placement Scope-Path und QueryFocus +
  • +
+ +
+
+ + + + +

+ man hat wohl ein ganzes Jahr lang zwar die Meetings aufrecht erhalten, aber nur sich informell ausgetauscht +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + +

+ Das ist wichtig für mich selber: denn ich habe sehr unter diesen Konflikten gelitten. Nur fanden sie gar nicht wirklich statt, sondern bestanden in einer Diskrepanz zwischen dem Stand, den ich mir erarbeitet habe, und den endlos-eintönig-immer-gleichen Klischees, die von den anderen Entwicklern und Usern kamen. Insofern habe ich noch eine Rechnung offen mit dieser »Community« — aber diese Rechnung hat hier nichts zu suchen. Im Grunde habe ich alles Wichtige bereits in meinem Essay »Complexity and Flexibility« gesagt.... +

+ +
+ +
+ + + + + + +

+ die Darstellung könnte sich vor allem +

+

+ auf die kollektiven Aspekte konzentrieren +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Technologie wird dabei eine »Mystifikation« und wird zum »Fetisch« — aber das ist nur oberflächlich. Die Technologie (konket: Git, Automatisierung, Plug-ins) soll nämlich eine Art Marktplatz der Ideen herstellen. Und der eigentliche, weltanschauliche Kern ist, daß »die Community« wie eine unsichtbare Hand alle Probleme löst, und man deshalb sich gedanklich nicht weiter anstrengen muß, ja sogar gar nicht darf, weil man sonst das heilsame Wirken der Marktkräfte stört. +

+ +
+ +
+ + + + +

+ verstehe dies Verhalten als ein Anti-Pattern — dem man verfällt +

+ +
+
+ + + + +

+ Die Komplexität sorgt dafür, „daß die Bäume nicht in den Himmel wachsen“ — und demütigt den sich aus dem Anspruch der Technik ergebenden Herrschaftsanspruch. Der Komplexität kann man nur standhalten, durch Verzicht auf Wunder und durch Selbstbeschränkung auf einige wenige Themen. +

+ +
+
+
+ + + + +

+ Lumiera ist entstanden durch meine Verstrickung in diesen Konflikt +

+ +
+ + + +

+ Ohne diese Verstrickung, und das damit verbundene Verfallen und die fehlende Reflexion, wäre dieses Projekt niemals zustande gekommen. Ich habe eine dialektisch-verhaftete Position eingenommen, die durch diesen Konflikt überhaupt erst ihre Form bekommen hat. Durch meine Hartnäckigkeit habe ich dem Projekt in der Anfangsphase den Weg zum »Erfolg« abgeschnitten. Dann aber passierte ein Wechsel des allgemeinen Klimas (der sich im Grunde bereits von Anfang an abgezeichnet hat). Das Resultat ist nun, daß ich, ganz allein, auf dieser Position stehe und über den damit verbundenen Anspruch bestimmen kann (solange niemand anders daherkommt — und auch nur wenn ich diesen Weg entschieden weiterverfolge). +

+ +
+
+ + + + +

+ ich sehe jetzt in dieser Position eine Chance +

+ +
+ + +
+
+
+
+
+
+ - + + + + + + + @@ -161568,9 +166917,13 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + @@ -161594,13 +166947,109 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + + + +

+ Geschrieben 10/2025 infolge der Auseinandersetzung mit den Anfängen des Lumiera-Projekts und implizit als Antwort auf den nie wirklich gelösten Architektur-Streit +

+ +
+ +
+ + + + + + + + + + + + + +

+ Das ist entstanden, weil Benny zunächst allgemein helfen/beitragen wollte; ich habe vorgeschlagen, er solle sich mit dem Thema Video-Output beschäftigen, unter der Maßgabe, ob es da bereits fertige und einfach nutzbare Frameworks gibt. Er hat dann relativ bald sich auf GStreamer konzentrierte, sehr schnell ein Tutorial-Beispiel gehabt für einen Video-Player, ist an der Stelle aber stecken geblieben. Im Rückblick muß ich sagen, daß GStreamer für unser Thema vermutlich keine gute Quelle ist — man bekommt nur ein massives Framework zu fassen — allerdings hat sich Benny auch nicht selbständig lateral bewegt. Im Frühjahr 2025 haben wir überlegt, was wir zur FrOSCon machen könnten; es war bereits beschlossen, daß wir nun jedes Jahr mit mindestens einem Vortrag präsent sein wollen. Ich hatte dann die Idee, diese Recherche gemeinsam weiterzuführen, da ich die Ergebnisse nun absehbar demnächst brauche, um die Engine zu testen. +

+ +
+
+ + + + + +
+
+ + + + + + + + +

+ ...der findet sich in der Seite project/credits.html und besteht aus einem speziellen CSS + ein JavaScript, das die Seite langsam scrollt. +

+

+ +

+

+ Relevant ist hier vor allem der Content, denn das war der erste Versuch, Attribution zu geben (und bisher auch die Basis des AUTHORS file) +

+ +
+
+ + + + + +

+ ....anhand der Git-Logs nach Auslassungen suchen; dann aber auch die Darstellung etwas rebalancieren, denn die entspricht mehr dem Eindruck aus der Anfangszeit, als jeder kleine Beitrag bejubelt wurde — aus heutiger Sicht haben wir einige substantielle Beiträge, die in dieser ganzen Masse an Credits untergehen, während Sachen hervorgehoben werden, die letztlich nie zustandegekommen sind (uWiki, Builddrone, neues Website-Layout, Christian's DataBackend) +

+ +
+ +
+
+
- + + + + + + + + + + +

+ Wir sollten darauf achten, auf den oberen Ebenen die Anzahl der Kategorien knapp zu halten — um eine gewisse systematische Auffindbarkeit zu gewährleisten; im Gegenzug dazu sind weitere Unterkategorien auf tiefer geschachtelten Ebenen eine praktisch kostenlos verfügbare Ressource, da die Kapazität eines Baumes exponentiell mit der Tiefe wächst +

+ +
+ + + + +

+ Wenn die Design- und Archtektur-Bereiche zu sehr in die Details abgleiten, fächern sie sich in technische Belange auf, welche nicht mehr so recht systematisch in eine Kategorie passen wollen. Für die technische Dokumentation ist das kein Problem, denn diese ist ohnehin quantitativ ausgelegt. +

+ +
+
+
+
+ @@ -161675,6 +167124,443 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + +

+ wie so oft hatte Christian eine ganz pfiffige Lösung, die zu kurz greift aber in die richtige Richtung zeigt (und auf die man erst mal kommen muß!) +

+ +
+ + + + + +

+ es gibt einen RfC: »WebsiteSupportMarkup« +

+ +
+
+
+ + + + + +

+ Die Implementierung braucht sehr wahrscheinlich einen kompletten Scan über alle Dokumente; das zu vermeiden führt direkt in ein DB-basiertes CMS. Daher, gemäß KISS sollte man erst mal versuchen das zu implementieren und beobachten, wie groß der Schmerz ist. Auch Menuegen selber war mal in zwei Tagen implementiert, ist schwer zu warten, aber erfüllt seinen Zweck inzwischen seit mehr als 10 Jahren +

+ +
+ +
+ + + + +

+ Das größte Problem ist wohl, daß wir nicht genau wissen, was wir brauchen (abgesehen von der Vorstellung, irgenwie magisch funktionierende Cross-Links zu bekommen)... +

+
    +
  • + wir wollen ein Tag-System, welches um weitere Quellen erweitert werden kann +
  • +
  • + wir wollen möglichst mit dem Taggen anfangen können, bevor unser Konzept wirklich klar ist +
  • +
  • + es schwirren viele Ideen herum bezüglich generierter Übersichtsseiten; was uns aber tatsächlich weht tut, ist die Schwierigkeit, Cross-Links in der Dokumentation zu verwenden. +
  • +
+ +
+
+ + + + + + + +

+ nun sind wohl 10 Jahre vergangen +

+

+ und das Problem besteht unverändert +

+ +
+ + + +

+ ...was aber vor allem daran liegt, daß ich allein bin und für mich sowiso alles per Mindmap organisiere; daher konnte ich das Problem bisher »aussitzen« — was aber leider dazu geführt hat, daß das TiddlyWiki (und meine Mindmap) ins Unermessliche gewachsen sind. Dennoch ist das Problem eigentlich brennend ernst: außer mir blickt keiner durch, und ohne mich findet niemand die Ergebnisse der umfangreichen Konzeptionsarbeit. +

+ +
+ + + +
+ + + + + + + +

+ Dieser Vorschlag stammt von Christian, und (selbst wenn der Vorschlag zunächst in zweifelhaftem Kontext stand) — es ist die einzige bisher vorgeschlagene Lösung, die mit einfachen Mitteln umsetzbar ist, letztlich sogar ohne jedwede Automatisierung +

+ +
+
+
+ + + + +

+ ...all die weiteren seinerzeit hitzig diskutieren »Killer-Features« sind meines Erachtens Extras, die man oben drauf setzen kann; auch Übersichts- und Kategorieseiten erreicht man letztlich wieder über einen ID-Link. Der einzige Knackpunkt ist, das Eingangs-Format der Links so hinzubekommen, daß es tragfähig ist. +

+ +
+
+ + + + + + +

+ Micro-HTTPD expandiert nicht automatisch *.html +

+ +
+
+ + + + +

+ Aus mehrerlei Gründen +

+
    +
  • + weil wir generell in der Adresszeile die kanonische URL sehen wollen +
  • +
  • + weil das Navigationsmenü nur mit der kanonischen URL funktioniert +
  • +
+ +
+ + + + + +
+ + + +
+ + + + + + + + +

+ »solange Vorrat reicht« — die ganze Frage der Duplikat-Resolution kann später auf technischer Ebene gelöst werden, solange es nur für jede verwendete ID einen Link gibt +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Die aktuelle Struktur ist aus Kompromissen entstanden und gewachsen, erfüllt aber derzeit noch ihren Zweck. Trotzdem ist die Website-Infrastruktur etwas mühsam. +

+
    +
  • + Es ist verwirrend, daß Content in mehreren Repos ist +
  • +
  • + Bilder sind in Git eingecheckt und stellen mithin ein latentes Problem dar +
  • +
  • + man ist daher gezwungen, Bilder in einen separaten Bereich zu legen +
  • +
  • + daher ist Content „kreuz und quer“ verteilt und oft nicht leicht zu finden +
  • +
+

+ Bei der Diskussion (mit Benny, in Bernbach, August 2025) ist uns aufgefallen, daß die Website eigentlich gut auf das Muster von Git-Submodulen passen würde. Es werden wohl weitere Module dazukommen, vor allem durch die von mir geplante »Knowledge Base«. Allerdings bedeuten Git-Submodule dann aber auch ein Anheben der Komplexität im Umgang mit der Website; man muß wohl zusätzliche „Handgriffe“ sich einprägen, oder die Automatisierung weiter treiben. Wir haben beschlossen, damit so lange zu warten, wie der Zustand mit den Bildern/Medien im »website-Repository« noch tragbar ist; perspektivisch werden wir die »documentation«-Struktur dann wohl doch aus dem Haupt-Repository herauslösen, vielleicht auch nur das eigentliche User-Manual. +

+

+ Die einzige Maßnahme, die wir nun unmittelbar umsetzen, ist, die Symlinks aus Git herauszunehmen — so daß man per manueller Einrichtung auf einer Maschine gleichzeitig mehrere Varianten der Website haben kann +

+ +
+
+
+ + + + + + + + + + + + + + + + +

+ ...was ich super finde! +

+

+ Denn dadruch wird eine Seite auch neu gerendert, wenn sich ein Include geändert hat, oder das page-Template +

+ +
+
+ + + + +

+ wodurch diese neuer wird als das zugehörige HTML — und damit von der eigentlichen Render-Schleife in build_website.sh aufgegriffen... +

+ +
+
+
+ + + + + + + +

+ auf jeder Seite steht im Footer das Datum der letzten Änderung gemöß Git +

+ +
+ +
+ + + + + + + + + + + + + + + + + + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...der Grund liegt in der Pflicht zur Bereitstellung der "Quellen". Das zwingt im Zusammenhang mit allgemeinen Inhalten wie Text, Bild und Video zur Auslegung, und dadurch wird die Situation rechtlich zweideutig. Theoretisch wäre das kein Problem, aber praktisch kann es ein Hindernis darstellen für jemanden, der lediglich gestalterischen Content  weiterverwenden und umgestalten möchte, also in unserem Fall Texte und Bilder. Daher bieten wir eine Wahlmögichkeite der Creatvice-Commons-By-SA, denn diese verpflichtet nicht zur Bereitstellung eines Quelltextes. +

+ +
+
+ + + + + + +

+ Einschätzung: ja +

+ +
+ + +
+ + + + +

+ ABER: das verpflichtet UNS, die CC-By-SA einzuhalten +

+ +
+ + + +

+ Und zwar deshalb, weil es nur einen kompatiblen Pfad gibt von CC-By-SA ⟶ GPL-3. +

+

+ Deshalb müssen wir die Vereinigungsmenge der Forderungen beider Lizenzen erfüllen, was aber möglich ist.... +

+ +
+ + + + +

+ ...hier müssen wir aufpassen. Da die CC-By-SA nicht auf Quellcode abstellt, muß die Attributierungs-Information jeweils auch textuell nahe bei dem jeweiligen Content aufgeführt sein. +

+ +
+
+ + + + +

+ ...das tun wir, unser Git-Repo ist öffentlich und die veröffentlichten Webseiten werden aus Asciidoc generiert. Für Bilder halten wir die bestmögliche Auflösung bereit, bzw. verwenden SVG, wo möglich +

+ +
+
+
+ + + + + + +

+ das heißt, mal eben den Spell-Checker laufen lassen, oder den Markup reparieren ist noch kein Beitrag, der eine Autorenschaft konstituiert. +

+ +
+
+ + + + + +

+ ABER: jeder relevante Autor eines Textes / Bildes muß im Text selber aufgeführt sein +

+ +
+ +
+ + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
@@ -161690,11 +167576,15 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + - + + + + + @@ -161709,10 +167599,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + - - + + @@ -161740,7 +167631,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161756,8 +167647,21 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + +

+ DEB-Paket: direkt <v%(version)s>-Tag von master verwenden +

+ +
+ + +
- + + @@ -161770,7 +167674,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161953,10 +167857,65 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + - + + + + + + + + + + + + +

+ Wobei allerdings (gemäß meinen Erfahrungen bei der Bank) die CI explizit so aufgesetzt werden muß, daß sie verschiedene »Linien« nicht vermischt. Es ist nicht möglich, die CI-Builds allein durch die Versionsnummer zu steuern. Vielmehr muß es eine dedizierte CI geben für +

+
    +
  • + Produktionsstand +
  • +
  • + Releases in Arbeit +
  • +
  • + Fixes in Arbeit +
  • +
  • + Integration +
  • +
  • + Feature-Development +
  • +
+ +
+
+ + + + +

+ ...so daß die unqualifizierte Version auf dem Integration-Branch die geringste Prio hat (am ältesten sortiert), Features danach stehen, und mit Timestamp markierte explizite Snapshots die höchste Prio haben +

+ +
+ + + + + + + + + + + + + @@ -161973,6 +167932,121 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo

+ +
+ + + + +

+ ...da in Git-Tags keine Tilde erlaubt ist, hat git-buildpackage hier eine Übersetzung in '_' eingeführt +

+ +
+ + + + + + + + +

+ ...denn dummerweise ist '_' ein word-constituent-char, d.h. die vorhergehenden Versions-Komponenten würden einen Trenner durch '_' einfach mit konsumieren +

+ +
+
+ + + + +

+ Gemäß Debian-Policy ist das nämlich der Trenner zum Paketnamen, und darf daher in der nachfolgenden Versionsnummer nicht nochmal vorkommen (d.h. der letzte Underscore trennt den Namen von der versionsnr) +

+ +
+
+
+ + + + + + +

+ ist so möglich, da Underscore anderweitig nicht erlaubt ist (und Grenzfälle können hier unberücksichtigt bleiben, da letztlich in Lumiera nur sinnvolle und valide Versionsnummern vergeben werden dürfen; als zusätzilcher Filter dient das mandatory-prefix 'v*' im Tag +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Und zwar temporär, während man auf dem Release-Zweig ist, kann es ein RC-Tag geben. Wenngleich auch die (von mir intendierte) Git-flow policy verlangt, daß solche RC-Tags mit dem Release selber wieder gelöscht werden — man wird sie aber zulassen müssen, damit später mal eine CI korrekt mit Release-Candidates umgehen kann. Die Realität ist komplex. Seufz. +

+ +
+ + +
+ + + + +

+ Drei Varianten wären denkbar, diese hier erscheint mir am praktischten, und natürlichsten (und ist einfach umzusetzen, ohne den Parser komplexer zu machen +

+ +
+ + + + + + +
    +
  • + man kann argparse.SUPPRESS verwenden +
  • +
  • + man nargs='?' setzen, und zudem einen Default angeben; damit ließe sich der Wert zur Option seinerseits optional machen... +
  • +
+

+ Dadruch würde aber der Aufruf komplexer, da nun der 'suffix' key möglicherweise nicht mehr im resultierenden dictionary nach Parser-Auswertung enthalten wäre. +

+ +
+
+
@@ -161986,6 +168060,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
+ @@ -161993,31 +168068,614 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
- - - - + + + + - + + + + + + + + + + + + + + + + + + + + +

+ Das war praktisch der Anfang der Diskussion, Benny sagte, die Einleitung wirke steif, und hat einige Vorschläge im Chat skizziert +

+ +
+
+ + + + +

+ ...aus dem, was ich geschrieben habe, aber nur der 2. Hälfte, und Benny's Formulierung, die um einiges glatter wirkt, da sie mehr an weithin aktzeptierte Formulierungen anknüpft. Das halte ich aber nun auch für besser, da es ja nur zum Thema hinführen soll. +

+ +
+
+
+ + + + + + +

+ "is established" ist zweifellos eine viel dezentere und neutralere Formulierung, aber weicht eben auch einer Aussage in der Sache aus. Das ist immer wieder der Konflikt zwischen uns Beiden; ich mache die Aussage in der Sache ja, weil ich einen Gedankengang entwickle, anstatt nur bekannte Umstände möglichst geläufig anzusprechen; damit ist meine Formulierung meist schwierig und herausfordernd. Nachdem dann Benny einmal alles geglättet hat, stößt er dann auf die Kernaussage und sagt: das ist jetzt aber komisch, wie kommst Du da drauf? Und in der Tat, nachdem der ganze Gedankengang in der Sache weg ist, ist die Aussage, bei der der Gedankengang ankommen sollte, nur noch beliebig und far fetched. +

+

+ +

+

+ Da ich diese Erfahrung in der Zusammenarbeit mit Benny nun schon oft gemacht habe, weiß ich, daß ich an zentralen Stellen den Konflikt suchen muß. Denn letztlich bin ich es, der einen Gedanken sieht und einen Entwurf macht. Würde Benny, auf seine Weise, etwas Entsprechendes tun, ich wäre der letzte das anzugreifen...! +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ siehe deutsche Wikipedia +

+ +
+
+ + + + +

+ siehe englische Wikipedia +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ TODO this commit requires a review +

+
    
+
'essence' does not work here. Don't know why, probably gramatical; but I
+
know what you'd like too say.
+
The problem with my suggestion, 'core', ist that core has several meanings.
+
One meaning refers to responsibility or location. So making an insigificant
+
code modification in this area; which is noot the meaning you intended with
+
'essence'. However 'core' can also mean 'essence'....so this is ambiguous using
+
core.
+
    
+
    'fundamental operation of the code base' might be better suited; but everyone
+
    gets 'core' immediately.
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...will sagen, er hat den generischen Ausdruck gewählt, den ich ganz bewußt nicht genommen habe, der eigentlichen Aussage wegen. Das hatten wir schon mehrfach. +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ A complex integration process is also +

+

+ required for large and intricately structured systems: changes will first be accommodated within a subsystem, +

+

+ which is followed by joining subsystem branches into a new state of integration +

+ +
+
+ + + + + + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ebenso hier: das meiste ist sehr gut, +

+

+ aber manches versteht Benny anscheinend nicht +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ was für einen native speaker schwierig zu verstehen ist, läßt er nicht gelten +

+ +
+ + + + + +

+ interessanterweise beharrt er darauf, +

+

+ das sei rein grammatikalisch +

+ +
+
+ + + + +

+ Das passiert uns immer wieder mal, bei der Arbeit an einem Text. Und es handelt sich immer um Gedanken, die man sehr wohl im Englischen ausdrücken kann (siehe die Übersetzung philosophischer Werke, daher habe ich es ja) aber die Engländer und Amerikaner der Tendenz nach nicht gebrauchen; und das liegt wohl mehr in ihrer eigenen Kultur: die Esssenz, der Wesenskern, ein Begriff der diesen trifft — so etwas ist ihnen suspekt, das erscheint ihnen wie ein "Label" das man künstlich draufklebt +

+ +
+ +
+ + +
+
+ + + + +
+ + + + + + + + + +

+ Dieser gegenwärtige Trend ist kein Pendelschlag in die andere Richtung, und es geht nicht darum, die bewährten alten Methoden gegen Neuerungen zu positionieren. Allerdings laufen die propagierten Methoden im Grunde auf eine Restauration hinaus; es werden wieder mal Tools und Technologien propagiert, allerdings unter dem Thema einer aggressiven Beschleunigung und Steigerung +

+ +
+
+ + + + + + + + + + +

+ Rein der Sache nach wäre auch nicht mehr notwendig; was derzeit an Argumenten vorgebracht wird ist vor allem dummes Zeug, formuliert von Leuten, die keine Erfahrung haben, und wieder einem naiven Technik-Glauben anhängen.... +

+ +
+
+ + + + +

+ ich vermute aber, dahinter steht eine ernst zu nehmende Tendenz: Industrialisierung +

+ +
+ + + + + + +

+ Das ist ein Geschehen, das nicht „absichtlich betrieben“ wird, sondern sich den Menschen aufdrängt, in der Form eines Anspruches: Sachverhalte und Umstände erscheinen plötzlich in einem anderen Licht, in einem Zusammenhang, und diejenigen, die das nicht sehen, nimmt man plötzlich als unmoralisch wahr. +

+ +
+
+
+ + + + + + + + + + +

+ und impliziert eine Gegenposition — ohne sie direkt zu bezeichnen +

+ +
+ + + +

+ Ich würde diese Gegenposition wie folgt charakerisieren: „egal was von Deiner Industrialisierung zu halten ist — Erfahrung brauchst Du trotzdem, Entscheidungen wirst Du weiterhin treffen müssen, und den Grenzen Deiner Fähigkeiten entgehst Du nicht“ +

+ +
+
+
+ +
- + + + + + + +

+ Und zwar aus mehrerlei Gründen +

+
    +
  • + didaktisch: mein Text operiert auf einem abstrakteren Level als der Original-Text von Vincent Driessen; daher gehe ich auf viele Details nicht ein, arbeite aber die Grundstrukturen und Motivationen stärker heraus +
  • +
  • + Abweichungen in der Methode: ich setzte die Tags etwas woanders, und ich schlage vor, die back-Merges sets vom Tag aus zu machen +
  • +
  • + Darstellung: ich möchte den Zeitablauf von unten nach oben darstellen, so wie er auch in fast allen Git-UIs gezeigt wird +
  • +
+ +
+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + + + + + + + + + + + + + + + + + +

+ nach einigem Herumknobeln: es paßt neben den einleitenden Text, ab dem 2. Absatz ⟹ daraus ergibt sich eine Beschränkung der Zeichnungsgröße +

+ +
+ +
+ + + + + + + + + + + + + + - + @@ -162027,6 +168685,21 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + +

+ rein praktisch gesehen bringt das keinen Mehrwert; +

+

+ wir hatten bisher nur »preview«-Releases, wlche nicht wirklich einen greifbaren Stand verkörpern. Zudem liegt das letzte solche Release jetzt (Räusper)  zehn Jahre zurück... wir würden also jetzt über 10 Jahre einen leeren Branch ziehen. Da erscheint es mir besser, das Schema jetzt neu aufzusetzen, mit Master von dem Punkt an dem Git-flow eingeführt wird +

+ +
+
@@ -162040,42 +168713,2697 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - + - - - - + + + + +

+ Weil da nun die Kopfzeile (Docking-Panel) nicht richtig gezeichnet wird, bzw. pseudo-transparent wird. +

+

+ Abbruch. Es zeigt sich, daß meine Grafikkarte das Auto-Keying von XV nicht unterstützt, d.h. die Attribute XV_AUTOPAINT_COLORKEY und XV_COLORKEY sind nicht definiert. Habe noch mind. 2 Stunden herumexperimentiert, bin aber auf keinen »grünen Zweig« gekommen. Diese Erfahrung läßt es für mich sehr fraglich erscheinen, ob wir XV unterstützen sollen....? +

+ +
+ + + +
+ + + + + + + + + + + + + + +
    +
  • + project/news/DevReport-16-11.txt : by cutting a new ``preview release'' (Version `Lumiera-0.pre.03`), and, in the process, updating the packages... +
  • +
  • + project/news/old_news.txt : We published the next »preview release« `0.pre.03` +
  • +
  • + project/background/history/Resources.txt : Erwähnung in der Zeittafel +
  • +
+ +
+ +
+ + + + + +
+ + + + + + + + +

+ Fazit: OK +

+ +
+
+
- - + + + + - - + + + + + + + - - + + + + + + + +

+ Das ist ein Thema mit langer Historie: theoretisch sollten Root-relative Links auf jeder Website funktionieren, in der Praxis gab es damit immer wieder Probleme. Gilt im Besonderen, wenn man die Website lokal mit einem Mini-HTTPD laufen läßt. Fazit: sollte eigens getestet werden, auch mit einem lokalen Webserver +

+ +
+
+ + + + +

+ Das widerstrebt mir sofort — denn um das angemessen zu machen, bräuchte man mehr als ein »pfiffiges bash-script«. Schon nach den ersten zwei Zusatzfeatures beginnen die Probleme und Wechselwirkungen. +

+

+ STOP! Das bisherige Setup war so genial, weil es minimalistisch ist und genau eine Sache macht; im Grunde war es bereits problematisch, Menugen zu integrieren (aber dennoch sinnvoll). +

+

+ +

+

+ Wenn überhaupt, dann sollte man das alles durch ein kleines Python-System ersetzen, das die Website-Sources scannt, Asciidoc anstößt und sonstige Infrastruktur generiert. +

+ +
+ + + + + + - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Tagger: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Mon Sep 1 02:27:12 2025 +0200 +

+

+ +

+

+ Review: Website infrastructure improvements by Cehteh from 2018 +

+

+ +

+

+ Regrouped thematically: +

+

+ - generic improvements of build_website.sh +

+

+ - additional features (Linkchecking, cleaning) +

+

+ - website maintainance and fixing of broken links +

+

+ -----BEGIN PGP SIGNATURE----- +

+

+ +

+

+ iHUEABYKAB0WIQTVnM7D++M2pMSFPUOUEG/3stxoAQUCaLToYAAKCRCUEG/3stxo +

+

+ Ad9LAP9rje8hIMWOY6gV5UnrbJ0+wnopy4j6GxRMWxMSoPpWVwD5AQ4HRKh9tdKe +

+

+ cz2r08O5G0ofTTc5fnV0GSXTZZq02g0= +

+

+ =ZDyL +

+

+ -----END PGP SIGNATURE----- +

+ +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ bei genauerer Betrachtung ist dieses Skript auch vorher bereits extrem pfiffig — es ist ein minimales Build-System in wenigen Zeilen Bash +

+ +
+
+ + + + + +

+ wirlich überprüfen kann ich das nicht, ohne das Skript analtyisch auseinanderzunehmen +

+ +
+ +
+ + + + +
+ + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...ich vermute, daß diese früher automatisch den Pfadnamen "gitweb" aufgegriffen hat, und jetzt (durch Christian's Umbenennung) unter einem anderen Namen in der Datenstruktur steht. +

+

+ Resultat: es sind nun zwei Nodes in dem Submenü, und einer davon hat eine falsche URL +

+ +
+ + + + + + + + + + + + +
+
+
+ + + +
+
+ + + + + + + + + + + + + + + + + + + +

+ Ha! ich fand diese Seite bisher immer schon lustlos im Design — so gut der Text auch ist (Benny's Hilfe sei Dank!) +

+

+ Dieses Logo ist eine banal-einfache Idee mit erheblicher Wirkung: nun stehen die zwei Blöcke oben prominent da, und die drei Textblöcke darunter setzen sich klarer ab... +

+

+ +

+

+ Die Breite der Grafik läßt sich leider nur +

+ +
+ +
+ + + + +

+ Diese Geschichte ist nun doch endlos lange her, und eigentlich etwas peinlich (wie meine erneute Unterschung der Anfänge gezeigt hat). Aus heutiger Sicht könnte dieser Text schon knapper sein ... und die beiden Abschnitte schließen nun direkt aneinander an, und sind auch insgesamt Abstrakter. Diesen ganzen Schlenker mit dem Namen "Cinelerra-3" brauchts wirklich nicht mehr! +

+ +
+ +
+
+ + + + + + + + + +

+ auch wenn wir die Storage nicht mehr loswerden können, immerhin kann man es mal unter den Teppich kehren +

+ +
+ +
+ + + + + + + + + + + + +

+ als »Müll« gelten Grafiken, hinter denen keine wirkliche Idee steht und auf die niemals aufgebaut wurde; ein Beispiel sind Screenshots aus der Prototypen-Zeit — da genügt es, einen einzigen aufzuheben +

+ +
+ +
+
+
+ + + + + + + + + +

+ ich teile definitiv nicht den Glauben an spontane Selbstheilungskräfte +

+ +
+
+ + + + + + + +

+ Das läuft bloß darauf hinaus, daß wieder mal ein neues »Design« erfunden wird und dann die Umsetzung anderen überlassen bleibt. Oder mir jemand erzählt, wie man heute im Internet kommuniziert (obwohl ich das sehr gut selber weiß) +

+ +
+
+ + + + +

+ sowas funktioniert möglicherweise bei einem gut eingespielten, professionellen Team. +

+ +
+
+ + + + +

+ Es ist mir völlig klar, daß »Jedermann« vor allem erschlagen und befremdet ist nach Lektüre der Design-Seiten. Und was ich gleich schon gar nicht mehr haben kann, wäre ein weiteres »GUI brainstorming« +

+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Stichworte allein sind ein flat namespace +

+ +
+
+ + + + + +

+ Das wäre eigentlich eine schöne Lösung, die uns weiterhin ein Content-Management-System erspart: wir erzeugen beim Seiten-Rendern eine Linkfarm, und die Links werden anhand von Tags aufgelöst, die in den Seiten als Kommentar stehen (ähnlich wie derzeit die Steuerung des Menüs) +

+ +
+
+ + + + +

+ Seinerzeit wollte Christian das mal eben schnell in Lua  implementieren, war aber am nächsten Tag zurückgerudert (als ihm klar wurde, daß die eigentliche Aufgabe schon etwas komplexer ist). Dann wollte sich Benny darum kümmern, ist aber bei einem Glossary-Generator steckengeblieben. Und ich — ich würde das wohl in 1-2 Wochen hinbekommen, würde dafür aber auch Menuegen neu schreiben, weil beide Aufgaben gleichermaßen eine Traversierung aller Sources erfordern. Meine Sorge dabei ist, daß das ein Performance-Bottleneck wird; denn dann brauchen wir inkrementelle Verarbeitung und damit eine Datenbank — und würden dann selber ein Content-Management-System schreiben. +

+ +
+
+ + + + +

+ Und das Problem hierbei ist so typisch Christian: „man kann dann ja mit Tags arbeiten!“ — Junge, ein System von Tags aufbauen, das für unsere Zwecke funktionert, das ist die eigentliche Aufgabe. +

+ +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Lumiera ist keine Plattform und kein Framework — wir haben lediglich Framework-artige Infrastruktur wie in jeder größeren Applikation +

+ +
+ +
+
+ + + +
+ + + + + + + + + + + + + + + + + + + +

+ ...da hatte anfangs niemand von uns dran gedacht; inzwischen haben wir dutzende  RfCs, und so manche gute griffige Namen sind bereis weg; generell sollte man +

+
    +
  • + RfCs mit einem Nummern-Schema versehen +
  • +
  • + im RfC-Subindex auch gewisse qualifizierte Schlagworte mit speichern +
  • +
+ +
+
+ + + + + + + + +

+ man kann Exclusions von Exclusions definieren; das klappt aber nur, wenn diese doppel-Exclusions spezieller sind als die allgemeine ignore-Regel. Insofern wird empfohlen, solche Regeln paarweise zu definieren +

+ +
+ +
+
+
+
+ + + + + + +

+ hier stimmt was nicht mit dem Link auf das allgemeine Essay +

+ +
+ + + + + + + + + + + + + +

+ ...so meine Schlußfolgerung; denn es fällt auf, daß ich keinen  der noch bestehenden Links in der Wayback-Maschine finde... +

+ +
+
+
+ + + + +

+ einige meiner Texte habe ich als HTML gespeichert +

+ +
+ + + + + + + + + + +

+ andererseits: alle wichtigen Ideen für Lumiera waren von Anfang an da +

+ +
+
+
+ + + + + + + + + + + + + + +

+ ...denn das ist das ist dann irgend ein Text, der 15 Jahre später in Git auftaucht; für den »Cinelerra_woes«-Text habe ich das wenigstens zeitnah gemacht +

+ +
+
+ + + + +

+ einigermaßen beweiskräftig ist Publikation, welche +

+
    +
  • + entweder auf Archive.org aufgezeichnet wurde +
  • +
  • + oder zeitnah in einem public-Git-Repo lag +
  • +
  • + oder in einem »geschlossenen Format« (wie PDF) vorliegt +
  • +
+

+ ...denn in diesen Fällen kann man zumindest schon durch den Kontext eine gewisse Beweiskraft ableiten. Für alle anderen Formate gilt sets, daß man sie im Grunde jederzeit erstellen könnte, im Besonderen wenn die eigentliche Formatierung viel später oder in einem neuen Format stattfindet. Solche Dokumente haben dann nur einen Wert wie eine Zeugenaussage +

+ +
+
+
+ + + + + + +

+ ...außer »Cinelerra woes« ... +

+

+ ich bin halt ein unverbesserlicher Sammler, und nachdem ich wußte, wonach ich suchen muß, hab ich sie auch ganz schnell gefunden +

+ +
+
+ + + + +

+ ...ich frage mich nämlich inzwischen oft, wann ich mir diese Ideen zugezogen habe; diese Seiten belegen für mich, daß es ich bei Lumiera im Kern um eine »Vision« handelt, die ich 2007 hatte. Und nicht um ein Konzept, welches ich mir durch endloses Nachdenken über viele Jahre ohne Realitätskontakt »zusammengesponnen« hätte.
Also im Grunde sehr ähnlich, wie bei Christian, der ja wohl auch damals bereits die komplette Plugin-Applikation vor seinem geistigen Auge gesehen hat +

+ +
+
+ + + + +

+ Sofern Lumiera scheitert, oder zu etwas ganz anderem wird, oder überhaupt jemand sich die Mühe macht, die Historie auszuleuchten — dann könnten solche Seiten auch erheblich negativ ausgedeutet werden: so eine absurde Idee, und sowas von weltfern... und dann hält man daran auch noch jahrelang fest, anstatt sich »vernünftiger Methoden« zu bedienen oder sich »wertvolle Ziele« zu setzen. +

+ +
+
+ + + + + + + + + + +
+
+ + + + + + + +

+ dann sind es nämlich wohl nur drei Seiten; alle anderen Seiten finden sich nahezu vollständig als erste Versionen späterer RfCs +

+ +
+
+ + + + + + + +

+ 2008-03-06T06:22:27+01:00 : ProcPlacementMetaphor.html +

+

+ 2008-03-06T06:22:56+01:00 : ProcBuilder.html +

+

+ 2008-03-06T06:23:09+01:00 : ArchitectureOverview.html +

+

+ 2008-03-06T06:23:38+01:00 : Cinelerra_woes.html +

+

+ 2008-03-06T06:23:48+01:00 : best_practices.html +

+

+ 2008-03-06T06:24:05+01:00 : Cin3_Project_Proposal.html +

+

+ 2008-03-06T06:24:22+01:00 : Possibilities_at_hand.html +

+ +
+
+ + + +
+ + + + + +

+ ...im zweiten Teil hat dieser Capture vom 2008 deutlich überarbeitete Inhalte, im Vergleich zu der Version, die ich 2011 für die Historien-Seite publiziert habe. Überdies bin ich (lt. Git) damals 2011 von Moin-Moin-Markup ausgegangen. Also  mußte ich irgendwo eine noch ältere Version gespeichert haben, als dieser capture hier von 2008. +

+

+ Beschluß: für die Historien-Seite bleibe ich bei der älteren (roheren) Fassung, aber ich dokumentiere diese Fassung trotzdem hier in der Git-Historie von dem Seitenbranch, den ich im Moment aufbaue +

+ +
+
+ + + + + + + + + +

+ Taucht erstmals in einem Merge-Commit im Mai 2008 auf (da habe ich das SVG wohl noch mit reingestopft) +

+

+ +

+

+ commit c0d7ae1aa2073e4e5b29f864d32a639c2864e9a1 +

+

+ Merge: b5d2e9486 2e58b02b8 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Tue May 27 02:11:35 2008 +0200 +

+

+ +

+

+     Merge added builder documentation +

+ +
+ +
+
+
+ + + + + + + + + + + +

+ ...sie stammen alle (mit Ausnahme von »Cinelerra woes«, von dem ich noch original-MoinMoin-Markup hatte) aus einem HTML-Snapshot im März 2008. Tatsächlich habe an ganz wenigen Stellen nun doch die Grammatik repariert, denn manche Sätze waren nahezu unverständlich in der Originalform. Außerdem habe ich manuell auf Asciidoc umgeschrieben, und dabei auch bisweilen die Formatierung minimal angepaßt (Umbrüche, Titel-Level vereinheitlicht, an einer Stelle eine Bullet-List aus einer Aufzählung gemacht) +

+ +
+
+ + + + + +
+ + + + + + + + + + + + + +

+ das war nun eine +

+

+ intensive Auseinandersetzung +

+ +
+ + + + + + + + + + + + + + + + + +
+
+ + + + + + + + + + + + + +

+ diese greift, wenn die mtime neuer wäre als die angegebene Unix-Epoch. Damit kann man einen Build reproducible machen +

+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
  • + <link rel="license" href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.html" /> +
  • +
  • + <link rel="license" href="https://www.gnu.org/licenses/gpl-3.0" /> +
  • +
  • + <link rel="license" href="https://creativecommons.org/licenses/by-sa/4.0/" /> +
  • +
+ +
+ +
+
+
+ + + + + + + + + + +

+ Grundsätzlich kann ich Content von anderen Leuten nicht ohne Weiteres aktualisieren. Aber Seiten, zu denen ich später Ergänzungen beigetragen habe, stellen ein abgeleitetes Werk dar, und in dem Zuge kann ich von dem Upgrade-Recht (das CC-Lizenzen stets beinhalten) Gebrauch machen. Das geht aber nur mit einem explizit genannten Stichdatum (oder wenn man sicherstellt, daß jede Seite tatsächlich bearbeitet wurde (Git-Commit) und einen entsprechenden Vermerk trägt +

+ +
+ + + + + + + + + + +

+ Vor allem relevant in der EU: die Datenbank als Ganzes (oder in großen Teilen) bleibt geschützt, da sie ein erhebliches Investment darstellt. CC-Lizenzen gelten nur für den Abruf und Gebrauch von Einzeldaten +

+ +
+
+ + + + + + +

+ Das beseitigt eine gefährliche Falle. Manche Länder (z.B. England, Frankreich, Japan) haben ein striktes moral rights regime, das ohne ensprechende Klarstellung dafür sorgen könnte, daß die per CC gegebenen Rechte durch einen Beitrag abgeschwächt werden könnten. Die neue Lizenz hat eine spezielle »Tunell-Klausel«, der zufolge per übersteuerndem Recht eingeschränkte Rechte wieder aufleben, sofern die Bearbeitung in einen anderen Rechtsraum gelangt. Zu den moral rights gehört das Recht eines Authors, über die Art der Repräsentation seines Werkes vollumfänglich zu bestimmen. Das bedeutet, daß ein Author das Recht hat, einem abgeleiteten Werk oder einer Übersetzung nicht zuzustimmen  und verlangen kann, daß entsprechende Werke effektiv aus dem Verkehr gezogen werden. Das würde auch greifen, wenn ein bisher substantieller Anteil marginalisiert wird, oder die Art und der Stil der Darstellung sich ändert. +

+ +
+ + + + + + + + +

+ Es gibt jetzt einen Pfad CC By SA 4 ⟶ GPL 3+ (aber nicht umgekehrt!) +

+ +
+
+
+ + + + + + +

+ Adapted Material: means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. +

+ +
+ + + + + + + + + +

+ Es geht nach meiner Einschätzung vor allem um die Protokolle, die andere Leute geschrieben haben, die RfCs und die Workflow/GUI-Proposals. Alle diese werden mit klarer Author-Angabe reproduziert +

+ +
+
+
+ + + + +

+ und die neue Version schränkt nach meiner Einschätzung keine Rechte ein, sondern stellt nur Rechte klar. Der größte Knackpunkt könnten moral rights sein, aber da stelle ich mich auf den Standpunkt, daß ich eine Adaption/Collection mache, und daher gar nicht über die moral rights von Dritten verfügen kann. Insofern bestehen diese weiter +

+ +
+
+ + + + +

+ bisweilen mit Benny als Co-Author +

+ +
+
+
+ + + +
+ + + + + + + + + +

+ Wobei in diesem Kontext zweifelhaft ist, was ein maschinenlesbarer Code auf einer allgemeinen Lizenz-Seite bringen soll. Das würde eigentlich nur Sinn machen, wenn der Button auf jeder Seite wäre +

+ +
+ + + + + + +

+ So stellt es zumindest ChatGPT dar. Demnach habe man die Empfehlungen bei CC vereinfacht, und biete nun einfach Grafiken an, die die User in ihre Website packen können. +

+ +
+
+ + + + + + + + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ CSS, falscher Link +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ....und jeweils sehen ob sich das bewährt und entsprechend klar ist +

+ +
+
+ + + + +

+ Denn damit kann man vermeiden, Attribution für Dinge zu geben, die nicht vorwärts gekommen sind +

+ +
+
+ + + + + + + + + + + +

+ ...die wollten mal was beitragen, haben sich auch in der Diskussion engagiert, aber nie etwas geliefert +

+ +
+
+ + + + + + + + + + + + + + + + +
    +
  • + ich hatte vor vielen Jahren in Asciidoc-Markup umgewandelt, was hier mit minimalem Aufwand möglich ist (einziges Problem: ich bekomme Ziffern  in der Aufzählung, statt Buchstaben wie im Original) +
  • +
  • + der eigentliche Text ist komplett identisch geblieben +
  • +
  • + geändert hat sich, daß jetzt auf die FSF-Website verlinkt wird, und daß ein Beispieltext angepaßt wurde +
  • +
+ +
+ +
+ + + + +

+ analog +

+ +
+ +
+ + + + +

+ Die LGPL hatte ich ohnehin nur der Vollständigkeit halber mit eingeschlossen; sie spielt für Lumiera derzeit keine Rolle. Daher kann ich auch gleich die aktuellste Version LGPL-3 nehmen. Auch diese transcodiere ich ganz oberflächlich nach Asciidoc +

+ +
+
+
+ + + + + +
+ + + + +

+ Okt.2009 hatten wir eine Kooperation mit der ffis.de vereinbart; in den nächsten Jahren gab es ein paar Klein-Spenden, die wir aber nicht von der ffis abgerufen haben, da wir damals keinen Bedarf hatten (Idee war z.B. immer gewesen, einem Entwickler die Reise zum Treffen zu zahlen — aber die Beteiligten konnten die Reise zur FrOSCon immer problemlos selber zahlen). Das ist zwar schön für uns .... aber eine derart veraltete Spenden-Seite wirft ein schlechtes Licht auf uns! +

+ +
+ + + +
+ + + + + + + +

+ klar machen: Diskusssion ist abgeschlossen +

+ +
+
+ + + + + + + + + + + + + + + + + +

+ Da die RfCs immer noch als eine wichtige Ebene in unserer Dokumentation gelten, sollte ihr Inhalt nicht gleichgültig sein, sondern auf Relevanz geprüft werden. +

+ +
+ + + + + + +

+ bisweilen ist die Formulierung so unbeholfen, daß das Gemeinte kaum verständlich ist; manchmal fehlt etwas Kontext und ein paar Hinweise wären sinnvoll +

+ +
+
+ + + + +

+ Es gibt einige RfCs aus der allerersten Zeit, die im Rückblick gradezu visionär wirken — oft aber ist bei diesen Entwürfen die Tragweite nicht klar. Daher sollten solche RfCs behutsam durch Kommentare und Textredaktion nachgeschärft und eingeordnet werden. Nicht zuletzt auch deshalb, weil man weiterhin auf diese Einträge wird verlinken müssen. +

+ +
+
+ + + + +

+ eine Menge RfCs waren politisch aufgeladen +

+ +
+ + + +

+ Es gab eine Zeit erheblicher Spannungen zwischen mir und Christian, die gekennzeichnet war von einem Ringen um den Stli des Projekts. Stil hier im weiten Sinn. Dem entsprechend finden sich viele doppelbödige Formulierungen, oder Vorschläge, die — nüchtern betrachtet — nachgerade durchgeknallt wirken. Auch für diese RfCs halte ich eine gewisse Einordnung für angezeigt. Das kann durch einen historischen Zusatz erfolgen, oder dadruch, daß ich sie in aller Form verwerfe und mir dadurch die Deutungshoheit in der Sache aneigne. Das kann bisweilen eine Gratwanderung sein — denn es geht mir nicht darum, zu siegen oder Recht zu haben, sondern es geht mir darum, das Projekt der Sache angemessen zu navigieren. Allerdings ist das, „was Sache ist“, ein Urteil, das ich fälle, nachdem ich duch die Sachverhalte durchgegangen bin, und zwar, sein vielen Jahren, allein. +

+ +
+
+ + + + +

+ Eine ganze Reihe der RfCs aus der allerersten Zeit gehören in diese Kategorie: sie entwerfen einen Arbeitsstil im Projekt, oft auch mit einer bestimmten Erwarung und Vorstellung bezüglich Formalismen und Automatisierung. Bezeichnenderweise stammen alle diese RfC von Christian. Einige wenige beschreiben Projekt-Konventionen, die sich tatsächlich auch so gehalten haben (z.B. die Anordnung der Repositories). Einge ganze Reihe weiterer Vorschläge erscheint mir komplett weltfremd (wie z.B. daß ein größeres Projekt funktionieren könnte, indem einfach jeder in Git eincheckt und nach belieben merged was gefällt, oder daß man jedwede Projektorganisation auf Git-commits zurückführen kann). Dem entsprechend hat auch nie jemand ernsthaft versucht, im Projekt so zu arbeiten. Das sollte dann auch im jeweiligen RfC vermerkt sein. Und schließlich gibt es einige wenige RfC, die die Organisation aus der Anfangszeit beschreiben; diese sind dadruch obsolet geworden, daß ich nun schon so ewig lange allein bin, und dem entsprechend anders vorgehen kann und muß. +

+ +
+
+
+ + + + + + +

+ explizit wieder in die Design-Phase zurück +

+ +
+
+ + + + +

+ habe ich schon vor einigen Jahren explizit verworfen +

+ +
+
+ + + + + + + + + + + + + +

+ Dieser RfC ist wieder so typisch Christian: er besteht aus einem sehr naheliegenden und sinnigen Vorschlag (Tags verwenden, Tags automatisch generieren, Tag-Verzeichnis generieren). Aber dann besteht er größtenteils aus einer teils genialen, teils unausgegorenen Idee, die sofort absolut gesetzt wird: eine Ontology über Tags definieren, mit logischen Operationen darauf. +

+

+ +

+

+ Diese Art Vorschläge bringen mich immer wieder in das gleiche Dilemma +

+
    +
  • + dem einfachen Teil würde ich gerne zustimmen, er müßte aber konkret ausgearbeitet werden +
  • +
  • + zu dem weitgreifenden Vorschschlag wäre wohl erst mal ein Prototyp notwendig, aber in eienr Art, die nicht gleich endgülitig Fakten schafft und andere Möglichkeiten verbaut. +
  • +
+

+ Und mit beiden Problemen läßt einen Christian dann allein; er hätte nur noch Interesse daran, einen extrem pfiffigen Prototypen für den weitreichenden Vorschlag ganz minimalistisch zu implementieren und dann das Thema abzuhaken. Ich finde mich dann immer wieder in dem ärgerlichen Dilemma: entweder ich lasse alle möglichen Vorschläge offen hängen, und dann laufe ich Gefahr, daß Christian irgendwann einfordert, das nun einfach mal zu akzeptieren (ohne weiter was für zu tun). Oder ich bin derjenige, der seine Vorschläge komplett verwirft, oder ich bin derjenige, der seine Vorschläge dann runter-strippt und implementiert, und mit den sich dann zeigenden konzeptionellen Problemen allein gelassen wird (so geschehen beim Lock-Cycle-detector, bei den Thread-Wrappern, seinem Interface/Plugin-System oder der Configuration). +

+

+ +

+

+ Hier entscheide ich mich dafür, den Vorschlag komplett zu verwerfen, mit den Argumenten, die ich damals schon als Diskussionsbeitrag geschrieben habe. Und zwar mache ich das aus Sorge, daß später irgend jemand auf die Idee kommt, den Vorschlag mal zu implementieren — was bestenfalls nutzlos wäre, schlimmstenfalls aber andere, wichtige Einrichtungen behindert oder verdirbt (man denke nur mal daran, wenn ein Website-Cross-Link-Generator implementiert wird, aber nur limitiert auf die hier vorgeschlagene Semantik) +

+ +
+ +
+ + + + +

+ Dieser RfC ist ein Kuriosum — eine »Duftmarke« aus der ersten Zeit. +

+

+ Christian hat das vorgeschlagen im März 2008; damals waren wir schon in einer festen Projekt-Organisation als »Lumiera« unterwegs. Ich kann mich definitiv nicht mehr erinnern, was ich damals von dem Vorschlag gehalten habe. Ich weiß noch, das Christian eine heftige Aversion gegen Bugzilla hatte (und wohl auch gegen jede Art von Ticket-Management). +

+

+ +

+

+ Diese Erinnerung schreibe ich jetzt auch in das Ticket rein, denn was soll man sonst damit machen? So für sich betrachtet (aus gegenwärtigem Kontext) erscheint es nur absurd, einen solchen RfC überhaupt zu formulieren, aber ich sollte Christian den Kredit geben, daß er ein Problem gesehen hat.
+

+

+ +

+

+ Jedenfalls klar ist, wenig später hatten wir ein Trac, dafür habe ich gesorgt, und Christian hat es zwar anfangs auch genutzt, aber letztlich immer für "Ichthyos Ding" gehalten. +

+ +
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + +

+ daher müssen die meisten RfCs aus heutiger Sicht neu beurteilt  werden +

+ +
+
+ + + + + + + + + + + + + + +

+ Diese dokumentieren den Stil und das »Mindset« aus der Zeit der entstehenden Bewegung, aus der später das Lumiera-Projekt wurde. Typisch für diese RfCs ist, daß sie ein wesentliches Element des Stils im Projekt bereits vorgreifend darstellen, aber typischwerise auch total „über das Ziel“ hinausschießen, indem Methoden und Verfahren vorgeschlagen werden, oder gar schon als gelebte Praxis deklariert werden, welche — nüchtern betrachtet — in unserer gegenwärtigen Zeit nicht funktionieren und ihren Zweck niemals erfüllen können. Solche RfC müssen explizit eingeordnet werden +

+ +
+ + + + + + + + + + + + + + + + + +

+ ⟹ heißt: hier hat er eine Vision, die ihm wichtiger als alles andere ist +

+ +
+
+ + + + +

+ ...ich fand Christian's Vorschläge in diese Richtung immer nur etwas „sonderbar“ und realtitätsfern, meist so völlig überzogen, daß ich nur „ja ja“ gesagt habe (wohl wissend, daß nichts konkretes folgend wird). Dumm gelaufen. Jetzt haben wir ein ganzes Bündel von solchen RfCs, und alle wurden entweder durchgepresst, oder durchgewunken, ohne weitere Diskussion. Ausnahme: die »Semantic Tags« von 2012. Da habe ich im Dev-Meeting kontra gegeben, und es kam bereits zueiner überraschend hitzigen Diskussion. +

+ +
+ +
+ + + + +

+ "points define a periphery" ...  möglicherweise hilft es, nicht an den jeweiligen Vorschlägen hängen zu bleiben, sondern mich zu fragen: worauf will Christian hinaus? +

+

+ +

+
    +
  • + sein allererster RfC war also, daß wir alle Bugtracker, und sonstigen Orga-Tools durch Git + Automatisierung ersetzen +
  • +
  • + das nächste war das Manifest. Darin ging es inhaltlich nicht um Cinelerra, sondern darum, ein Projekt "möglichst einfach und zugänglich" zu machen. Jeder soll tun was er für richtig hält, und dadurch lösen sich alle Probleme von selber (wenn man die Leute nur durch clevere Automatisierung und Git zusammenschaltet ⟹ das ist die Idee der »Unsichtbaren Hand« aus dem Liberalismus) +
  • +
  • + dann hat er x weitere Aktionen und RfCs gestartet, die alle darauf hinauslaufen, eine Infrastruktur zu schaffen (dem Projekt hat das enorm geholfen) +
  • +
  • + und dann hat er monatelang überhaupt nichts beigetragen, sondern hat sich mit vollem Eifer in das uWiki-Projekt geworfen, aber es exakt in dem Moment aufgegeben, als klar war, daß es nicht genügt, alles über einen eleganten Bootstrap zu verschalten, sondern daß tatsächliche Knochenarbeit (Webentwicklung) notwendig wäre. Nicht daß Christian nicht hart arbeiten kann, aber wenn man sich durch dicke Bretter bohren muß und Mengen von Details ordnen, dann ist das nicht seine Vision, sondern wohl ehr eine Bankrotterkärung. +
  • +
  • + danach hat er eine Menge Infrastruktur im Backend hochgezogen, die nur darauf zielt, die Arbeit für den Entwickler möglichst einfach zu machen, und dafür bestimmte Schemata global enforced. Er hat dann immer eingefordert, daß sich alle von jetzt an daran halten müssen, denn sonst wirkt das ja nicht +
  • +
  • + als nächstes kam das Thema "Plug-ins" + Lua. Auch das zielt darauf, alles möglichst modular, flach und einfach zugänglich zu machen, um aufgrund jeder neu auftauchenden Idee alles mit allem neu verschalten zu können +
  • +
  • + kurz darauf hat Christian mehrere Initiativen gestartet, den globalen Applikations-Rahmen "in den Griff" zu bekommen. Mich hat das sehr empört (und ich hab entsprechend giftig reagier), denn er hat meine bereits geleistete Arbeit komplett ignoriert und dann nach meinem Hinweis als "Overengineering" beiseite geschoben. Ich hab das nicht einordnen können, denn es war offensichtlich nicht persönlich gemeint. Sondern er wollte Dinge beiseite schieben, die seine Vision stören +
  • +
  • + sehr ähnlich lief's dann beim Config-System, wie ich jetzt aus den Meeting-Summaries rekonstruieren konnte. Alle anderen Devs haben hin darauf hingewiesen, daß es zu dem Thema zig ausgereifte Lösungen gibt. Darauf ist er nicht einmal eingegangen (und hat sich auch nicht erkenntlich mit diesen Lösungen auseinandergesetzt). Was ich so deute, daß er an das Thema grundsätzlich ganz anders rangehen wollte. Christian zeigte auch keinerlei Interesse an einer Requirement-Analyse, was ich so deute, daß er das Thema als Vehikel gesehen hat, um seine Vision voranzubringen. Auch der bestehende Implementation-Draft bestätigt diese Lesart: er ist bezüglich der Nutzbarkeit derart rudimentär, daß man ihn grade eben mit Tricks durch einen Unit-Test prügeln kann. Aber ein elaboriertes System von Matching- und Ersetzungregeln direkt in der Stringverarbeitung ist sehr detailliert durchdacht und angelegt worden. +
  • +
  • + Auch später noch, nachdem Christian schon nicht mehr aktiv beigetragen hat, kamen als Vorschläge zu aktuellen Problemen manchmal unglaublich elegante Abkürzungs-Lösungen (wie die Linkfarm), deren Stärke darin besteht, das eigentliche Problem aus den Angeln heben. Meist aber kamen irgendwelche Vorschläge für Automatisierung und clevere Textersetzungs-Regeln (Semantic Tags, Git commit message format, Vorschläge, Metadata-Hooks als Overlay direkt in die Datenstrukturen im Backend einzubauen, Vorschläge für Caching an allen möglichen Stellen, oder die Idee, Tests elaboriert automatisch zu generieren) +
  • +
+ +
+
+ + + + +

+ Ich war jetzt lange Zeit allein, und insofern waren die RfC egal, denn ich weiß ja, was geschehen ist. Da ich aber nun das Ziel ins Auge fasse, ein Team aufzubauen, ändert sich die Situation. Ich muß nun dafür sorgen, meine Deutungshoheit zu ratifizieren. Ich habe diese Deutungshoheit durch harte Arbeit erlangt, nicht durch Magie. Alle entscheidenden Durchbrüche in den letzten Jahren beruhen vor allem auf Denkarbeit, also viele Stunden Reflexion, die auch aufgeschrieben und wieder gelesen wird. +

+

+ +

+

+ Meine Haltung zu dem, was Christian's Vision sein könnte (letztlich meine Auslegung!), hat sich in den letzten Jahren geändert. Und zwar von „schaug' mer mal was es in Beweung setzt“ auf „ich sehe jetzt wohin das führt und ich will nicht in dieser Zukunft leben, sondern in einer anderen“. +

+

+ Konsequenzen +

+
    +
  • + Ich *DEUTE* Christians Vision als Teil eines Trends zur Industrialisierung. Das ist etwas, was mit den Menschen geschieht, ohne daß es absichtsvoll geplant wird. +
  • +
  • + Ich *NAVIGIERE* das Projekt in Richtung einer möglichen Dialektik dazu (⚠ Achtung: nicht in Richtung von Tradition und Konservativismus; ich gebrauche den Begriff »Handwerk« als Vehikel). +
  • +
+ +
+ + +
+ + + + +
+
+ + + + +

+ Diese forumulieren wesentliche Elemente der Vision aus, unter der das Projekt begonnen wurde. Einige dieser RfC wurden sofort beschlossen — und die Realität in der Codebasis hat sich dann ganz anders entwickelt. Andere RfC wurden erst mal auf „noch mehr Arbeit erforderlich“ gestellt — was in jedem Fall realisitischer ist, denn in der Regel ist ein weiter Weg notwendig, um dieser Vision auch nur nahe zu kommen. Diese RfC müssen also explizit von mir neu beurteilt werden +

+ +
+ + + + + + + + + + + + + +
+ + + + +

+ Diese RfC gibt es in verschiedensten Formen, von einer kurz hingeworfenen Idee bis zu einem elaboriert ausgearbeiteten Konzept. Allen gemeinsam ist, daß man sie alsbald beiseite geschoben hat, da den Entwicklern eigentlich von Anfang an klar war, was für ein weiter Weg vor uns liegt. Diese RfC können getrost liegen bleiben, so wie sie sind. +

+ +
+
+ + + + +

+ Diese RfC sind allesamt mit Konflikten verbunden, und wurden nur deshalb formuliert, weil der Initiator schon ahnte, daß es Widerstand gegen diese Idee geben würde. Hier kann man zwei Klassen beobachten +

+
    +
  • + einige RfC sind so verschwurbelt, daß ohne Kenntnis der damaligen Situation überhaupt nicht erkenntlich ist, worum es überhaupt geht; diese RfC wurden meist sehr kontrovers diskutiert, bisweilen sogar per Winkelzug durchgeprügelt und als Konsens dargestellt. +
  • +
  • + die sonstigen RfC dieser Art sind extrem elaboriert geschrieben, so daß man eigentlich nichts mehr dagegen sagen kann; verräterisch ist nur, daß der Diskussionsteil komplett fehlt, oder nicht ernst gemeint ist. +
  • +
+

+ Der Beschluß-Status dieser RfC ist fragwürdig. Tatsächlich wurde über alle diese Vorschläge eine faktische Entscheidung von mir getroffen, indem ich eine Richtung eingschlagen habe, die ich für richtig halte und begründen kann. Die notwendige Diskussion mußte ich dazu mit mir selber führen und ein formaler Beschluß war nicht mehr möglich. Im Ergebnis sind nun praktisch alle charakteristischen Vorschläge von Christian von mir verworfen worden und die allermeisten meiner Vorschläge wurden weiterentwickelt und dabei jedoch substantiell verändert. Insofern ist für diese RfC eine Klarstellung notwendig +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Der eigentliche RfC schlägt nur vor, Lua zur verbindlichen Scriptsparche zu machen, und C-Bindings einzurichten. Die Kommentare ergeben dann aber, daß Christian diesen RfC sehr wohl im Zusammenhant mit seiner Plugin-Vision gesehen hat, und tatsächliche alle internen Interfaces öffnen und von Lua aufrufbar machen wollte. +

+

+ +

+

+ Dieser Zusammenhang haftet dem RfC nun an, und auch meine Ablehnung stellt darauf ab ⟹ es ist nicht sinnvoll, diesen RfC zu „reparieren“ +

+ +
+
+
+
+
+
+ + + + + + + + + + + +

+ Effektiv habe ich die »Plugin-Architektur« nun beerdigt. Es wird kein generelles Interface-System geben, sondern nur ein neues Konzept für Plugins und Feature-Bundles +

+ +
+
+ + + + +

+ Ich habe vor 2 Jahren beschlossen, daß das System der C Error-States nur noch mitgeführt wird, aber den Exceptions untergeordnet ist. Das bedeutet, perspektivisch werden Ausnahmen nur noch per Exception signalisiert, und es ist nicht mehr akzeptabel einfach mal so eine Flag zu setzen (auch wenn sie Thread-local ist). Man sollte nicht mehr erwarten, daß irgendjemand einen Lumiera-Error-State prüft +

+ +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +

+ Dieser Content erweckt ein falsches Bild. Ich werde dafür sorgen, daß niemand mehr ein »C-Ökosystem« aufmacht. Imperativ programmieren kann man auch in C++, und mithilfe der Standardlibrary. Die wenigen Verwendungen der hier aufgeführten Library-Datenstrukturen von Christian werden mit dem Config-Loader wegfallen. Diese C-Library ist aus der Dynamik der Anfangszeit entstanden, aber seit 2010 trage ich nahezu die gesamte Entwicklung allein, und setze daher die Maßstäbe. +

+ +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Name + Datum als Asciidoc-Delimited-Block +

+ +
+ + + +

+ also mit + einleiten und dann mit -- umschließen +

+ +
+
+ + + + + + + + + + + + + +

+ ...das ist vermutlich ein Fehler in der MoinMoin-2-Asciidoc-Konvertierung gewesen: viele Diskussionsbeiträge beginnen mit einem "--", was von Asciidoc u.U. als Beginn eines »delimited block« interpretiert wird +

+ +
+ + +
+ + + + +

+ ...wodurch sie Asciidoc nicht erkennt, sondern dem vorhergehenden Absatz zuschlägt +

+ +
+ +
+ + + + +

+ ...das geht vermutlich zurück auf das Moin-Moin-Wiki von Cehteh: Dort war es üblich, Stichworte mal vorsorglich als Link zu schreiben; in wiki-typischer Weise wurden daraus dann nicht-existente Seiten, die man sukzessive erstellen konnte. Duch die automatische Umwandlung in Asciidoc sind daraus leider sehr viele Links nach dem Muster link:blablubb[]  enstanden. +

+ +
+ + + + +
+
+ + + + + + + + + + + + +

+ ...die dann aber dem gekennzeichneten Inhalt widersprechen können +

+ +
+ + + + + + + +
+
+

+ After a talk on IRC ichthyo and me agreed on making lumiera a multi language +

+

+ project where each part can be written in the language which will fit it best. +

+

+ Language purists might disagree on such a mix, but I believe the benefits +

+

+ outweigh the drawbacks. +

+

+
+ +

+

+ ct:: '2007-07-03 05:51:06' +

+

+ +

+
+
+ +
+
+ + + + + + + + + +

+ In die kleine Tabelle im Kopf des RfC wird beim Anlegen ein Timestamp gesetzt; dieses Datum erscheint stets plausibel, Timestamps in Kommentaren sind zeitnah, aber etwas später. Oft wurden RfC auch in developer-meetings auf IRC besprochen; auch das ergibt ein schlüssiges Bild. +

+

+ ⟹ alle RfC lassen sich grob einer Phase des Projekts zuordnen +

+ +
+ +
+
+
+ + + + +

+ war trotzdem ein Monster-Aufwand +

+ +
+ + + +

+ ....aber mußte mal sein; der Zeitpunkt erscheint mir richtig, denn ich ziehe anscheinend nun einige Trennlinien explizit und spreche Entscheidungen aus. Denn wenn es mir gelingt in dem Projekt wieder etwas in Bewegung zu setzen, werde ich alsbald für diese art Arbeit keine Zeit mehr haben! +

+ +
+
+
+ + + + + + + + + + + + + + + + + + + + +

+ Also es ist definitiv so, und zwar in jeder Installation die ich sehe. Jetzt kann ich mich aber gar nicht mehr erinnern, wie Benny auf diesen Vorschlag kam. War das nur eine rein-theoretische Überlegung, ist es in einer Diskussion passiert, ohne daß wir die Website gesehen haben (ich erinnere mich ganz dunkel, daß wir das in Bernbach besprochen haben) +

+ +
+
+ + + + +
+
+

+ ⚠ Achtung: im Website-Repo +

+

+ commit a32d3e0f7caf8d905e3203608c426953f85fd6e4 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> 2013-10-26 23:55:23 +

+

+ Committer: Ichthyostega <prg@ichthyostega.de> 2013-10-26 23:55:23 +

+

+
+ +

+

+ Menu: attach the Doxygen node also into the documentation subdir +

+

+ +

+
+
+ +
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +

+ Da ich "autobrief" verwende, ist der erste Satz stets auch die Kurzbeschreibung. Zudem stelle ich die Langbeschreibung stets an den Anfang der Seite, weil ich dies für die nützlichste Info halte. Die ganzen sonstigen Member-Listen sind ehr verwirrend +

+ +
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Das ist im Grunde die Formulierung aus der DEB-Paketbeschreibung, also eine knappe Charakterisierung was Lumiera ist, aus Sicht eines prospektiven Benutzers.... Aber der erste Satz wirkt aufgebläht und auch der Hinweis auf auf den Status eines Development-Snapshot erscheint aufgebläht und etwas redundant. +

+ +
+
+ + + + + + + + + + + + + +

+ ...denn das erscheint mir immer noch ziemlich aus der Zeit gefallen; mit gegenwärtiger Software kann man nichts sinnvolles anfangen ohne Internet-Connection; daher ist eine ausführliche Bauanleitung viel angebrachter auf der Website. Das README gibt nur eine Zusammenfassung... +

+
    +
  • + mit was man es zu tun hat +
  • +
  • + was man weiter noch braucht um den Code zu bauen +
  • +
  • + wo man mehr Informationen und Anleitungen findet +
  • +
+ +
+ +
+
+ + + + + + +

+ ...ein Commit-Log einer größeren Applikation ist für sich allein nicht aussagekräftig; es muß in den Kontext gestellt werden durch ein offiziell verbindlich vorgegebenes Urteil wo das Projekt steht und wohin es sich bewegt. +

+ +
+ + +
+ + + + + + + + +

+ alle diese Preview-Releases wurden bisher bedingt durch Änderungen im Kontext, wie z.B. der Umstand, daß ich allein die Zügel tatsächlich übernommen habe, oder der Upgrade auf eine neue Refernz-Plattform und höhere Sprachstandards. Zwar wollte ich das immer, aber es ist mir nie gelungen, diese Releases auch mit Erreichen eines Meilensteins zu koppeln. Zudem haben wir noch keinen der großen Meilensteine erreicht. +

+ +
+
+ + + + + +

+ NEWS sollte neben einem Datum auch die Versionsnummer tragen +

+ +
+ + + + + + + + + + + + + + + + + + + + + +

+ Das hab ich neulich schon im Rahmen der Website überlegt und so beschlossen; ich kann das Aggregat re-lizensieren unter einer kompatiblen Lizenz (eigentlich könnte man das auch für GPL2+ ⟶ GPL3+ so machen). Auch Stackoverfow hat seine Lizenz für »Subscriber Content« auf CC-By-SA 4.0 gehoben +

+ +
+
+
+ + + + + + + + + + + + + + + + +

+ technical/build/LumieraDebianPackage.html +

+ +
+ + + + + +

+ enthält auch Beschreibung des Installation-Bundle +

+ +
+ + + +

+ die ist gut und auch nützlich dort; könnte aber auch übernommen werden in die Beschreibung des Buildsystems +

+ +
+ +
+ + + + + + + + + + + + + + +

+ Verweise auf den Debhalper-Sequencer, +

+

+ mit Manpage und dem Abschnitt in der Policy, +

+

+ in dem die Override-Targets erläutert sind +

+ +
+
+
+
+ + + + +

+ ...nicht nur daß diverse Paketnamen peinlich veraltet sind — auch die ganze Darstellung ist verwirrend, und inzwischen einseitig.... +

+
    +
  • + sollte die grundsätzliche Prozedur zu Beginn abstrakt darstellen +
  • +
  • + sollte eine kompakte Anleitung für den kompletten Bootstrap vom Quellpaket auflisten +
  • +
  • + sollte aber auch die Variante mit mk-build-deps darstellen, da hierfür nicht das Lumiera DEB-Depot ins System konfiguriert werden muß; in all den letzten Jahren was das nämlich die einzige Methode, die überhaupt noch funktioniert hat, auch wenn sie deutlich umständlicher ist als mit dem Apt-Repo +
  • +
+

+ Der allgemeine Teil dafür kann nun gestrafft werden, da wir mache Information schon woanders breit darstellen +

+ +
+ +
+ + + + +

+ Aktuelle Distributionen und Daten, Text gestrafft und viele xrefs eingebaut, vor allem auf die Apt-Konfiguration und die Anleitung für den GPG-Key (denn leider ist das ganze Thema komplexer geworden; früher mußte man nur eine Zeile in die sources.list reinklatschen...) +

+ +
+ + + + +
+
+ + + + + + + + + + + + + + + +

+ Denn ich mußte mir das heute schon wieder zusammensuchen... +

+
    +
  • + die SCons-Kommando-Argumente werden im Konstruktor des Environment-Objekts geparst +
  • +
  • + die erwartete Argument-Definition kommt dorthin im Keyword-Argument 'variables' +
  • +
  • + wir definieren sie in unserem Options-Objekt +
  • +
  • + weitere key=value-Bindings können als zusätzliche KW-Args mitgegeben werden +
  • +
  • + im Besonderen diejenigen, die aus 'optcache' geladen wurden +
  • +
  • + alle diese Variablen (incl. der von der Kommandozeile) werden 'build variables' +
  • +
  • + diese können per env.subst(string) interpoliert werden +
  • +
  • + bei eingebauten Kommando-Aufrufen macht das SCons automatisch +
  • +
+ +
+ +
+ + + + + + + + + + + + + + + + + + + @@ -162386,22 +171714,23 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - - - + + + - - + + + - - + + @@ -162411,13 +171740,18 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + - - + + + + + + - + @@ -162616,6 +171950,7 @@ actively maintained upstream. Please remove gdl from Debian.

+ @@ -162775,7 +172110,7 @@ actively maintained upstream. Please remove gdl from Debian. - + @@ -162789,20 +172124,51 @@ actively maintained upstream. Please remove gdl from Debian. - - - + + + + + + - - - + + + + + + + + + +

+ Das betrifft auch das Thema »Video-Output«, zu dem Benny und ich einen Vortrag auf der FrOSCon25 gehalten haben. In dem Zusammenhang haben wir uns Basiskenntnisse in OpenGL und Shader-Programmierung angeeignet, aber beschlossen, das Thema vorerst noch nicht zu priorisieren — für die Integration von Lumiera genügt es wenn »irgendwie« Video ausgegeben werden kann.... +

+ +
- + + + + +

+ ...rückt jetzt immer näher, in viele Distributionen wird er derzeit reingedrückt; für mich selber kommt Wayland aber erst in Frage, wenn er auf XFCE stabil läuft und mein »pragmatisches Farbmanagement« dadurch nicht gefärdet wird. Vermutlich bedeutet das, daß ich dazu erst mal mich von meiner UrUrUralten Grafikkarte trennen muß... (die sowiso nur noch für Debian/Trixie ein letztes Mal mit dem Tesla-Treiber unterstützt wurde). Haha, ich arbeite immer noch zufrieden und glücklich mit Hardware von 2011, das soll mir erst mal jemand nachmachen +

+ +
+
+ + + + + + + + @@ -163294,7 +172660,7 @@ actively maintained upstream. Please remove gdl from Debian. - + @@ -163368,7 +172734,7 @@ actively maintained upstream. Please remove gdl from Debian. - + @@ -163589,7 +172955,8 @@ Since then others have made contributions, see the log for the history.
- + + @@ -163605,7 +172972,7 @@ Since then others have made contributions, see the log for the history.
- + @@ -163677,9 +173044,9 @@ Since then others have made contributions, see the log for the history.
- - - + + + @@ -163692,6 +173059,347 @@ Since then others have made contributions, see the log for the history.
+ + + + +
    +
  • + wenn ich gleich wieder darüber iteriere, ist es nicht notwendig, zu materialisieren +
  • +
  • + und für Debendencies gilt: sie müssen ohnehin eine Liste sein in SCons, also besser an der Erzeugungsstelle einmal in eine Liste packen +
  • +
+ +
+
+
+ + + + + + + + + + + + + +

+ Beschluß: wir gehen auf 3.10 +

+ +
+ + +
+
+ + + + + + + + + + + + +

+ Was war denn überhaupt der Sinn der vgsuppression? Welche Aufrufe sollten damit ausgenommen werden? warum brauchen die die Tests??? +

+ +
+
+ + + + +

+ Die »klassischen Hacker« waren seinerzeit unbedingt davon überzeugt, daß wir viel mit Valgrind arbeiten müssen, weil wir ja sonst Probleme mit Memory-Leaks „nie in den Griff bekommen“. Ich dagegen wollte immer ein deterministisches Memory-Management, und hab mich mit diesem Ansatz durchgeführt. Erste Versuche mit Valgrind waren nicht sonderlich hilfreich. Vor allem wegen Dingen wie dem "MPool", der nicht deterministisch ist. Ebenso hat Christian irgendwann einmal einen "Leak-Checker" geschrieben, und wollte den eingebunden haben. Dann kam heraus, daß sein C-Code leakt, aber der C++-Code nicht, weil die smart-Pointer per Konstruktion »wasserdicht« sind. Daraufhin hat Christian schlagartig das Interesse an dem Thema verloren. Und sich auch nie um eine brauchbare Konfiguration der vgsuppression gekümmert. Ich hatte darauf auch keinen Bock, denn das ist eine endlose Knobelei, und wozu? Ich weiß ja daß die smart-pointer nicht leaken. +

+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ searchpath.cpp :  replaceMagicLinkerTokens() +

+ +
+ +
+ + + + +

+ SCons würde nämlich diese $ORIGIN ebenfalls versuchen, zu expandieren +

+ +
+
+
+ + + + + + + + + + + +

+ ...dies dient dazu, Defaults aus dem 'optcache' zu laden +

+ +
+
+
+ + + + + + + + + + +

+ ...hab heute schon wieder ganzschön lang gebraucht, um mir das zusammenzupuzzeln (und ich kenne SCons und unser Buildsystem) +

+ +
+ +
+
+ + + + + +
+ + + + + + + + + + + + + + + +

+ Hauptsache, man hat irgendwas total trickreich eingefädelt, so daß man sich später von der linken Tasche in die rechte Tasche spielen kann +

+ +
+
+ + + + + + + + + + + +

+ und exakt so machen wir es bereits +

+ +
+ +
+ + + + + +

+ das Config-System ist nur noch pro forma da +

+ +
+
+ + + + +

+ lumiera_get_plugin_path_default() +

+ +
+
+
+
+
+
+ + + + +
+ + + + + + + + + + + + + +

+ Nein! denn unser Buildsystem ist nicht Autotools oder CMake +

+ +
+ +
+ + + + + + + +

+ das beruht aber auf einer Mystifikation +

+ +
+
+ + + + + + + +
+ + + + +

+ ...weil es dadurch zusätzliche Seiteneffekt-Abhängigeiten gibt, die man dem System nicht »ansieht« +

+ +
+
+ + + + +

+ ...das dann auch die üblichen Overlay-Ebenen hat (Paket, System, User) +

+ +
+
+
+ + + + + + + + + + + + + +

+ Für den normalen Build ist das irrelevant; erst wenn wir das Install-Target aufrufen, passiert da etwas. Und dann sollte das auf Betriebssystem-Ebene geregelt sein (und das erfordert i.d.R. auch Root-Rechte) +

+ +
+
+ + + + +

+ Das ist so eine ganz typische Paketbau-Funktionalität: prüfen ob das Zielverzeichnis existiert, richtige Rechte hat und leer ist — oder eben einige dieser Kriterien grade nicht prüftn +

+ +
+
+
+ + + + + + + + + + + +

+ Oh weh! +

+

+ Hätte ich das Thema doch bloß nicht angefaßt ... das war jetzt mehr als ein Tag ekelhafte Debugging-Arbeit, und ich hab nun Interna von SCons gesehen, die ich lieber nicht wissen würde.... +

+

+ +

+

+ Meine Einschätzung bleibt allerdings trotzdem, daß SCons konzeptionell  eines der modernsten Buildsysteme ist, das ich kenne, und das einzige unter Linux geläufige Buildsystem, das auch nur anähernd zeitgemäß ist. Auch wenn die Implementierung dann sowohl »pythonisch«, alsauch „hemdsärmelig“ ist..... +

+ +
+
@@ -163707,7 +173415,7 @@ Since then others have made contributions, see the log for the history.
- + @@ -164017,7 +173725,7 @@ Since then others have made contributions, see the log for the history.
- + @@ -164037,8 +173745,8 @@ Since then others have made contributions, see the log for the history.
- - + + @@ -164078,7 +173786,7 @@ Since then others have made contributions, see the log for the history. - + @@ -166952,7 +176660,7 @@ Since then others have made contributions, see the log for the history.
- + @@ -167154,7 +176862,7 @@ Since then others have made contributions, see the log for the history.

- /** derive total ordering from base class */ + /** derive total ordering from base class */

std::strong_ordering operator<=>(FrameRate  const&) const =  default; @@ -167987,7 +177695,7 @@ Since then others have made contributions, see the log for the history.src/vault/gear/work-force.cpp:69:43: warning: '++' expression of 'volatile'-qualified type is deprecated [-Wvolatile]

- 69 | for (volatile size_t i=0; i<degree; ++i) {/*SPIN*/} + 69 | for (volatile size_t i=0; i<degree; ++i) {/*SPIN*/}

@@ -168372,7 +178080,7 @@ Since then others have made contributions, see the log for the history.

- /** + /**

* Identification tuple for addressing frames unambiguously. @@ -168393,7 +178101,7 @@ Since then others have made contributions, see the log for the history.* be replaced by a combined C/C++ header

- */ + */

class FrameID : boost::totally_ordered<FrameID>  ////////////TODO it seems we don't need total ordering, only comparison. Clarify this! @@ -169031,7 +178739,7 @@ Since then others have made contributions, see the log for the history. - + @@ -169179,7 +178887,7 @@ Since then others have made contributions, see the log for the history.* which in turn becomes the only child of the new Record.

- */ + */

Record (Mutator const&  mut) @@ -169465,15 +179173,22 @@ Since then others have made contributions, see the log for the history. - - - + + + + + + + + + - - + + + @@ -169509,10 +179224,10 @@ Since then others have made contributions, see the log for the history. - - - - + + + + @@ -169742,23 +179457,123 @@ Since then others have made contributions, see the log for the history. + + + + - - - + + + + + + + + + + + + +

+ mußte dabei die scons-Soup zusammenführen; trivial ⟶ ich hab zwei neue Funktionen im V1-Stil (Resultat wird zwar nicht funktionieren, aber das ist mir egal) +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - - - - + + + + + @@ -169777,7 +179592,7 @@ Since then others have made contributions, see the log for the history. - + @@ -169786,50 +179601,178 @@ Since then others have made contributions, see the log for the history.
+ - +

- wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird. + wähle Kompatibiltät genau so, daß Ubuntu-Noble noch unterstützt wird, ansonsten den Level für »Trixie«

- - - + + + + + + +

+ das ist derzeit tatsächlich verbindlich ... und auch relativ knapp so, weshalb es im Buildsystem gecheckt werden sollte +

+ +
+ + + + + +

+ ...im Grunde ist das gegen den Basis-Kontrakt, daß man lediglich »einen Compiler« verlangt... +

+ +
+
- - + + - - - - + + + - - + + + + + + - - - - - - - - - - - - - - + + + + - + + + + + + + + + + + + + + + + + + + +

+ Das berücksichtigt auch Ubuntu-Noble(24.04), ist aber derzeit auch genau der Level, der in Debian-Trixie standardmäßig zum Einsatz kommt +

+ +
+ + + + + + + + + + + + + + + + + + + +

+ ist keine direkte Dependency mehr +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...das war ein Beschluß auf dem Entwickler-Meeting im September: auch wenn wir (Benny+ich) jetzt viel Know-How aufgesammelt haben, verschieben wir das Thema »Shader-Programmierung« dann doch noch in die Zukunft, weil es nicht strikt notwendig ist, um die einfachste Form von Playback zu bekommen. Demnach könnten wir sogar mit dem bestehenden XVideo-Code weitermachen (oder eben Legacy GL nehmen, sofern noch Motivation dafür da ist) +

+ +
+
+
+ + + + + + + +

+ explizite Wahl, wegen Ubuntu/Noble +

+ +
+
+ + + + +

+ ...naja, nicht wirklich, denn dazu müßte ich mal die ganze SCons-Doku durhclesen, um zu sehen, was man modernisieren könnte. Aber da ich nun nur noch mit entsprechend neuerer Software arbeite, ist es auch nicht mehr angemessen, eine niedrigere Version zu deklarieren, da ich nicht merke, wenn ich neuere Feature verwende, die irgendwo im Internet beschrieben sind. Konkret bin ich jetzt auf SCons 4.8 (habe 4.10 Features explizit noch nicht verwenden können). Allerdings ist Ubuntu-Noble erst auf 4.5 (hoffen wir mal daß das alles gut geht...) +

+ +
+
+
+
+ - + @@ -169953,9 +179896,1073 @@ Since then others have made contributions, see the log for the history.
- + + + + +

+ Lifecycle/Start-up ist immer noch nicht failsafe ⟶ auf später vertagt, da es zusätzlich verkompliziert ist durch das Design des Subsystem-Runners, das eine zusätzliche Fehlerbehandlung jenseits der Event-Loop schwierig macht; und ich bin mit diesem Design ohnehin nicht zufrieden, betrachte es aber nicht als ein dringendes Problem +

+ +
+ +
+
+ + + + + + + + +

+ ...heißt nämlich, daß man Lumiera derzeit nicht nach /usr/local/ installieren könnte! +

+

+ Das wenn ein »richtiger« Unix-Hacker mitbekommt, dann haben wir uns ziemlich lächerlich gemacht: „mit Autotools wär das nicht passiert...“ +

+ +
+
+ + + + +

+ Ich würde nie auf die Idee kommen, etwas anders ins System zu installieren, als via DEB-Paket. Und für das Debian-Paketieren brauchen wir ja einen Pfad relativ zum Build-Root (nämlich im debian/lumiera -  Unterverzeichnis, denn dort wird der Content für das neue DEB-Paket nach dem Build zusammengestellt....) +

+ +
+
+ + + + + + + + + + + + +

+ wie viele Build-Systeme beruht auch der SCons-Build darauf, rekursiv definierte Sub-Builds aus Unterverzeichnissen zu aggregieren. Das bedeutet, daß für den eigentlichen Bauvorgang jeweils in das Unterverzeichnis gewechselt wird. Das ist aber problematisch für Aktionen im Build-Tree, und deshalb bietet SCons diese spezielle Konvention mit dem '#'-Präfix, das den Pfad dann relativ zum Build-Root verankert +

+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Effektiv ist das '#'-Präfix jetzt in $INSTALLDIR und $TARGDIR hineingewandert. Das ist aber eine SCons-spezifische Konvention, mit der der Icon-Renderer natürlich nix anfangen kann +

+ +
+ +
+
+ + + + + +
+ + + + + + + +

+ der verhält sich nach dem Motto: »schad ja nix«... +

+

+ Auf einigen esoterischen Platformen müssen Shared-Libs tatsächlich executable sein, und auf allen anderen Plattformen wird das Flag ignoriert +

+ +
+
+ + + + +

+ Es ist nämlich so: Shared-Libs können eine main()-Funktion enthalten; und wenn das der Fall ist, können sie auch als Executables aufgerufen werden. Rein theoretisch könnte das ein Baustein in einem komplexen Exploit sein, der aus einer überraschenden Ecke käme, da das ein Thema ist, was niemand »auf dem Radar hat«. Manche Libraries haben in der Tat ein Main, und das macht typischerweise gewisse Diagnose-Funktionalität. +

+

+ +

+

+ Klingt alles doch einigermaßen an den Haaren herbeigezogen, aber Debian stellt sich auf den Standpunkt: Unnötiges verbieten schad' nix +

+ +
+
+ + + + + + + + + +

+ ...das liegt daran, daß ich das Bauen von Executables und Libraries und Plugins bereits hochgradig customised habe, im LumieraEnvironment. Das bedeutet, es gibt bereits einen env.Install()-Aufruf, tief in Lumiera-spezifischem Framework-Code. Genau diesen Aufruf muß ich nun so modifizieren, daß entweder davor oder danach noch die Permissions geändert werden. +

+ +
+ + + + + + +

+ Use one of these approaches: chain actions in a single Command, or install first then attach a post-action (via AddPostAction  or Command on the installed node). Both keep the install and chmod as a single build step. +

+
+ + +

+ Examples +

+
    +
  • + Chain actions in a single Command (recommended when you want one target built by a composed action): +
  • +
+

+    
+

+ py +

+
+
env.Command(
+    target = '$INSTDIR/myfile',
+    source = 'myfile',
+    action = [
+        env.Install('$INSTDIR', '$SOURCE'),
+        SCons.Action.Action('chmod 0644 $TARGET')
+    ]
+)
+
    +
  • + Install then add a post-action to change permissions (clear intent, uses SCons helpers): +
  • +
+

+    
+

+ py +

+
+
installed = env.Install('$INSTDIR', 'myfile')
+env.AddPostAction(installed, SCons.Action.Action('chmod 0644 $TARGET'))
+
    +
  • + Install then use the built-in Chmod builder on the installed node: +
  • +
+

+    
+

+ py +

+
+
installed = env.Install('$INSTDIR', 'myfile')
+env.Chmod(installed[0], 0o644)
+
+ + +

+ Tips & Alternatives +

+
    +
  • + Prefer env.Command when you need a single atomic step that both installs and changes permissions. +
  • +
  • + Use AddPostAction when you want to keep the install separate and express a follow-up operation. +
  • +
  • + env.Chmod is a portable, Python-level builder; string chmod  commands rely on the shell/OS. +
  • +
+ +
+ + + + + +

+ das wäre schön ... demnach ist ja SCons wirklich so generisch, wie ich gehofft hatte +

+ +
+
+ + + + + + + + + +

+ die entsprechende Methode hanhabt einen Builder-Parameter install=True +

+ +
+ + + +

+ ...den habe ich wohl so eingebaut, damit dieser Umstand auch deklarativ sichtbar wird; zudem gibt es Build-Resultate, die nicht installiert werden (z.B. Tests) +

+ +
+
+ + + + +

+ Es ist klar wie das geht, ich empfinde es aber nach heutigen Standards nicht mehr als besonders schön, aber praktisch, da das hier ein letztlich in sich geschlossenes Ökosystem ist +

+ +
+
+ + + + + + + + + +

+ Debian/Trixie hat 4.8 +

+ +
+ +
+
+
+ + + + + + + + +

+ Nein. Macht den Code viel komplexer und steht in keinem Verhältnis zum Nutzen, denn die paar Library-Builder invocations werden uns nicht umbringen +

+ +
+ +
+ + + +
+
+
+
+ + + + + + +

+ ....und jetzt wird's mal Zeit, das aufzuräumen, da ich nun sowiso schon so viel Aufwand in Clean-up gesteckt habe!!! +

+ +
+
+ + + + + + + + + + + + + + + + +

+ wenn Files als Seiteneffekt erzeugt werden, kann es helfen, explizit ein Manifest-File als HIlfs-Target zu erzeugen +

+ +
+
+ + + + +
+ + + + + +

+ ...und wir fügen das erzeugte Objekt per env.Append(BUILDERS=) hinzu. Genau wie in der Doku immer noch dargestellt +

+ +
+
+ + + + + + + + +

+ Anmerkung: das war alles eine falsche Fährte +

+ +
+
+
+ + + + + + + +

+ Parsing icons/svg/track-unlocked.svg +

+

+ scons: rebuilding `target/gui/icons/24x24/track-unlocked.png' because: +

+

+            `data/icons/svg/track-unlocked.svg' changed +

+

+            `target/rsvg-convert' changed +

+

+ rendering Icon: data/icons/svg/track-unlocked.svg --> target/gui/icons/24x24/track-unlocked.png target/gui/icons/22x22/track-unlocked.png target/gui/icons/16x16/track-unlocked.png +

+

+ Parsing data/icons/svg/track-unlocked.svg +

+ +
+
+ + + + + + +

+ in tool/SConscript (letzte Zeile) +

+
+
+

+ # Rendering the SVG Icons depends on rsvg-convert +

+

+ env.Depends(icons, rsvg) +

+

+ +

+
+
+ +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ daß er nämlich wenig systematisch aufgebaut ist, und darauf angewiesen, daß alle Daten korrekt normalisiert sind, und die Aufrufe jeweils richtig erfolgen: +

+
    +
  • + aufgerufen werden muß auf der Dependency +
  • +
  • + aber das 'node'-Argument muß die Node des davon abhängigen Targets liefern +
  • +
  • + denn es werden die Dependencies des Targets mit der Build-Information der Source verglichen +
  • +
+ +
+
+
+ + + + + + + +

+ ...um all die Komplexität von unserem SCons-Build auszuschalten; also praktisch das beispiel für einen Builder mit Emitter aus der Doku nachbauen +

+ +
+ + + + + + + + + + + + +
+
+

+ from SCons.Environment import  Environment +

+

+ from SCons.Builder import Builder +

+

+ from SCons.Script import Decider +

+

+
+ +

+

+
+ +

+

+ Decider('content-timestamp') +

+

+
+ +

+

+ env = Environment() +

+

+ bld = Builder(action='(echo -n "FOO `date -Isecond` :"; cat) < $SOURCE > $TARGET') +

+

+ env.Append(BUILDERS={'Foo': bld}) +

+

+
+ +

+

+
+ +

+

+ env.Foo('file.foo', 'file.input') +

+

+ env.Program('hello.c') +

+

+
+ +

+

+ +

+
+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ sondern enthält genau einen Eintrag, nämlich die SOURCE +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + +

+ Die Action ist hier ein Python-Objekt +

+ +
+
+ + + + + + + + +

+ ...und hier wird self (=die Target-Node) als 4.Parameter mitgegeben, die Prüfung erfolgt auf dem child, also der Source-Node +

+ +
+
+ + + + + + +

+ was korrekt wit, da auch explain() auf der Source-Node aufgerufen wird +

+ +
+
+ + + + +

+ scons: rebuilding `target/gui/icons/24x24/track-unlocked.png' because the contents of the build action changed +

+ +
+
+
+
+
+
+
+
+
+ + + + + + +

+ Short answer +

+

+ Make the Action expose a stable, deterministic signature by providing an explicit string function (strfunction) and/or an explicit variable list (varlist) when creating the Action, and avoid putting non-deterministic values (timestamps, randoms, VM-specific paths) into that signature. +

+

+ Why +

+

+ SCons decides whether to rebuild partly from the Action's signature  (a string representing the action) and from node signatures. A Python Action built without an explicit strfunction can produce unstable or overly-broad signatures and cause unnecessary rebuilds. +

+

+ How (concise example) +

+
    +
  • + Import SCons Action and make the Python function do the work. +
  • +
  • + Provide an explicit strfunction that returns a deterministic string (or a short label). +
  • +
  • + Optionally provide varlist to include relevant environment variables in the signature. +
  • +
+

+ Example: +

+

+    
+

+ python +

+
+
from SCons.Action import Action
+
+def my_build(target, source, env):
+    # do deterministic build steps
+    with open(str(target[0]), "wb") as out:
+        out.write(open(str(source[0]), "rb").read())
+    return None
+
+# deterministic signature string; keep it short and stable
+def my_strfunc(act, target, source, env):
+    return "my_build: %s -> %s" % (",".join([s.path for s in source]), ",".join([t.path for t in target]))
+
+# optionally include env variables that should affect rebuilds
+my_action = Action(my_build, my_strfunc, varlist=['MYFLAG', 'OTHER_VAR'])
+
+env.Command('out.bin', 'in.bin', my_action)
+

+ Practical rules +

+
    +
  • + Provide strfunction (or cmdstr) so the action signature is explicit and stable. +
  • +
  • + Use varlist to include only environment variables that legitimately change build output. +
  • +
  • + Avoid including timestamps, absolute temp paths, random values, or local-only data in the signature. +
  • +
  • + Prefer content-based decider (SCons default) for file changes; only make action signature sensitive to what truly affects outputs. +
  • +
+

+ Tips & Alternatives +

+
    +
  • + To debug why SCons rebuilds, run SCons with --debug=explain to see which signature or node change triggered the rebuild. +
  • +
  • + If you need fully content-driven rebuilds, ensure the decider is set appropriately and rely on file content signatures rather than variable-heavy action signatures. +
  • +
+ +
+ + + + + + + + +

+ aber ist komplett falsch und irreführend +

+ +
+
+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Muß schon sagen, nach einiger Zeit Debugging bin ich schon wieder am Kotzen. Dieser Stil!!!! +

+

+ Man akzeptiert irgendwas und geht dann durch eine zigfach verschachtelte Kette von Adaptern, solange bis es irgendwann.... wenn ... dann ... eben doch irgendwie paßt +

+ +
+ +
+ + +
+ + + + + + + + + + + + + + + + +

+ die Builder-Funktion in Lumiera ruft ein externes Python-Modul auf +

+ +
+
+ + + + + +

+ copyMergeDirectory=<function copyMergeDirectory at 0x7f0eeb296ac0> +

+ +
+
+ + + + +

+ copyMergeDirectory=<function copyMergeDirectory at 0x7f5e85912ac0> +

+ +
+
+
+
+
+ + + + + + + + + + + + + +

+ r-grep über das ganze SCons-Paket gemacht.... +

+

+ Die Klasse erbt von der 'ABC' - Basisklasse (Python-3-Konstrukt). Aber die Argumente von gc(...) sprechen eigentlich dafür, daß das zu SCons gehört +

+ +
+
+ + + + + + +

+ Diese Mentalität der Leute macht mich wütend. +

+

+ Kann man mal sein Hirn einschalten, bevor man loshackt?? +

+

+ Wenn jemand eine eigene Implementierung liefert, dann hat er Gründe dafür und man kann erwarten, daß dann auch der Kontrakt erfüllt wird. Woher wollen die denn wissen, ob eine custom-Implementierung überhaupteine »Varlist« eingeschlossen haben möchte???!!  Zumal die ABC (ActionBase) gar kein Attribut 'self.varilist' hat... das kommt erst im nächsten Layer dazu. +

+ +
+ +
+
+ + + + + + + +

+ es teht ja nur darum, re-Builds der Icons zu vermeiden +

+ +
+
+ + + + + + + + + + + + + + + +
+ + + + + + + + +

+ ...die Standard-Implementierung dieser get_contents()-Methode vewendet ein Rendering der involvierten Code-Objekte, inklusive der Variablen. Hier würde der IconSvgRenderer auftauchen. Stattdessen setzen wir eine Prüfsumme auf den Python-Quellcode; das Executable rsvog-convert ist sowiso auch noch eine Dependency, und auch Änderungen daran würden erkannt. Und natürlich Änderungen am SVG-Quellcode. +

+ +
+
+ + + + +

+ ...und das lassen wir SCons machen, das kann das ja sehr gut... +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Nov.2025 beim Erweitern/Debuggen entdeckt: da stößt das Setup mit der Hilfsfunktion getDirname() an ihre Grenzen. Gilt vermutlich auch für den ConfigData()-Builder. So belassen. Also: besser immer ein Präfix angeben, es ist ja auch kein optionales Argument +

+ +
+ +
@@ -169985,6 +180992,18 @@ Since then others have made contributions, see the log for the history.
+ + + + +

+ ...aber derzeit läuft unser Trac nicht, und ich kann nicht auf das Ticket zugreifen. Hab die Zeile mit dem Workaround einfach wieder rausgenommen +

+ +
+ + +
@@ -170046,14 +181065,14 @@ Since then others have made contributions, see the log for the history.
- + - + @@ -170074,7 +181093,7 @@ Since then others have made contributions, see the log for the history. - + @@ -170543,7 +181562,11 @@ Since then others have made contributions, see the log for the history.
- + + + + + @@ -170577,7 +181600,7 @@ Since then others have made contributions, see the log for the history. - + @@ -170672,7 +181695,7 @@ Since then others have made contributions, see the log for the history.

- /* + /*

  INDEX-ITER.hpp  -  iterator with indexed random-access to referred container @@ -170705,7 +181728,7 @@ Since then others have made contributions, see the log for the history.

- */ + */

@@ -170726,8 +181749,9 @@ Since then others have made contributions, see the log for the history.
- + + @@ -170857,6 +181881,9 @@ Since then others have made contributions, see the log for the history. + + + @@ -170879,7 +181906,12 @@ Since then others have made contributions, see the log for the history. - + + + + + + @@ -170933,12 +181965,12 @@ Since then others have made contributions, see the log for the history. - +

- Wichtig: hier nur was wirklich gebaut ist und funktioniert! + Wichtig: auf der Doku-Seite zum Paket nur was wirklich gebaut ist und funktioniert!

@@ -171107,6 +182139,10 @@ Since then others have made contributions, see the log for the history.
+ + + + @@ -171209,8 +182245,9 @@ Since then others have made contributions, see the log for the history. - - + + + @@ -171231,6 +182268,7 @@ Since then others have made contributions, see the log for the history.
+ @@ -171244,7 +182282,7 @@ Since then others have made contributions, see the log for the history.
- + @@ -171288,7 +182326,7 @@ Since then others have made contributions, see the log for the history. - + @@ -171367,12 +182405,36 @@ Since then others have made contributions, see the log for the history. - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -171670,13 +182732,14 @@ Since then others have made contributions, see the log for the history. - + - + + @@ -171684,7 +182747,7 @@ Since then others have made contributions, see the log for the history. - + @@ -171843,7 +182906,7 @@ Since then others have made contributions, see the log for the history. - + @@ -172182,11 +183245,1447 @@ Since then others have made contributions, see the log for the history. + + + + + +
    +
  • + master fungiert direkt als upstream-Branch +
  • +
  • + das Versionsschema angepaßt: upstream-tag = v%(version)s +
  • +
+ +
+ + + +
+ + + + +

+ wird veröffentlicht in einem separaten Git-Repo debian/lumiera, ist aber auch in meinem 'ichthyo'-Repository +

+ +
+
+ + + + + + + +

+ die stammt eigentlich aus der Lumiera-Webiste und wurde umgeschrieben in ein eigenständiges HTML.... unbedingt per Diff/Merge  aktualisieren vom Website-Content! +

+ +
+ + +
+
+
+ + + + + + + + + + + + + +

+ Dort bin ich bereits vor ½ Jahr durch die ganze Serie von Neuerungen im Debian-Standard gegangen und habe viele Detail-Fragen geklärt +

+ +
+
+ + + + + + +

+ Soll die Dokumentationsgenerierung überspringen, aber ein leeres Doumentations-Paket bauen +

+ +
+ +
+
+ + + + + + +

+ ...und wenn das problematisch wird, sollte das DEB-Packaging die DEB_BUILD_OPTIONS "terse" unterstützen +

+ +
+ + + + + + + + + + +

+ war letztlich eine Sackgasse, +

+

+ hat aber wichtige Umstände geklärt +

+ +
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Speziell GLib ist bekanntermaßen buggy, wenngliech auch sich das in den letzten Jahren verbessert hat. Aber die Leute ändern und modernisieren auch ständig ... also gibt es nicht wirklich einen »Kompatibilitäts-Level« +

+ +
+
+ + + + +

+ deshalb ist es ja »Referenz-Platform«, was auch bedeutet, wir orientieren uns nach Vorne, und die Referenz-Platform ist eigentlich der Mindest-Level (mit ein klein wenig Wasser unter dem Kiel, wegen Ubuntu) +

+ +
+ + +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +

+ ...nur mit dem Unterschied, daß wir hier nun die Aufrufe direkt im debian/rules stehen haben; im Grunde hat uns die "magic" gar nicht viel gebracht, nachdem man sich erst mal damit beschäftigt hat. +

+ +
+
+ + + + +

+ override_dh_auto_clean: (hier zusätzlich optcache und configure-cache weglöschen) +

+

+ override_dh_auto_build +

+

+ override_dh_auto_test +

+

+ override_dh_auto_install +

+ +
+
+ + + + +

+ DEB_SCONS_OPTIONS = \ +

+

+ BUILDLEVEL=ALPHA \ +

+

+ DEBUG=True       \ +

+

+ OPTIMIZE=False   \ +

+

+ VALGRIND=False   \ +

+

+ ARCHFLAGS=" -fstack-protector-strong" +

+ +
+
+
+ + + + + + + + + + + + +

+ SCons verwendet eine MD5-Summe über den Quellcode und außerdem  auch über alle Compiler-Schalter und Environment-Settings +

+ +
+ +
+ + + + +

+ sollte daher alle drei Targets mit den gleichen Settings aufrufen +

+ +
+ +
+ + + + +

+ Folgeproblem: *** Directory path for variable 'INSTALLDIR' does not exist: debian/lumiera +

+ +
+ + + + + + + + +

+ prüft und Syntax, aber nicht ob das Filesystem-Element existiert +

+ +
+ + +
+ + + + + + + + + + +

+ NodeDevel_test : hier werden Checksummen über Datenblöcke gebildet und eine dafür präparierte Render-Pipeline geschickt. +

+

+ Dieser Test enthält keine concurrency — also deutet ein (nicht reproduzierbarer) Fehler hier auf ein Hardware-Problem hin (den Verdacht hab ich schon länger) +

+ +
+ + + + + + + + + + + +

+ Unterschied: -fstack-protector-strong +

+ +
+ + + + + + + +
+
+

+ Buffer clone[50]; +

+

+ for (uint i=0;  i<channels; ++i) +

+

+ CHECK (not clone[i]->isSane()); +

+

+ +

+
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + +

+ ist Sane() prüft nur header_.isPlausible() ⟹ das prüft ob ein das Marker-Wort im Header liegt — was durchaus der Fall sein kann, wenn exakt an der gleichen Stelle vorher schon mal ein Buffer-Header lag.... +

+ +
+
+ + + + + +

+ ...vermutlich mit dem temporären TestFrame, der beim vorhergehenden Test während der Verifikation erzeugt wird. Dieser dürfte ja in den Bereich fallen, der in dieser Methode vom zweiten Array abgedeckt wird +

+ +
+
+ + + + + + + + + + + + +

+ alle Verwendungen (nur in diesem Test) brauchen einen sauberen Buffer +

+ +
+ + + +

+ Dieses Konstrukt wird (augenscheinlich, habe dies stichprobenhaft geprüft) nur in diesem einen Test verwendet. Es werden jeweils ein/mehrere Buffer auf den Stack gelegt. In den meisten Fällen wir dann in diesen Buffer etwas generiert. In einigen Testfällen wird vorher geprüft, daß der Buffer keinen validen Testframe enthält, und nachher, daß dies der Fall ist. Die Prüfung vorher scheitert im vorliegenden Problemfall, vermutlich weil im Stack-Speicher exakt an der gleichen Stelle vorher das gleiche Verarbeitungsmuster stattfand +

+ +
+
+ + + + +

+ TestFrame selber generiert in seinem Konstruktor stets eine valide Buffer-Füllung und belegt alle Metadaten. Möglicherweise hatte ich die Idee, den »Buffer« über beliebige Storage legen zu können, um sie dann zu begutachten. Diese Verwendung fand dann aber nicht statt +

+ +
+
+
+ + + + + + + +

+ das erspart mir das Gewürge, da std::byte kein numerischer Datentyp ist +

+ +
+
+
+
+
+ + + + + + + +

+ hab gesehen daß der Speicher jetzt mit NULL gefüllt wird +

+ +
+
+ + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +

+ Seltsam.... +

+

+ Ich sehe keinerlei generische Platzhalter in meinem File...  Allerdings werde ich das demnächst ohnehin umstellen auf das maschinenlesbare Format +

+ +
+
+ + + + + + + + + + +

+ g++ -o target/modules/libtest-vault.so -Wl,--no-undefined -Wl,--as-needed -Wl,-soname=libtest-vault.so -Wl,-rpath=\$ORIGIN/../modules,--enable-new-dtags -shared tests/vault/mem/extent-family-test.os tests/vault/gear/activity-detector-test.os tests/vault/gear/scheduler-usage-test.os tests/vault/gear/test-chain-load-test.os tests/vault/gear/scheduler-commutator-test.os tests/vault/gear/scheduler-activity-test.os tests/vault/gear/scheduler-invocation-test.os tests/vault/gear/work-force-test.os tests/vault/gear/block-flow-test.os tests/vault/gear/scheduler-stress-test.os tests/vault/gear/scheduler-service-test.os tests/vault/gear/scheduler-load-control-test.os tests/vault/gear/special-job-fun-test.os -lm -ldl -lpthread -lrt -lnobugmt -lstdc++fs -lboost_program_options -lgavl target/modules/liblumieravault.so target/modules/liblumieracommon.so target/modules/liblumierasupport.so +

+ +
+ +
+ + + + + + + + + + + + + + + + +

+ Da wir ja ein durchaus spezielles Versionsnummernschema haben. Die Fehlermeldung sieht so aus, als würde das als ein RC für eine Version v0 gedeutet +

+ +
+ +
+ + + + + + + + + + + + + + + +
+ + + + +

+ doc-base-file-references-missing-file /usr/share/doc/lumiera/README.debian +

+ +
+ + + +

+ dämlicher Typo +

+ +
+ +
+ + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Für die Installation per DEB-Paket brauchen wir kein allgemeines README, da vor allem die Bau- und Installations-Vorrausetzungen bereits erfüllt sind, und auch die Lizenz anderweitig deklariert wird. Daher sollte hier im README.debian alles für den reinen User Wissenswerte stehen +

+ +
+
+ + + + +
    +
  • + auf die NEWS +
  • +
  • + Auf die Website +
  • +
  • + (geplant: User-Manual) +
  • +
+ +
+
+
+ + + + + + + + + + + + + + +

+ /documentation/user/manual.html +

+ +
+ +
+ + + + + + + + + + + + + +

+ das war eine Scheiß-Arbeit... +

+
    +
  • + das Savepage-Plugin schreibt das DOM komplett neu +
  • +
  • + es fügt <tbody>-Elemente ein +
  • +
  • + es löst HTML-Entities auf (was ich definitiv nicht will, obschon es wegen UTF-8 eigentlich möglich wäre) +
  • +
  • + es fügt hinter jedem schließenden Tag noch whitespace ein (Windows???) +
  • +
+ +
+ +
+
+ + + + +

+ und den Output in doc/devel/LumieraHelpLandingPage.html einchecken +

+ +
+ +
+ + + + + + + + + +

+ Denn in Zukunft sollt das Buildsystem auch irgendwann mal ein User-Manual generieren und korrekt installieren; diese Platzhalter-Seite markiert mithin bereits den Ort dieser Installation und dient auch als Anker für diese zukünftige Funktionalität +

+ +
+ + +
+ + + + + + + +

+ ....naja... das ist relativ; wie bei jeder DSL, wenn man mal das Schema verstanden hat, dann ist es konzis und deklarativ, und wenn man das Schema wieder vergessen hat, dann ist es »magisch« +

+ +
+ +
+ + + + + + + + + + + + + +

+ (gemäß FHS) ⟹ <prefix>/share/doc/<paktename>/ +

+ +
+
+ + + + + + + + + + + + + + + + + + +

+ Das hier ist ein Buildsystem für ein Projekt von überschaubarem Umfang. Ganz ehrlich, ich erwarte nicht, daß irgendjemand außer mir  das SCons mag und pflegt. Also geht es höchstens darum, nach bestehendem Schema die eine oder andere Datei hinzuzufügen. Überdies frage ich mich, wie lange wir bei SCons bleiben können (hoffentlich noch lange, und hoffentlich darf dann nicht ich einen Ersatz programmieren, oder mich mit CMake herumärgern, das bei Weitem nicht so deklarativ ist +

+ +
+ +
+
+
+ + + + + + + +

+ dann wird subdir = <die letzte Pfadkomponente>, und das ist nicht, was man erwartet, sofern die Directories mehr als eine Ebene tief liegen. Kann ich jetzt nicht so ohne Weiteres ändern, ohne die Hilfsfunktion getDirname() (BuildHelper.py) umzuschreiben. Das ist es mir dann doch nicht wert! +

+ +
+ + + +
+
+
+ + + + +

+ Installationsziel: <prefix>/share/doc/lumiera/manual-html/index.html +

+ +
+
+ + + + +
+
+
+ + + + + + + +

+ Was aber auch daran liegen könnte, daß XFCE nicht Gnome ist +

+ +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Bei den GUI-Icons gibt es ein app-icon.svg — aber das sieht unfertig/kaputt aus; vermutlich hat sich da Joel damals daran versucht, aber er ist daran gescheitert, daß das Lumiera-Logo sich nicht ohne Weiteres in ein Icon übersetzen läßt. Außerdem folgen diese SVGs ja einem ganz bestimmten Schema, und enthalten daher mehrere Varianten auf einem gemeinsamen »Canvas« +

+ +
+
+ + + + +

+ Tja... damals hat man zwar ein Lumiera-Logo designt — aber dann würde noch die Arbeit ausstehen, daraus eine Design-Linie zu entwickeln, die in verschiedensten Größen und in verschiedenem Umfeld konsistent funktioniert. Und ersatzweise hat dann jeder für jeden Einzelfall seine Variante gebastelt (und ich mach ja auch nix Anderes) +

+ +
+ + + + + + + + + + +

+ Deklarativität setzt etablierte Kategorien vorraus +

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Some works meticulously keep track of what copyrights and licenses apply to each particular file when combining source from multiple origins. Some instead apply + +

+ all licenses and all copyrights of component parts to the entire combined work. Both are generally accepted by the open source community, as long as it's clear that an effort is being made to identify and comply with the original licenses. +

+ +
+
+ + + +
+ + + + +

+ Das ist expizit erlaubt und stellt ein Statement für die Codebasis als Sammel-Veröffentlichung dar; diese Angabe ersetzt nicht die Angaben für die Files, aber stellt eine (damit zwingend kompatible) Veröffentlichung eines Sammelwerks dar, welches damit ein vereinfachtes Handle bietet für die Weiterverbreitung (und insofern dann zumindest die Einzel-Lizenzen überlagert). Bezüglich der Attributierung ist die GPL ja nicht so streng wie die CC oder Apache +

+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +

+ ...ist mir aber schon neulich aufgefallen, beim Aufbereiten der Daten für die Historien-Seite. Joel war also noch gut 1 1/2 Jahre formal im Projekt mit dabei, und hat an Meetings teilgenommen, bis er sich offiziell verabschiedet hat +

+ +
+
+
+ + + + + + + + + + + + + + + + +

+ das Alsa-Experiment, was unfertig ist und nur funktioniert wenn die Soundkarte zwei Kanäle hat und 16 Bit erwartet (also bei mir funktioniert es schon mal nicht deshalb). Allerdings ist das Experiment bis heute im Code, als lumiera-output-probe. +

+ +
+
+ + + + + + + + + + + +

+ In der aktuellen Codebasis ist kein Code von ihm (mehr) enthalten, und sein Code wurde nie verwendet. Sein Beitrag ist auf der »Credits« page gewürdigt, allerdings auch da nur unter "IRC crew" +

+ +
+ + +
+
+ + + + + + + +

+ Die Authorschaft am Code hat rechtliche Relevanz, denn sie begründet eine Lizenz und auch ein Veto-Recht im Falle einer intendierten Lizenz-Änderung (z.B. Kommerzialisierung). Auf diesem Hintergrund halte ich es nicht sinnvoll, jemanden als "Code-Author" zu führen, der keinen signifikante  Beitrag zum Code geleistet hat, denn Copyright setzt eine gewisse »Schöpfungshöhe« vorraus. +

+ +
+ + +
+
+
+ + + + +

+ Die Zeiträume des Copyright mit aufgeführt, und explizit auf das Git-Repo verwiesen, den allgemeinen Einsichten gemäß, die ich heute über die Wirkungsweise des GPL-Copyright gewonnen habe: Zeitpunkt und Autoren-Namen müssen für die GPL verbindlich mitgeführt werden, es ist aber nicht eigens eine »Attribution« notwendig (jedoch die Git-Historie allein genügt nicht, sondern die summarische Info muß auch irgendwo im Content zu finden sein) +

+ +
+ +
+
+
+ + + + + + + + + +

+ Hypothese: ich hab bisher nie aus einem komplett gecleanten Git-Tree heraus gebaut, sondern das Signaturfile war bereits da und es wurden daher zumindest die Plattform-Tests gecached. Vielleicht lag es aber auch daran, daß bisher CDBS das SCons clean erst nach der Source-Erstellung aufgerufen hat? +

+ +
+
+ + + + + + + + + +

+ soll nicht in den Orig-Source-Tarball +

+ +
+
+ + + + +

+ Änderungen daran sollen ignoriert werden, da sonst der Paketbau nach dem ersten Clean abbrechen würde +

+ +
+
+
+
+
+ + + + +

+ WorkForce_test und SchedulerStress_test +

+

+ Der Paket-Build ist eine schwierige Ausgangssituation, da kurz vorher das System unter Vollast stand. Es ist mir zwar gelungen, die Tests im normalen Entwicklungs-Setup weithin zuverlässig zu bekommen, aber es ist nahezu unmöglich, herauszufinden, was genau beim Paketbuild dann doch anders läuft +

+ +
+ + + + + + + + + + + + + + + + + + +

+ Forky ist im Moment noch weitgehend identisch zu Trixie; daher hatte ich es ja auch (noch) nicht als unterstützte Platform definiert. Das wird erst in etwa einem Jahr sinnvoll sein, wenn sich Forky deutlich weiterentwickelt hat. Insofern ist es jetzt auch (noch) nicht sinnvoll, die Vorläuferpakte zu bauen, denn sie werden in einem Jahr obsolet sein +

+ +
+ +
+
+ + + + + + + + + + + + + + + + + + +

+ 0000000515: CHECK: file-support-test.cpp:85: thread_1: simplifiedPermissionAccess: (not out.good()) +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ CHECK: incidence-count-test.cpp:127: thread_1: verify_incidentCount: (isLimited ( 5500, stat.timeCase(1), 6800)) +

+ +
+ + + + + + + + + + + + + + + +
+ + + + +

+ Das DEB-Paket ist nun reif für das Release +

+
    +
  • + Paketinhalt ist nun so wie definiert +
  • +
  • + alle relevanten Lintian-Meldungen wurden behoben +
  • +
  • + Lumiera wird nun korrekt ins Menü eingebunden +
  • +
  • + einige instabile Tests (von marginaler Bedeutung) wurden per Patch deaktiviert +
  • +
  • + Paketbau auch auf Ubuntu/Noble bestätigt +
  • +
+ +
+ + +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + +

+ dpkg-shlibdeps: Warnung: Name und Version können nicht aus Bibliotheksnamen »liblumierasteam.so« entnommen werden +

+ +
+
+ + + + +

+ LumieraEnvironment.py, Line 391: +

+

+ +

+
+
+

+ def defineSoname (self,  target, **kw): +

+

+ """ internal helper to extract or guess +

+

+ a suitable library SONAME, either using an +

+

+ explicit spec, falling back on the lib filename +

+

+ """ +

+

+ if 'soname' in  kw: +

+

+ soname = self.subst(kw['soname'])  # explicitly defined by user +

+

+ else: # else: use the library filename as DT_SONAME +

+

+ +

+
+
+ +
+
+ + + + + + + + + +

+ Die Manpage ist komplex, und das Thema auch ... so auf die Schnelle verstehe ich nicht, was hier von wem wie ausgewertet wird +

+ +
+
+
+
+
+ + + + +

+ Derzeit(2025) ist noch überhaupt nicht klar, in welcher Form wir Dokumentation ausliefern; naheliegend wäre es, unser (nicht vorhandenes) User-Manual aus den Asciidoc-Quellen zu bauen und damit als HTML lokal auszuliefern; das funktioniert aber nicht so ohne Weiteres, da die Seiten auf unsere Website abgestellt sind, und daher die volle Struktur vorraussetzen, und im Besonderen einen Webserver. Diesbezüglich fällt mir natürlich sofort das Stichwort »HTML-Help« ein — kann Asciidoc sowas generieren? +

+ +
+ + + + + + + + +
+
+
+ @@ -172213,7 +184712,7 @@ Since then others have made contributions, see the log for the history. - + @@ -172251,7 +184750,7 @@ Since then others have made contributions, see the log for the history. - + @@ -172447,6 +184946,7 @@ Since then others have made contributions, see the log for the history. + @@ -172652,6 +185152,7 @@ Since then others have made contributions, see the log for the history. + @@ -172768,7 +185269,7 @@ Since then others have made contributions, see the log for the history.
- + @@ -172881,6 +185382,7 @@ Since then others have made contributions, see the log for the history. + @@ -172990,8 +185492,217 @@ Since then others have made contributions, see the log for the history.
- + + + + + + + + +

+ Zehn Jahre Reise ins Ungewisse.... +

+
    +
  • + jetzt auf Debian/Trixie angekommen und C++23 +
  • +
  • + mitten im »Playback Vertical Slice« +
  • +
+ +
+ +
+ + + + + + + +
    +
  • + master fungiert direkt als upstream-Branch +
  • +
  • + das Versionsschema angepaßt: upstream-tag = v%(version)s +
  • +
+ +
+ + + +
+ + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
  • + git clone in ein Unterverzeichnis vom Paketverzeichnis +
  • +
  • + Paketverzeichnis in den Container gemounted
    + +
    podman run -v /Werk/Gang/pack:/pack -it ichthyo/pack-debian-trixie-20250317
    +
  • +
  • + im Container.... +
  • +
      +
    • + (ggfs dort equivs installieren) +
    • +
    • + cd /pack +
    • +
    • + mk-build-dep --install --remove +
    • +
    • + gbp buildpackage --git-tag +
    • +
    +
+ +
+ + + + + +

+ Vorbereitung: +

+

+ ./build-pack-dock debian:trixie-2025#### +

+ +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -173104,6 +185815,49 @@ Since then others have made contributions, see the log for the history. + + + + + + + + +

+ Das Log ist geflutet mit Warnungen, und viele Querverweise funktionieren nicht. Leider sind Probleme mit Doxygen schwer zu diagnostizieren, da der Lauf lange dauert, und die Codebasis riesig ist. Es gibt daher keine klar definierte Agenda, die man sinnvoll abarbeiten könnte. Ich kann immer nur von Zeit zu Zeit stichprobenartige Kontrollen machen +

+ +
+ + + + + + +

+ ...obwohl ich diese Warnung abgeschaltet habe; wahrscheinlich handelt es sich um Fälle, wo ich (gemäß Clean Code) nur einen Parameter dokumentiert habe, der nicht selbsterklärend ist. +

+ +
+
+
+ + + + +

+ Ich finde die Seiten meist total verwirrend; es sind eigentlich nur die File-Kommentare sinnvoll. Selbst die Typ-Kommentare sind oft verwirrend, weil die Typen irgendwo stehen und der Kontext nicht so ersichtlich ist wie im Code. Hinzu kommt, daß der allgemeine Scope (auch Namespace) oft geflutet ist mit Metaprogramming-Definitionen, die nicht im richtigen Zusammenhang dargestellt werden. Es ist in dem Zusammenhang total unpraktisch, daß die Template-Parameter mit angegeben werden, und daß zusamengehörige Spezialisierungen nicht aufgesammelt werden. Das ist aber vermutlich gar nicht möglich. +

+

+ +

+

+ Insgesamt scheint das Prinzip einer API-Doc nicht auf einen modernen, funktionalen Programmierstil zu passen. +

+ +
+
+
@@ -173296,6 +186050,25 @@ Since then others have made contributions, see the log for the history.
+ + + + + + + + + + + + + + + + + + + @@ -173521,7 +186294,7 @@ Since then others have made contributions, see the log for the history.
- + @@ -173731,6 +186504,151 @@ Since then others have made contributions, see the log for the history.
+ + + + +

+ Reguläres Upgrade der »Referenz-Plattform« ⟼ Debian/Trixie. +

+

+ Diese relevanten Versionen sind allesamt sehr knapp gewählt, unterstüzten aber auch noch Ubuntu/Noble (24.04) +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Es ist also im Besonderen nicht notwendig, daß irgend ein gewerblicher »Dienst« angeboten wird, da auch alle Arten von Publikationen mit erfaßt werden sollen. +

+ +
+
+ + + + +

+ Auf eine Telefonnummer kann man verzichten. Aber die eMail muß regelmäßig gelesen werden (Reaktionszeit: Stunden). Und für die Adresse gilt: man muß dort persönlich einen Verantwortlichen antreffen können. Beispielsweise für eine gerichtliche  Ladung oder einen Durchsuchungsbeschluß. Es ist also eine Postbox explizit nicht ausreichend. +

+ +
+
+ + + + +

+ Umsatzsteuernummer, Name der Zulassungsbehörde, bei Freiberuflern der Name der Stelle die den Titel oder das Diplom ausgestellt hat. Bei Unternehmen die Rechtsform. Bei journalistischen Publikationen, die regelmäßige Aktualisierungen beinhalten und regelmäßig publizierte Druckerzeugnisse wiedergeben (d.h. Zeitungen, Nachrichtendienste) muß ein Verantwortlicher benannt werden, der sofort reaktionsfähig ist (es genügt nicht die Angabe eines Firmensitzes) +

+ +
+
+ + + + +

+ Konkret heißt das: es muß ein Link in den Footer, der »Impressum« heißt und mit höchstens einem Klick zum Ziel führt. Verlinken auf eine Hompage genügt nicht +

+ +
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ das inhärente Problem können wir nicht lösen: wir haben nämlich keinen geordneten Betrieb, weil wir keine Firma sind, sondern uns irgendwie durchwurschteln. Nur auf dieser Basis funktioniert unser Projekt ... leider kann eine zunehmende Regulierung so etwas nicht gestatten, und treibt damit all die »Kleinen« in die Arme des Plattform-Kapitalismus +

+ +
+
+ + + + +
    +
  • + Das ganze Thema Server führt immer zu Spannungen, sobald wir drüber reden. Es geht so lange wunderbar gut, wie die Kiste „irgendwie tut“ und man Christian vertraut... +
  • +
  • + Und noch wichtiger: die Rechtslage ist mir nicht klar. Inwiefern sind wir verpflichtet, unsere Prozeduren überhaupt zu konkretisieren? Genügt es nicht, daß wir uns pauschal zum Datenschutz verpflichten? Letztlich läuft unser Setup darauf hinaus, daß irgend jemand diesen Server nach den »Regeln des Handwerks« betreibt und sonst niemand drauf darf. Und letztlich erheben und extrahieren wir ja tatsächlich keine Daten. Auf diese Situation bezogen hab ich Bedenken, daß wir uns in falsche Tatsachenbehauptungen hineinmanövrieren, wenn wir suggerieren, bestimmte Prozeduren zu haben. +
  • +
+ +
+
+ + + +
+ + + + +
+