From 1c234d5a0beef10cf1f7558124a0f175c3a63f49 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 5 Nov 2025 02:55:45 +0100 Subject: [PATCH] clean-up: some Doxygen improvements - reorganise the navigation tab structure - place all further index lists into a common "Index" tab - include a list of concepts - remove the various "member" sub-tabs, these are not helpful - the "modules" tab is now called "topics" (since C++ has now Modules!) - generally re-sync DoxygenLayout.xml with a current pristine template - comb though the Doxygen Warnings and fix a lot of small problems --- doc/devel/Doxyfile | 3 +- doc/devel/DoxygenLayout.xml | 109 +- src/common/advice/advice.cpp | 10 +- src/common/instancehandle.hpp | 2 +- src/doxygen.dox | 25 +- src/include/display-handles.hpp | 2 +- src/lib/diff/diff-language.hpp | 6 +- src/lib/meta/tuple-helper.hpp | 2 +- src/lib/multifact.hpp | 2 +- src/lib/random-draw.hpp | 3 +- src/lib/scoped-ptrvect.hpp | 2 +- src/lib/split-splice.hpp | 2 +- src/lib/test/microbenchmark-adaptor.hpp | 2 +- src/lib/text-template-gen-node-binding.hpp | 2 +- src/lib/time/formats.hpp | 2 +- src/lib/time/quantiser.cpp | 2 +- src/lib/time/timecode.cpp | 2 +- src/stage/ctrl/bus-term.hpp | 4 +- src/stage/ctrl/ui-manager.cpp | 2 +- src/stage/dialog/name-chooser.hpp | 2 +- src/stage/interact/ui-location-solver.hpp | 2 +- src/stage/model/tangible.hpp | 2 +- src/stage/output/xv-displayer.cpp | 2 +- src/steam/fixture/segmentation.cpp | 2 +- .../diff/diff-complex-application-test.cpp | 2 +- .../library/diff/diff-ignore-changes-test.cpp | 2 +- .../diff-tree-application-simple-test.cpp | 2 +- .../diff/diff-tree-application-test.cpp | 2 +- wiki/thinkPad.ichthyo.mm | 1063 ++++++----------- 29 files changed, 494 insertions(+), 771 deletions(-) diff --git a/doc/devel/Doxyfile b/doc/devel/Doxyfile index 6d0e56002..b05bcefba 100644 --- a/doc/devel/Doxyfile +++ b/doc/devel/Doxyfile @@ -157,7 +157,8 @@ REFERENCES_LINK_SOURCE = NO SOURCE_TOOLTIPS = YES USE_HTAGS = NO VERBATIM_HEADERS = NO -CLANG_ASSISTED_PARSING = YES +#CLANG_ASSISTED_PARSING = YES +CLANG_ASSISTED_PARSING = NO CLANG_OPTIONS = -DDEBUG -DEBUG_ALPHA #--------------------------------------------------------------------------- diff --git a/doc/devel/DoxygenLayout.xml b/doc/devel/DoxygenLayout.xml index 63a67fff4..8fb457962 100644 --- a/doc/devel/DoxygenLayout.xml +++ b/doc/devel/DoxygenLayout.xml @@ -2,42 +2,43 @@ - - - - - - - - + + + + + + + + + + + + + - - - + + + - - - - - - - + + + + - - - + + @@ -62,13 +63,15 @@ + + - - + + @@ -84,12 +87,18 @@ - + + + + + + + @@ -97,24 +106,41 @@ + + + + + + + + + + + - + - + + + + - + - + + + + @@ -134,14 +160,19 @@ + + + + + @@ -160,6 +191,8 @@ + + @@ -172,10 +205,28 @@ - + + + + + + + + + + + + + + + + + + + diff --git a/src/common/advice/advice.cpp b/src/common/advice/advice.cpp index c5f9d51e6..f246f62d2 100644 --- a/src/common/advice/advice.cpp +++ b/src/common/advice/advice.cpp @@ -301,13 +301,8 @@ namespace advice { * into an internal buffer within the AdviceSystem. We then use the * Index to remember the presence of this advice data and to detect * possible matches with existing advice::Request entries. - * @param adviceData pointer to the copied data, + * @param newProvision pointer to the copied data, * actually pointing to an ActiveProvision - * @return pointer to an superseded old provision entry, - * which the caller then needs to de-allocate. - * The caller is assumed to know the actual type - * and thus the size of the entry to deallocate. - * Returning `NULL` in case no old entry exists. */ void AdviceLink::publishProvision (PointOfAdvice* newProvision) @@ -323,9 +318,6 @@ namespace advice { * after removing the provision index entry * we also need to re-process any requests * which happen to match our binding... - * @return pointer to the existing provision entry, - * to be deallocated by the caller, which - * is assumed to know it's exact type. */ void AdviceLink::discardSolutions () diff --git a/src/common/instancehandle.hpp b/src/common/instancehandle.hpp index a067d9c00..aac59d963 100644 --- a/src/common/instancehandle.hpp +++ b/src/common/instancehandle.hpp @@ -207,7 +207,7 @@ namespace lumiera { /** Set up an InstanceHandle managing the * registration and deregistration of interface(s). * Should be placed at the service providing side. - * @param a (single) interface descriptor, which can be created with + * @param descriptor a (single) interface descriptor, which can be created with * LUMIERA_INTERFACE_INSTANCE and referred to by LUMIERA_INTERFACE_REF */ InstanceHandle (LumieraInterface descriptor) diff --git a/src/doxygen.dox b/src/doxygen.dox index 984daff0e..8f69f9c97 100644 --- a/src/doxygen.dox +++ b/src/doxygen.dox @@ -1,5 +1,5 @@ /* - DOXYGEN.dox - font page for the Doxygen API documentation + DOXYGEN.dox - front page for the Doxygen API documentation Copyright (C) @@ -46,7 +46,7 @@ with the *ASCIIDOC* tool and published at the [Lumiera website](http://Lumiera.o necessary to understand the actual code - right now, you are looking at the **API Documentation**, which is the entrance point to the actual code - on your exploration path down to the internal details, you might want to follow the overview given - + by the [Layer and Subsystem](modules.html) overview + + by the [Layer and Subsystem](topics.html) overview + the file level comments of relevant interfaces */ @@ -54,13 +54,24 @@ with the *ASCIIDOC* tool and published at the [Lumiera website](http://Lumiera.o /* ==== Layers ==== */ /** @defgroup vault Vault-Layer -*/ + * Provides the technical services for all processing and system access. + * Manages worker pools, schedules jobs, does the memory management for the + * heavy multimedia data. Loads and delegates to external libraries for + * media processing. + */ /** @defgroup steam Steam-Layer -*/ + * Keeps the Session, generates the rendering graphs for sequences, + * arranges what to do when and how, coordinates command/event processing, + * playback and rendering. + */ /** @defgroup gui Graphical User Interface -*/ + * Interaction and Presentation layer. + * Provides the structures to coordinate navication, presentation state + * and gestures. Defines the widgets and controllers for the UI. + * Loaded as Plug-in. + */ /* ==== Subsystems ==== */ @@ -86,6 +97,10 @@ with the *ASCIIDOC* tool and published at the [Lumiera website](http://Lumiera.o /** @defgroup scheduler Scheduler @ingroup vault + The Scheduler acts as the central hub in the implementation of the RenderEngine + and coordinates the processing resources of the application. A Render Job is created + for every frame and passed to the Scheduler, marked with a deadline, and connected + to _prerequisite_ jobs. */ /** @defgroup memory Memory Management diff --git a/src/include/display-handles.hpp b/src/include/display-handles.hpp index 3658bd04c..9f9efcc91 100644 --- a/src/include/display-handles.hpp +++ b/src/include/display-handles.hpp @@ -11,7 +11,7 @@ */ -/** @file display-handles.h +/** @file display-handles.hpp ** Opaque handles and similar typedefs used to communicate via the ** lumiera::Display and lumiera::DummyPlayer facade interfaces. ** diff --git a/src/lib/diff/diff-language.hpp b/src/lib/diff/diff-language.hpp index 18b3cd7f0..281f846d9 100644 --- a/src/lib/diff/diff-language.hpp +++ b/src/lib/diff/diff-language.hpp @@ -272,9 +272,9 @@ namespace diff{ /** * generic builder to apply a diff description to a given target data structure. * The usage pattern is as follows - * #. construct a DiffApplicator instance, wrapping the target data - * #. feed the diff (sequence of diff verbs) to the #consume function - * #. the wrapped target data has been altered, to conform to the given diff + * -# construct a DiffApplicator instance, wrapping the target data + * -# feed the diff (sequence of diff verbs) to the #consume function + * -# the wrapped target data has been altered, to conform to the given diff * @note a suitable DiffApplicationStrategy will be picked, based on the type * of the concrete target sequence given at construction. (Effectively * this means you need a suitable DiffApplicationStrategy specialisation, diff --git a/src/lib/meta/tuple-helper.hpp b/src/lib/meta/tuple-helper.hpp index 3e14aa4cb..44d89fc5c 100644 --- a/src/lib/meta/tuple-helper.hpp +++ b/src/lib/meta/tuple-helper.hpp @@ -19,7 +19,7 @@ ** helpers to build tuple types from metaprogramming and to pretty-print tuples. ** ** Notably, a `concept tuple_like` is provided, which is satisfied for any type in compliance - ** with the »tuple protocol«. Together with a [generic accessor][\ref lib::meta::getElm), + ** with the »tuple protocol«. Together with a [generic accessor][\ref lib::meta::getElm], ** this allows to handle all _tuple-like_ types uniformly. ** @note Due to an unfortunate limitation of the standard, we're forced to provide our own alternative ** implementation to replace `std::apply`, so that a function can be applied to any _tuple-like_ diff --git a/src/lib/multifact.hpp b/src/lib/multifact.hpp index 1877d65ef..cf9253c21 100644 --- a/src/lib/multifact.hpp +++ b/src/lib/multifact.hpp @@ -283,7 +283,7 @@ namespace lib { * Select a production line and invoke the fabrication function. * @param id select the actual pre installed fabrication function to use * @param args additional arguments to pass to the fabrication. - * @note the template parameter #SIG defines the raw or nominal signature + * @note the template parameter \a SIG defines the raw or nominal signature * of the fabrication, and especially the number of arguments * @return the created product, after passing through the #Wrapper functor */ diff --git a/src/lib/random-draw.hpp b/src/lib/random-draw.hpp index 442a6c845..d5f9dca2e 100644 --- a/src/lib/random-draw.hpp +++ b/src/lib/random-draw.hpp @@ -17,7 +17,8 @@ ** value with a limited target domain. The intended usage scenario is to parametrise some ** configuration or computation »randomly«, with well defined probabilities and value ranges. ** A DSL is provided to simplify the common configuration and value mapping scenarios. - ** @paragraph The underlying implementation was extracted 11/2023 from (and later used by) + ** \par motivation + ** The underlying implementation was extracted 11/2023 from (and later used by) ** TestChainLoad; there, random numbers are derived from node hash values and must be mapped ** to yield control parameters governing the topology of a DAG datastructure. Notably, a ** draw is performed on each step to decide if the graph should fork. While numerically diff --git a/src/lib/scoped-ptrvect.hpp b/src/lib/scoped-ptrvect.hpp index 81fdfe76c..0ddadab49 100644 --- a/src/lib/scoped-ptrvect.hpp +++ b/src/lib/scoped-ptrvect.hpp @@ -145,7 +145,7 @@ namespace lib { * This object will be removed form this collection * and returned as-is; it won't be deleted when the * ScopedPtrVect goes out of scope. - * @param obj address of the object in question. + * @param objAddress address of the object in question. * @return pointer to the object, if found. * Otherwise, NULL will be returned and the * collection of managed objects remains unaltered diff --git a/src/lib/split-splice.hpp b/src/lib/split-splice.hpp index 09a79495e..cea559c46 100644 --- a/src/lib/split-splice.hpp +++ b/src/lib/split-splice.hpp @@ -85,7 +85,7 @@ namespace lib { namespace error = lumiera::error; - namespace splitsplice {/// Implementation of [»SplitSplice« algorithm](\ref splite-splice.hpp) + namespace splitsplice {/// Implementation of [»SplitSplice« algorithm](\ref split-splice.hpp) /** diff --git a/src/lib/test/microbenchmark-adaptor.hpp b/src/lib/test/microbenchmark-adaptor.hpp index d795c99ab..3733d3a02 100644 --- a/src/lib/test/microbenchmark-adaptor.hpp +++ b/src/lib/test/microbenchmark-adaptor.hpp @@ -13,7 +13,7 @@ /** @file microbenchmark-adaptor.hpp - ** Helpers and wrappers so simplify usage of \ref micobenchmark.hpp. + ** Helpers and wrappers so simplify usage of \ref microbenchmark.hpp. ** Notably the benchmark functions expect the actual »test subject« as a ** function or lambda with signature `size_t(size_t)`. The argument will be ** the loop index and the result value will be added into a checksum, which diff --git a/src/lib/text-template-gen-node-binding.hpp b/src/lib/text-template-gen-node-binding.hpp index 125b28e56..2f1dadb5b 100644 --- a/src/lib/text-template-gen-node-binding.hpp +++ b/src/lib/text-template-gen-node-binding.hpp @@ -66,7 +66,7 @@ namespace lib { /** * Data-binding for a tree of GenNode data (ETD). * Attributes are accessible as keys, while iteration descends - * into the child scope of the attribute indicated in the ${for }` tag. + * into the child scope of the attribute indicated in the `${for }` tag. * @see TextTemplate_test::verify_ETD_binding() */ template<> diff --git a/src/lib/time/formats.hpp b/src/lib/time/formats.hpp index b5e2f5ca5..0874f3e3a 100644 --- a/src/lib/time/formats.hpp +++ b/src/lib/time/formats.hpp @@ -211,7 +211,7 @@ namespace time { public: /** build a new Descriptor to denote support for all the Formats, - * @param TY typelist holding all the Format types to support + * @tparam TY typelist holding all the Format types to support */ template static Supported diff --git a/src/lib/time/quantiser.cpp b/src/lib/time/quantiser.cpp index d84be41e2..3591214d5 100644 --- a/src/lib/time/quantiser.cpp +++ b/src/lib/time/quantiser.cpp @@ -249,7 +249,7 @@ namespace time { * @remark This function reverses building the drop-frame timecode, * and thus maps a time into consecutive frame numbers * at NTSC framerate (i.e. without gaps) - * @param timecode represented as time value in µ-ticks + * @param time represented as time value in µ-ticks * @return the absolute frame number as addressed by NTSC drop-frame * @todo 2011 I doubt this works correct for negative times!! */ diff --git a/src/lib/time/timecode.cpp b/src/lib/time/timecode.cpp index deeb6dd1d..f508f3cdd 100644 --- a/src/lib/time/timecode.cpp +++ b/src/lib/time/timecode.cpp @@ -213,7 +213,7 @@ namespace time { /** handle the limits of SMPTE timecode range. * This is an extension and configuration point to control how * to handle values beyond the official SMPTE timecode range of - * 0:0:0:0 to 23:59:59:##. When this strategy function is invoked, + * `0:0:0:0` to `23:59:59:##`. When this strategy function is invoked, * the frames, seconds, minutes and hours fields have already been processed * and stored into the component digxels, under the assumption the overall * value stays in range. diff --git a/src/stage/ctrl/bus-term.hpp b/src/stage/ctrl/bus-term.hpp index e7b6b269e..4fabf889f 100644 --- a/src/stage/ctrl/bus-term.hpp +++ b/src/stage/ctrl/bus-term.hpp @@ -40,8 +40,8 @@ ** which is constructed in a way to ensure it is always has a ** bidirectional communication link to the Nexus. ** - ** @see [BusTerm_test] - ** @see Tangible + ** @see \ref BusTerm_test + ** @see \ref Tangible ** */ diff --git a/src/stage/ctrl/ui-manager.cpp b/src/stage/ctrl/ui-manager.cpp index d541a439b..893630ac8 100644 --- a/src/stage/ctrl/ui-manager.cpp +++ b/src/stage/ctrl/ui-manager.cpp @@ -153,7 +153,7 @@ namespace ctrl { /** * @remarks moves the given operation into our private dispatcher queue and then * schedules dequeuing and invocation into the UI event thread. - * @param op a completely closed lambda or functor + * @param task a completely closed lambda or functor * @warning closure need to be by value or equivalent, since * the operation will be executed within another call stack */ diff --git a/src/stage/dialog/name-chooser.hpp b/src/stage/dialog/name-chooser.hpp index fc273cf28..d56e2e84c 100644 --- a/src/stage/dialog/name-chooser.hpp +++ b/src/stage/dialog/name-chooser.hpp @@ -45,7 +45,7 @@ namespace dialog { * Creates a name chooser dialog. * @param parent The window which will be the parent of this dialog. * @param title The string for the title of this dialog. - * @param default_name The name that will be shown by default in the + * @param defaultName The name that will be shown by default in the * edit box of the dialog. */ NameChooser(Gtk::Window &parent, cuString title, cuString defaultName); diff --git a/src/stage/interact/ui-location-solver.hpp b/src/stage/interact/ui-location-solver.hpp index c4f90f30d..3312ed199 100644 --- a/src/stage/interact/ui-location-solver.hpp +++ b/src/stage/interact/ui-location-solver.hpp @@ -243,7 +243,7 @@ namespace interact { /** * Solve for a location according to the given location rule. * @param depth desired kind of UI element (and thus the depth in the UI topology tree) - * @param elementType designator of the specific element to be created at that level + * @param elementTypeID designator of the specific element to be created at that level * @return an explicit location, resolved against the current UI topology. May be empty * @remarks the returned path is either empty (no solution exists), or it is "partially covered" * by the existing UI; here, the "covered" part are the already existing UI elements, diff --git a/src/stage/model/tangible.hpp b/src/stage/model/tangible.hpp index 039362078..5317efa5d 100644 --- a/src/stage/model/tangible.hpp +++ b/src/stage/model/tangible.hpp @@ -235,7 +235,7 @@ namespace model { /** convenience shortcut to build a message suitable for command invocation - * @param args... sequence of arguments to be packaged into a lib::diff::Rec for invocation + * @param args ... sequence of arguments to be packaged into a lib::diff::Rec for invocation */ template inline lib::diff::GenNode diff --git a/src/stage/output/xv-displayer.cpp b/src/stage/output/xv-displayer.cpp index 999901577..6d23bfaab 100644 --- a/src/stage/output/xv-displayer.cpp +++ b/src/stage/output/xv-displayer.cpp @@ -14,7 +14,7 @@ * *****************************************************************/ -/** @file xvdisplayer.cpp +/** @file xv-displayer.cpp ** Implementation of video output via XVideo ** @todo WIP as of 5/2025 -- attempt to port this component to GTK-3 ///////////////////////////////////////TICKET #1403 */ diff --git a/src/steam/fixture/segmentation.cpp b/src/steam/fixture/segmentation.cpp index 400d9f8ff..322030b29 100644 --- a/src/steam/fixture/segmentation.cpp +++ b/src/steam/fixture/segmentation.cpp @@ -46,7 +46,7 @@ namespace fixture { /** * @param start (optional) definition of the new Segment's start point (inclusive) * @param after (optional) definition of the end point (exclusive) - * @param jobTicket specification of provided render functionality for the new Segment + * @param modelLink specification of provided render functionality for the new Segment * @remarks missing definitions will be derived or interpolated according to context * - if start point is omitted, the new Segment will start seamlessly after * any preceding Segment's end, in case this preceding Segment ends earlier diff --git a/tests/library/diff/diff-complex-application-test.cpp b/tests/library/diff/diff-complex-application-test.cpp index 7c08df609..602182c83 100644 --- a/tests/library/diff/diff-complex-application-test.cpp +++ b/tests/library/diff/diff-complex-application-test.cpp @@ -291,7 +291,7 @@ namespace test{ * @see DiffTreeApplication_test generic variant of tree diff application * @see TreeMutatorBinding_test coverage of the "building blocks" * @see TreeMutator_test base operations of the adapter - * @see diff-tree-application.hpp + * @see tree-diff-application.hpp * @see tree-diff.hpp */ class DiffComplexApplication_test diff --git a/tests/library/diff/diff-ignore-changes-test.cpp b/tests/library/diff/diff-ignore-changes-test.cpp index 6b6bf66f7..241275b41 100644 --- a/tests/library/diff/diff-ignore-changes-test.cpp +++ b/tests/library/diff/diff-ignore-changes-test.cpp @@ -72,7 +72,7 @@ namespace test{ * * @see DiffComplexApplication_test test case which _indeed does a lot..._ * @see TreeMutator_test base operations of the adapter - * @see diff-tree-application.hpp + * @see tree-diff-application.hpp * @see tree-diff.hpp */ class DiffIgnoreChanges_test diff --git a/tests/library/diff/diff-tree-application-simple-test.cpp b/tests/library/diff/diff-tree-application-simple-test.cpp index 93e929e97..f2e7d7405 100644 --- a/tests/library/diff/diff-tree-application-simple-test.cpp +++ b/tests/library/diff/diff-tree-application-simple-test.cpp @@ -85,7 +85,7 @@ namespace test{ * @see GenericRecord_test * @see GenNode_test * @see DiffListApplication_test - * @see diff-tree-application.hpp + * @see tree-diff-application.hpp * @see tree-diff.hpp * @see tree-diff-traits.hpp */ diff --git a/tests/library/diff/diff-tree-application-test.cpp b/tests/library/diff/diff-tree-application-test.cpp index fc6355cc7..dc72d37ec 100644 --- a/tests/library/diff/diff-tree-application-test.cpp +++ b/tests/library/diff/diff-tree-application-test.cpp @@ -98,7 +98,7 @@ namespace test{ * @see GenericRecord_test * @see GenNode_test * @see DiffListApplication_test - * @see diff-tree-application.hpp + * @see tree-diff-application.hpp * @see tree-diff.hpp */ class DiffTreeApplication_test diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index b995e470d..aca8c2d90 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -158835,7 +158835,19 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + + + + + + + + + @@ -158907,7 +158919,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -158945,6 +158957,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + @@ -158954,7 +158972,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161520,9 +161538,9 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161534,9 +161552,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

