From 19497f8a7b44442ed7e3f77444d42854047bedb9 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 28 Oct 2025 02:23:42 +0100 Subject: [PATCH] clean-up: update content of the introductory overview pages MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The »Outer Space« and »Inner Core« documents present a comprehensive overview of the vision, architecture and essential parts of the implementation. In the light of changes to policy, design and implementation approaches, some updates were necessary to align these crucial texts with the current state of planning and implementation. Notably I have added a recent Screenshot of the UI, showing a nested track structure pushed up by Diff from the core. Over the last weeks, I conducted an extended analysis of the inception time of the Lumiera project, which gave me a sharpened understanding of the goals, going forward. I have also written an in-depth essay "Complexity and Flexibility". See the corresponding commits in the Website repository. --- doc/technical/overview.txt | 301 +- doc/user/intro/intro.txt | 98 +- src/lib/diff/gen-node.hpp | 1 + src/lib/several.hpp | 4 + src/lib/split-splice.hpp | 2 +- src/stage/widget/video-display-widget.cpp | 4 + src/stage/widget/video-display-widget.hpp | 3 +- wiki/thinkPad.ichthyo.mm | 4638 ++++++++++++++++++++- 8 files changed, 4813 insertions(+), 238 deletions(-) diff --git a/doc/technical/overview.txt b/doc/technical/overview.txt index 19459c969..a37f5d649 100644 --- a/doc/technical/overview.txt +++ b/doc/technical/overview.txt @@ -1,7 +1,7 @@ Lumiera: The Inner Core ======================= :Author: Lumiera_Core_Developers -:Date: Winter 2012 +:Date: 2012 / 2025 :toc: [abstract] @@ -40,7 +40,8 @@ This three Layers are: The extra components are: Lumiera:: - The main program itself, basically acts only as loader to pull the rest up. + The main program itself, which starts all Subsystems and controls the + overall lifecycle. Common:: Vital components and common services which must be available for pulling up @@ -57,7 +58,7 @@ The Lumiera team agreed on using GNU coding style with slight adaptations. Generally speaking, we strive to keep the code base consistent and stick to widely accepted guidelines and best practices. See our separate link:{ldoc}/technical/code/codingGuidelines.html[Coding Guidelines] page. -Function naming conventions and other details are also described in several RFCs. + Documentation @@ -89,10 +90,20 @@ In practice, this approach might not be suitable at times, nevertheless we try to stick to it as far as possible and maintain fairly complete test coverage. +Furthermore, tests are a vital form of documentation: when done right, +a test engages the functionality by accessing and combining the interfaces +of the code. For many central elements of the Lumiera Application, some tests +are written in a ``narrative style'' to explain how parts are meant to fit +together and shall be used. This kind of test does not focus on covering +all corner cases -- rather it is organised like a trail to showcase +the central ideas and basic assumptions of a component. + Releases and Development Process ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lumiera is developed in a collaborative style. Releases are done ``when ready''. +Feature development and releases are organised using the +link:code/GitBranching.html[Git-flow] branching scheme. We (the core developers) are always open for comments, new ideas and proposals. In fact, there is even a world-pushable ``mob'' Git repository on our server: minor contributions can be pushed there right away, we'll notice any changes. @@ -105,9 +116,9 @@ Porting to other platforms is OK for us, but requires Someone^TM^ to volunteer. For development and dependency management, we try to stick close to what Debian/stable provides. Whenever we need special or more recent libraries, we care for a backport and publish a DEB package for use on Debian/Stable. -We also run a series of Debian Repositories, and we try to build a Lumiera -package for an array of Debian-like distributions (Ubuntu, Mint). Through -these ongoing efforts, we try to keep up with the evolution of platform, +We also run a series of link:/debian/[Debian Repositories], and we try to build +a Lumiera package for an array of Debian-like distributions (Ubuntu, Mint). +Through these ongoing efforts, we try to keep up with the evolution of platform, compilers, language and libraries, and we maintain our ability to release, even while there are no public releases planned for the foreseeable future. @@ -125,7 +136,7 @@ passive, yet provides vital services commonly used. While the core components are linked into a coherent application and may utilise each other's services directly based on C/C++ language facilities, -several important parts of the applications are loaded as plug-ins, starting +several important parts of the application are loaded as plug-ins, starting with the GUI. @@ -137,7 +148,7 @@ contained within the Session, which belongs to the _steam layer_ below. User interfaces are implemented as plug-ins and are pulled up on demand, they won't contain any relevant persistent state beyond presentation. -_As of 2018, the one and only interface under active development is +_As of 2023, the one and only interface under active development is the Lumiera GTK GUI,_ based on GTK-3 / gtkmm. The sources are in tree (directory 'src/stage') and it is integrated into the standard build and installation process. By default, running the 'lumiera' executable will @@ -150,6 +161,12 @@ Steam Layer High Level Model ~~~~~~~~~~~~~~~~ +All the content of the Project is represented as a tree of symbolic objects, +connected together through _Placements._ There are some general conventions +how these objects are expected to be arranged; any content fitting with these +conventions will be discovered, interpreted and transformed into something +that can be rendered and thus ``performed'' + _tbw_ Assets @@ -164,10 +181,6 @@ Scoping ^^^^^^^ _tbw_ -MObject References -^^^^^^^^^^^^^^^^^^ -_tbw_ - QueryFocus ^^^^^^^^^^ _tbw_ @@ -198,6 +211,17 @@ _tbw_ Low Level Model ~~~~~~~~~~~~~~~ +The content of the current Session (the Project) can be _performed_ by +pulling from a set of render pipelines. These are generated automatically +By the Builder and represented as a **D**irected **A**cyclic **G**raph of +_Render Nodes_, chained together, so that the output of one node becomes the +input of the next node. +Each Render Node is backed by a processing function, which is provided by +a »Media processing library« and typically loaded dynamically, as an extension +or Plug-in. The Low-level Model is optimised for rendering performance; the +user can control its structure and contents by re-arranging the objects in +the High-level Model. + _tbw_ @@ -351,17 +375,6 @@ some facilities to monitor and adjust resource usage depending and adapting to the system and current circumstances. -Profiler -^^^^^^^^ - -Collects statistic about resource load, helps to decide if job constraints can -be fulfilled. - -Things to watch: - * CPU utilisation - * memory usage (swapping, paging) - * I/O load, latency - @@ -404,9 +417,6 @@ link:{ldoc}/design/application/SubsystemLifecycle.html#_initialisation_and_lifec link:{ldoc}/design/architecture/Subsystems.html#_lifecycle[documentation] [small]#(likewise incomplete, but we're getting there, eventually [yellow-background]##2018##)# -Interface system -~~~~~~~~~~~~~~~~ -_tbw_ Plugin loader ~~~~~~~~~~~~~ @@ -441,10 +451,6 @@ Serialiser ~~~~~~~~~~ _tbw_ -Config loader -~~~~~~~~~~~~~ -_tbw_ - @@ -469,12 +475,6 @@ contains:: indicate that a value is _somehow contained_ within a collection, sanitise:: make any string usable as identifier. -In a similar vein, the header 'lib/util-foreach.hpp' provides a generic -``for-each-element'' mechanism, which works for all STL containers, but -also for all _Lumiera Forward Iterators_. The loop body is provided -as a functor. In case this functor is a predicate (boolean result), -the +and_all+ and +has_any+ functions allow to test for conjunction -and disjunction. Locking @@ -614,39 +614,12 @@ Errors states get declared in headers with the `LUMIERA_ERROR_DECLARE(err)` macr A matching definition needs to reside in some translation unit, using the `LUMIERA_ERROR_DEFINE(err, msg)` macro. There is no central registry, any component can introduce its own error codes but must ensure that the error identifier is -unique. +unique. An error state is maintained in a thread-local variable, and set automatically +when throwing an exception. Error states can be helpful when diagnosing unexpected +failures, and can be used to ``sneak'' an error condition through a call-chain +of plain-C functions, but are no longer considered a suitable concept for error +handling in general. -.Error handling in C -There are two helper macro forms for setting up error conditions, one is -`LUMIERA_ERROR_SET..(flag, err, extra)` and the other one is -`LUMIERA_ERROR_GOTO..(flag, err, extra)`. Each for different logging levels. -The `SET` form just logs an error and sets it, the `GOTO` form also jumps to -an error handler. Both take a NoBug flag used for logging and a optional -`extra` c-string. - - -[source,C] --------------------------------------------------------------------------------- -const char* -mayfail() -{ - const char* ret = foo(); - if (!ret) - LUMIERA_ERROR_GOTO (flag, FOO_FAILED, 0); - - if (!bar(ret)) - LUMIERA_ERROR_GOTO (flag, BAR_FAILED, 1, - lumiera_tmpbuf_snprintf (256, "foo was %s", ret)); - - return "everything ok"; - - /* cleanup in reverse setup order */ - BAR_FAILED1: - lumiera_free (ret); - FOO_FAILED0: - return NULL; -} --------------------------------------------------------------------------------- @@ -657,20 +630,20 @@ Consequently, we access most services _by type name_, pulling up a single implem instance on demand. Yet some aspects of the *Singleton Pattern* are known to be problematic. Rather than placing this singleton lifecycle logic into the individual implementation classes, we use a _singleton factory_, to manage the instance creation and lifecycle of the singleton -or service instance separate from the singleton class itself. Singleton initialisation happens -lazily with this approach, and thus needs to be protected in a multithreaded environment; we -use Double Checked Locking with std::atomic for this purpose. +or service instance separate from the singleton class itself, as a *Monostate*. Singleton +initialisation happens lazily with this approach, and thus needs to be protected in a +multithreaded environment; we use Double Checked Locking with `std::atomic` for this purpose. Singletons need to be written in a way to cope with that somewhat nondeterministic environment. They will be created on-demand, and be destroyed _eventually,_ in the application shutdown phase. -This results in the general policy that within Lumiera, performing any ``business'' code in the -application shutdown phase (after exiting +main()+) is _strictly prohibited._ Generally speaking, +This results in the general policy within Lumiera that performing any ``business'' code in the +application shutdown phase (after exiting `main()`) is _strictly prohibited._ Generally speaking, destructors _must not perform any significant work_ and are are expected to be failsafe. .accessing the singleton instance By convention, when clients are expected actively to access the singleton instance, the interface class holds the singleton factory as a public static member with the -name +instance+. This allows clients to write `SomeService::instance()` to get a +name `instance`. This allows clients to write `SomeService::instance()` to get a reference to the implementation. .subclasses and services @@ -796,6 +769,72 @@ WARNING: `boost::format` is known to be about 10 times slower than `printf` -- best to avoid it for performance critical code. +Text Template Engine +~~~~~~~~~~~~~~~~~~~~ +While there are a lot of text templating languages and feature-rich +libraries available, none fulfilled our requirements to be minimalist, +and support generic structured data bindings, without enforcing some +specific _property tree_ or ``object'' data type. The solution provided +in `text-template.hpp` supports substitution with the `${name}` syntax, +also with conditionals and repeated instantiation. Data is provided +through a type parameter, which has to fulfil a data binding protocol. +A ready-to-use implementation is available for `std::map`, +key-value bindings given in a string (for the purpose of easy testing) +and for the Lumiera xref:_external_tree_description[»ETD«] framework +(i.e. structured data encapsulated as `GenNode`). + +LL Parser +~~~~~~~~~ +A similar situation was encountered regarding the requirement to parse +nested syntax structures. There is an abundance of library solutions +available, but none fulfilled the requirements of simplicity and +generic data binding. Some solutions are extremely heavyweight, +attempt to mimic an EBNF syntax notation, or deliver the result +model packaged into yet-another object or property tree data format. +The library solution provided in `parse.hpp` is based on the +technique of parser combinators, but uses template metaprogramming +to generate a functor to accept and produce that specific data +structure needed for each individual use case. The accepted syntax +is defined with a builder notation. Instead of a lexer, +regular expressions are used as terminal symbols. + +CSV Data Tables +~~~~~~~~~~~~~~~ +Template Metaprogramming also allows to build a succinct solution +for tabular data with generic typing, which was developed to support +performance testing and statistical evaluations. Data is maintained +in a vector per column, using a generic column definition scheme. +Data can be persisted and loaded from text files with CSV syntax. +The header `data.hpp` is complemented by `statistic.hpp` with some +basic evaluation functions and is used, for example, to generate +Gnuplot diagrams from timing observations, also relying on +the Text Template Engine to parametrise a Gnuplot script. + +External Tree Description +~~~~~~~~~~~~~~~~~~~~~~~~~ +It might seem convenient, yet is in fact dangerous to build a larger +application around a common shared data model. Such a central model +exhibits a fatal tendency to become an ubiquitous source of truth, +which would create an ill-guided incentive towards strong coupling. +According to the principle of subsidiarity, in Lumiera we prefer +treating a data model as an local detail of the implementation. + +However, parts of the application need a way to collaborate by +exchanging chunks of tree-shaped information. A schematic and +formalised notation is used for that purpose, designated as +**E**xternal **T**ree **D**escription, which is structured +similar to JSON, but uses binary data. The implementation +is based on a recursive algebraic data type, but the variant +branches are kept opaque, so that processing can not proceed +by switch-on-selector and thus either requires knowledge about +the expected data pattern in advance, or must be rely on a visitor +implementation otherwise. + +This structured data notation is used at various places, notably +to pass command invocations over the UI-Bus, or to send model changes +in the form of a »Diff message«. + + Wrappers and Opaque Holders ~~~~~~~~~~~~~~~~~~~~~~~~~~~ .smart handle @@ -853,17 +892,6 @@ and assignment incur the cost of an additional virtual call, assuming the target objects cooperate by mixing in a copy management interface. -.vector of references -a minimal interface for an array-like entity, but exposing only references -to the contained elements. Obviously this means to use a virtual call for -the subscript operation. This interface allows interfaces to expose something -_array-like_ without committing to a specific implementation type for the -exposed elements within the ``array''. The Lumiera library provides a set -of standard implementations for this +lib::RefArray+ interface, including -a vector based and a directly array based variant. - -WARNING: in rework 2024 (Playback Vertical Slice) - Unique Identifiers ~~~~~~~~~~~~~~~~~~ @@ -925,16 +953,6 @@ checks or clean-up work. -Temporary Buffers -~~~~~~~~~~~~~~~~~ - -Provides a small number of round robin buffers which need not to be freed. -Must only be used locally when no deep recursion may use tmpbufs. Using these -wrong (recursively) will result in corrupted data. - -Very fast and efficient from smallest too hugest allocations. No need to care -for 'free()' - Template Metaprogramming ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -960,56 +978,58 @@ _tbw_ Preprocessor Metaprogramming ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -ppmpl.h +'ppmpl.h' Algorithms & Datastructures ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Probabilistic Splay Tree -^^^^^^^^^^^^^^^^^^^^^^^^ -Self optimising splay tree +Intrusive Linked List +^^^^^^^^^^^^^^^^^^^^^ +The template `LinkedElements` allows to build intrusive single-linked +data structures, that can be iterated. They can be configured with a +_policy baseclass_ to control if the container takes ownership and to +integrate a custom allocator. The typical usage for such a setup is in +low-level performance-critical data structures for rendering and playback, +where data is already arranged with good locality and shall be +made traversable in some way. -Advantage: - * can be iterated - * very fast in situations where few common elements are queried most often - -Disadvantages - * provides no own locking, needs to be locked from outside - * (almost) every access is a mutation and needs an exclusive lock, bad for concurrency - - - -Hash functions -^^^^^^^^^^^^^^ -_planned_ - - -Linked Lists +Split-Splice ^^^^^^^^^^^^ +Highly configurable generic algorithm for handling a segmentation +of an ordered data axis into seamlessly arranged intervals in +ascending order. The segmentation can be refined with new intervals, +handling all possible cases of relationship to the existing interval +structure. -.llist - -Cyclic double linked intrusive list. - - +Several Elements +^^^^^^^^^^^^^^^^ +A generic, abstracted data container with random access, which plays +a crucial role for the mass allocation of small objects in the Render Engine. +The template `lib::Several` provides array-like access to a sequence of +elements marked as type `TY`, without disclosing the actual data layout or +data type. Notably this allows to place size-constrained polymorphic data +objects into a common memory block. The data structure is created with +the helper template `lib::SeveralBuilder` and can be configured with +policies to control aspects of allocation, initialisation and destruction. +In combination with the `AllocationCluster` custom allocator, it is even +possible to build arbitrary-sized collections, adding and growing the +structure within very strict limits. The typical, intended usage pattern +is to build-up a data structure dynamically, driven by a discovery or +compilation process. The data structure is then finalised and knowledge +regarding the detail data type can be discarded (``type erasure''). +Data can be used subsequently with array-style subscript access and is +finally discarded as a whole, possibly even without invoking any destructor. //Undocumented -//access-casted.hpp -//advice.hpp symbol-impl.cpp -//allocationcluster.cpp symbol.hpp +//symbol.hpp //cmdline.cpp //cmdline.hpp //del-stash.hpp //diagnostic-context.hpp //element-tracker.hpp -//external -//factory.hpp -//format.hpp -//frameid.hpp //functor-util.hpp -//handle.hpp //hash-indexed.hpp //iter-adapter-stl.hpp //iter-adapter.hpp @@ -1019,42 +1039,17 @@ Cyclic double linked intrusive list. //lifecycleregistry.hpp //lumitime-fmt.hpp //lumitime.cpp -//multifact-arg.hpp -//multifact.hpp -//nobug-init.cpp <`, managed by the allocator. ** In its simplest form, this storage is heap allocated and automatically deleted. ** @see several-builder.hpp + ** @warning 2025 The implementation is preliminary and thus wastes a significant + ** amount of storage in the data structure header; this is not a fundamental + ** problem however and can be mitigated by clever data packing combined + ** with some meta programming. */ diff --git a/src/lib/split-splice.hpp b/src/lib/split-splice.hpp index 02add3a17..09a79495e 100644 --- a/src/lib/split-splice.hpp +++ b/src/lib/split-splice.hpp @@ -53,7 +53,7 @@ ** - `DELETE`: delete all segments between the given start (incl) and end (excl) POS ** ** Moreover, POS (iterators) to indicate the complete domain are required, and a specification - ** of the ORD values of the new segmen's _start_ and _after_ points -- which however can also + ** of the ORD values of the new segment's _start_ and _after_ points -- which however can also ** be defined only partially (as optional values), to use contextual information... ** - if only the start point is given, then the existing segment containing this point ** will be shortened, and the new segment will cover the span until the existing segment's end diff --git a/src/stage/widget/video-display-widget.cpp b/src/stage/widget/video-display-widget.cpp index eb5e8702d..49f227155 100644 --- a/src/stage/widget/video-display-widget.cpp +++ b/src/stage/widget/video-display-widget.cpp @@ -15,6 +15,10 @@ /** @file video-display-widget.cpp ** Implementation of video display, embedded into the UI. ** @deprecated defunct since the transition to GTK-3 + ** @warning WIP 2025 — this is demo code, defunct since the transition to GTK-3 + ** but then upgraded and fixed in 2025, and will be reworked as part of + ** the »Playback Vertical Slice« to establish an actual connection + ** to the Render Engine */ diff --git a/src/stage/widget/video-display-widget.hpp b/src/stage/widget/video-display-widget.hpp index 4a625af0e..c749d3feb 100644 --- a/src/stage/widget/video-display-widget.hpp +++ b/src/stage/widget/video-display-widget.hpp @@ -14,7 +14,8 @@ /** @file video-display-widget.hpp ** Widget to create a video display embedded into the UI - ** @deprecated defunct since the transition to GTK-3 + ** @warning WIP 2025 — will be reworked as part of the »Playback Vertical Slice« + ** to establish an actual connection to the Render Engine */ diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 08699e5bf..b995e470d 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -159762,6 +159762,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + @@ -161217,7 +161218,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161516,13 +161517,4348 @@ 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
+    

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

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