und zwar für zwei Dinge @@ -161590,9 +161606,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

nenne es »can be solved« @@ -161602,9 +161616,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

deute es als ein Festhalten an einer »einfachen« Lösung @@ -161617,9 +161629,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

dahinter steckt eine Form des Verfallens @@ -161637,9 +161647,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

⟹ auf Frederick Brooks zurückgreifen @@ -161654,9 +161662,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Recherche: das war ja noch alles viel dramatischer @@ -161687,9 +161693,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

...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") @@ -161706,9 +161710,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Das meine ich auf mehreren Ebenen @@ -161735,9 +161737,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Warnung: gefühlte Realität @@ -161745,9 +161745,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

...sinnlos dagegen zu argumentieren, man darf sie aber auch nicht einfach vom Tisch wischen und für „unreal“ erklären @@ -161757,9 +161755,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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 @@ -161769,9 +161765,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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. @@ -161781,9 +161775,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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) @@ -161793,9 +161785,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Auseinandersetzung mit der Historie  ⟹  habe Liberalismus  dahinter entdeckt @@ -161803,9 +161793,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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. @@ -161817,9 +161805,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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. @@ -161829,9 +161815,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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) @@ -161841,9 +161825,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Das ist ein strategischer Ansatz @@ -161869,9 +161851,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