+  
+
+
+
+
+
+
 
 
 
@@ -161580,6 +165916,19 @@ 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
+    

+  
+
+
+
 
 
 
@@ -163348,9 +167697,9 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
-
+
 
 
 
@@ -163390,7 +167739,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -163471,9 +167820,13 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
+
 
 
+
+
+
 
 
 
@@ -163581,8 +167934,9 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
+
 
 
 
@@ -163601,6 +167955,47 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      das war nun eine
+    

+    

+      intensive Auseinandersetzung
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -163644,11 +168039,15 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
-
+
+
+
 
+
+
 
-
+
+
 
   
   
@@ -163657,6 +168056,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
     

   
 
+
+
 
 
   
@@ -163677,7 +168078,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
   
 
 
-
+
 
   
   
@@ -163690,7 +168091,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
   
   
     

-      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 das 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.
+      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.
     

   
 
@@ -163810,7 +168211,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -164053,8 +168454,105 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
+
+
+
+
+
+
 
-
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -164086,12 +168584,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
-
+
+
+
 
-
-
-
+
 
 
   
@@ -164104,7 +168601,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
   
   
@@ -164113,7 +168610,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
     

   
 
-
+
 
 
 
@@ -164130,7 +168627,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -164184,8 +168681,49 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
+
+
 
 
+
+
+  
+    
+  
+  
+    

+      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!
+    

+  
+
 
 
 
@@ -164195,10 +168733,62 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
-
+
+
+
 
 
+
+
+
+
+
+  
+    
+  
+  
+    

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

+        

+          
+        

+      

+    

+  
+
+
+