...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. @@ -161903,9 +161883,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

habe nun alle RfC durchgesehen und verstehe einige Zusammenhänge besser @@ -161922,9 +161900,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Erste Mail: Oktober 2006. @@ -161941,9 +161917,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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. @@ -161956,9 +161930,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

war aber bereits etwas skeptisch, da er Cinelerra länger kannte als Cehteh @@ -161968,9 +161940,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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 @@ -161986,9 +161956,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

...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). @@ -162003,9 +161971,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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. @@ -162024,9 +161990,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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. @@ -162037,9 +162001,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

...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. @@ -162049,9 +162011,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

die C++ - Strukturen von Ichthyo hat er bewundert, @@ -162068,9 +162028,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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 @@ -162081,9 +162039,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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 @@ -162096,9 +162052,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Und zwar handelte es sich um Code von hoher Qualittät, rein als Library konzipiert, sauber strukturiert, gründlich getestet @@ -162109,9 +162063,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

...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 @@ -162132,9 +162084,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - + Richard Spindler found his way through Parma thanks to the great @@ -162149,9 +162099,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Hatte damals die Idee, @@ -162168,9 +162116,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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) @@ -162189,9 +162135,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Fazit: es hat sich erübrigt @@ -162205,9 +162149,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit 13b963ba5bc39603c1d425752f07d8b3941f01ba @@ -162229,9 +162171,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit 0a9c2599dd49990b8ccf779a44abdaba626bdd86 @@ -162253,9 +162193,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit 0a9c2599dd49990b8ccf779a44abdaba626bdd86 @@ -162277,9 +162215,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit a313ea87a588241a1db72b6cac6e2aee2b512fc7 @@ -162307,9 +162243,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit 471148b7db2e41f2c081760cc367710ce6999da9 @@ -162331,9 +162265,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit ebb4da6cc738392c015c7d66c54c6483331459f4 @@ -162355,9 +162287,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit ed4decb5de9c6c22bb0f9173e3d239fefe9453e7 @@ -162380,9 +162310,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit 45c21677009dfc733d0ecd6f26d783c99b2818d5 @@ -162404,9 +162332,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

commit ce3eb42131b0f8f809b00ef9a7759eb885e684d3 @@ -162427,9 +162353,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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... @@ -162460,9 +162384,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

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 @@ -162473,9 +162395,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - + On Tue, 14 Aug 2007 23:32:01 +0200, Edouard Chalaron @@ -162518,9 +162438,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - + 

marquitux caballero wrote:
@@ -162591,9 +162509,7 @@ Cinelerra mailing list - - - + 
This my maybe arguable view how to hive Cinelerra CV out of its
 develoment stall:
@@ -162656,9 +162572,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     

       ...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
@@ -162668,9 +162582,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       
  • 
@@ -162695,9 +162607,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       Error, Locking, Plugin und eine Linked List
@@ -162707,9 +162617,7 @@ Cinelerra mailing 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).
@@ -162733,9 +162641,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -162745,9 +162651,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -162761,9 +162665,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -162773,9 +162675,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -162785,9 +162685,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -162812,9 +162710,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       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).
@@ -162836,9 +162732,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -162855,9 +162749,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       die Plug-in-Kontroverse war bereits damals, in den ersten Wochen
@@ -162871,9 +162763,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
    
       wie kam es daß wir neu gebaut haben?
@@ -162888,9 +162778,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       
    • 
@@ -162963,9 +162851,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       Einsicht: der Plugin-Streit war bereits in den ersten Wochen
@@ -162973,9 +162859,7 @@ Cinelerra mailing list
   
 
 
-  
-    
-  
+  
   
     
      
       ...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
@@ -162986,9 +162870,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       schon die erste lange Antwortmail ("how to proceed?") erscheint latent-feindselig. Und die zweite, grundsätzliche Mail ist eine Kriegserklärung.
@@ -163008,9 +162890,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -163020,9 +162900,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       Und das hat mehrere Quellen
@@ -163043,9 +162921,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       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)
@@ -163070,9 +162946,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       Deshalb ist die Beurteilung dieser Kontroverse so schwierig
@@ -163095,9 +162969,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       8.7.
@@ -163107,9 +162979,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       9.7.
@@ -163119,9 +162989,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
      
       Ersichtlich erst schon in den Mails, aber ganz schlagend in der einzigen Debatte, die ein direktes Gespräch war (auf IRC am 10.7):
@@ -163139,9 +163007,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
        
       
      • 
@@ -163163,9 +163029,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
        
       Christian blieb im Projekt, das Projekt lief weiter, und ich habe von seinem Netzwerk profitiert
@@ -163175,9 +163039,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
        
       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.
@@ -163195,9 +163057,7 @@ Cinelerra mailing list
 
 
 
-  
-    
-  
+  
   
     
        Wow Du hast hast mächtig vorgelegtb mit deiner uml/wiki doc.
 
@@ -163240,9 +163100,7 @@ Vorschlag währe das man Bouml nach doc/uml/ generiern lässt
 
 
 
-  
-    
-  
+  
   
     
        Voßeler Hermann wrote:
        
     
        
@@ -163278,9 +163136,7 @@ interessierte davon was mitbekommen anstatt privater mails.
 
 
 
-  
-    
-  
+  
   
     
        
       Bis dahin war Christian immer sehr ermutigend, fand alles Toll, hat zu allem weitere (sehr sinnvolle) Vorschläge gemacht....
@@ -163290,9 +163146,7 @@ interessierte davon was mitbekommen anstatt privater mails.
 
 
 
-  
-    
-  
+  
   
     
        
       das war mir damals zwar unbewußt aufgefallen,
@@ -163303,9 +163157,7 @@ interessierte davon was mitbekommen anstatt privater mails.
   
 
 
-  
-    
-  
+  
   
     
        
       Woher weiß ich das?
@@ -163325,9 +163177,7 @@ interessierte davon was mitbekommen anstatt privater mails.
 
 
 
-  
-    
-  
+  
   
     
        
     
        
@@ -163355,9 +163205,7 @@ oder bouml einfach ein paar sachen um bestimmte dinge zu modelliern.
 
 
 
-  
-    
-  
+  
   
     
        
       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)
@@ -163367,9 +163215,7 @@ oder bouml einfach ein paar sachen um bestimmte dinge zu modelliern.
 
 
 
-  
-    
-  
+  
   
     
        Ichthyostega wrote:
        
     
        
@@ -163390,9 +163236,7 @@ note about gnu style: (how I/emacs interpret it)
        
 
 
 
-  
-    
-  
+  
   
     
        
       ganz klar eine Anspielung an "Terminator"
@@ -163407,9 +163251,7 @@ note about gnu style: (how I/emacs interpret it)

 
 
 
-  
-    
-  
+  
   
     

       

@@ -163432,9 +163274,7 @@ note about gnu style: (how I/emacs interpret it)
 
 
 
-  
-    
-  
+  
   
     

       angeblich hätte er sich mir mir auf ein Multi-Language-Projekt geeinigt
@@ -163447,9 +163287,7 @@ note about gnu style: (how I/emacs interpret it)
 
 
 
-  
-    
-  
+  
   
     

       ist das möglich oder eine dreiste Lüge?
@@ -163460,9 +163298,7 @@ note about gnu style: (how I/emacs interpret it)
 
 
 
-  
-    
-  
+  
   
     

       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...
@@ -163472,9 +163308,7 @@ note about gnu style: (how I/emacs interpret it)
 
 
 
-  
-    
-  
+  
   
     

       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....
@@ -163509,9 +163343,7 @@ note about gnu style: (how I/emacs interpret it)
 
 
 
-  
-    
-  
+  
   
     

       Und zwar in mehrerlei Hinsicht. Zum einen, Christian hat den wichtigeren 
@@ -163553,9 +163385,7 @@ proposals about C nameing rules, plugins and interfaces. (i am back ;))
 
 
 
-  
-    
-  
+  
   
     

       ich habe C-Funktionen stets nur als eine Konzession betrachtet
@@ -163563,9 +163393,7 @@ proposals about C nameing rules, plugins and interfaces. (i am back ;))
   
 
 
-  
-    
-  
+  
   
     

       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.
@@ -163575,9 +163403,7 @@ proposals about C nameing rules, plugins and interfaces. (i am back ;))
 
 
 
-  
-    
-  
+  
   
     

       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
@@ -163591,9 +163417,7 @@ proposals about C nameing rules, plugins and interfaces. (i am back ;))
 
 
 
-  
-    
-  
+  
   
     
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
@@ -163607,9 +163431,7 @@ implementation, since this is a very low level building block.
 
 
 
-  
-    
-  
+  
   
     

       "review it carefully if it looks ok, I straight go into make a referene implementation...."
@@ -163633,9 +163455,7 @@ implementation, since this is a very low level building block.
 
 
 
-  
-    
-  
+  
   
     

       "since this is a very low level building block."
@@ -163650,9 +163470,7 @@ implementation, since this is a very low level building block.
 
 
 
-  
-    
-  
+  
   
     

       
Am Dienstag, den 03.07.2007, 20:51 +0200 schrieb Christian Thaeter:
@@ -163700,9 +163518,7 @@ Hermann
 
 
 
-  
-    
-  
+  
   
     

       effektiv ist das eine freundlich verpackte Ablehnung
@@ -163712,9 +163528,7 @@ Hermann
 
 
 
-  
-    
-  
+  
   
     

       hier sage ich explizit, und mir Argument,
@@ -163727,9 +163541,7 @@ Hermann
 
 
 
-  
-    
-  
+  
   
     
    
       
  • 
@@ -163747,9 +163559,7 @@ Hermann
 
 
 
-  
-    
-  
+  
   
     
    
       Das meine ich als echte Frage, und die ist wichtig, zum Verständnis dessen, was dann geschah.
@@ -163771,9 +163581,7 @@ Hermann
 
 
 
-  
-    
-  
+  
   
     
    
       Christian antwortet am selben Abend völlig naiv und macht klar was er will
@@ -163781,9 +163589,7 @@ Hermann
   
 
 
-  
-    
-  
+  
   
     
    Voßeler Hermann wrote:
    
     
    
@@ -163889,9 +163695,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       Das geht mir jetzt so, und das ging mir vermutlich damals nicht anders.
@@ -163904,9 +163708,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       Und damit meine ich eine Applikation, nicht OS-level Code.
@@ -163924,9 +163726,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       Er skizziert ja, wie er sich das vorstellt:
@@ -163946,9 +163746,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       Das macht diesen Vorschlag so »entwaffnend«:
@@ -163977,9 +163775,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       Fazit: ich stecke nun bis über die Ohren in der Scheiße
@@ -163995,9 +163791,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -164007,9 +163801,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       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
@@ -164032,9 +163824,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -164061,9 +163851,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       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..."
@@ -164089,9 +163877,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -164106,9 +163892,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       
    • 
@@ -164133,9 +163917,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -164147,9 +163929,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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).
@@ -164169,9 +163949,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Ich bin jetzt erstaunt, welche bedeutende, und auch besonnene Rolle dieser Mann in den ersten Wochen gespielt hat. Das war mir komplett entfallen.
@@ -164180,9 +163958,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Sein Vorschlag
@@ -164203,9 +163979,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -164215,9 +163989,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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)
@@ -164228,9 +164000,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Christian will das System jetzt öffnen und die Entscheidung darüber fixieren
@@ -164241,9 +164011,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       11.7 : Christian erklärt den Plugin-RfC einseitig für anerkannt
@@ -164251,9 +164019,7 @@ we provide for us, we provide for people extenting it too)
   
 
 
-  
-    
-  
+  
   
     
      
       
      
@@ -164276,9 +164042,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -164288,9 +164052,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -164308,9 +164070,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Das Log dazu habe ich aufgehoben in meinem privaten Trac.
@@ -164324,9 +164084,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Er hat mich selten überhaupt ausreden lassen. Er hat permanennt auf einzelne Stichworte reaagiert, und diese nach seiner Sicht »entkräftet«: 
@@ -164344,9 +164102,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Nicht wirklich, aber im Zusammenhang war das der Eindruck
@@ -164368,9 +164124,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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...?
@@ -164391,9 +164145,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       ich kann mich jetzt wieder erinnern,
@@ -164408,9 +164160,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -164420,9 +164170,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       im Rückblick nicht klar: warum habe ich den Kompromiß nicht explizit klargestellt?
@@ -164433,9 +164181,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -164445,9 +164191,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       ...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)
@@ -164458,9 +164202,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Das ist ausschließlich Spekulation bzw. Interpolation.
@@ -164472,9 +164214,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       ...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
@@ -164484,9 +164224,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -164496,9 +164234,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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)
@@ -164508,9 +164244,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -164520,9 +164254,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -164532,9 +164264,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -164551,9 +164281,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       ich kann jetzt den Zusammenhang gedanklich fassen
@@ -164569,9 +164297,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       Einige erfahrene Männer, die allesamt ihr Handwerk verstehen, gehen mit einem gemeinsamen Werk vorran und leiten eine Bewegung ein.
@@ -164584,9 +164310,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       allerdings nie irgend etwas zum DataBackend
@@ -164603,9 +164327,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       er hat sich dann zu 150% auf das uWiki geworfen
@@ -164621,9 +164343,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       und zwar passiert hier bereits der Streit über die Plug-in-zentrische Architektur
@@ -164634,9 +164354,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -164671,9 +164389,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      
       ....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:
@@ -164696,9 +164412,7 @@ we provide for us, we provide for people extenting it too)
 
 
 
-  
-    
-  
+  
   
     
      mark carter schrieb:
      
     
      
@@ -164725,9 +164439,7 @@ on some aspects of file handling media loading.

 
 
 
-  
-    
-  
+  
   
     
At the moment I just choose to ignore it and picked me one region, ...

   
@@ -164736,9 +164448,7 @@ on some aspects of file handling media loading.

 
 
 
-  
-    
-  
+  
   
     

       gemeint war, Lumiera ist ein Projekt, das auch heroischen Einsatz einfach spurlos aufsaugt, wie ein trockener Schwamm
@@ -164748,9 +164458,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     

       »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.
@@ -164771,9 +164479,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     

       z.B. wir sollten doch alles in QT bauen, weil es dadurch viel einfacher wird, und obendrein auch gleich noch portabel
@@ -164788,9 +164494,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     

       Wichtig: er hat sich nie in dieser Rolle „gesonnt“ — sondern sets die festgelegten Formeln wiederholt und auf meinen Beitrag eigens hingewiesen
@@ -164801,9 +164505,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     

       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“
@@ -164815,9 +164517,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     

       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
@@ -164828,9 +164528,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     

       ...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)
@@ -164844,9 +164542,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
    
       
  • 
@@ -164861,9 +164557,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
    
       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.
@@ -164879,9 +164573,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
    
       Raffaella und Odin haben dieses Moment aufgegriffen —
@@ -164902,9 +164594,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
    
       ...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.
@@ -164916,9 +164606,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
    
       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)
@@ -164932,9 +164620,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
    
       ohne sie explizit breitzutreten!
@@ -164943,9 +164629,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       
    • 
@@ -164959,9 +164643,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       Wir hatten den »Drive« und wir hatten ein Konzept, das in überschaubarer Zeit machbar erschien
@@ -164971,9 +164653,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       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«
@@ -164983,9 +164663,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       Damit meine ich: ein »Mission Statement« und ein »Projektkonzept«, das plausibel und machbar erscheint, und nicht „völlig durchgeknallt“
@@ -164994,9 +164672,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       ...und anfangs auch tatsächlich plausibel war
@@ -165007,9 +164683,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -165022,9 +164696,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       man hat sich auf einen Weg gemacht,
@@ -165048,9 +164720,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       Erzählen auf dem Grundton: das kann doch nicht gutgehen...
@@ -165069,9 +164739,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       das Thema der Flexibilität
@@ -165084,9 +164752,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       ...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
@@ -165109,9 +164775,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       Benny hatte schon vor Monaten gesagt,
@@ -165122,9 +164786,7 @@ on some aspects of file handling media loading.
   
 
 
-  
-    
-  
+  
   
     
      
       ...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...
@@ -165136,9 +164798,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -165152,9 +164812,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       danke Benny!
@@ -165170,9 +164828,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       we don't say this in this context. Does transliterate refer to 'meaning',
@@ -165204,9 +164860,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       Fix because 'properly' is here coloquial because, again, it is
@@ -165227,9 +164881,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      
       also ist Benny's Vorschlag inhaltlich viel bessern
@@ -165243,9 +164895,7 @@ on some aspects of file handling media loading.
 
 
 
-  
-    
-  
+  
   
     
      Lately i had almost no time to hack on cinelerra and it doesn't seem
 that situation will improve in forseeable future.
      
@@ -165260,9 +164910,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       ich muß hier eine Deutung machen, um den Sachverhalt klar zu fassen
@@ -165270,9 +164918,7 @@ that situation will improve in forseeable future.
   
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -165286,9 +164932,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       insofern: Benny's Formulierung ist sogar sehr gut, sie ist nämlich dezent
@@ -165312,9 +164956,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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...
@@ -165338,9 +164980,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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...
@@ -165356,9 +164996,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Andraz: "Leute, ich kann nicht mehr!"
@@ -165375,9 +165013,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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....)
@@ -165386,9 +165022,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       ich kann nicht einschätzen,
@@ -165399,9 +165033,7 @@ that situation will improve in forseeable future.
   
 
 
-  
-    
-  
+  
   
     
      
       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)
@@ -165417,9 +165049,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -165435,9 +165065,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Please check: i think you mean 'general' here
@@ -165453,9 +165081,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Create our own toolset to track issues, tasks, bugs in a distributed manner.
@@ -165465,9 +165091,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Und mir fällt auf, daß dies sein erster inhaltlicher RfC war
@@ -165477,9 +165101,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -165496,9 +165118,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -165532,9 +165152,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       versuche die grammatikalische Verbesserung aufzunehmen,
@@ -165570,9 +165188,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Benny hat sich jetzt 3 Wochen nicht mehr gemeldet, daher konzentriere ich mich nun auf das Wesentliche und räume solche Nebenthemen einfach ab
@@ -165583,9 +165199,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       There appears to be widespread consensus that simple building blocks should be provided as free software, that “can be used to combine new functionality”
@@ -165606,9 +165220,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Die Frage ist: gehe ich mit dieser Mutmaßung zu weit? Es ist schon starker Tobak
@@ -165636,7 +165248,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -165645,9 +165257,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -165659,9 +165269,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -165672,9 +165280,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       und hat begonnen, dicke Bretter zu bohren:
@@ -165698,9 +165304,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       man hat wohl ein ganzes Jahr lang zwar die Meetings aufrecht erhalten, aber nur sich informell ausgetauscht
@@ -165729,9 +165333,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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....
@@ -165744,9 +165346,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       die Darstellung könnte sich vor allem
@@ -165784,23 +165384,18 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -165810,9 +165405,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -165823,9 +165416,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Lumiera ist entstanden durch meine Verstrickung in diesen Konflikt
@@ -165833,9 +165424,7 @@ that situation will improve in forseeable future.
   
 
 
-  
-    
-  
+  
   
     
      
       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).
@@ -165845,9 +165434,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       ich sehe jetzt in dieser Position eine Chance
@@ -165918,9 +165505,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -167697,7 +167282,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -167966,9 +167551,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       das war nun eine
@@ -168454,18 +168037,16 @@ that situation will improve in forseeable future.
 
 
 
-
-
-
+
+
+
 
 
 
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -168475,9 +168056,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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
@@ -168508,9 +168087,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -168528,7 +168105,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -168687,9 +168264,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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.
@@ -168705,9 +168280,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       war trotzdem ein Monster-Aufwand
@@ -168715,9 +168288,7 @@ that situation will improve in forseeable future.
   
 
 
-  
-    
-  
+  
   
     
      
       ....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!
@@ -168743,9 +168314,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       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)
@@ -168755,9 +168324,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       
      
@@ -168791,30 +168358,82 @@ that situation will improve in forseeable future.
 
 
 
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Da ich "autobrief" verwende, ist der erste Satz stets auch die Kurzbeschreibung. Zudem stelle ich die Langbeschreibung stets an den Anfang der Seite, weil ich dies für die nützlichste Info halte. Die ganzen sonstigen Member-Listen sind ehr verwirrend
+    
      
+  
+      
+      
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
 
-
+
 
 
 
 
-
-
-
+
+
+
+
 
-
-
+
+
 
-
-
+
+
+
+
+
+
 
 
+
+
 
-
+
+
 
+
 
 
+
 
 
 
@@ -170322,7 +169941,8 @@ Since then others have made contributions, see the log for the history.      
 
 
-
+
+
 
 
 
@@ -170338,7 +169958,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -179936,6 +179556,49 @@ Since then others have made contributions, see the log for the history.
 
 
+
+
+
+
+
+
+  
+  
+    
      
+      Das Log ist geflutet mit Warnungen, und viele Querverweise funktionieren nicht. Leider sind Probleme mit Doxygen schwer zu diagnostizieren, da der Lauf lange dauert, und die Codebasis riesig ist. Es gibt daher keine klar definierte Agenda, die man sinnvoll abarbeiten könnte. Ich kann immer nur von Zeit zu Zeit stichprobenartige Kontrollen machen
+    
      
+  
+      
+
+
+
+
+  
+  
+    
      
+      ...obwohl ich diese Warnung abgeschaltet habe; wahrscheinlich handelt es sich um Fälle, wo ich (gemäß Clean Code) nur einen Parameter dokumentiert habe, der nicht selbsterklärend ist.
+    
      
+  
+      
+      
+      
+
+
+  
+  
+    
      
+      Ich finde die Seiten meist total verwirrend; es sind eigentlich nur die File-Kommentare sinnvoll. Selbst die Typ-Kommentare sind oft verwirrend, weil die Typen irgendwo stehen und der Kontext nicht so ersichtlich ist wie im Code. Hinzu kommt, daß der allgemeine Scope (auch Namespace) oft geflutet ist mit Metaprogramming-Definitionen, die nicht im richtigen Zusammenhang dargestellt werden. Es ist in dem Zusammenhang total unpraktisch, daß die Template-Parameter mit angegeben werden, und daß zusamengehörige Spezialisierungen nicht aufgesammelt werden. Das ist aber vermutlich gar nicht möglich.
+    
      
+    
      
+      
+    
      
+    
      
+      Insgesamt scheint das Prinzip einer API-Doc nicht auf einen modernen, funktionalen Programmierstil zu passen.
+    
      
+  
+      
+      
+