From 7e8a8a5b764a92c492aca2867dd442d5b798827e Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 3 Aug 2025 01:41:15 +0200 Subject: [PATCH 01/51] Recherche / preparation for FrOSCon talk The topic of this talk was ''Video output from a Linux desktop application'' after extended research we built a demo application in four flavours (XVideo, SDL, OpenGL legacy / modern). This research project was set off by our immediate needs for a setup to show computed video pixel data in a viewer window in the GUI; the investigated technologies should work at present and in the near term future (yet leaving out Vulkan and Wayland) --- src/stage/output/xv-displayer.cpp | 12 +- src/stage/output/xv-displayer.hpp | 2 - src/stage/widget/video-display-widget.cpp | 2 - .../engine/worker/dummy-image-generator.hpp | 1 + wiki/thinkPad.ichthyo.mm | 850 +++++++++++++++++- 5 files changed, 845 insertions(+), 22 deletions(-) diff --git a/src/stage/output/xv-displayer.cpp b/src/stage/output/xv-displayer.cpp index 4390c0aab..999901577 100644 --- a/src/stage/output/xv-displayer.cpp +++ b/src/stage/output/xv-displayer.cpp @@ -26,6 +26,8 @@ //#include "lib/format-cout.hpp" #include +#include +#include namespace stage { namespace output { @@ -144,8 +146,9 @@ namespace output { if (gotPort) { - XGCValues values; - memset(&values, 0, sizeof(XGCValues)); +// XGCValues values; +// memset(&values, 0, sizeof(XGCValues)); +///////////////////////////////////////////////////////////////TODO actually pass these to XCreateGC to set line width or fill colour etc. gc = XCreateGC( display, window, 0, NULL ); xvImage = ( XvImage * ) XvShmCreateImage( display, grabbedPort, FORMAT_ID_YUY2, 0, videoWidth, videoHeight, &shmInfo ); @@ -167,8 +170,8 @@ namespace output { } XSync( display, false ); - shmctl( shmInfo.shmid, IPC_RMID, 0 ); - } + shmctl( shmInfo.shmid, IPC_RMID, 0 ); // mark the segment as deleted + } // -- it will be retained until the last client calls shmdt() } } else @@ -233,6 +236,7 @@ namespace output { XvShmPutImage (display, grabbedPort, window, gc, xvImage, 0, 0, videoWidth, videoHeight, org_x, org_y, destW, destH, false); + XFlush (display); } } diff --git a/src/stage/output/xv-displayer.hpp b/src/stage/output/xv-displayer.hpp index ecac3e346..9cc1ae048 100644 --- a/src/stage/output/xv-displayer.hpp +++ b/src/stage/output/xv-displayer.hpp @@ -29,8 +29,6 @@ #include "stage/gtk-base.hpp" #include -#include -#include #include #include diff --git a/src/stage/widget/video-display-widget.cpp b/src/stage/widget/video-display-widget.cpp index 0190aeb40..eb5e8702d 100644 --- a/src/stage/widget/video-display-widget.cpp +++ b/src/stage/widget/video-display-widget.cpp @@ -71,11 +71,9 @@ namespace widget { { REQUIRE (videoWidth > 0); REQUIRE (videoHeight > 0); - /* ///////////////////////////////TICKET #1403 : temporarily disabled XV for experimentation with Pixbuf (but XV works and is usable) displayer_ = make_unique (*this, videoWidth, videoHeight); if (displayer_->usable()) return; - */ displayer_ = make_unique (*this, videoWidth, videoHeight); if (displayer_->usable()) return; diff --git a/src/steam/engine/worker/dummy-image-generator.hpp b/src/steam/engine/worker/dummy-image-generator.hpp index cf8f7c358..a9f741b3f 100644 --- a/src/steam/engine/worker/dummy-image-generator.hpp +++ b/src/steam/engine/worker/dummy-image-generator.hpp @@ -21,6 +21,7 @@ ** dummy playback service. ** ** @todo obsolete since 2010, can be removed once we have a real player in the UI + ** @todo revived in 2025 for research of video output techniques; this is test code. ** @see stage::controller::PlaybackController ** @see steam::play::DummyPlayerService ** diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 217bd36a3..571f215f3 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -36349,6 +36349,10 @@ + + + + @@ -130333,7 +130337,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + @@ -130402,6 +130407,42 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + + + + + + + + + + + + + + + + + +

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

+ + + + + + + + + @@ -130612,7 +130653,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + @@ -130659,6 +130701,20 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + + + + + + + @@ -151816,8 +151872,22 @@ std::cout << tmpl.render({"what", "World"}) << s - + + + + + +

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

+ + + + + + + @@ -152992,7 +153062,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -153022,6 +153092,101 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + + +

+ #include <gtkmm.h> +

+

+ #include <iostream> +

+

+ +

+

+ class MyApp +

+

+   : public Gtk::Application +

+

+   { +

+

+   protected: +

+

+     // install into the default startup handler +

+

+     void +

+

+     on_startup()  override +

+

+       { +

+

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

+

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

+

+       } +

+

+     +

+

+     static bool +

+

+     on_timeout() +

+

+       { +

+

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

+

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

+

+       } +

+

+   }; +

+

+ +

+

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

+

+   { +

+

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

+

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

+

+   } +

+ + + + + + @@ -155449,6 +155614,15 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + + + + + + @@ -159501,6 +159675,31 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + +

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

+ + + + + + + + @@ -159567,6 +159766,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + @@ -159584,13 +159787,36 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + + + + +

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

+

+ +

+

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

+ + + + - + + + + @@ -159602,6 +159828,14 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + @@ -159900,6 +160134,40 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo

+ + + + + + +

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

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

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

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

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

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

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

+

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

+ + + + + + + + + + @@ -161012,7 +161348,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161038,8 +161374,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + @@ -161398,9 +161734,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - + + + + @@ -161419,6 +161758,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + @@ -161439,8 +161782,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + @@ -161448,6 +161791,485 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + + + + +

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

+ + + + + + + +

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

+ + + + + + + + + + +

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

+

+ +

+

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

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

+ siehe deutsche Wikipedia +

+ + + + + + + +

+ siehe englische Wikipedia +

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

+ TODO this commit requires a review +

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

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

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

+ A complex integration process is also +

+

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

+

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

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

+ ebenso hier: das meiste ist sehr gut, +

+

+ aber manches versteht Benny anscheinend nicht +

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

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

+ + + + + + + +

+ interessanterweise beharrt er darauf, +

+

+ das sei rein grammatikalisch +

+ + + + + + + +

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

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

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

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

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

+ + + + + + + +

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

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

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

+ + + + + +

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

+ + + + + + From 7bbb21a8adeb16d57b5141acfd6a4004e4e029ee Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 19 Aug 2025 15:15:36 +0200 Subject: [PATCH 02/51] DOC: minutes of FrOSCon meeting MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Topic: proposals for Lumiera Workflow Present: - Wouter Verweijlen - Benny Lyons - Hermann Voßeler Note: This commit creates a new subsection for the discussion related to Wouter's »Lumiera Workflow Proposals«.... --- .../workflow/Verwijlen/FrosconMeeting.txt | 84 ++++++++++ doc/design/workflow/Verwijlen/index.txt | 9 ++ doc/design/workflow/index.txt | 3 + wiki/Workflow_Verwijlen.mm | 149 ++++++++++++++++++ 4 files changed, 245 insertions(+) create mode 100644 doc/design/workflow/Verwijlen/FrosconMeeting.txt create mode 100644 doc/design/workflow/Verwijlen/index.txt create mode 100644 wiki/Workflow_Verwijlen.mm diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt new file mode 100644 index 000000000..39b422635 --- /dev/null +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -0,0 +1,84 @@ +Meeting at FrOSCon 2025 +======================= +Date: 2025-08-17 +Author: Benny Lyons and Hermann Voßeler +:toc: + +Present:: +- Wouter Verwijlen +- Benny Lyons +- Hermann Voßeler + +Endgoal:: + To produce a design document. + +This Meeting is based on the document link:TODO[»Lumiera Workflow Proposals«] by Wouter Verwijlen. +Wouter traveled to FrOSCon to meet the core team in person. This meeting discussed some central points +of the planned workflow support in the Lumiera GUI. We discussed problems, agreed on various points +and decided to produce a design document. Here we attempt to reconstruct and document the original meeting. + +Points discussed +---------------- +We agreed upon the importance of a _Magnetic Timeline,_ as introduced by Final Cut X. However, our +Placement concept [TODO Link] which predates FCX's release [TODO source] shares similar goals but +its scope is more far-reaching. We consider _Magnetic Timeline_ to be an important advancement to +legacy track oriented GUI schemes; but it is more mouse confined and does not support several Control +Systems footnote:[Mouse, keyboard, pen, hardware controls] on an equal footing, which is our vision. + +Modes, Tools and Views +~~~~~~~~~~~~~~~~~~~~~~ +Modes are generally frowned upon in the User Interface Design discipline. On the other hand, they enjoy +popularity in video editing applications. Tools and Views were introduced to improve the usability +of Modes. We agreed to adopt tools as the more preferable system, but only if we manage to develop +a suitable handling mechanism that can be used naturally throughout all Control Systems. + +Taking inspiration from Blender, Hermann proposed a fundamental shift by extending the scope of tool usage +to the entire UI. To do this, we agreed to introduce a top-level tool to navigate throughout the UI. +Wouter expressed some concerns on how effect parameters and mixer stripes could be accessd. This +remains a problem to be resolved. We agreed that this default navigation tool should map down +naturally to conventional usage of the mouse. + +We discussed that a consequence of that decision might be to introduce a spcial tool dedicated +to dragging and moving clips, but we were concerned that such a mode might hamper fluid working +with the UI. It seems preferrable to introduce the moving of clips as a sub-mode into the +navigation tool, with the option to lock moving of clips. + +Wouter introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI. +The ability of Tools to support sub-modes is a simple extension of this proposal. +With this functionality, it would be then be possible to switch between trim-, roll-, slide- and shuffle-edit +after activating the edit tool. Similarily, the _gear switch_ as proposed in a previous online discussion +would be integrated as a sub-mode if a user decided to manipulate any setting value. + +Internatinalisation +~~~~~~~~~~~~~~~~~~~ +The language of the UI is English. This does not mean that we exclude any language +(all contributions are welcome). Certain words and terminology should never be translated, e.g., +Track, Clip, Placement, ... . We allso do not support translations that require a re-ordering +of UI elements such as languages written right-to-left. This is due to priorities that we define. + + +Unlimited Placement Constraints +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Agreement on all points [TODO] + +Routing +^^^^^^^ +Hermann explained how the routing in Render Engine is based on Placements. +All data streams are grouped according to the medium (video, audio,...) by default. +Mixing-groups can be automatically established if resources are tagged. + + +Layering order +~~~~~~~~~~~~~~ + + +Grouping Devices +~~~~~~~~~~~~~~~~ + +Target audience +~~~~~~~~~~~~~~~ + + +Conclusions +----------- + diff --git a/doc/design/workflow/Verwijlen/index.txt b/doc/design/workflow/Verwijlen/index.txt new file mode 100644 index 000000000..0aa9839c6 --- /dev/null +++ b/doc/design/workflow/Verwijlen/index.txt @@ -0,0 +1,9 @@ +Lumiera Workflow Proposals +========================== +Date: 2025 + +//MENU: Workflow Proposals Verwijlen + +- TODO include full text of from Wouter +- link:FrosconMeeting.html[Discussion at FrOSCon 2025] + diff --git a/doc/design/workflow/index.txt b/doc/design/workflow/index.txt index d2f4e367b..abfc5248d 100644 --- a/doc/design/workflow/index.txt +++ b/doc/design/workflow/index.txt @@ -1,6 +1,9 @@ Design Documents: Workflow ========================== +//MENU: prepend child LumieraWorkflowOutline +//MENU: put child InterfaceConcept_Varga after LumieraWorkflowOutline + In our discussions, the term *Workflow* denotes specific considerations about _the way_ a given task can be achieved, within the application, in the most suitable and stringent fashion. This effort is closely related to GUI and interface design, but likewise quite integral, diff --git a/wiki/Workflow_Verwijlen.mm b/wiki/Workflow_Verwijlen.mm new file mode 100644 index 000000000..8437bde0b --- /dev/null +++ b/wiki/Workflow_Verwijlen.mm @@ -0,0 +1,149 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ich sehe das als Günstige Gelegenheit +

+ + + + + + + +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From eb887706e589941a182ecfe969c3684f27e1c7dc Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 20 Aug 2025 01:16:28 +0200 Subject: [PATCH 03/51] DOC: minutes (continued...) --- .../workflow/Verwijlen/FrosconMeeting.txt | 48 +++++++++++++++---- 1 file changed, 40 insertions(+), 8 deletions(-) diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index 39b422635..cfd61b873 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -13,7 +13,7 @@ Endgoal:: To produce a design document. This Meeting is based on the document link:TODO[»Lumiera Workflow Proposals«] by Wouter Verwijlen. -Wouter traveled to FrOSCon to meet the core team in person. This meeting discussed some central points +Wouter travelled to FrOSCon to meet the core team in person. This meeting discussed some central points of the planned workflow support in the Lumiera GUI. We discussed problems, agreed on various points and decided to produce a design document. Here we attempt to reconstruct and document the original meeting. @@ -34,32 +34,35 @@ a suitable handling mechanism that can be used naturally throughout all Control Taking inspiration from Blender, Hermann proposed a fundamental shift by extending the scope of tool usage to the entire UI. To do this, we agreed to introduce a top-level tool to navigate throughout the UI. -Wouter expressed some concerns on how effect parameters and mixer stripes could be accessd. This +Wouter expressed some concerns on how effect parameters and mixer stripes could be accessed. This remains a problem to be resolved. We agreed that this default navigation tool should map down naturally to conventional usage of the mouse. -We discussed that a consequence of that decision might be to introduce a spcial tool dedicated +We discussed that a consequence of that decision might be to introduce a special tool dedicated to dragging and moving clips, but we were concerned that such a mode might hamper fluid working -with the UI. It seems preferrable to introduce the moving of clips as a sub-mode into the +with the UI. It seems preferable to introduce the moving of clips as a sub-mode into the navigation tool, with the option to lock moving of clips. Wouter introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI. The ability of Tools to support sub-modes is a simple extension of this proposal. With this functionality, it would be then be possible to switch between trim-, roll-, slide- and shuffle-edit -after activating the edit tool. Similarily, the _gear switch_ as proposed in a previous online discussion +after activating the edit tool. Similarly, the _gear switch_ as proposed in a previous online discussion would be integrated as a sub-mode if a user decided to manipulate any setting value. Internatinalisation ~~~~~~~~~~~~~~~~~~~ The language of the UI is English. This does not mean that we exclude any language (all contributions are welcome). Certain words and terminology should never be translated, e.g., -Track, Clip, Placement, ... . We allso do not support translations that require a re-ordering +Track, Clip, Placement, ... . We also do not support translations that require a re-ordering of UI elements such as languages written right-to-left. This is due to priorities that we define. Unlimited Placement Constraints ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Agreement on all points [TODO] +The use of fine-grained placement constraints is plagued with overwhelming the user with +excessive relationships. This can be improved by using a small number of prototype set-ups: +magnetic, relative and music anchored. Moreover, we require a diagnostic to reveal the reason why +a given clip is positioned at where it is. Routing ^^^^^^^ @@ -70,10 +73,39 @@ Mixing-groups can be automatically established if resources are tagged. Layering order ~~~~~~~~~~~~~~ - +The layering order is usually arranged according to track sequence in the UI. +To retain this configuration we would have to put some content into a track which can be +located at a distance from other related content: not an ideal situation. One way to alleviate +this problem is to allow the user to configure the layer ordering for a single track so that +all content is always fixed to be above a reference clip. While this promises to be an +interesting mechanism to improve the track sequence dilemma and provide the user a greater +track arrangement freedom, further practical tests need to be carried out to determine its +feasibility. Grouping Devices ~~~~~~~~~~~~~~~~ +One idea presented in Wouters document was the introduction of a light-weight grouping device. +This would solve some problems, for example, a number of objects can be collectively moved +as one unit together. Hermann proposed to use placements to achieve the same effect. +It is yet to be resolved how this grouping can be visually represented. + +One important issue proposed by Wouter was to use segments to arrange the narrative at the +top level. To implement this feature would require on the one hand a considerable effort +by developers, on the other hand, it does not naturally fit into the Lumiera core design +as it would be a very specific extension instead of a homogeneous building block in Lumiera. +Hermann proposes to use nested sequences to implement this feature which is already been +planned for the session model. All these nested sequences will have their own track structure, +which is a tree relationship. For example, expanding one structure would not necessarily +expand neighbouring structures. Another advantage of using this mechanism is that it can +be used to construct a transition between adjacent chapters of a film while still retaining +the ability to reshuffle chapters to explore various narratives. We can thus solve two +problems with the same feature. + +Wouter was concerned that it might be tedious to navigate between different chapters, +especially if it is necessary to expand or collapse these elements repeatedly. One +countermeasure to releave constant opening and closing elements would be to expand +the elements stepwise while still retaining the ability to edit the contents. + Target audience ~~~~~~~~~~~~~~~ From e2d9fea710aec2dfe3af5f443eb28be8e403807d Mon Sep 17 00:00:00 2001 From: benn Date: Wed, 20 Aug 2025 20:00:09 +0200 Subject: [PATCH 04/51] DOC: Add section "Target audience" TODO the ordered list of target groups. I didn't have a list of all target groups and their priority, so please provide the list somebody. --- .../workflow/Verwijlen/FrosconMeeting.txt | 27 ++++++++++++++++--- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index cfd61b873..f59cc66d6 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -9,7 +9,7 @@ Present:: - Benny Lyons - Hermann Voßeler -Endgoal:: +End goal:: To produce a design document. This Meeting is based on the document link:TODO[»Lumiera Workflow Proposals«] by Wouter Verwijlen. @@ -49,7 +49,7 @@ With this functionality, it would be then be possible to switch between trim-, r after activating the edit tool. Similarly, the _gear switch_ as proposed in a previous online discussion would be integrated as a sub-mode if a user decided to manipulate any setting value. -Internatinalisation +Internationalisation ~~~~~~~~~~~~~~~~~~~ The language of the UI is English. This does not mean that we exclude any language (all contributions are welcome). Certain words and terminology should never be translated, e.g., @@ -103,12 +103,31 @@ problems with the same feature. Wouter was concerned that it might be tedious to navigate between different chapters, especially if it is necessary to expand or collapse these elements repeatedly. One -countermeasure to releave constant opening and closing elements would be to expand -the elements stepwise while still retaining the ability to edit the contents. +countermeasure to relieve constant opening and closing elements would be to expand +the elements step wise while still retaining the ability to edit the contents. Target audience ~~~~~~~~~~~~~~~ +It is important to identify our target audience to be able to obtain a clear +vision of which features are more preferable to include and those features which +might be less suitable to incorporate into Lumiera. This will allow us to +fine-focus into the particular needs of these groups and provide us with a +mechanism to curtail our long feature list. Eventually we might have a list of +features ordered according to priority. Other factors are, of course, +important in determining whether a feature is implemented or not, e.g., effort +required to implement a feature; but we focus solely on identifying our target +audience here. + +Wouter identified five groups which mould most likely be attracted to Lumiera +and its goals. During our discussions, we ordered these groups according to, in our +opinion, those who would be most interested too those he would be less interested. + +These groupings are naturally provisional and will mostly likely change--which +is very good--as we add important features that are deemed essential but fit to +no group in our selection. + +We identified the following groups: Conclusions From a021fe11898f455cba2ab0a1e402ae191fae04e7 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 21 Aug 2025 21:15:14 +0200 Subject: [PATCH 05/51] DOC: rework the "Target audience" and add an overall conclusion - included the list of "Personas", quoting from Wouter's document - add some details from the ensuing discussion - close the document with a section "Conclusions" to list the most relevant open points --- .../workflow/Verwijlen/FrosconMeeting.txt | 90 +++++++++++++------ doc/design/workflow/Verwijlen/index.txt | 2 +- 2 files changed, 66 insertions(+), 26 deletions(-) diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index f59cc66d6..67e95cafe 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -1,7 +1,7 @@ Meeting at FrOSCon 2025 ======================= -Date: 2025-08-17 -Author: Benny Lyons and Hermann Voßeler +:Date: 2025-08-17 +:Author: Benny Lyons and Hermann Voßeler :toc: Present:: @@ -19,11 +19,19 @@ and decided to produce a design document. Here we attempt to reconstruct and doc Points discussed ---------------- -We agreed upon the importance of a _Magnetic Timeline,_ as introduced by Final Cut X. However, our -Placement concept [TODO Link] which predates FCX's release [TODO source] shares similar goals but -its scope is more far-reaching. We consider _Magnetic Timeline_ to be an important advancement to -legacy track oriented GUI schemes; but it is more mouse confined and does not support several Control -Systems footnote:[Mouse, keyboard, pen, hardware controls] on an equal footing, which is our vision. +We agreed upon the importance of a _Magnetic Timeline,_ as introduced by Final Cut X. +However, our link:{ldoc}devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)] +which predates FCPX's release,footnote:[Final Cut Pro X was +link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic +Timeline« is generally considered a novel concept introduced with this update. The initial reception +was rather controversial.] +shares similar goals but its scope is more far-reaching. We consider _Magnetic Timeline_ to be an +important advancement to legacy track oriented GUI schemes; but it is more mouse confined and does +not support several Control Systems footnote:[The term »Control System« refers to one technical +realisation of an human-computer-interface, which is used coherently and can coexist with other +such interfaces -> link:{ldoc}/design/gui/InteractionControl.html#_foundation_concepts[more]. + +The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...] +on an equal footing, which is our vision. Modes, Tools and Views ~~~~~~~~~~~~~~~~~~~~~~ @@ -32,9 +40,9 @@ popularity in video editing applications. Tools and Views were introduced to imp of Modes. We agreed to adopt tools as the more preferable system, but only if we manage to develop a suitable handling mechanism that can be used naturally throughout all Control Systems. -Taking inspiration from Blender, Hermann proposed a fundamental shift by extending the scope of tool usage +Taking inspiration from Blender, _Hermann_ proposed a fundamental shift by extending the scope of tool usage to the entire UI. To do this, we agreed to introduce a top-level tool to navigate throughout the UI. -Wouter expressed some concerns on how effect parameters and mixer stripes could be accessed. This +_Wouter_ expressed some concerns on how effect parameters and mixer stripes could be accessed. This remains a problem to be resolved. We agreed that this default navigation tool should map down naturally to conventional usage of the mouse. @@ -43,9 +51,9 @@ to dragging and moving clips, but we were concerned that such a mode might hampe with the UI. It seems preferable to introduce the moving of clips as a sub-mode into the navigation tool, with the option to lock moving of clips. -Wouter introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI. +_Wouter_ introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI. The ability of Tools to support sub-modes is a simple extension of this proposal. -With this functionality, it would be then be possible to switch between trim-, roll-, slide- and shuffle-edit +With this functionality, it would be then be possible to switch between trim-, roll-, slide- and slip-edit after activating the edit tool. Similarly, the _gear switch_ as proposed in a previous online discussion would be integrated as a sub-mode if a user decided to manipulate any setting value. @@ -64,9 +72,8 @@ excessive relationships. This can be improved by using a small number of prototy magnetic, relative and music anchored. Moreover, we require a diagnostic to reveal the reason why a given clip is positioned at where it is. -Routing -^^^^^^^ -Hermann explained how the routing in Render Engine is based on Placements. +.Routing +_Hermann_ explained how the routing in Render Engine is based on Placements. All data streams are grouped according to the medium (video, audio,...) by default. Mixing-groups can be automatically established if resources are tagged. @@ -84,16 +91,16 @@ feasibility. Grouping Devices ~~~~~~~~~~~~~~~~ -One idea presented in Wouters document was the introduction of a light-weight grouping device. +One idea presented in _Wouter_'s document was the introduction of a light-weight grouping device. This would solve some problems, for example, a number of objects can be collectively moved -as one unit together. Hermann proposed to use placements to achieve the same effect. +as one unit together. _Hermann_ proposed to use placements to achieve the same effect. It is yet to be resolved how this grouping can be visually represented. -One important issue proposed by Wouter was to use segments to arrange the narrative at the +One important issue proposed by _Wouter_ was to use segments to arrange the narrative at the top level. To implement this feature would require on the one hand a considerable effort by developers, on the other hand, it does not naturally fit into the Lumiera core design as it would be a very specific extension instead of a homogeneous building block in Lumiera. -Hermann proposes to use nested sequences to implement this feature which is already been +_Hermann_ proposes to use nested sequences to implement this feature which is already been planned for the session model. All these nested sequences will have their own track structure, which is a tree relationship. For example, expanding one structure would not necessarily expand neighbouring structures. Another advantage of using this mechanism is that it can @@ -101,7 +108,7 @@ be used to construct a transition between adjacent chapters of a film while stil the ability to reshuffle chapters to explore various narratives. We can thus solve two problems with the same feature. -Wouter was concerned that it might be tedious to navigate between different chapters, +_Wouter_ was concerned that it might be tedious to navigate between different chapters, especially if it is necessary to expand or collapse these elements repeatedly. One countermeasure to relieve constant opening and closing elements would be to expand the elements step wise while still retaining the ability to edit the contents. @@ -119,17 +126,50 @@ important in determining whether a feature is implemented or not, e.g., effort required to implement a feature; but we focus solely on identifying our target audience here. -Wouter identified five groups which mould most likely be attracted to Lumiera -and its goals. During our discussions, we ordered these groups according to, in our -opinion, those who would be most interested too those he would be less interested. +In his »Lumiera Workflow Proposals«, _Wouter_ identified five groups which mould +most likely be attracted to Lumiera and its goals. -These groupings are naturally provisional and will mostly likely change--which -is very good--as we add important features that are deemed essential but fit to +- The highly specialised editor who works in an environment where different parts of the + post-production of a film are handled by different people: assistant editors, colourists, + audio engineers, etc. +- The allround contracted editor who handles all aspects of post-production +- The allround artistic filmmaker who also edits +- The allround social media creator who values the use of visual effects, + motion graphics and sound effects. +- The free-flowing editor who does not have a fixed idea of how the edit should be + and instead wants to play and move things around, and who might not work in a linear + fashion: they might do a bit of colour correction to get a better sense of how a scene feels, + then go back to editing, etc. +- The editor who has the film already cut in their head and have a very strong sense of + what they want to do and work in a very structured way towards accomplishing this vision. + +These groupings are naturally provisional and will mostly likely change -- which +is very good -- as we add important features that are deemed essential but fit to no group in our selection. -We identified the following groups: +_Benny_ proposed to order these groups according to, in our opinion, those who would be +most interested to those he would be less interested. In the following discussion, we +identified the first group (the specialised editor within an industrial work environment) +and also the social media creators to be a more challenging audience, since these require +rather specialised tools to perform their tasks. Conclusions ----------- +While we reached agreement in many points, the goal is to produce a design document for +the GUI workflow. This task will require to spell out many details, thereby validating +the viability of our ideas. +- it remains to be shown that a generic _gesture concept_ can be mapped onto different + control systems coherently +- it is not clear yet to which extent it is possible to include other UI elements like + the effect property settings into an overarching _navigation mode_ +- a scheme must be worked out which allows to add a _placement prototype_ to each clip + added to the timeline; furthermore we need to develop a representation that exposes + the detailed _placement constraints_ in an understandable way +- the proposed mechanism to control the layering order should be actually implemented + and put into practical use to determine its feasibility +- we need to consider in more detail how the proposed _light-weight grouping_ can be + represented graphically and what actual features can be attached to such a new device. +- a detailed analysis is required to establish gradual steps of expanding / collapsing, + so that the overall timeline remains balanced and excess complexity can be hidden. diff --git a/doc/design/workflow/Verwijlen/index.txt b/doc/design/workflow/Verwijlen/index.txt index 0aa9839c6..b15430c31 100644 --- a/doc/design/workflow/Verwijlen/index.txt +++ b/doc/design/workflow/Verwijlen/index.txt @@ -2,7 +2,7 @@ Lumiera Workflow Proposals ========================== Date: 2025 -//MENU: Workflow Proposals Verwijlen +//MENU: label Workflow Proposals Verwijlen - TODO include full text of from Wouter - link:FrosconMeeting.html[Discussion at FrOSCon 2025] From a2890a627f7ec355f2223919f0760420439abb16 Mon Sep 17 00:00:00 2001 From: Wouter Verwijlen Date: Fri, 4 Apr 2025 22:17:43 +0200 Subject: [PATCH 06/51] Workflow-discussion: Lumiera Workflow Proposals (draft v1) This is the version from 4.Apr - add a subchapter about the current NLE landscape - add a subchapter on tracks vs. trackless - add a bit more information in the navigation subchapter. =========================================================== Remark from Ichthyo(committer): Converted from PDF to raw text with pdftotext wouter250404v1.pdf WorkflowProposals.txt Images extracted with pdfimages -png wouter250404v1.pdf ...and then cropped in Gimp ("crop to content"); images 06 and 11 needed to be split in two parts cropped in Gimp ("crop to content") NOTE: Adding the images separately to the Website-repository, in order to save storage space in the main repository, because content, once added, can not be removed from Git.... --- .../workflow/Verwijlen/WorkflowProposals.txt | 555 ++++++++++++++++++ 1 file changed, 555 insertions(+) create mode 100644 doc/design/workflow/Verwijlen/WorkflowProposals.txt diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt new file mode 100644 index 000000000..0123168a7 --- /dev/null +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -0,0 +1,555 @@ +Lumiera Workflow Proposals +Wouter Verwijlen +Last updated: 3 April 2025 +I would like to share a first version of a collection of workflow ideas for Lumiera. These ideas come +from having cut hundreds (or possibly thousands) of videos over the past 20 years as a professional +editor, working in Avid Media Composer, Adobe Premiere Pro (from before it was called "Pro"), +Lightworks and DaVinci Resolve. +The main ideas behind these proposals are: +• + +Editing should feel as organic as possible. An editor should perceive the NLE as an +extension of their body, where interaction with the NLE will ultimately become natural. This +does not mean that a user should immediately understand everything without there being a +certain learning curve. Some new concepts might take a while to master. + +• + +An editor should not be able to accidentally overwite part of their work in the timeline when +that part is not within sight (in other words: when it's offscreen). This includes throwing +things out of sync, losing transitions, or overwriting clips. + +• + +Interaction with a NLE shouldn't depend on a specific device. It should be possible to +operate Lumiera with only the keyboard, only the mouse, other peripherals or a combination +of these. We can nudge people towards ways of working we think are optimal, but we +shouldn't dictate how to use this application. Many different editors work on many different +types of content, and each type of content requires different workflows, some of which we +might not even foresee. We can't make a one size fits all solution in terms of workflow, +unless we would target Lumiera at a very specific professional field (for example: only long +form films and not short social media content). But even within the same types of content +I've seen different editors using different ways of working. +So if the aim for Lumiera is to be a general purpose video editing application, then we can +not force any specific way of doing things and instead we should support many different +workflows, in other words: provide a platform with possibilities for each editor to make it +their own (which will arguably be a harder goal to achieve). Instead of a "we know what's +best for you" approach I propose a "smart defaults with many options for configuration" +approach. + +• + +A big question is: who is "the user"? We aim to create a tool for professionals, but there are +many types of professionals working in entirely different parts of the media industry or in +other fields. In the previous paragraph it was mentioned that different types of content +require different types of workflows. How to accomodate all of these different people who +work on different things? +I would like to propose a set of personas to keep in mind while designing the application. +Examples of such personas could be: +◦ The highly specialised editor who works in an environment where different parts of the +post-production of a film are handled by different people: assisant editors, colorists, +audio engineers, etc. +◦ The allround contracted editor who handles all aspects of post-production +◦ The allround artistic filmmaker who also edits + + ◦ The allround social media creator who values the use of visual effects, motion graphics +and sound effects. +◦ The free-flowing editor who doesn’t have a fixed idea of how the edit should be and +instead wants to play and move things around, and who might not work in a linear +fashion: they might do a bit of color correction to get a better sense of how a scene feels, +then go back to editing, etc. +◦ The editor who has the film already cut in their head and have a very strong sense of +what they want to do and work in a very structured way towards accomplishing this +vision. +Of course, there are many more types of people and many people who are a combination of +personas. These are only meant to paint the spectrum of possibilities. +• + +Lumiera provides a chance to reimagine how an NLE could work, in other words: how it +can be designed around modern ways of interacting with computers. In that sense there is +total freedom to create innovative new solutions to improve how people edit videos. On the +other hand, if we create paradigms that are too uncommon, new users might not understand +Lumiera fast enough and move on to something else. There's a balance to be found between +providing familiarity and innovation, and we need to think carefully when breaking +traditional paradigms about the reason they have existed for so long and if it’s worth +breaking them. +In any case, I think we should at least make an effort to study the way current NLE's work, +and while we might never know for sure what the reasoning behind their workflow designs +was, we should make an attempt to understand this reasoning. Some designs might have +come from technical limitations, and others might have had really clever thinking behind +them. Let's see what we can learn from that. + +• + +Ideally we should also include workflows for editors using XR headsets in combination with +controllers or even hand tracking. While I do have a headset at work that I experiment with, +we might want someone with actual XR design skills to be involved here. + +Initially I would like to focus on the most fundamental tasks that each and every editor has to deal +with while creating a video: +1. Finding the parts you need out of a lot of source material (logging and organizing footage) +2. The timeline as the editor’s canvas: inserting and grouping material, arranging clips, +trimming and other timeline features +3. Finishing: audio mixing, color correction, titles, effects, exporting +4. The broader GUI concept +Many of the ideas presented here are not necessarily unique: a lot of these either exist in one NLE +or another, or might be more common in so-called Digital Audio Workstations (DAWs). This +document closely inspects the working of other software applications to see how we can learn from +those. +These proposals are by no means finished or complete. They are merely meant to be the starting +point for discussion and would also require user testing. We will want to iterate over certain ideas so +that they will evolve over time, while others might be rejected completely, which is totally fine, of +course. + + The current NLE landscape +A few decades ago there was this idea that only a single application could be called ‘the best’, in +other words: the one true NLE to rule them all. Some even went as far as calling it “the NLE wars”. +There was fierce competition between Avid Media Composer, Final Cut Pro, and Adobe Premiere +and each had its fans. Over the years this discussion faded away. Final Cut Pro was disregarded by +many after the radical rewrite that was released as Final Cut Pro X. Avid Media Composer retained +its spot as the industry standard for television and feature film, while Adobe Premiere Pro +conquered the rest of the media industry. It became clear that no single NLE would be ‘the best’ for +all people and all purposes. They each had their own sets of strengths and weaknesses, and therefore +each would find its own audience. +While NLE’s evolved in de 2010’s, differences between them grew. +Media Composer and Lightworks were already very powerful NLE’s, specialised in the core editing +process, mostly for longer format productions. They offered many configuration options and in turn +had a high learning curve. +Final Cut Pro X sat on the other end of the spectrum. It had few configuration options but was easy +to learn. It became popular among a new crowd: the solo content creators. +Then in between sat Premiere Pro, comfortably. It profited massively from being part of the +Creative Suite, later the Creative Cloud: for many media companies it was very cost effective to pay +Adobe a single sum of money (pre-Creative Cloud) and later subscription fees, and receive all the +tools they could possibly need for media creation. But also the application itself was an all-in-one +solution for all parts of post-production: it offered many tools for audio mixing, color grading, +visual effects, etc. Sure, Media Composer and FCPX also offered tools for these jobs, but were less +developed in these areas and often required plugins to achieve many of the more advanced tasks. +Then came along DaVinci Resolve, a color grading application that was bought by Blackmagic +Design and transformed into another all-in-one powerhouse, which slowly started to take a seat next +to Premiere’s throne. +In the meantime the media landscape changed. NLE’s became more affordable and hardware more +capable, and the result was that editing was no longer a thing only done by professionals: everybody +became an editor, and everybody could edit any moment, anywhere, on laptops, tablets or +smartphones. Social media became a huge new platform where many new makers developed their +own channels and found an audience for their videos. And so came NLE’s that were focussed on +social media content, most notably CapCut. It took FCP’s idea of easy to learn even farther and +offered many one-click visual effects, automatic subtitles and mostly: a lot of effect presets and +assets (titles, other graphics, music) available within the application. +Right now we’re witnessing the early stages of the introduction of AI in most NLE’s. This expands +the possibilities for manipulating video and audio without requiring much technical knowledge. +Voices, music, video clips and even rough cuts can be generated. Audio issues can easily be fixed, +mixing and mastering can be done automatically, tracking en keying becomes a lot easier than it +used to, to name a few things. +And that’s basically where we are now. There’s not one editor to rule them all, there are many, and +they all shine in different fields or sectors. Some NLE’s try to expand and cater to different crowds +(Lightworks for example, received an easier GUI and many presets and assets to attract social +media content creators), others decided to just keep on doing what they’ve always been good at. +The question is: where will we position Lumiera? Due to targeting the Linux platform, it makes +most sense to try and sit in the middle of everything. If we specialise too much, the potential user +base might be too small, although in all fairness, this is an assumption not backed by any real world + + data. Would there be a way to check the validity of this statement? And how should we quantify +"too small"? This is a topic that requires more discussion. + +Chapter 1: working with source material +To be written. + +Chapter 2: the timeline +The timeline is the core of the editing application. This is the editor’s canvas: the space where the +actual film or video is constructed, or rather: crafted. Therefore it is of the highest importance for +Lumiera to feature a timeline that takes the best of what current NLE’s have to offer, while thinking +carefully on how we can improve upon these ways of working. There are many different aspects to +working in the timeline which I will explore in the different subsections of this chapter. + +Tracks vs trackless +Traditionally, NLE's have been track-based. The reason for this is that they have been modelled +after analog hardware. For example, Adobe Premiere's predecessor ReelTime was created to work +like 3/4" tape decks. +I'd like to quote Randy Ubillos, original creator of ReelTime and Final Cut Pro: +"In a track based system the layers at the beginning, middle and end all share the exact same tracks +and you’re always potentially disrupting things in other parts of the project when you make changes +in another area. One of the most common things I heard from editors was that as a project +progressed the likelihood of a change in one part of a project having an unintended effect +somewhere else in the timeline went up dramatically. Tracks implicitly put a relationship between +all of the items in that track, even though they may be actually completely unrelated. " +Source: https://www.linkedin.com/pulse/interview-randy-ubillos-developer-fcp-x-david-busse +Tracks have several advantages: +• + +They give us a way to organise our timeline by dedicating certain types of clips to certain +tracks. For example: +◦ Interview shots on V1 +◦ B-roll on V2 +◦ Graphics on V3 +Or for audio: +◦ Dialog on A1 + A2 +◦ Music on A3 + A4 +◦ Sound effects on A5-A8 + +• + +They allow for track-based effects (usually only implemented on the audio side). + +• + +They support editing by keyboard, as you can toggle tracks on and off and bind this to keys. + +Disadvantages of tracks: +• + +They’re quite inflexible: you can't easily change their order. + + • + +As we saw in Randy’s quote, later in the editing process, when timelines become more +complex, it's easy to mess things up. Often not all tracks are visible within the viewport and +therefore you will need to remember its state (enabled/disabled/sync locked) and contents +or else a trim operation might throw things out of sync, or you might accidentally overwrite +clips. Similar issues can happen horizontally. In Avid for example, I've seen people make an +entire row of empty cuts at the end of their timeline, simply so they can check later if +anything was accidentally thrown out of sync. Lightworks has out-of-sync indicators to +mitigate sync issues. + +• + +Clips that naturally belong together are separated, for example b-roll and associated sound +effects. Instead, clips that only share a shallow relation are grouped together. + +• + +To me, personally, track management takes me out of my storytelling flow. It's a necessity +that doesn't directly aid in the creative process. + +Editors often proudly share screenshots of their timelines on social media, and they do look +impressive, but these are in fact pretty fragile structures. + +One of my own timelines, which is relatively simple by comparison to those of many Hollywood movies + +So naturally, a question would be: what will happen if we would let go of the track paradigm? This +is what Final Cut Pro has done, starting from the rewrite of Final Cut Pro X. At the time, a +disastrous marketing campaign caused many editors to leave the application, although more and +more people are starting to realise that many of its ideas were way ahead of its time. It’s still the +only big NLE out there that was designed with computers in mind, and not analog hardware. +It’s not entirely trackless, but it manages to hide the concept of tracks from the user. In a nutshell, it +works by having a primary storyline (in a track-based NLE this would be V1+A1) where you build +the foundation of your edit. Then the video clips you put on top and the audio clips you put below +get connected to one or more clips from the primary storyline. Move a clip on the primary storyline, +and all connected clips automatically move with it. With a modifier key you can ignore clip +connections, so that you can also easily move a primary clip elsewhere without its connected +siblings coming along. +Sounds good! Why not just copy this? One reason is that FCP assumes that all clips clips that are +not on the primary storyline should be connected to this primary storyline. This might work well for +fiction films, but not necessarily for other types of video. Earlier I mentioned an example of sound +effects that share a connection to b-roll on a higher layer. FCP won’t allow you to connect them. +How else could we group clips together that ought to be connected? We could potentially group +them in compound clips that are directly editable, like so: + + However, there are a few problems with this: we expect rendering to happen from top to bottom, in +which case the b-roll would cover the subtitles. On top of that, it’s hard to see at which points video +clips overlap. Last but not least: it looks rather unorganised. +Can we restructure this? Perhaps like this: + +But how exactly would a user interact with a timeline like this? You’d need a toggle somewhere +(and corresponding keyboard shortcut) to toggle the compounds on and off. When the compounds +are enabled, you can move entire compound clips at once. When turned off, you could edit any +individual clip. When using the keyboard, one could cycle through all visible compound clips with +a key like Tab and then perform actions on the compound clip, or choose to step ‘into’ and ‘out of’ +these compound clips to work on the material inside. +This rises another question: would enabling/disabling of compounds actually be an improvement +over track management? This idea clearly needs a lot more thought and development to see if it +could actually work in a real-world editing scenario, but it might be an interesting direction to +explore. + + Inserting material onto the timeline +To be written. + +Grouping material: sections +I would like to propose the ability to divide a timeline into multiple sections. Each of these sections +will have a header in the ruler that can be edited, to give each section a name (similar to how +duration markers in Premiere are displayed). + +The benefits of sections: +• + +Creating a broad sense and clear overview of how a timeline is constructed. Background +colors in the timeline will make it easy to differentiate between different sections. + +• + +Easy navigation between sections by keyboard shortcuts. + +• + +Keeping sync. All clips in a section are encapsulated. If you work in one section, you will +not be able to throw clips in other sections out of sync. Users could also time-lock a section, +so it will stay in place regardless of other edit operations. This is especially useful when +editing on music, but will also prevent losing sync between other elements that have been +carefully lined up. Sections will not prevent anyone throwing anything out of sync within a +section, but at least not the entire timeline will be affected. + +• + +The order of sections can easily be changed by clicking and dragging. This way sections can +be used to, for example, easily change the order of scenes. The free-flowing editor for +example, can construct different parts of their edit on different parts of the timeline in +different sections, and then arrange them later. + +• + +Sections could have a versioning system: this would allow the user to try different cuts +within a section and to quickly change between these different versions. + +Several other characteristics of sections: +• + +Clips can be excluded from being part of a section. For example: music tracks could span +the entire length of a video by not being included in any section. + + • + +When working within a section, its size will adapt to your edit operations (so its edges will +shrink or expand automatically while trimming or moving clips). + +• + +A new timeline will have one large section spanning its entire length. A “split section” +button and keyboard shortcut will create new sections. + +Things to consider: +• + +How to move clips from one section to another? + +• + +If sections can be time-locked then they will probably need to be able to overlap. + +Navigating the timeline +Quick timeline navigation is key in editing. Let’s start by examining how other NLE’s deal with +this. We need to make a distinction between: +• + +Moving the viewport: the visible section of the timeline. + +• + +Moving the playhead (which will ultimately also move the viewport, once the playhead goes +offscreen). + +Moving the viewport, by mouse: +• + +This usually happens by dragging scrollbars. + +• + +In pretty much every application the scrollwheel can be used to scroll either horizontally or +vertically (usually a setting defines the default direction, and the other direction can be +toggled with a modifier key). + +• + +DaVinci Resolve allows moving the viewport by middle mouse dragging. Quite useful, +actually. + +Moving the viewport, by keyboard: +• + +Some apps use Page Up/Down for this (i.e. Premiere). + +• + +Resolve scrolls the timeline vertically with Page Up and Down and supports shortcuts for +Previous/Next Timeline Page. + +Moving the viewport, by other device: +• + +I don't recall having seen this option anywhere. + +Moving the playhead, by mouse: +• + +Avid allows doing this by clicking anywhere in the timeline (as long as the smart tools are +disabled, else you need to click in empty areas). + +• + +FCP skims the timeline by default when moving the mouse. Clicking parks the playhead in a +new location. + +• + +Others require clicking in the ruler above the timeline or dragging the actual playhead. + +• + +The playhead will obviously also move during playback, which can be started and stopped +by clicking buttons underneath viewers or above the timeline. + +Moving the playhead, by keyboard: +• + +Through playback, using j/k/l as a shuttle (repeated taps increase playback speed). + +• + +Most apps provide keyboard shortcuts for moving single frames left and right. + + • + +Most apps provide keyboard shortcuts for moving steps of multiple frames left and right (in +Premiere you can choose how large the steps are, Resolve only supports single seconds). + +• + +Most apps provide keyboard shortcuts for going to the previous or next cut. + +• + +Most apps provide keyboard shortcuts for going to the previous or next marker. + +• + +Most apps will use the Home and End keys to move to the start and end of the timeline. + +• + +Most apps provide keyboard shortcuts for going to the previous or next keyframe. + +• + +Most apps provide ways for typing timecodes. + +Combining mouse and keyboard: +• + +Adobe Premiere has a "move playhead to cursor" feature that can be bound to a key. Very +useful! + +Using other devices: +• + +Shuttle: allows controlling playback speeds and direction depending on how far you turn the +dial left or right. + +• + +Jog wheel: allows stepping left or right, frame by frame. + +• + +Blackmagic's Speed Editor has the option to change the function of its wheel between +shuttle, jog and scroll. The shuttle mode is practically unusable, but jog and scroll provide +amazingly fluid ways to navigate the timeline. Especially in combination with markers and +jumping between these by keyboard shortcuts, this is a wonderful way to work. + +Zooming also needs to be mentioned here, because often we might be zoomed in, do some work, +zoom out to get an overview of the timeline, and zoom in to another part of the timeline. +Zooming in and out, by mouse: +• + +Usually done either by using a zoom tool, + +• + +Or by using zoom sliders. + +Zooming in and out, by keyboard: +• + +Every NLE has keys to zoom in and out horizontally. Some (Premiere, Resolve, Avid) +support keys to expand and shrink all track heights at once (vertical zooming). + +About keyboard shortcuts +I can imagine that all of the keyboard shortcuts for navigation were invented simply to provide +many options for each editor to choose what they need. This way, every editor can pick the +shortcuts that best fit their workflow. +Navigation by means of keyboard has very good support in most apps and it's a matter of providing +similar shortcuts in Lumiera. It could be expanded by allowing the creation of navigation markers +(a special category of markers) that are bound to keys or numbers. A user can jump to specific +markers by pressing a "go to navigation marker" key, followed by the key they bound. This is +basically Vim's way of doing it (m+0-9a-zA-Z to bind, backtick+0-9a-zA-Z to jump). Or we might +want to keep it as simple as having the regular ‘add marker’, ‘add and edit marker’ and ‘go to +next/previous marker’ keyboard shortcuts. +Sections will get navigation markers automatically, so a user doesn't have to create each marker +manually. Or we might want to include keyboard shortcuts for ‘go to previous/next section’. +Fast forward and fast rewind keys as found in Reaper might be a helpful addition to the +aforementioned keys. This would give as a quick way to skim a timeline by keyboard. While fast + + forward and rewind can be achieved by the regular j/k/l shuttle controls, this requires a lot of +tapping to get to the desired speed, over and over again. + +About mouse navigation +Scrollbars and zoom sliders have a different set of reasons for being chosen as the de facto standard +widgets for navigation. Familiarity on the one hand, and visibility on the other. By having these +controls visible at all times, yet outside of the working area itself, each user will be able to locate +them while they remain out of the way. These are very good reasons for their existence and +positioning, but they come at the cost of speed: moving your mouse cursor out of your main +working area towards the edges and back takes time and interrupts the creative flow. It works, but +it's not ideal. That's why I would like to propose an additional way to navigate by mouse, which is +by popup widgets. These will pop up around the cursor, triggered by a keyboard press (similar to +how Blender uses pie menus): +• Skim widget: by moving the mouse in a small bar we can quickly skim the entire timeline. This +will move both the viewport and playhead. Clicking the left mouse button will accept the new +position and close the widget. + +• Autoscroll widget: when the user moves the mouse cursor slightly left or right, it will enter zones +in which the timeline view will scroll left or right (much like the autoscroll feature in Firefox). +When the user moves the mouse farther away from the initial starting point, the scrollspeed will +increase. This will also work vertically. The playhead will move along as well. + + • Zoom widget: moving the mouse left or right from the center will zoom horizontally, up and +down will zoom vertically. + +Mouse-only navigation: +• Combined widget: we could make a widget that combines skimming, autoscroll (only +horizontally) and zooming (horizontally). This widget is triggered by clicking and pressing the right +mouse button. When released, it will commit to the new location/view. If a user right clicks and +immediately releases the button, a regular context menu will appear. + + Why popup widgets? +I can’t speak for others, but personally I dislike moving the mouse downwards towards the edge of +the screen to access scrollbars or zoom sliders. We’d like the mouse to stay in the center of where +we’re working. +With popup widgets, we might be able to improve navigation speed, but at the cost of familiarity +and visibility. That's why I propose to include all aforementioned widgets. We keep the traditional +sliders and scrollbars, but also add the popup widgets as an extra method for navigation for whoever +is willing to learn this. + +Potential downsides +• + +Widgets might be partially displayed offscreen when the mouse is near the edge of the +screen. + +• + +Very long timelines might make the skimming widget oversensitive. Possible solution: +either enlarge the bar, or create zones near the edges of the bar where the behaviour changes +to be similar to the autoscroll widget. + +• + +When using the keyboard shortcut versions: a downside is having even more keyboard +shortcuts that need quick access from the one hand that stays on the keyboard. + +Arranging clips +To be written. + +Selecting and moving clips +To be written. + +Timeline tools vs modes +To be written. + +Trimming +To be written. + + Chapter 3: finishing +To be written. + +Chapter 4: a broader GUI concept +To be written. + + \ No newline at end of file From 262fe7f3bbdb23959f8900894a8a26f33db94008 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 23 Apr 2025 03:45:15 +0200 Subject: [PATCH 07/51] Workflow-publish: rewrite the text from Wouter into Asciidoc --- .../workflow/Verwijlen/WorkflowProposals.txt | 439 +++++++++--------- doc/design/workflow/Verwijlen/index.txt | 18 +- 2 files changed, 234 insertions(+), 223 deletions(-) diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt index 0123168a7..f414c33f1 100644 --- a/doc/design/workflow/Verwijlen/WorkflowProposals.txt +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -1,27 +1,26 @@ Lumiera Workflow Proposals -Wouter Verwijlen -Last updated: 3 April 2025 +========================== +:Author: Wouter Verwijlen +:Date: 3 April 2025 +:TOC: + I would like to share a first version of a collection of workflow ideas for Lumiera. These ideas come from having cut hundreds (or possibly thousands) of videos over the past 20 years as a professional editor, working in Avid Media Composer, Adobe Premiere Pro (from before it was called "Pro"), Lightworks and DaVinci Resolve. -The main ideas behind these proposals are: -• -Editing should feel as organic as possible. An editor should perceive the NLE as an +The main ideas behind these proposals are: + +* Editing should feel as organic as possible. An editor should perceive the NLE as an extension of their body, where interaction with the NLE will ultimately become natural. This does not mean that a user should immediately understand everything without there being a certain learning curve. Some new concepts might take a while to master. -• - -An editor should not be able to accidentally overwite part of their work in the timeline when +* An editor should not be able to accidentally overwite part of their work in the timeline when that part is not within sight (in other words: when it's offscreen). This includes throwing things out of sync, losing transitions, or overwriting clips. -• - -Interaction with a NLE shouldn't depend on a specific device. It should be possible to +* Interaction with a NLE shouldn't depend on a specific device. It should be possible to operate Lumiera with only the keyboard, only the mouse, other peripherals or a combination of these. We can nudge people towards ways of working we think are optimal, but we shouldn't dictate how to use this application. Many different editors work on many different @@ -30,6 +29,7 @@ might not even foresee. We can't make a one size fits all solution in terms of w unless we would target Lumiera at a very specific professional field (for example: only long form films and not short social media content). But even within the same types of content I've seen different editors using different ways of working. ++ So if the aim for Lumiera is to be a general purpose video editing application, then we can not force any specific way of doing things and instead we should support many different workflows, in other words: provide a platform with possibilities for each editor to make it @@ -37,86 +37,92 @@ their own (which will arguably be a harder goal to achieve). Instead of a "we kn best for you" approach I propose a "smart defaults with many options for configuration" approach. -• - -A big question is: who is "the user"? We aim to create a tool for professionals, but there are +* A big question is: who is "the user"? We aim to create a tool for professionals, but there are many types of professionals working in entirely different parts of the media industry or in other fields. In the previous paragraph it was mentioned that different types of content require different types of workflows. How to accomodate all of these different people who work on different things? ++ I would like to propose a set of personas to keep in mind while designing the application. Examples of such personas could be: -◦ The highly specialised editor who works in an environment where different parts of the ++ +** The highly specialised editor who works in an environment where different parts of the post-production of a film are handled by different people: assisant editors, colorists, audio engineers, etc. -◦ The allround contracted editor who handles all aspects of post-production -◦ The allround artistic filmmaker who also edits - - ◦ The allround social media creator who values the use of visual effects, motion graphics +** The allround contracted editor who handles all aspects of post-production +** The allround artistic filmmaker who also edits +** The allround social media creator who values the use of visual effects, motion graphics and sound effects. -◦ The free-flowing editor who doesn’t have a fixed idea of how the edit should be and +** The free-flowing editor who doesn't have a fixed idea of how the edit should be and instead wants to play and move things around, and who might not work in a linear fashion: they might do a bit of color correction to get a better sense of how a scene feels, then go back to editing, etc. -◦ The editor who has the film already cut in their head and have a very strong sense of +** The editor who has the film already cut in their head and have a very strong sense of what they want to do and work in a very structured way towards accomplishing this vision. ++ Of course, there are many more types of people and many people who are a combination of personas. These are only meant to paint the spectrum of possibilities. -• -Lumiera provides a chance to reimagine how an NLE could work, in other words: how it +* Lumiera provides a chance to reimagine how an NLE could work, in other words: how it can be designed around modern ways of interacting with computers. In that sense there is total freedom to create innovative new solutions to improve how people edit videos. On the other hand, if we create paradigms that are too uncommon, new users might not understand Lumiera fast enough and move on to something else. There's a balance to be found between providing familiarity and innovation, and we need to think carefully when breaking -traditional paradigms about the reason they have existed for so long and if it’s worth +traditional paradigms about the reason they have existed for so long and if it's worth breaking them. ++ In any case, I think we should at least make an effort to study the way current NLE's work, and while we might never know for sure what the reasoning behind their workflow designs was, we should make an attempt to understand this reasoning. Some designs might have come from technical limitations, and others might have had really clever thinking behind them. Let's see what we can learn from that. -• - -Ideally we should also include workflows for editors using XR headsets in combination with +* Ideally we should also include workflows for editors using XR headsets in combination with controllers or even hand tracking. While I do have a headset at work that I experiment with, we might want someone with actual XR design skills to be involved here. Initially I would like to focus on the most fundamental tasks that each and every editor has to deal with while creating a video: + 1. Finding the parts you need out of a lot of source material (logging and organizing footage) -2. The timeline as the editor’s canvas: inserting and grouping material, arranging clips, +2. The timeline as the editor's canvas: inserting and grouping material, arranging clips, trimming and other timeline features 3. Finishing: audio mixing, color correction, titles, effects, exporting 4. The broader GUI concept + Many of the ideas presented here are not necessarily unique: a lot of these either exist in one NLE or another, or might be more common in so-called Digital Audio Workstations (DAWs). This document closely inspects the working of other software applications to see how we can learn from those. + These proposals are by no means finished or complete. They are merely meant to be the starting point for discussion and would also require user testing. We will want to iterate over certain ideas so that they will evolve over time, while others might be rejected completely, which is totally fine, of course. - The current NLE landscape -A few decades ago there was this idea that only a single application could be called ‘the best’, in -other words: the one true NLE to rule them all. Some even went as far as calling it “the NLE wars”. +The current NLE landscape +------------------------- +A few decades ago there was this idea that only a single application could be called ``the best'', in +other words: the one true NLE to rule them all. Some even went as far as calling it ``the NLE wars''. There was fierce competition between Avid Media Composer, Final Cut Pro, and Adobe Premiere and each had its fans. Over the years this discussion faded away. Final Cut Pro was disregarded by many after the radical rewrite that was released as Final Cut Pro X. Avid Media Composer retained its spot as the industry standard for television and feature film, while Adobe Premiere Pro -conquered the rest of the media industry. It became clear that no single NLE would be ‘the best’ for +conquered the rest of the media industry. It became clear that no single NLE would be ``the best'' for all people and all purposes. They each had their own sets of strengths and weaknesses, and therefore each would find its own audience. -While NLE’s evolved in de 2010’s, differences between them grew. -Media Composer and Lightworks were already very powerful NLE’s, specialised in the core editing + +While NLE's evolved in de 2010's, differences between them grew. + +Media Composer and Lightworks were already very powerful NLE's, specialised in the core editing process, mostly for longer format productions. They offered many configuration options and in turn had a high learning curve. + Final Cut Pro X sat on the other end of the spectrum. It had few configuration options but was easy to learn. It became popular among a new crowd: the solo content creators. + Then in between sat Premiere Pro, comfortably. It profited massively from being part of the Creative Suite, later the Creative Cloud: for many media companies it was very cost effective to pay Adobe a single sum of money (pre-Creative Cloud) and later subscription fees, and receive all the @@ -124,84 +130,92 @@ tools they could possibly need for media creation. But also the application itse solution for all parts of post-production: it offered many tools for audio mixing, color grading, visual effects, etc. Sure, Media Composer and FCPX also offered tools for these jobs, but were less developed in these areas and often required plugins to achieve many of the more advanced tasks. + Then came along DaVinci Resolve, a color grading application that was bought by Blackmagic Design and transformed into another all-in-one powerhouse, which slowly started to take a seat next -to Premiere’s throne. -In the meantime the media landscape changed. NLE’s became more affordable and hardware more +to Premiere's throne. + +In the meantime the media landscape changed. NLE's became more affordable and hardware more capable, and the result was that editing was no longer a thing only done by professionals: everybody became an editor, and everybody could edit any moment, anywhere, on laptops, tablets or smartphones. Social media became a huge new platform where many new makers developed their -own channels and found an audience for their videos. And so came NLE’s that were focussed on -social media content, most notably CapCut. It took FCP’s idea of easy to learn even farther and +own channels and found an audience for their videos. And so came NLE's that were focussed on +social media content, most notably CapCut. It took FCP's idea of easy to learn even farther and offered many one-click visual effects, automatic subtitles and mostly: a lot of effect presets and assets (titles, other graphics, music) available within the application. -Right now we’re witnessing the early stages of the introduction of AI in most NLE’s. This expands + +Right now we're witnessing the early stages of the introduction of AI in most NLE's. This expands the possibilities for manipulating video and audio without requiring much technical knowledge. Voices, music, video clips and even rough cuts can be generated. Audio issues can easily be fixed, mixing and mastering can be done automatically, tracking en keying becomes a lot easier than it used to, to name a few things. -And that’s basically where we are now. There’s not one editor to rule them all, there are many, and -they all shine in different fields or sectors. Some NLE’s try to expand and cater to different crowds + +And that's basically where we are now. There's not one editor to rule them all, there are many, and +they all shine in different fields or sectors. Some NLE's try to expand and cater to different crowds (Lightworks for example, received an easier GUI and many presets and assets to attract social -media content creators), others decided to just keep on doing what they’ve always been good at. +media content creators), others decided to just keep on doing what they've always been good at. + The question is: where will we position Lumiera? Due to targeting the Linux platform, it makes most sense to try and sit in the middle of everything. If we specialise too much, the potential user base might be too small, although in all fairness, this is an assumption not backed by any real world - - data. Would there be a way to check the validity of this statement? And how should we quantify +data. Would there be a way to check the validity of this statement? And how should we quantify "too small"? This is a topic that requires more discussion. + Chapter 1: working with source material -To be written. +--------------------------------------- +[red]#To be written.# + Chapter 2: the timeline -The timeline is the core of the editing application. This is the editor’s canvas: the space where the +----------------------- +The timeline is the core of the editing application. This is the editor's canvas: the space where the actual film or video is constructed, or rather: crafted. Therefore it is of the highest importance for -Lumiera to feature a timeline that takes the best of what current NLE’s have to offer, while thinking +Lumiera to feature a timeline that takes the best of what current NLE's have to offer, while thinking carefully on how we can improve upon these ways of working. There are many different aspects to working in the timeline which I will explore in the different subsections of this chapter. Tracks vs trackless +~~~~~~~~~~~~~~~~~~~ Traditionally, NLE's have been track-based. The reason for this is that they have been modelled after analog hardware. For example, Adobe Premiere's predecessor ReelTime was created to work like 3/4" tape decks. + I'd like to quote Randy Ubillos, original creator of ReelTime and Final Cut Pro: +____ "In a track based system the layers at the beginning, middle and end all share the exact same tracks -and you’re always potentially disrupting things in other parts of the project when you make changes +and you're always potentially disrupting things in other parts of the project when you make changes in another area. One of the most common things I heard from editors was that as a project progressed the likelihood of a change in one part of a project having an unintended effect somewhere else in the timeline went up dramatically. Tracks implicitly put a relationship between all of the items in that track, even though they may be actually completely unrelated. " -Source: https://www.linkedin.com/pulse/interview-randy-ubillos-developer-fcp-x-david-busse +____ +Source: https://www.linkedin.com/pulse/interview-randy-ubillos-developer-fcp-x-david-busse[Interview with Randy Ubillos] + Tracks have several advantages: -• -They give us a way to organise our timeline by dedicating certain types of clips to certain -tracks. For example: -◦ Interview shots on V1 -◦ B-roll on V2 -◦ Graphics on V3 -Or for audio: -◦ Dialog on A1 + A2 -◦ Music on A3 + A4 -◦ Sound effects on A5-A8 +* They give us a way to organise our timeline by dedicating certain types of clips to certain +tracks. -• +** For example: +*** Interview shots on V1 +*** B-roll on V2 +*** Graphics on V3 -They allow for track-based effects (usually only implemented on the audio side). +** Or for audio: +*** Dialog on A1 + A2 +*** Music on A3 + A4 +*** Sound effects on A5-A8 -• +* They allow for track-based effects (usually only implemented on the audio side). -They support editing by keyboard, as you can toggle tracks on and off and bind this to keys. +* They support editing by keyboard, as you can toggle tracks on and off and bind this to keys. Disadvantages of tracks: -• -They’re quite inflexible: you can't easily change their order. +* They're quite inflexible: you can't easily change their order. - • - -As we saw in Randy’s quote, later in the editing process, when timelines become more +* As we saw in Randy's quote, later in the editing process, when timelines become more complex, it's easy to mess things up. Often not all tracks are visible within the viewport and therefore you will need to remember its state (enabled/disabled/sync locked) and contents or else a trim operation might throw things out of sync, or you might accidentally overwrite @@ -210,236 +224,196 @@ entire row of empty cuts at the end of their timeline, simply so they can check anything was accidentally thrown out of sync. Lightworks has out-of-sync indicators to mitigate sync issues. -• - -Clips that naturally belong together are separated, for example b-roll and associated sound +* Clips that naturally belong together are separated, for example b-roll and associated sound effects. Instead, clips that only share a shallow relation are grouped together. -• - -To me, personally, track management takes me out of my storytelling flow. It's a necessity +* To me, personally, track management takes me out of my storytelling flow. It's a necessity that doesn't directly aid in the creative process. Editors often proudly share screenshots of their timelines on social media, and they do look impressive, but these are in fact pretty fragile structures. -One of my own timelines, which is relatively simple by comparison to those of many Hollywood movies +.One of my own timelines, which is relatively simple by comparison to those of many Hollywood movies +image::{imgg}/wouter/01-timeline.jpg[Screenshot of a timeline] So naturally, a question would be: what will happen if we would let go of the track paradigm? This is what Final Cut Pro has done, starting from the rewrite of Final Cut Pro X. At the time, a disastrous marketing campaign caused many editors to leave the application, although more and -more people are starting to realise that many of its ideas were way ahead of its time. It’s still the +more people are starting to realise that many of its ideas were way ahead of its time. It's still the only big NLE out there that was designed with computers in mind, and not analog hardware. -It’s not entirely trackless, but it manages to hide the concept of tracks from the user. In a nutshell, it + +It's not entirely trackless, but it manages to hide the concept of tracks from the user. In a nutshell, it works by having a primary storyline (in a track-based NLE this would be V1+A1) where you build the foundation of your edit. Then the video clips you put on top and the audio clips you put below get connected to one or more clips from the primary storyline. Move a clip on the primary storyline, and all connected clips automatically move with it. With a modifier key you can ignore clip connections, so that you can also easily move a primary clip elsewhere without its connected siblings coming along. + Sounds good! Why not just copy this? One reason is that FCP assumes that all clips clips that are not on the primary storyline should be connected to this primary storyline. This might work well for fiction films, but not necessarily for other types of video. Earlier I mentioned an example of sound -effects that share a connection to b-roll on a higher layer. FCP won’t allow you to connect them. +effects that share a connection to b-roll on a higher layer. FCP won't allow you to connect them. + How else could we group clips together that ought to be connected? We could potentially group them in compound clips that are directly editable, like so: - However, there are a few problems with this: we expect rendering to happen from top to bottom, in -which case the b-roll would cover the subtitles. On top of that, it’s hard to see at which points video +.Compound clips +image::{imgg}/wouter/02-1-grouped.png[Timeline with compound clips] + +However, there are a few problems with this: we expect rendering to happen from top to bottom, in +which case the b-roll would cover the subtitles. On top of that, it's hard to see at which points video clips overlap. Last but not least: it looks rather unorganised. + Can we restructure this? Perhaps like this: -But how exactly would a user interact with a timeline like this? You’d need a toggle somewhere +.Overlapping compound clips +image::{imgg}/wouter/02-2-grouped.png[Timeline with stacked overlapping compound clips] + +But how exactly would a user interact with a timeline like this? You'd need a toggle somewhere (and corresponding keyboard shortcut) to toggle the compounds on and off. When the compounds are enabled, you can move entire compound clips at once. When turned off, you could edit any individual clip. When using the keyboard, one could cycle through all visible compound clips with -a key like Tab and then perform actions on the compound clip, or choose to step ‘into’ and ‘out of’ +a key like Tab and then perform actions on the compound clip, or choose to step ``into'' and ``out of'' these compound clips to work on the material inside. + This rises another question: would enabling/disabling of compounds actually be an improvement over track management? This idea clearly needs a lot more thought and development to see if it could actually work in a real-world editing scenario, but it might be an interesting direction to explore. - Inserting material onto the timeline -To be written. + +Inserting material onto the timeline +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[red]#To be written.# + Grouping material: sections +~~~~~~~~~~~~~~~~~~~~~~~~~~~ I would like to propose the ability to divide a timeline into multiple sections. Each of these sections will have a header in the ruler that can be edited, to give each section a name (similar to how duration markers in Premiere are displayed). -The benefits of sections: -• +.Timeline with sections +image::{imgg}/wouter/03-sections.png[Timeline organised into a sequence of sections] -Creating a broad sense and clear overview of how a timeline is constructed. Background + +The benefits of sections: + +* Creating a broad sense and clear overview of how a timeline is constructed. Background colors in the timeline will make it easy to differentiate between different sections. -• +* Easy navigation between sections by keyboard shortcuts. -Easy navigation between sections by keyboard shortcuts. - -• - -Keeping sync. All clips in a section are encapsulated. If you work in one section, you will +* Keeping sync. All clips in a section are encapsulated. If you work in one section, you will not be able to throw clips in other sections out of sync. Users could also time-lock a section, so it will stay in place regardless of other edit operations. This is especially useful when editing on music, but will also prevent losing sync between other elements that have been carefully lined up. Sections will not prevent anyone throwing anything out of sync within a section, but at least not the entire timeline will be affected. -• - -The order of sections can easily be changed by clicking and dragging. This way sections can +* The order of sections can easily be changed by clicking and dragging. This way sections can be used to, for example, easily change the order of scenes. The free-flowing editor for example, can construct different parts of their edit on different parts of the timeline in different sections, and then arrange them later. -• - -Sections could have a versioning system: this would allow the user to try different cuts +* Sections could have a versioning system: this would allow the user to try different cuts within a section and to quickly change between these different versions. Several other characteristics of sections: -• -Clips can be excluded from being part of a section. For example: music tracks could span +* Clips can be excluded from being part of a section. For example: music tracks could span the entire length of a video by not being included in any section. - • - -When working within a section, its size will adapt to your edit operations (so its edges will +* When working within a section, its size will adapt to your edit operations (so its edges will shrink or expand automatically while trimming or moving clips). -• - -A new timeline will have one large section spanning its entire length. A “split section” +* A new timeline will have one large section spanning its entire length. A ``split section'' button and keyboard shortcut will create new sections. Things to consider: -• -How to move clips from one section to another? +* How to move clips from one section to another? +* If sections can be time-locked then they will probably need to be able to overlap. -• - -If sections can be time-locked then they will probably need to be able to overlap. Navigating the timeline -Quick timeline navigation is key in editing. Let’s start by examining how other NLE’s deal with +~~~~~~~~~~~~~~~~~~~~~~~ +Quick timeline navigation is key in editing. Let's start by examining how other NLE's deal with this. We need to make a distinction between: -• -Moving the viewport: the visible section of the timeline. +* Moving the viewport: the visible section of the timeline. -• - -Moving the playhead (which will ultimately also move the viewport, once the playhead goes +* Moving the playhead (which will ultimately also move the viewport, once the playhead goes offscreen). Moving the viewport, by mouse: -• -This usually happens by dragging scrollbars. +* This usually happens by dragging scrollbars. -• - -In pretty much every application the scrollwheel can be used to scroll either horizontally or +* In pretty much every application the scrollwheel can be used to scroll either horizontally or vertically (usually a setting defines the default direction, and the other direction can be toggled with a modifier key). -• - -DaVinci Resolve allows moving the viewport by middle mouse dragging. Quite useful, +* DaVinci Resolve allows moving the viewport by middle mouse dragging. Quite useful, actually. Moving the viewport, by keyboard: -• -Some apps use Page Up/Down for this (i.e. Premiere). +* Some apps use Page Up/Down for this (i.e. Premiere). -• - -Resolve scrolls the timeline vertically with Page Up and Down and supports shortcuts for +* Resolve scrolls the timeline vertically with Page Up and Down and supports shortcuts for Previous/Next Timeline Page. Moving the viewport, by other device: -• -I don't recall having seen this option anywhere. +* I don't recall having seen this option anywhere. Moving the playhead, by mouse: -• -Avid allows doing this by clicking anywhere in the timeline (as long as the smart tools are +* Avid allows doing this by clicking anywhere in the timeline (as long as the smart tools are disabled, else you need to click in empty areas). -• - -FCP skims the timeline by default when moving the mouse. Clicking parks the playhead in a +* FCP skims the timeline by default when moving the mouse. Clicking parks the playhead in a new location. -• +* Others require clicking in the ruler above the timeline or dragging the actual playhead. -Others require clicking in the ruler above the timeline or dragging the actual playhead. - -• - -The playhead will obviously also move during playback, which can be started and stopped +* The playhead will obviously also move during playback, which can be started and stopped by clicking buttons underneath viewers or above the timeline. Moving the playhead, by keyboard: -• -Through playback, using j/k/l as a shuttle (repeated taps increase playback speed). +* Through playback, using j/k/l as a shuttle (repeated taps increase playback speed). -• +* Most apps provide keyboard shortcuts for moving single frames left and right. -Most apps provide keyboard shortcuts for moving single frames left and right. - - • - -Most apps provide keyboard shortcuts for moving steps of multiple frames left and right (in +* Most apps provide keyboard shortcuts for moving steps of multiple frames left and right (in Premiere you can choose how large the steps are, Resolve only supports single seconds). -• +* Most apps provide keyboard shortcuts for going to the previous or next cut. -Most apps provide keyboard shortcuts for going to the previous or next cut. +* Most apps provide keyboard shortcuts for going to the previous or next marker. -• +* Most apps will use the Home and End keys to move to the start and end of the timeline. -Most apps provide keyboard shortcuts for going to the previous or next marker. +* Most apps provide keyboard shortcuts for going to the previous or next keyframe. -• - -Most apps will use the Home and End keys to move to the start and end of the timeline. - -• - -Most apps provide keyboard shortcuts for going to the previous or next keyframe. - -• - -Most apps provide ways for typing timecodes. +* Most apps provide ways for typing timecodes. Combining mouse and keyboard: -• -Adobe Premiere has a "move playhead to cursor" feature that can be bound to a key. Very -useful! +* Adobe Premiere has a "move playhead to cursor" feature that can be bound to a key. + Very useful! Using other devices: -• -Shuttle: allows controlling playback speeds and direction depending on how far you turn the +* Shuttle: allows controlling playback speeds and direction depending on how far you turn the dial left or right. -• +* Jog wheel: allows stepping left or right, frame by frame. -Jog wheel: allows stepping left or right, frame by frame. - -• - -Blackmagic's Speed Editor has the option to change the function of its wheel between +* Blackmagic's Speed Editor has the option to change the function of its wheel between shuttle, jog and scroll. The shuttle mode is practically unusable, but jog and scroll provide amazingly fluid ways to navigate the timeline. Especially in combination with markers and jumping between these by keyboard shortcuts, this is a wonderful way to work. @@ -447,40 +421,42 @@ jumping between these by keyboard shortcuts, this is a wonderful way to work. Zooming also needs to be mentioned here, because often we might be zoomed in, do some work, zoom out to get an overview of the timeline, and zoom in to another part of the timeline. Zooming in and out, by mouse: -• -Usually done either by using a zoom tool, +* Usually done either by using a zoom tool, -• - -Or by using zoom sliders. +* Or by using zoom sliders. Zooming in and out, by keyboard: -• -Every NLE has keys to zoom in and out horizontally. Some (Premiere, Resolve, Avid) +* Every NLE has keys to zoom in and out horizontally. Some (Premiere, Resolve, Avid) support keys to expand and shrink all track heights at once (vertical zooming). + About keyboard shortcuts +~~~~~~~~~~~~~~~~~~~~~~~~ I can imagine that all of the keyboard shortcuts for navigation were invented simply to provide many options for each editor to choose what they need. This way, every editor can pick the shortcuts that best fit their workflow. -Navigation by means of keyboard has very good support in most apps and it's a matter of providing -similar shortcuts in Lumiera. It could be expanded by allowing the creation of navigation markers -(a special category of markers) that are bound to keys or numbers. A user can jump to specific -markers by pressing a "go to navigation marker" key, followed by the key they bound. This is -basically Vim's way of doing it (m+0-9a-zA-Z to bind, backtick+0-9a-zA-Z to jump). Or we might -want to keep it as simple as having the regular ‘add marker’, ‘add and edit marker’ and ‘go to -next/previous marker’ keyboard shortcuts. -Sections will get navigation markers automatically, so a user doesn't have to create each marker -manually. Or we might want to include keyboard shortcuts for ‘go to previous/next section’. -Fast forward and fast rewind keys as found in Reaper might be a helpful addition to the -aforementioned keys. This would give as a quick way to skim a timeline by keyboard. While fast - forward and rewind can be achieved by the regular j/k/l shuttle controls, this requires a lot of +Navigation by means of keyboard has very good support in most apps and it's a matter of providing +similar shortcuts in Lumiera. It could be expanded by allowing the creation of *navigation markers* +(a special category of markers) that are bound to keys or numbers. A user can jump to specific +markers by pressing a ``go to navigation marker'' key, followed by the key they bound. This is +basically Vim's way of doing it (m+0-9a-zA-Z to bind, backtick+0-9a-zA-Z to jump). Or we might +want to keep it as simple as having the regular ``add marker'', ``add and edit marker'' and ``go to +next/previous marker'' keyboard shortcuts. + +Sections will get navigation markers automatically, so a user doesn't have to create each marker +manually. Or we might want to include keyboard shortcuts for ``go to previous/next section''. + +*Fast forward and fast rewind keys* as found in Reaper might be a helpful addition to the +aforementioned keys. This would give as a quick way to skim a timeline by keyboard. While fast +forward and rewind can be achieved by the regular j/k/l shuttle controls, this requires a lot of tapping to get to the desired speed, over and over again. + About mouse navigation +~~~~~~~~~~~~~~~~~~~~~~ Scrollbars and zoom sliders have a different set of reasons for being chosen as the de facto standard widgets for navigation. Familiarity on the one hand, and visibility on the other. By having these controls visible at all times, yet outside of the working area itself, each user will be able to locate @@ -488,68 +464,87 @@ them while they remain out of the way. These are very good reasons for their exi positioning, but they come at the cost of speed: moving your mouse cursor out of your main working area towards the edges and back takes time and interrupts the creative flow. It works, but it's not ideal. That's why I would like to propose an additional way to navigate by mouse, which is -by popup widgets. These will pop up around the cursor, triggered by a keyboard press (similar to +by *popup widgets*. These will pop up around the cursor, triggered by a keyboard press (similar to how Blender uses pie menus): -• Skim widget: by moving the mouse in a small bar we can quickly skim the entire timeline. This + +Skim widget:: by moving the mouse in a small bar we can quickly skim the entire timeline. This will move both the viewport and playhead. Clicking the left mouse button will accept the new position and close the widget. ++ +.Skim widget +image::{imgg}/wouter/04-1-skim.png[A skim widget rendered as overlay] -• Autoscroll widget: when the user moves the mouse cursor slightly left or right, it will enter zones + +Autoscroll widget:: when the user moves the mouse cursor slightly left or right, it will enter zones in which the timeline view will scroll left or right (much like the autoscroll feature in Firefox). When the user moves the mouse farther away from the initial starting point, the scrollspeed will increase. This will also work vertically. The playhead will move along as well. ++ +.Autoscroll widget +image::{imgg}/wouter/04-2-autoscroll.png[A widget for auto-scrolling] - • Zoom widget: moving the mouse left or right from the center will zoom horizontally, up and +Zoom widget:: moving the mouse left or right from the center will zoom horizontally, up and down will zoom vertically. ++ +.Zoom widget +image::{imgg}/wouter/04-3-zoom.png[An overlay widget to control zooming] Mouse-only navigation: -• Combined widget: we could make a widget that combines skimming, autoscroll (only + +Combined widget:: we could make a widget that combines skimming, autoscroll (only horizontally) and zooming (horizontally). This widget is triggered by clicking and pressing the right mouse button. When released, it will commit to the new location/view. If a user right clicks and immediately releases the button, a regular context menu will appear. ++ +.Combined skim, zoom and scroll widget +image::{imgg}/wouter/04-4-combined.png[Overlay widget to combin skim, zoom and autoscrol function] + + +Why popup widgets? +^^^^^^^^^^^^^^^^^^ +I can't speak for others, but personally I dislike moving the mouse downwards towards the edge of +the screen to access scrollbars or zoom sliders. We'd like the mouse to stay in the center of where +we're working. - Why popup widgets? -I can’t speak for others, but personally I dislike moving the mouse downwards towards the edge of -the screen to access scrollbars or zoom sliders. We’d like the mouse to stay in the center of where -we’re working. With popup widgets, we might be able to improve navigation speed, but at the cost of familiarity and visibility. That's why I propose to include all aforementioned widgets. We keep the traditional sliders and scrollbars, but also add the popup widgets as an extra method for navigation for whoever is willing to learn this. Potential downsides -• +^^^^^^^^^^^^^^^^^^^ -Widgets might be partially displayed offscreen when the mouse is near the edge of the +* Widgets might be partially displayed offscreen when the mouse is near the edge of the screen. -• - -Very long timelines might make the skimming widget oversensitive. Possible solution: +* Very long timelines might make the skimming widget oversensitive. Possible solution: either enlarge the bar, or create zones near the edges of the bar where the behaviour changes to be similar to the autoscroll widget. -• - -When using the keyboard shortcut versions: a downside is having even more keyboard +* When using the keyboard shortcut versions: a downside is having even more keyboard shortcuts that need quick access from the one hand that stays on the keyboard. Arranging clips -To be written. +~~~~~~~~~~~~~~~ +[red]#To be written.# Selecting and moving clips -To be written. +~~~~~~~~~~~~~~~~~~~~~~~~~~ +[red]#To be written.# Timeline tools vs modes -To be written. +~~~~~~~~~~~~~~~~~~~~~~~ +[red]#To be written.# Trimming -To be written. +~~~~~~~~ +[red]#To be written.# - Chapter 3: finishing -To be written. +Chapter 3: finishing +-------------------- +[red]#To be written.# Chapter 4: a broader GUI concept -To be written. +-------------------------------- +[red]#To be written.# - \ No newline at end of file diff --git a/doc/design/workflow/Verwijlen/index.txt b/doc/design/workflow/Verwijlen/index.txt index b15430c31..3155d0adc 100644 --- a/doc/design/workflow/Verwijlen/index.txt +++ b/doc/design/workflow/Verwijlen/index.txt @@ -3,7 +3,23 @@ Lumiera Workflow Proposals Date: 2025 //MENU: label Workflow Proposals Verwijlen +//MENU: prepend WorkflowProposals -- TODO include full text of from Wouter +************************ +Wouter Verwijlen is a documentary filmmaker from Utrecht (Netherlands). +************************ + +Many years ago, the Lumiera team first got to know Wouter on occasion +of the link:https://lac.linuxaudio.org/2010/[Linux Audio Conference]. +In spring 2025, he proposed to contribute with concept work related to +UI and workflow, drawing on his longtime experience working with all +professional editing software packages as part of his work in media +production and filmmaking. Knowing those applications in and out, +with all their various strengths and weaknesses allows to compile +a comprehensive overview how the central tasks of film editing +are handled by contemporary software solutions -- and how +this handling might be improved. + +- link:WorkflowProposals.html[»Lumiera Workflow Proposals«] by Wouter Verwijlen - link:FrosconMeeting.html[Discussion at FrOSCon 2025] From 68633de53bc9607f8abfc28f0e630c58263732ef Mon Sep 17 00:00:00 2001 From: Wouter Verwijlen Date: Sun, 29 Jun 2025 14:33:16 +0200 Subject: [PATCH 08/51] Workflow-discussion: Lumiera Workflow Proposals (draft v2) Chapter 2 (about the timeline) is now complete. - extend discussion regarding trackless - add section about Tools / Modes / Views - section: Adding clips to the timeline - section: Selecting clips - section: Arranging clips - section: Trimming clips - section: Splitting and merging clips - section: Removing clips - add subchapter regarding sections of the timeline - Adding and editing transitions - Changing timeline clip properties =========================================================== Remark from Ichthyo(committer): Converted from PDF to raw text with pdftotext wouter250629v2.pdf WorkflowProposals.txt Images extracted with pdfimages -png -j wouter250629v2.pdf wouter/wouter250629v2 Images required no cropping; the white background images were omitted. Again adding the images separately to the Website-repository, in order to save storage space in the main repository.... --- .../workflow/Verwijlen/WorkflowProposals.txt | 726 +++++++++++++++--- 1 file changed, 638 insertions(+), 88 deletions(-) diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt index f414c33f1..fd3e8088a 100644 --- a/doc/design/workflow/Verwijlen/WorkflowProposals.txt +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -1,7 +1,7 @@ Lumiera Workflow Proposals ========================== :Author: Wouter Verwijlen -:Date: 3 April 2025 +:Date: 29 June 2025 :TOC: I would like to share a first version of a collection of workflow ideas for Lumiera. These ideas come @@ -9,6 +9,10 @@ from having cut hundreds (or possibly thousands) of videos over the past 20 year editor, working in Avid Media Composer, Adobe Premiere Pro (from before it was called "Pro"), Lightworks and DaVinci Resolve. +This document focuses on analysing the behaviour of Non-linear Editors (NLE's), in other words +software in which a user can edit films and videos, in order to discuss possible solutions for the +design of Lumiera. + The main ideas behind these proposals are: * Editing should feel as organic as possible. An editor should perceive the NLE as an @@ -20,7 +24,7 @@ certain learning curve. Some new concepts might take a while to master. that part is not within sight (in other words: when it's offscreen). This includes throwing things out of sync, losing transitions, or overwriting clips. -* Interaction with a NLE shouldn't depend on a specific device. It should be possible to +* Interaction with an NLE shouldn't depend on a specific device. It should be possible to operate Lumiera with only the keyboard, only the mouse, other peripherals or a combination of these. We can nudge people towards ways of working we think are optimal, but we shouldn't dictate how to use this application. Many different editors work on many different @@ -114,7 +118,7 @@ conquered the rest of the media industry. It became clear that no single NLE wou all people and all purposes. They each had their own sets of strengths and weaknesses, and therefore each would find its own audience. -While NLE's evolved in de 2010's, differences between them grew. +While NLE's evolved in the 2010's, differences between them grew. Media Composer and Lightworks were already very powerful NLE's, specialised in the core editing process, mostly for longer format productions. They offered many configuration options and in turn @@ -144,7 +148,7 @@ social media content, most notably CapCut. It took FCP's idea of easy to learn e offered many one-click visual effects, automatic subtitles and mostly: a lot of effect presets and assets (titles, other graphics, music) available within the application. -Right now we're witnessing the early stages of the introduction of AI in most NLE's. This expands +Right now we are witnessing the early stages of the introduction of AI in most NLE's. This expands the possibilities for manipulating video and audio without requiring much technical knowledge. Voices, music, video clips and even rough cuts can be generated. Audio issues can easily be fixed, mixing and mastering can be done automatically, tracking en keying becomes a lot easier than it @@ -164,8 +168,19 @@ data. Would there be a way to check the validity of this statement? And how shou Chapter 1: working with source material --------------------------------------- -[red]#To be written.# +This chapter will not cover every detail of the process of ingesting, project organisation and +logging. It will focus on the main strategies of how a user goes through all of their material within a +specific project in order to select the parts needed for the final edit. I will compare the ways in +which different NLE's handle this and will propose possible directions for Lumiera to support +certain workflows. +[red]#To be written:# +Asset organisation: bins vs metadata-based structures (+ search bins/filters) +Viewing footage: single clips vs source reels; continuous playback from browser +Source monitor + program monitor vs a single monitor +Creating selects: selects reels, subclips and keyword collections +On markers and notes +From selects to editing in the timeline: Timelines in the source viewer: reel to reel editing Chapter 2: the timeline ----------------------- @@ -177,11 +192,40 @@ working in the timeline which I will explore in the different subsections of thi Tracks vs trackless ~~~~~~~~~~~~~~~~~~~ -Traditionally, NLE's have been track-based. The reason for this is that they have been modelled -after analog hardware. For example, Adobe Premiere's predecessor ReelTime was created to work -like 3/4" tape decks. +In general, we can observe two extremes when it comes to editing: +• -I'd like to quote Randy Ubillos, original creator of ReelTime and Final Cut Pro: +On the one hand, there are NLE's modeled to resemble working with analog gear (i.e. +classic editing stations from KEM, Steenbeck, Moviola). A lot of terminology in editing +software (‘bins', ‘reels', ‘cut', ‘mark in/out', among many others) stems from the analog +origins of editing. Lightworks is an example of this. When trimming you ‘unjoin' a cut, +make changes, and then ‘join' the cut again, as if working with analog film that needs to be +taped together. It works best in conjunction with the Lightworks Console, a hardware device +that was designed specifically to make software editing feel as if editing analog film. Very +hands-on, very tactile, according to editors who have worked with these consoles +(unfortunately I haven't had a chance to try this myself). +Not just Lightworks, but also Avid is said to have been greatly influenced by analog +equipment, and Adobe Premiere's predecessor ReelTime was created to work like 3/4" tape +decks. Blackmagic's Speed Editor (and corresponding Cut Page in Resolve) has also been +designed according to this principle: to make editing feel like you're operating a machine. +Pressing buttons, rotating dials. This has a great feel to it, but it's less flexible than the other +extreme: + +• + +Editing and trimming designed to be performed by mouse. Most NLE's added this earlier or +later during their development. Final Cut Pro was from its core designed to be used this way. +It's fast, and in combination with the clip connections and magnetic timeline, it's the least +destructive way to edit. Trimming and editing by mouse is less precise though, which is why +even FCP offers many keyboard shortcuts for precise trimming by keyboard. Using a mouse +feel slightly less tactile than using physical buttons and dials. +In this same category we can also mention touch screens (as they offer similar interactions +as a mouse, with the addition of finger gestures). Editing on a smartphone or tablet, when +not using a pen, feels even further removed from giving you a physical connection between +your hands and the buttons on the screen. + + Because of its analog roots, traditionally, NLE's have been track-based. I'd like to quote Randy +Ubillos, original creator of ReelTime and Final Cut Pro: ____ "In a track based system the layers at the beginning, middle and end all share the exact same tracks and you're always potentially disrupting things in other parts of the project when you make changes @@ -211,7 +255,7 @@ tracks. * They support editing by keyboard, as you can toggle tracks on and off and bind this to keys. -Disadvantages of tracks: +Tracks have disadvantages as well: * They're quite inflexible: you can't easily change their order. @@ -227,8 +271,9 @@ mitigate sync issues. * Clips that naturally belong together are separated, for example b-roll and associated sound effects. Instead, clips that only share a shallow relation are grouped together. -* To me, personally, track management takes me out of my storytelling flow. It's a necessity -that doesn't directly aid in the creative process. +* To me, personally, track management (i.e. the enabling and disabling of tracks and/or sync +locks in order to get a certain result when performing editing operations) takes me out of +my storytelling flow. It's a necessity that doesn't directly aid in the creative process. Editors often proudly share screenshots of their timelines on social media, and they do look impressive, but these are in fact pretty fragile structures. @@ -242,21 +287,27 @@ disastrous marketing campaign caused many editors to leave the application, alth more people are starting to realise that many of its ideas were way ahead of its time. It's still the only big NLE out there that was designed with computers in mind, and not analog hardware. -It's not entirely trackless, but it manages to hide the concept of tracks from the user. In a nutshell, it -works by having a primary storyline (in a track-based NLE this would be V1+A1) where you build -the foundation of your edit. Then the video clips you put on top and the audio clips you put below -get connected to one or more clips from the primary storyline. Move a clip on the primary storyline, -and all connected clips automatically move with it. With a modifier key you can ignore clip -connections, so that you can also easily move a primary clip elsewhere without its connected -siblings coming along. +It's not entirely trackless, but it manages to hide the concept of tracks from the user. There are no +buttons to enable or disable tracks or other track controls, and instead, the tracks are called ‘layers'. +In a nutshell, it works by having a primary storyline (in a track-based NLE this would be V1+A1) +where you build the foundation of your edit. Then the video clips you put on top and the audio clips +you put below get connected to one or more clips from the primary storyline. Move a clip on the +primary storyline, and all connected clips automatically move with it. With a modifier key you can +ignore clip connections, so that you can also easily move a primary clip elsewhere without its +connected siblings coming along. -Sounds good! Why not just copy this? One reason is that FCP assumes that all clips clips that are -not on the primary storyline should be connected to this primary storyline. This might work well for -fiction films, but not necessarily for other types of video. Earlier I mentioned an example of sound -effects that share a connection to b-roll on a higher layer. FCP won't allow you to connect them. +Extending one clip will automatically move all connected clips in order to keep sync +Sounds good. Why not just copy this? One reason is that FCP assumes that all clips that are not on +the primary storyline should be connected to this primary storyline. This might work well for fiction +films, but not necessarily for other types of video. Earlier I mentioned an example of sound effects +that share a connection to b-roll on a higher layer. FCP won't allow you to connect them. Another +limitation of FCP is that it's primarily designed to be operated by mouse. It's not possible to use +keyboard commands to, for example, swap the position of clips (other than by cut and paste), or to +perform slip edits (the trim keys will work, but the clip needs to be selected by mouse using the +Trim tool). -How else could we group clips together that ought to be connected? We could potentially group -them in compound clips that are directly editable, like so: +How else could we group clips together that ought to be connected? We could create groups that are +directly editable, like so: .Compound clips image::{imgg}/wouter/02-1-grouped.png[Timeline with compound clips] @@ -270,72 +321,144 @@ Can we restructure this? Perhaps like this: .Overlapping compound clips image::{imgg}/wouter/02-2-grouped.png[Timeline with stacked overlapping compound clips] -But how exactly would a user interact with a timeline like this? You'd need a toggle somewhere -(and corresponding keyboard shortcut) to toggle the compounds on and off. When the compounds -are enabled, you can move entire compound clips at once. When turned off, you could edit any -individual clip. When using the keyboard, one could cycle through all visible compound clips with -a key like Tab and then perform actions on the compound clip, or choose to step ``into'' and ``out of'' -these compound clips to work on the material inside. +But how exactly would a user interact with a timeline like this? I will leave the answer to that +question for an actual design document, as for now I just wanted to show the concept of grouping so +that it becomes clear that alternative ways to organise the timeline might be of great value. -This rises another question: would enabling/disabling of compounds actually be an improvement -over track management? This idea clearly needs a lot more thought and development to see if it -could actually work in a real-world editing scenario, but it might be an interesting direction to -explore. +Tools + modes + views +If we observe existing NLE's, we can distinguish several ways to change timeline interactions. +Some use a tool-based approach (Adobe Premiere, Final Cut Pro), others a mode-based approach +(Avid Media Composer, Lightworks and DaVinci Resolve), and we can also see a view-based +approach (FCP's use of the precision editor, explained in more detail later). Which of these +interaction methods would be preferred for Lumiera? +Using modes is somewhat controversial, as it increases cognitive load (the user needs to remember +which mode they're in) and can lead to user errors (an action in one mode might do something +different than intended in another mode). Another thing about modes is that they require a user +action for entering and exiting. + A tool-based approach however, is very mouse-centered. It changes the behaviour of the mouse, not +of keyboard actions, and this change is visible in the cursor. Tools are of little use to the keyboard +editor. +A view-based approach is not too different from using modes, with the difference that it drastically +alters the contents of a view or panel in the user interface. It's less common and can be seen in +FCP's precision editor. It doesn't change the working of keyboard shortcuts or the mouse and it +alters the timeline via animations in a very fluid way. -Inserting material onto the timeline -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[red]#To be written.# +Final Cut Pro's precision editor +Another example is the Trim View in DaVinci Resolve: whenever you perform a trimming +operation, the program monitor displays a trim view (showing the frames left and right of the cut +next to each other). As soon as you start doing something else, it exits this trim view. It needs no +dedicated user action. +This might seem like a great approach (and can be combined with tools and/or modes), but it does +mean a user needs to reorient a bit when they exit the altered view and return to its default state. +Perhaps that's a small price to pay, when not overdone. +When we more closely examine the behaviour of NLE's, we see that things are not as black and +white as they seem. No NLE exclusively uses one method over others. Resolve's modes do in fact +also change the mouse cursor's look and behaviour and can therefore be considered a hybrid +mode/tool system. FCP's Select and Position tools also change the behaviour of trimming keys and +can therefore indeed also be considered modes, which gives us a hybrid design as well. Specialised +views can be combined with tools or modes. +To conclude: all methods have pros and cons. Tools, modes and views aren't mutually exclusive, so +I think we should use whichever method or combination of methods is appropriate for different +actions in Lumiera. Whenever we can, we should try to avoid all three and design the app to be as +consistent as possible. Whenever we use a mode, we should see if we can design it in a way in +which a user fluidly enters and exits this mode, without requiring extra actions: contextual modes. +Most mode-based NLE's already implement this for their trim mode in a way where selecting a trim +side automatically enters trim mode. However, a user does still need to explicitly exit trim mode. +Regardless of the method, immediate visual differentiation of tools/modes/views is important and +I'd like this to extend to any timeline option that can be toggled on/off. Therefore I'd like to propose +the use of a contextual bar that appears over the bottom part of the timeline whenever a contextual +mode is active. -Grouping material: sections -~~~~~~~~~~~~~~~~~~~~~~~~~~~ -I would like to propose the ability to divide a timeline into multiple sections. Each of these sections -will have a header in the ruler that can be edited, to give each section a name (similar to how -duration markers in Premiere are displayed). + Currently I'm thinking of using this bar on two or three occasions: +1. When selecting clips. It can feature: +a Group Clips button +a Cut button +a Duplicate button +a Nudge Left ‘<' button +a Nudge Right ‘>' button +a Ripple toggle +a Snap toggle +2. When trimming. It can feature: +a Trim radio button +a Slip radio button +a Slide radio button +a Trim Left ‘<' button +a Trim Right ‘>' button +a Ripple Trim toggle +3. When adding clips to the timeline. It can feature options like Insert, Overwrite, Replace, etc. +See the next subchapter: ‘Adding clips to the timeline'. +A limitation of such a bar is that it might overlap with content that a user wishes to interact with. If +this is the case, then clicking on the grid with dots will let a user drag this bar out of the way. As an +extra option I would like to suggest to use a modifier key (Ctrl?) which temporarily hides the +contextual bar. Another consideration could be to attach this bar to the bottom of the timeline and +combine it with the zoom and navigation sliders, although I feel a more central default position will +get things done quicker. -.Timeline with sections -image::{imgg}/wouter/03-sections.png[Timeline organised into a sequence of sections] +Adding clips to the timeline +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +All NLE's offer multiple ways to get your material in the timeline, and those methods fall into the +following categories: +• -The benefits of sections: +Drag and drop from either the project contents panel or directly from a file browser -* Creating a broad sense and clear overview of how a timeline is constructed. Background -colors in the timeline will make it easy to differentiate between different sections. +• -* Easy navigation between sections by keyboard shortcuts. +By creating a timeline out of selected clips in a bin -* Keeping sync. All clips in a section are encapsulated. If you work in one section, you will -not be able to throw clips in other sections out of sync. Users could also time-lock a section, -so it will stay in place regardless of other edit operations. This is especially useful when -editing on music, but will also prevent losing sync between other elements that have been -carefully lined up. Sections will not prevent anyone throwing anything out of sync within a -section, but at least not the entire timeline will be affected. +• -* The order of sections can easily be changed by clicking and dragging. This way sections can -be used to, for example, easily change the order of scenes. The free-flowing editor for -example, can construct different parts of their edit on different parts of the timeline in -different sections, and then arrange them later. +N point editing, of which the most commonly used is three point editing: you load a source +clip (or timeline) into a (source) viewer/monitor, mark an in point, out point and use one of +multiple options (by clicking their buttons, by pressing the corresponding keyboard shortcut, +or by dragging your clip from the source viewer into the program monitor onto a list of +zones), of which the most common ones are: +◦ Insert (based on playhead position) +◦ Overwrite (based on playhead position) -* Sections could have a versioning system: this would allow the user to try different cuts -within a section and to quickly change between these different versions. + ◦ Place on top (based on playhead position) +◦ Append (added to the end of the timeline) +Three point editing also works by only providing an in-point on the source clip, and marking +in and out points on the timeline. In order to choose on which tracks your clips end up, +track-based NLE's usually provide a way to route source tracks to timeline tracks via the +track header. +Some NLE's support four point editing, where speed adjustments are applied to make the +selected duration in the source clip match the selected duration in the timeline. +• -Several other characteristics of sections: +Avid features a Replace Edit option: a selected clip on the timeline can be replaced by the +contents in the source browser with a single click or keystroke. -* Clips can be excluded from being part of a section. For example: music tracks could span -the entire length of a video by not being included in any section. +All of these options make sense, but in general I find it easier to remember two options (insert and +overwrite) and easily forget any surplus options that NLE's offer. We should also try to limit the +amount of keyboard shortcuts that a user needs to memorize, so two options seems like a proper +number. In that case, I would suggest one key/function for an Insert operation. +The second key/function will be a more generic ‘Add Clip' action, which might display a pop-up in +which we can select which method to use. TAB will cycle between Overwrite, Place on Top, +Append and Replace, followed by Enter to confirm. It will remember the last used option. Double +tapping the keyboard shortcut for this action will skip the pop-up. +Having to repeatedly view a pop-up menu (or double tapping a key) might feel cumbersome, so an +alternative could be to let the ‘Add Clip' action insert a clip by default and show all different +options via the contextual bar. You can then change the behaviour after the fact, until you commit +by doing something else. In this case, adding a clip will enter and exit another contextual mode. +One last thing I would like to address is the destruction that an insert operation can cause. Usually +this can be prevented by proper track management, but you can wonder why you would ever want +an insert action to cause the following: -* When working within a section, its size will adapt to your edit operations (so its edges will -shrink or expand automatically while trimming or moving clips). - -* A new timeline will have one large section spanning its entire length. A ``split section'' -button and keyboard shortcut will create new sections. - -Things to consider: - -* How to move clips from one section to another? -* If sections can be time-locked then they will probably need to be able to overlap. +Inserting a clip with sync locks enabled for V2 might split a clip in Avid Media Composer. +In this case, if you'd like the clips on V2 to stay in sync, the overlapping clip will be split in two. If +you don't want this to happen you would have to move the overlapping clip to another track +temporarily, or move everything on V2 by hand with the same amount of frames as the duration of +the clips that's inserted. My point is, however, that while the behaviour above makes sense when +you strictly follow the logic of how such a timeline works, in real-life you would rarely want a clip +to be split only to keep sync. Therefore, I would like to propose insert operations to be nondestructive by nature. Overlapping clips on other tracks or layers will simply move in its entirety. +Another thing to consider, as I put much emphasis on grouping (or linking) clips, is that we might +want to differentiate between inserting a clip into the currently active group, or inserting it in a +newly created group. This way a clip will always end up in a group without much manual work. Navigating the timeline ~~~~~~~~~~~~~~~~~~~~~~~ @@ -431,8 +554,7 @@ Zooming in and out, by keyboard: * Every NLE has keys to zoom in and out horizontally. Some (Premiere, Resolve, Avid) support keys to expand and shrink all track heights at once (vertical zooming). - -About keyboard shortcuts +Navigating with keyboard shortcuts ~~~~~~~~~~~~~~~~~~~~~~~~ I can imagine that all of the keyboard shortcuts for navigation were invented simply to provide many options for each editor to choose what they need. This way, every editor can pick the @@ -446,8 +568,9 @@ basically Vim's way of doing it (m+0-9a-zA-Z to bind, backtick+0-9a-zA-Z to jump want to keep it as simple as having the regular ``add marker'', ``add and edit marker'' and ``go to next/previous marker'' keyboard shortcuts. -Sections will get navigation markers automatically, so a user doesn't have to create each marker -manually. Or we might want to include keyboard shortcuts for ``go to previous/next section''. +Sections (explained later in this chapter) will get navigation markers automatically, so a user doesn't +have to create each marker manually. Or we might want to include keyboard shortcuts for ``go to +previous/next section''. *Fast forward and fast rewind keys* as found in Reaper might be a helpful addition to the aforementioned keys. This would give as a quick way to skim a timeline by keyboard. While fast @@ -524,21 +647,447 @@ to be similar to the autoscroll widget. * When using the keyboard shortcut versions: a downside is having even more keyboard shortcuts that need quick access from the one hand that stays on the keyboard. +Selecting clips +Selecting a single clip happens in all NLE's by left mouse clicking. Selecting multiple clips happens +through box-select, by using left mouse and drag. Premiere and Resolve both offer ‘Selection +follows playhead', where the position of the playhead determines which clip gets selected. Then +there are keyboard shortcuts, to select the next or previous clip on a track. Final Cut Pro lets you +move the clip selection up and down by Cmd+up/down. +Selecting multiple clips by keyboard has no support that I know of in any big NLE. I would suggest +to add this though, because the alternative for keyboard selection is the famous mark in/out range. +That's a pretty arbitrary way to indicate what you'd like to extract, lift or remove, and, in all +fairness, this works great as long as your timeline has few tracks. However, once you have multiple +overlapping clips on different tracks, combinations of mark/lift/extract/insert/overwrite require +careful track selection and there are serious risks of throwing tracks out of sync. It's not very +convenient either, the moment you start creating J- or L-cuts. It's a butcher's knife that pays no +respect to any kind of clip connections. +While we should support marking in and out points (and I'd advice to copy Lightworks' mark and +park, where you only need to set a single mark and the playhead becomes the second mark) simply +because most professional editors are so used to them, we should aim to include less destructive +ways of arranging clips on the timeline. The natural element in the timeline is the clip, so I would +suggest to focus on providing proper ways to select clips and edit the positions and durations of +these clips, instead of relying on in and out marks to do the job. +I would propose to use the arrow keys for navigating clips and groups. There can be a cursor (for +example, a white dot) which we can move left, right, up, and down by using the arrow keys. +Changing the cursor from clip to clip will also move the playhead to the start of the highlighted clip +- but this is secondary. A clip-based focus instead of playhead/cut-based focus will be different from +what any other NLE does at the moment, but enabling multi-clip selection by keyboard will be a +good reason to go in this direction. + +Selection mockup: selected clips are highlighted in yellow, the cursor is a white dot. + +For selecting, we can introduce an ‘add to selection' key which adds the highlighted clip to the +current selection (apart from the convention of using Ctrl+mouse click). Selected clips can have a +differently colored box, yellow, for example. +One thing to note is that we do still need extra keyboard shortcuts to move the playhead frame by +frame, indepently from the clip selection. See the navigation subchapter for more details. +Selection will be one of the previously mentioned contextual modes. The user can always return to +their previous selection until they make a new one, by pressing the corresponding keyboard shortcut +(S). + Arranging clips ~~~~~~~~~~~~~~~ -[red]#To be written.# - -Selecting and moving clips -~~~~~~~~~~~~~~~~~~~~~~~~~~ -[red]#To be written.# - -Timeline tools vs modes -~~~~~~~~~~~~~~~~~~~~~~~ -[red]#To be written.# +Most NLE's handle the arranging of clips in a destructive way. Drop one clip over another, and the +clips underneath disappear. Move one of two clips that are connected by a transition, and the +transition disappears. While it's certainly true that experienced editors will understand the risks +involved in moving clips and will therefore avoid such destructive behaviour unless they intend for +something to be destroyed, accidents still occur and most probably someone won't notice until much +later, when undo cannot help to recover the lost work anymore. +At the same time, something as fundamental as swapping the position of two neighbouring clips is +harder than it should. Premiere has Ctrl+Alt+drag, but the results can be destructive. Resolve has a +similar modifier combination, and keyboard shortcuts for swapping left and right, but these also +easily mess up parts of your edit if you're not careful with your track selection. Avid's smart tool +has a Segment Mode that can be set to extract/splice-in, which will do a similar thing. It only has an +effect on the tracks that hold the clip selection and results can get messy when there are J- or L-cuts. +An alternative is to select a clip by mouse, use ‘ripple cut', move the playhead to the next cut, and +use ‘paste insert', but this can also be destructive when not being careful with track management. +We've talked about using in and out marks already in the previous subchapter, so I will skip that for +now. +FCP is the only widely used NLE as of now that allows non-destructively changing the order of +clips, by having other clips move out of the way: the so-called magnetic timeline. How come the +other professional NLE's make it so difficult to simply change the order of clips? The reason for +that, I can only assume, is that the software doesn't know how clips on different tracks relate to +each other. And as a result, it will be very hard to guess how to exactly change the order. FCP solves +this problem by having clips always connect to a primary storyline. Lumiera could do a similar +thing by utilising its grouping features, in combination with a Ripple-toggle in the contextual bar of +the selection mode. As long as clip relations are clear, changing the order of clips should be simple +to achieve. +Trimming clips Trimming ~~~~~~~~ -[red]#To be written.# +Trimming means extending or shortening the duration of one or more clips (simultaneously), either +from its start or end. In most applications, there are two distinct ways to trim: ripple trimming and +non-ripple trimming. Ripple trimming means that when you extend or shorten a clip, all other clips +on the same track and possibly on other tracks move along. When non-ripple trimming, all clips +stay in place, and when a clip is shortened, a gap appears. To choose a trim type, NLE's use either +tools or modes. +• + +FCP's Select tool defaults to ripple trimming, and it's Position tool does non-ripple +trimming. + +• + +In Premiere it's the other way around: the default selection tool does non-ripple trims, and +the ripple edit tool... well, it's in the name. A user doesn't have to switch tools per se: +pressing the Ctrl modifier will inverse a tool's mode of operation. + +• + +Resolve talks in terms of modes, not tools, and it has two modes related to trimming: the +default Selection Mode and Trim Edit Mode. The latter lets you ripple trim (by dragging the +edges of clips), slip (dragging inside a clip, upper half) and slide (dragging inside a clip, +lower half) - more on slip and slide edits later. + +• + +Avid has a trim mode that can be in overwrite trim or ripple trim mode, indicated by the +color of the trim sides (red or yellow). The timeline will be in either of these modes when +entering trim mode. + +• + +Lightworks has a trim mode that defaults to ripple trimming, unless you specifically use the +“drag to black” feature by Control-clicking trim edges when entering trim mode. When + + using the keyboard, one needs to mark a section and use the Remove command (similar to +Avid's ‘lift') to create a gap. +Next to ripple/non-ripple trimming there are three other edit operations closely related to trimming +that need to be mentioned: +• + +Roll edits. This is where you move a cut left or right, so that as a result, one clips gets +extended, while the other gets shortened. + +• + +Slip edits. Nothing gets extended or shortened. Instead, you shift the contents of one or more +clips on the timeline. + +• + +Slide edits. This moves a selected clip (or clip selection) left or right, thereby keeping its +own duration, while the duration of its surrounding clips gets altered. + +Some apps use their trimming system for slip and slide edits (Avid, Lightworks). Others use a +special tool or mode and/or separate keyboard shortcuts for this (FCP, Premiere, Resolve). + +Selecting trim sides +Every trim starts by selecting which sides of which clips need to be included in the trimming. How +many sides to select greatly depends on how many tracks are involved and if the NLE has a sync +lock system or not. Sync locks makes sure that when you ripple trim selected clips, clips on other +tracks automatically stay in sync. This means (manually) enabling or disabling the sync lock per +track. Once set, trimming a single clip can be enough to have all tracks move along, although you +might still need to manually select trim sides for overlapping clips to get the desired result. + +Avid's sync locks will split longer clips by default, in order to keep sync. Such destructive behaviour should be avoided +in Lumiera. + +Without sync locks you will have to select trim sides on every track that needs to stay in sync, +although, as we'll see, even that can be accomplished by a single keystroke. FCP is the exception +here: it does not use sync locks (as it has a trackless design), but keeps sync not based on tracks, but +on clip connections (this is discussed in the subchapter ‘Tracks vs Trackless'). +Let's first examine trim side selection by mouse. This is generally as simple as clicking near the +edge of a clip, or on the edge between two clips to select both sides for a roll edit. +Adding additional trim sides often works by using modifier like Ctrl + left click (Premiere, Resolve, +Lightworks, Avid). FCP does not allow the selection of multiple trim sides and therefore does not +support asymmetric trimming. Such trims are still possible, but need to be performed in two steps +rather than one. +Keyboard selection of trim sides happens in general by providing shortcuts for selecting the left (A) +side, the right (B) side, or both, of a cut (Avid, Premiere, Resolve and FCP, although the latter does +not have a shortcut for selecting both sides as it uses a dedicated Trim tool for roll edits). This + + applies to the cut nearest to the playhead. Lightworks is the only NLE with a slightly different, but +very powerful method: instead of A/B/both, it has four shortcuts: +• Trim last out +• Trim in +These two apply to all cuts on enabled tracks to the left of the playhead. +• Trim out +• Trim next in +These two apply to all cuts on enabled tracks to the right of the playhead. +These commands can be combined: when pressing multiple keys, new trim sides are added to the +selection. This allows for quickly selecting many trim sides on many tracks. + +One keystroke led to the selection of these four trim sides in Lightworks + +Another feature that was already mentioned in a previous chapter, is FCP's precision editor, which +can be triggered by double clicking a cut or by keyboard shortcut. This shows how much footage +from each clip is available for trimming and allows ripple trimming as well as roll edits to be +performed by mouse or keyboard. + +Performing the trim +Usually we see three ways to perform a trim: +1. Frame by frame. This can be done by mouse by clicking and dragging the edges of a clip, or +by keyboard by using shortcuts for left one frame, right one frame, left 10/many frames, +right 10/many frames. Instead of using keyboard shortcuts, dedicated hardware can be used +to joggle left or right to perform trimming. +2. By specifying an exact amount of frames. Pretty much every NLE supports using the plus +and minus keys on the keypad to enter exact frame numbers. Lightworks does an excellent +job at this: when not entering any amount (so just plus/minus + enter) it will repeat the last +entered amount of frames. +3. Dynamic trimming. This means starting playback of the timeline around the position of the +cut, and pressing a key to mark a point in realtime where the cut should be placed. Avid and +Lightworks have dynamic trimming support within their trim modes. Resolve has a separate +switch for this that needs to be toggled, and Premiere has a separate mode for dynamic +trimming, simply called ‘Trim Mode'. FCP does not seem to support dynamic trimming at +the time of writing. + + Previewing the cut +Most NLE's feature a Preview keyboard shortcut with user-adjustable pre-roll and post-roll +duration. Avid always does a looped preview around the cut in trim mode when triggering playback. + +Entering and exiting trim mode +Avid and Lightworks have keyboard commands to both enter and exit their trim modes. When used +for entering, Lightworks will re-enable the previous trim side selection. FCP's precision editor can +be closed with the Escape key, as can Avid's trim mode. + +Analysis and proposal +My proposal is to leverage the same system as the clip selection system to highlight a clip, and then +have three commands: +• +• +• + +Select the clip's in point as trim side +Select the clip's out point as trim side +Select the clip's in point for a roll edit + +If the latter is pressed a second time, it will take the clip's out point for a roll edit. When the first +two shortcuts are pressed once, they select the trim side for ripple trims. When pressed again, they +will switch to non-ripple trims (and back again with another press). There should be a clear visual +difference between these two (perhaps through the color of the brackets, as in Avid). +Note that this approach closely resembles Lightworks, and is different from Avid, FCP, Premiere +and Resolve. Those apps take the cut closest to the playhead as the basis for choosing a trim side. +Lightworks takes the underlying clip as its basis. Since we already have a mechanism for navigating +clips, we should probably not add another mechanism just for navigating cuts. +I propose to not make use of sync locks. They apply to entire tracks and we previously established +that clips that have no relation to each other might share a track, so it makes little sense to provide +track based operations. We should instead take the actual clip connections that the user establishes +into account. This way we also don't need to be able to select multiple trim sides at once (for +complex asymmetric trimming operations), as this can create sync problems elsewhere on a track. +Trimming itself doesn't need to be reinvented. Trimming frame by frame, by a specific amount of +frames or dynamically through playback make perfect sense and offer a full range of options, from +extremely precise to trimming on gut feeling. +Ideally trimming sides should stay active and we won't need to enter or exit a trim mode. However, +if we consider that we need the following keyboard shortcuts: +• +• +• +• + +Trim left many frames +Trim left 1 frame +Trim right 1 frame +Trim right many frames + +These same keys can't double for nudging clips, the way it does in many apps, without using modes. +Therefore my proposal is indeed to introduce a Trim mode. As said, it should be designed as a +contextual mode that we fluidly enter and exit and that is visually easy to distinguish from the +regular mode, which we can call the Position mode. Trim mode can be accentuated by marking the +part of the timeline we'll be previewing. As in Avid, in trim mode playback could always preview +the selected cut, so we won't need a special Preview (sometimes called 'Play around') shortcut. Trim +mode will be exited automatically whenever the user clicks in an empty spot of the timeline or +presses the trim mode key (T). This key can also be used to return to the last-used trim +configuration. + + Mockup of the trim mode. The striped area marks the pre- and post-roll that will be previewed. + +Splitting and merging clips +Tool-based NLE's offer a Blade or Cut tool that will cut clips wherever a user clicks. All NLE's +offer a dedicated keyboard shortcut for creating a cut at the playhead as well. +Merging two timeline clips with so-called ‘through edits' is often possible by selecting the cut for a +roll edit and pressing the delete key. A through edit is a cut made within a clip, where the start of the +second clip in the timeline matches the next frame from the source clip that corresponds to the first +timeline clip. +A Blade tool, a shortcut for Add Cut and the ability to remove through edits with backspace seem +all worth implementing. + +Removing clips +In general, we find the following options: +• + +Select a clip, then: backspace or delete key, or (ripple) cut command. + +• + +In and out points, then lift or extract. + +• + +Lightworks lets you remove a clip by dragging it outside of the timeline window. + +These operations are so common that I would not change them. + +Organising the timeline: sections +I would like to propose the ability to divide a timeline into multiple sections. Each of these sections +will have a header in the ruler that can be edited, to give each section a name (similar to how +duration markers in Premiere are displayed). + + The benefits of sections: +• + +Creating a broad sense and clear overview of how a timeline is constructed. Background +colors in the timeline will make it easy to differentiate between different sections. + +• + +Easy navigation between sections by keyboard shortcuts. + +• + +Keeping sync. All clips in a section are encapsulated. If you work in one section, you will +not be able to throw clips in other sections out of sync. Users could also time-lock a section, +so it will stay in place regardless of other edit operations. This is especially useful when +editing on music, but will also prevent losing sync between other elements that have been +carefully lined up. Sections will not prevent anyone throwing anything out of sync within a +section, but at least not the entire timeline will be affected. + +• + +The order of sections can easily be changed by clicking and dragging. This way sections can +be used to, for example, easily change the order of scenes. The free-flowing editor for +example, can construct different parts of their edit on different parts of the timeline in +different sections, and then arrange them later. + +• + +Sections could have a versioning system: this would allow the user to try different cuts +within a section and to quickly change between these different versions. + +Several other characteristics of sections: +• + +Clips can be excluded from being part of a section. For example: music tracks could span +the entire length of a video by not being included in any section. + +• + +When working within a section, its size will adapt to your edit operations (so its edges will +shrink or expand automatically while trimming or moving clips). + +• + +A new timeline will have one large section spanning its entire length. A “split section” +button and keyboard shortcut will create new sections. + +Things to consider: +• + +How to move clips from one section to another? + +• + +If sections can be time-locked then they will probably need to be able to overlap. + +Adding and editing transitions +There's usually a variety of ways to add transitions: +• + +Right clicking on a cut and choosing a transition from a context menu + +• + +Double clicking or dragging a transition from an effects or transitions panel + + • + +With keyboard shortcuts. Premiere has separate shortcuts for audio and video transitions, +others (Lightworks, Resolve) have a single transition shortcut that detects whether a video or +audio transition needs to be added. The default length can often be adjusted in the app's +settings, as well as the default transition type. Some apps have shortcuts to create a +transition from a clip's start or end to the position of the playhead. + +• + +Avid has a configuration panel for adding transitions: + +• + +Some apps allow adding transitions to every cut in the in-out range (Avid, Lightworks). Avid +gives you the option to skip cuts that already have a transition. Very useful for adding short +(2-4 frame) audio transitions to each audio clip that doesn't have a specific transition applied +already. + +• + +Most apps allow adding transitions to a selection of clips. + +• + +Blackmagic's Speed Editor lets you select different transitions through a button press and the +big dial, and lets you adjust its length through the dial as well. + +Editing transitions: +• + +Changing a transition's duration always works by dragging the transition handles in between +clips (in Avid you will need to have Transition Manipulation enabled for this to work). + +• + +Changing a transition's position sometimes works by dragging it left or right (Premiere, +Avid). + +• + +Avid lets you type in the duration underneath the viewers. + +• + +Often you can double click a transition to enter a duration. + +• + +Final Cut Pro has a right click context menu option called ‘Change Duration' (Ctrl+D) +which lets you enter the desired duration by keyboard and press enter, for video transitions. +Audio transitions are actually performed by creating fades and having these fades between +clips overlap. They can be adjusted with the fade handles and require the ‘Show Audio +Lanes' or ‘Expand Audio' options to be enabled. + +• + +Lightworks lets you trim transitions via its trim mode like any other cut. + +• + +DaVinci Resolve and Final Cut Pro have a Transition tab on their Inspector panels where +length and position of transitions can be adjusted, among other settings. + +Most of these established ways of working with transitions can be applied to Lumiera. I would like +to suggest to also add Avid's option to add transitions to a large number of cuts while skipping +existing transitions (and this should even be the default). + + One thing we do need to address is how transitions magically disappear in pretty much any NLE +except Avid and Final Cut Pro, the moment you move one of the two adjacent clips elsewhere, or +whenever you replace a clip by another. Transitions take time to setup in the right way, and they +shouldn't disappear by themselves. I would suggest to follow Avid and FCP's behaviour and leave +transitions in place by default. + +Changing timeline clip properties +Each NLE has an effect properties panel en most have a generic properties panel for changing all +basic properties of clips in the timeline, such as: +• +• +• +• +• +• + +X & Y position +scaling +orientation +rotation +opacity and blend mode +stabilization + +Avid is the only NLE out there that still requires adding an effect to change these basic clip +properties (‘3D DVE'). Quick access to such properties saves a lot of time, so enabling this is +essential. Depending on the actual effects workflow we might want basic properties to be part of an +effect that is automatically applied to each clip when it's added to the timeline. A separate Properties +panel (as in Premiere) is less ideal: the fewer panels, the better. FCP and Resolve use a tabbed +approach for their panels (which is named ‘Inspector') to keep different categories of properties +separated. Chapter 3: finishing -------------------- @@ -548,3 +1097,4 @@ Chapter 4: a broader GUI concept -------------------------------- [red]#To be written.# +Panels vs fixed layouts. Workspaces. From 6a42606c3a9518c52a6a1b847231aa7b0f621fde Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 23 Aug 2025 01:55:23 +0200 Subject: [PATCH 09/51] Workflow-publish: adapt additions to Asciidoc - add markup to match formatting from PDF - link to the images extracted into the website Git-repository - adjust image sizes to fit into the text - add some cross references (incidentally: TimelineDiscussion.txt -- store image locally) --- .../gui/GuiDiscussion/TimelineDiscussion.txt | 2 +- .../workflow/Verwijlen/WorkflowProposals.txt | 487 +++++++++--------- 2 files changed, 245 insertions(+), 244 deletions(-) diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt index 7a5d8ecd8..6c6c2a6e9 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt @@ -126,7 +126,7 @@ Joel Conclusions: Timeline like this: -image::http://www.kenstone6.net/fcp_homepage/images_fcp_5_new_martin/07_fc_studio_new_martin.jpg[] +image::{imgg}/Joel-Conclusions-UI-layout.jpg[Conclusions for the UI layout] Tracks '''''''''' diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt index fd3e8088a..213459eb9 100644 --- a/doc/design/workflow/Verwijlen/WorkflowProposals.txt +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -175,12 +175,13 @@ which different NLE's handle this and will propose possible directions for Lumie certain workflows. [red]#To be written:# -Asset organisation: bins vs metadata-based structures (+ search bins/filters) -Viewing footage: single clips vs source reels; continuous playback from browser -Source monitor + program monitor vs a single monitor -Creating selects: selects reels, subclips and keyword collections -On markers and notes -From selects to editing in the timeline: Timelines in the source viewer: reel to reel editing + +- Asset organisation: bins vs metadata-based structures (+ search bins/filters) +- Viewing footage: single clips vs source reels; continuous playback from browser +- Source monitor + program monitor vs a single monitor +- Creating selects: selects reels, subclips and keyword collections +- On markers and notes +- From selects to editing in the timeline: Timelines in the source viewer: reel to reel editing Chapter 2: the timeline ----------------------- @@ -193,17 +194,17 @@ working in the timeline which I will explore in the different subsections of thi Tracks vs trackless ~~~~~~~~~~~~~~~~~~~ In general, we can observe two extremes when it comes to editing: -• -On the one hand, there are NLE's modeled to resemble working with analog gear (i.e. +* On the one hand, there are NLE's modeled to resemble working with analog gear (i.e. classic editing stations from KEM, Steenbeck, Moviola). A lot of terminology in editing -software (‘bins', ‘reels', ‘cut', ‘mark in/out', among many others) stems from the analog -origins of editing. Lightworks is an example of this. When trimming you ‘unjoin' a cut, -make changes, and then ‘join' the cut again, as if working with analog film that needs to be +software (``bins'', ``reels'', ``cut'', ``mark in/out'', among many others) stems from the analog +origins of editing. Lightworks is an example of this. When trimming you ``unjoin'' a cut, +make changes, and then ``join'' the cut again, as if working with analog film that needs to be taped together. It works best in conjunction with the Lightworks Console, a hardware device that was designed specifically to make software editing feel as if editing analog film. Very hands-on, very tactile, according to editors who have worked with these consoles (unfortunately I haven't had a chance to try this myself). ++ Not just Lightworks, but also Avid is said to have been greatly influenced by analog equipment, and Adobe Premiere's predecessor ReelTime was created to work like 3/4" tape decks. Blackmagic's Speed Editor (and corresponding Cut Page in Resolve) has also been @@ -211,28 +212,27 @@ designed according to this principle: to make editing feel like you're operating Pressing buttons, rotating dials. This has a great feel to it, but it's less flexible than the other extreme: -• - -Editing and trimming designed to be performed by mouse. Most NLE's added this earlier or +* Editing and trimming designed to be performed by mouse. Most NLE's added this earlier or later during their development. Final Cut Pro was from its core designed to be used this way. It's fast, and in combination with the clip connections and magnetic timeline, it's the least destructive way to edit. Trimming and editing by mouse is less precise though, which is why even FCP offers many keyboard shortcuts for precise trimming by keyboard. Using a mouse feel slightly less tactile than using physical buttons and dials. ++ In this same category we can also mention touch screens (as they offer similar interactions as a mouse, with the addition of finger gestures). Editing on a smartphone or tablet, when not using a pen, feels even further removed from giving you a physical connection between your hands and the buttons on the screen. - Because of its analog roots, traditionally, NLE's have been track-based. I'd like to quote Randy +Because of its analog roots, traditionally, NLE's have been track-based. I'd like to quote Randy Ubillos, original creator of ReelTime and Final Cut Pro: ____ -"In a track based system the layers at the beginning, middle and end all share the exact same tracks +``In a track based system the layers at the beginning, middle and end all share the exact same tracks and you're always potentially disrupting things in other parts of the project when you make changes in another area. One of the most common things I heard from editors was that as a project progressed the likelihood of a change in one part of a project having an unintended effect somewhere else in the timeline went up dramatically. Tracks implicitly put a relationship between -all of the items in that track, even though they may be actually completely unrelated. " +all of the items in that track, even though they may be actually completely unrelated.'' ____ Source: https://www.linkedin.com/pulse/interview-randy-ubillos-developer-fcp-x-david-busse[Interview with Randy Ubillos] @@ -279,7 +279,7 @@ Editors often proudly share screenshots of their timelines on social media, and impressive, but these are in fact pretty fragile structures. .One of my own timelines, which is relatively simple by comparison to those of many Hollywood movies -image::{imgg}/wouter/01-timeline.jpg[Screenshot of a timeline] +image::{imgg}/wouter/01-timeline.jpg[width="110%", alt="Screenshot of a timeline", link="{imgg}/wouter/01-timeline.jpg"] So naturally, a question would be: what will happen if we would let go of the track paradigm? This is what Final Cut Pro has done, starting from the rewrite of Final Cut Pro X. At the time, a @@ -288,7 +288,7 @@ more people are starting to realise that many of its ideas were way ahead of its only big NLE out there that was designed with computers in mind, and not analog hardware. It's not entirely trackless, but it manages to hide the concept of tracks from the user. There are no -buttons to enable or disable tracks or other track controls, and instead, the tracks are called ‘layers'. +buttons to enable or disable tracks or other track controls, and instead, the tracks are called ``layers''. In a nutshell, it works by having a primary storyline (in a track-based NLE this would be V1+A1) where you build the foundation of your edit. Then the video clips you put on top and the audio clips you put below get connected to one or more clips from the primary storyline. Move a clip on the @@ -296,8 +296,12 @@ primary storyline, and all connected clips automatically move with it. With a mo ignore clip connections, so that you can also easily move a primary clip elsewhere without its connected siblings coming along. -Extending one clip will automatically move all connected clips in order to keep sync -Sounds good. Why not just copy this? One reason is that FCP assumes that all clips that are not on +image::{imgg}/wouter/02-trim-magnetic-1.jpg[width="100%", alt="(before trim)"] + +.Extending one clip will automatically move all connected clips in order to keep sync +image::{imgg}/wouter/02-trim-magnetic-2.jpg[width="100%", alt="(after trim)"] + +_Sounds good._ Why not just copy this? One reason is that FCP assumes that all clips that are not on the primary storyline should be connected to this primary storyline. This might work well for fiction films, but not necessarily for other types of video. Earlier I mentioned an example of sound effects that share a connection to b-roll on a higher layer. FCP won't allow you to connect them. Another @@ -306,11 +310,11 @@ keyboard commands to, for example, swap the position of clips (other than by cut perform slip edits (the trim keys will work, but the clip needs to be selected by mouse using the Trim tool). -How else could we group clips together that ought to be connected? We could create groups that are -directly editable, like so: +How else could we group clips together that ought to be connected? + +We could create groups that are directly editable, like so: .Compound clips -image::{imgg}/wouter/02-1-grouped.png[Timeline with compound clips] +image::{imgg}/wouter/03-grouped-1.png[width="100%", alt="Timeline with compound clips"] However, there are a few problems with this: we expect rendering to happen from top to bottom, in which case the b-roll would cover the subtitles. On top of that, it's hard to see at which points video @@ -319,76 +323,94 @@ clips overlap. Last but not least: it looks rather unorganised. Can we restructure this? Perhaps like this: .Overlapping compound clips -image::{imgg}/wouter/02-2-grouped.png[Timeline with stacked overlapping compound clips] +image::{imgg}/wouter/03-grouped-2.png[width="100%", alt="Timeline with stacked overlapping compound clips"] But how exactly would a user interact with a timeline like this? I will leave the answer to that question for an actual design document, as for now I just wanted to show the concept of grouping so that it becomes clear that alternative ways to organise the timeline might be of great value. Tools + modes + views +~~~~~~~~~~~~~~~~~~~~~ If we observe existing NLE's, we can distinguish several ways to change timeline interactions. Some use a tool-based approach (Adobe Premiere, Final Cut Pro), others a mode-based approach (Avid Media Composer, Lightworks and DaVinci Resolve), and we can also see a view-based approach (FCP's use of the precision editor, explained in more detail later). Which of these interaction methods would be preferred for Lumiera? -Using modes is somewhat controversial, as it increases cognitive load (the user needs to remember + +* Using *modes* is somewhat controversial, as it increases cognitive load (the user needs to remember which mode they're in) and can lead to user errors (an action in one mode might do something different than intended in another mode). Another thing about modes is that they require a user action for entering and exiting. - - A tool-based approach however, is very mouse-centered. It changes the behaviour of the mouse, not +* A *tool*-based approach however, is very mouse-centered. It changes the behaviour of the mouse, not of keyboard actions, and this change is visible in the cursor. Tools are of little use to the keyboard editor. -A view-based approach is not too different from using modes, with the difference that it drastically +* A *view*-based approach is not too different from using modes, with the difference that it drastically alters the contents of a view or panel in the user interface. It's less common and can be seen in FCP's precision editor. It doesn't change the working of keyboard shortcuts or the mouse and it alters the timeline via animations in a very fluid way. -Final Cut Pro's precision editor +.Final Cut Pro's precision editor +image::{imgg}/wouter/04-fcp-precision-editor.jpg[precision editor] Another example is the Trim View in DaVinci Resolve: whenever you perform a trimming operation, the program monitor displays a trim view (showing the frames left and right of the cut next to each other). As soon as you start doing something else, it exits this trim view. It needs no dedicated user action. + This might seem like a great approach (and can be combined with tools and/or modes), but it does mean a user needs to reorient a bit when they exit the altered view and return to its default state. Perhaps that's a small price to pay, when not overdone. + When we more closely examine the behaviour of NLE's, we see that things are not as black and white as they seem. No NLE exclusively uses one method over others. Resolve's modes do in fact also change the mouse cursor's look and behaviour and can therefore be considered a hybrid mode/tool system. FCP's Select and Position tools also change the behaviour of trimming keys and can therefore indeed also be considered modes, which gives us a hybrid design as well. Specialised views can be combined with tools or modes. + To conclude: all methods have pros and cons. Tools, modes and views aren't mutually exclusive, so I think we should use whichever method or combination of methods is appropriate for different actions in Lumiera. Whenever we can, we should try to avoid all three and design the app to be as consistent as possible. Whenever we use a mode, we should see if we can design it in a way in -which a user fluidly enters and exits this mode, without requiring extra actions: contextual modes. +which a user fluidly enters and exits this mode, without requiring extra actions: _contextual modes._ Most mode-based NLE's already implement this for their trim mode in a way where selecting a trim side automatically enters trim mode. However, a user does still need to explicitly exit trim mode. + Regardless of the method, immediate visual differentiation of tools/modes/views is important and I'd like this to extend to any timeline option that can be toggled on/off. Therefore I'd like to propose -the use of a contextual bar that appears over the bottom part of the timeline whenever a contextual +the use of a _contextual bar_ that appears over the bottom part of the timeline whenever a contextual mode is active. - Currently I'm thinking of using this bar on two or three occasions: +.Contextual bar with options for the mode/tool +image::{imgg}/wouter/05-contextual-bar.png[width="100%", alt="contextual bar"] + +Currently I'm thinking of using this bar on two or three occasions: + 1. When selecting clips. It can feature: -a Group Clips button -a Cut button -a Duplicate button -a Nudge Left ‘<' button -a Nudge Right ‘>' button -a Ripple toggle -a Snap toggle + + * a Group Clips button + * a Cut button + * a Duplicate button + * a Nudge Left '<' button + * a Nudge Right '>' button + * a Ripple toggle + * a Snap toggle + 2. When trimming. It can feature: -a Trim radio button -a Slip radio button -a Slide radio button -a Trim Left ‘<' button -a Trim Right ‘>' button -a Ripple Trim toggle -3. When adding clips to the timeline. It can feature options like Insert, Overwrite, Replace, etc. -See the next subchapter: ‘Adding clips to the timeline'. + + * a Trim radio button + * a Slip radio button + * a Slide radio button + * a Trim Left '<' button + * a Trim Right '>' button + * a Ripple Trim toggle + +3. When adding clips to the timeline. + + + It can feature options like Insert, Overwrite, Replace, etc. + + + -> See the next subchapter: »Adding clips to the timeline«. + A limitation of such a bar is that it might overlap with content that a user wishes to interact with. If this is the case, then clicking on the grid with dots will let a user drag this bar out of the way. As an extra option I would like to suggest to use a modifier key (Ctrl?) which temporarily hides the @@ -396,70 +418,74 @@ contextual bar. Another consideration could be to attach this bar to the bottom combine it with the zoom and navigation sliders, although I feel a more central default position will get things done quicker. + Adding clips to the timeline ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All NLE's offer multiple ways to get your material in the timeline, and those methods fall into the following categories: -• -Drag and drop from either the project contents panel or directly from a file browser - -• - -By creating a timeline out of selected clips in a bin - -• - -N point editing, of which the most commonly used is three point editing: you load a source +* Drag and drop from either the project contents panel or directly from a file browser +* By creating a timeline out of selected clips in a bin +* N point editing, of which the most commonly used is three point editing: you load a source clip (or timeline) into a (source) viewer/monitor, mark an in point, out point and use one of multiple options (by clicking their buttons, by pressing the corresponding keyboard shortcut, or by dragging your clip from the source viewer into the program monitor onto a list of zones), of which the most common ones are: -◦ Insert (based on playhead position) -◦ Overwrite (based on playhead position) - - ◦ Place on top (based on playhead position) -◦ Append (added to the end of the timeline) ++ +** Insert (based on playhead position) +** Overwrite (based on playhead position) +** Place on top (based on playhead position) +** Append (added to the end of the timeline) ++ Three point editing also works by only providing an in-point on the source clip, and marking in and out points on the timeline. In order to choose on which tracks your clips end up, track-based NLE's usually provide a way to route source tracks to timeline tracks via the track header. ++ Some NLE's support four point editing, where speed adjustments are applied to make the selected duration in the source clip match the selected duration in the timeline. -• -Avid features a Replace Edit option: a selected clip on the timeline can be replaced by the +* Avid features a Replace Edit option: a selected clip on the timeline can be replaced by the contents in the source browser with a single click or keystroke. All of these options make sense, but in general I find it easier to remember two options (insert and overwrite) and easily forget any surplus options that NLE's offer. We should also try to limit the amount of keyboard shortcuts that a user needs to memorize, so two options seems like a proper number. In that case, I would suggest one key/function for an Insert operation. -The second key/function will be a more generic ‘Add Clip' action, which might display a pop-up in + +The second key/function will be a more generic ``Add Clip'' action, which might display a pop-up in which we can select which method to use. TAB will cycle between Overwrite, Place on Top, Append and Replace, followed by Enter to confirm. It will remember the last used option. Double tapping the keyboard shortcut for this action will skip the pop-up. + Having to repeatedly view a pop-up menu (or double tapping a key) might feel cumbersome, so an -alternative could be to let the ‘Add Clip' action insert a clip by default and show all different +alternative could be to let the ``Add Clip'' action insert a clip by default and show all different options via the contextual bar. You can then change the behaviour after the fact, until you commit by doing something else. In this case, adding a clip will enter and exit another contextual mode. + One last thing I would like to address is the destruction that an insert operation can cause. Usually this can be prevented by proper track management, but you can wonder why you would ever want an insert action to cause the following: -Inserting a clip with sync locks enabled for V2 might split a clip in Avid Media Composer. +image::{imgg}/wouter/06-sync-insert-1.png[height=110, alt="sync insert"] -In this case, if you'd like the clips on V2 to stay in sync, the overlapping clip will be split in two. If -you don't want this to happen you would have to move the overlapping clip to another track +.Inserting a clip with sync locks enabled for V2 might split a clip in Avid Media Composer. +image::{imgg}/wouter/06-sync-insert-2.png[height=110, alt="sync insert"] + +In this case, if you'd like the clips on V2 to stay in sync, the overlapping clip will be split in two. +If you don't want this to happen you would have to move the overlapping clip to another track temporarily, or move everything on V2 by hand with the same amount of frames as the duration of the clips that's inserted. My point is, however, that while the behaviour above makes sense when you strictly follow the logic of how such a timeline works, in real-life you would rarely want a clip -to be split only to keep sync. Therefore, I would like to propose insert operations to be nondestructive by nature. Overlapping clips on other tracks or layers will simply move in its entirety. +to be split only to keep sync. Therefore, I would like to propose insert operations to be nondestructive +by nature. Overlapping clips on other tracks or layers will simply move in its entirety. + Another thing to consider, as I put much emphasis on grouping (or linking) clips, is that we might want to differentiate between inserting a clip into the currently active group, or inserting it in a newly created group. This way a clip will always end up in a group without much manual work. + Navigating the timeline ~~~~~~~~~~~~~~~~~~~~~~~ Quick timeline navigation is key in editing. Let's start by examining how other NLE's deal with @@ -554,8 +580,9 @@ Zooming in and out, by keyboard: * Every NLE has keys to zoom in and out horizontally. Some (Premiere, Resolve, Avid) support keys to expand and shrink all track heights at once (vertical zooming). + Navigating with keyboard shortcuts -~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I can imagine that all of the keyboard shortcuts for navigation were invented simply to provide many options for each editor to choose what they need. This way, every editor can pick the shortcuts that best fit their workflow. @@ -568,9 +595,9 @@ basically Vim's way of doing it (m+0-9a-zA-Z to bind, backtick+0-9a-zA-Z to jump want to keep it as simple as having the regular ``add marker'', ``add and edit marker'' and ``go to next/previous marker'' keyboard shortcuts. -Sections (explained later in this chapter) will get navigation markers automatically, so a user doesn't -have to create each marker manually. Or we might want to include keyboard shortcuts for ``go to -previous/next section''. +Sections (explained xref:_organising_the_timeline_sections[later in this chapter]) +will get navigation markers automatically, so a user doesn't have to create each marker manually. +Or we might want to include keyboard shortcuts for ``go to previous/next section''. *Fast forward and fast rewind keys* as found in Reaper might be a helpful addition to the aforementioned keys. This would give as a quick way to skim a timeline by keyboard. While fast @@ -595,7 +622,7 @@ will move both the viewport and playhead. Clicking the left mouse button will ac position and close the widget. + .Skim widget -image::{imgg}/wouter/04-1-skim.png[A skim widget rendered as overlay] +image::{imgg}/wouter/07-1-skim.png[width="100%", alt="A skim widget rendered as overlay"] Autoscroll widget:: when the user moves the mouse cursor slightly left or right, it will enter zones @@ -604,13 +631,13 @@ When the user moves the mouse farther away from the initial starting point, the increase. This will also work vertically. The playhead will move along as well. + .Autoscroll widget -image::{imgg}/wouter/04-2-autoscroll.png[A widget for auto-scrolling] +image::{imgg}/wouter/07-2-autoscroll.png[width="100%", alt="A widget for auto-scrolling"] Zoom widget:: moving the mouse left or right from the center will zoom horizontally, up and down will zoom vertically. + .Zoom widget -image::{imgg}/wouter/04-3-zoom.png[An overlay widget to control zooming] +image::{imgg}/wouter/07-3-zoom.png[width="100%", alt="An overlay widget to control zooming"] Mouse-only navigation: @@ -620,7 +647,7 @@ mouse button. When released, it will commit to the new location/view. If a user immediately releases the button, a regular context menu will appear. + .Combined skim, zoom and scroll widget -image::{imgg}/wouter/04-4-combined.png[Overlay widget to combin skim, zoom and autoscrol function] +image::{imgg}/wouter/07-4-combined.png[width="100%", alt="Overlay widget to combin skim, zoom and autoscrol function"] Why popup widgets? @@ -647,12 +674,15 @@ to be similar to the autoscroll widget. * When using the keyboard shortcut versions: a downside is having even more keyboard shortcuts that need quick access from the one hand that stays on the keyboard. + Selecting clips +~~~~~~~~~~~~~~~ Selecting a single clip happens in all NLE's by left mouse clicking. Selecting multiple clips happens -through box-select, by using left mouse and drag. Premiere and Resolve both offer ‘Selection -follows playhead', where the position of the playhead determines which clip gets selected. Then +through box-select, by using left mouse and drag. Premiere and Resolve both offer ``Selection +follows playhead'', where the position of the playhead determines which clip gets selected. Then there are keyboard shortcuts, to select the next or previous clip on a track. Final Cut Pro lets you move the clip selection up and down by Cmd+up/down. + Selecting multiple clips by keyboard has no support that I know of in any big NLE. I would suggest to add this though, because the alternative for keyboard selection is the famous mark in/out range. That's a pretty arbitrary way to indicate what you'd like to extract, lift or remove, and, in all @@ -661,12 +691,14 @@ overlapping clips on different tracks, combinations of mark/lift/extract/insert/ careful track selection and there are serious risks of throwing tracks out of sync. It's not very convenient either, the moment you start creating J- or L-cuts. It's a butcher's knife that pays no respect to any kind of clip connections. -While we should support marking in and out points (and I'd advice to copy Lightworks' mark and -park, where you only need to set a single mark and the playhead becomes the second mark) simply + +While we should support marking in and out points (and I'd advice to copy Lightworks' _mark and +park,_ where you only need to set a single mark and the playhead becomes the second mark) simply because most professional editors are so used to them, we should aim to include less destructive ways of arranging clips on the timeline. The natural element in the timeline is the clip, so I would suggest to focus on providing proper ways to select clips and edit the positions and durations of these clips, instead of relying on in and out marks to do the job. + I would propose to use the arrow keys for navigating clips and groups. There can be a cursor (for example, a white dot) which we can move left, right, up, and down by using the arrow keys. Changing the cursor from clip to clip will also move the playhead to the start of the highlighted clip @@ -674,17 +706,20 @@ Changing the cursor from clip to clip will also move the playhead to the start o what any other NLE does at the moment, but enabling multi-clip selection by keyboard will be a good reason to go in this direction. -Selection mockup: selected clips are highlighted in yellow, the cursor is a white dot. +.Selection mockup: selected clips are highlighted in yellow, the cursor is a white dot. +image::{imgg}/wouter/08-selection.png[width="100%", alt="selecting clips"] -For selecting, we can introduce an ‘add to selection' key which adds the highlighted clip to the +For selecting, we can introduce an ``add to selection'' key which adds the highlighted clip to the current selection (apart from the convention of using Ctrl+mouse click). Selected clips can have a differently colored box, yellow, for example. + One thing to note is that we do still need extra keyboard shortcuts to move the playhead frame by frame, indepently from the clip selection. See the navigation subchapter for more details. -Selection will be one of the previously mentioned contextual modes. The user can always return to +Selection will be one of the previously mentioned _contextual modes._ The user can always return to their previous selection until they make a new one, by pressing the corresponding keyboard shortcut (S). + Arranging clips ~~~~~~~~~~~~~~~ Most NLE's handle the arranging of clips in a destructive way. Drop one clip over another, and the @@ -693,18 +728,22 @@ transition disappears. While it's certainly true that experienced editors will u involved in moving clips and will therefore avoid such destructive behaviour unless they intend for something to be destroyed, accidents still occur and most probably someone won't notice until much later, when undo cannot help to recover the lost work anymore. + At the same time, something as fundamental as swapping the position of two neighbouring clips is harder than it should. Premiere has Ctrl+Alt+drag, but the results can be destructive. Resolve has a similar modifier combination, and keyboard shortcuts for swapping left and right, but these also easily mess up parts of your edit if you're not careful with your track selection. Avid's smart tool has a Segment Mode that can be set to extract/splice-in, which will do a similar thing. It only has an effect on the tracks that hold the clip selection and results can get messy when there are J- or L-cuts. -An alternative is to select a clip by mouse, use ‘ripple cut', move the playhead to the next cut, and -use ‘paste insert', but this can also be destructive when not being careful with track management. +An alternative is to select a clip by mouse, use ``ripple cut'', move the playhead to the next cut, and +use ``paste insert'', but this can also be destructive when not being careful with track management. + We've talked about using in and out marks already in the previous subchapter, so I will skip that for now. + FCP is the only widely used NLE as of now that allows non-destructively changing the order of -clips, by having other clips move out of the way: the so-called magnetic timeline. How come the +clips, by having other clips move out of the way: the so-called _magnetic timeline_ +(see xref:_tracks_vs_trackless[above]). How come the other professional NLE's make it so difficult to simply change the order of clips? The reason for that, I can only assume, is that the software doesn't know how clips on different tracks relate to each other. And as a result, it will be very hard to guess how to exactly change the order. FCP solves @@ -713,67 +752,55 @@ thing by utilising its grouping features, in combination with a Ripple-toggle in the selection mode. As long as clip relations are clear, changing the order of clips should be simple to achieve. + Trimming clips -Trimming -~~~~~~~~ +~~~~~~~~~~~~~~ Trimming means extending or shortening the duration of one or more clips (simultaneously), either from its start or end. In most applications, there are two distinct ways to trim: ripple trimming and non-ripple trimming. Ripple trimming means that when you extend or shorten a clip, all other clips on the same track and possibly on other tracks move along. When non-ripple trimming, all clips stay in place, and when a clip is shortened, a gap appears. To choose a trim type, NLE's use either tools or modes. -• -FCP's Select tool defaults to ripple trimming, and it's Position tool does non-ripple +* FCP's Select tool defaults to ripple trimming, and it's Position tool does non-ripple trimming. -• - -In Premiere it's the other way around: the default selection tool does non-ripple trims, and +* In Premiere it's the other way around: the default selection tool does non-ripple trims, and the ripple edit tool... well, it's in the name. A user doesn't have to switch tools per se: pressing the Ctrl modifier will inverse a tool's mode of operation. -• - -Resolve talks in terms of modes, not tools, and it has two modes related to trimming: the +* Resolve talks in terms of modes, not tools, and it has two modes related to trimming: the default Selection Mode and Trim Edit Mode. The latter lets you ripple trim (by dragging the edges of clips), slip (dragging inside a clip, upper half) and slide (dragging inside a clip, lower half) - more on slip and slide edits later. -• - -Avid has a trim mode that can be in overwrite trim or ripple trim mode, indicated by the +* Avid has a trim mode that can be in overwrite trim or ripple trim mode, indicated by the color of the trim sides (red or yellow). The timeline will be in either of these modes when entering trim mode. -• - -Lightworks has a trim mode that defaults to ripple trimming, unless you specifically use the +* Lightworks has a trim mode that defaults to ripple trimming, unless you specifically use the “drag to black” feature by Control-clicking trim edges when entering trim mode. When +using the keyboard, one needs to mark a section and use the Remove command (similar to +Avid''s ``lift'') to create a gap. - using the keyboard, one needs to mark a section and use the Remove command (similar to -Avid's ‘lift') to create a gap. Next to ripple/non-ripple trimming there are three other edit operations closely related to trimming that need to be mentioned: -• -Roll edits. This is where you move a cut left or right, so that as a result, one clips gets +* Roll edits. This is where you move a cut left or right, so that as a result, one clips gets extended, while the other gets shortened. -• - -Slip edits. Nothing gets extended or shortened. Instead, you shift the contents of one or more +* Slip edits. Nothing gets extended or shortened. Instead, you shift the contents of one or more clips on the timeline. -• - -Slide edits. This moves a selected clip (or clip selection) left or right, thereby keeping its +* Slide edits. This moves a selected clip (or clip selection) left or right, thereby keeping its own duration, while the duration of its surrounding clips gets altered. Some apps use their trimming system for slip and slide edits (Avid, Lightworks). Others use a special tool or mode and/or separate keyboard shortcuts for this (FCP, Premiere, Resolve). + Selecting trim sides +^^^^^^^^^^^^^^^^^^^^ Every trim starts by selecting which sides of which clips need to be included in the trimming. How many sides to select greatly depends on how many tracks are involved and if the NLE has a sync lock system or not. Sync locks makes sure that when you ripple trim selected clips, clips on other @@ -781,46 +808,58 @@ tracks automatically stay in sync. This means (manually) enabling or disabling t track. Once set, trimming a single clip can be enough to have all tracks move along, although you might still need to manually select trim sides for overlapping clips to get the desired result. -Avid's sync locks will split longer clips by default, in order to keep sync. Such destructive behaviour should be avoided -in Lumiera. +image::{imgg}/wouter/09-sync-trim-1.png[height=140, alt="trimming with sync-lock(before)"] + +.Avid's sync locks will split longer clips by default, in order to keep sync. Such destructive behaviour should be avoided in Lumiera. +image::{imgg}/wouter/09-sync-trim-2.png[height=140, alt="trimming with sync-lock(after)"] Without sync locks you will have to select trim sides on every track that needs to stay in sync, although, as we'll see, even that can be accomplished by a single keystroke. FCP is the exception here: it does not use sync locks (as it has a trackless design), but keeps sync not based on tracks, but -on clip connections (this is discussed in the subchapter ‘Tracks vs Trackless'). +on clip connections (this is discussed in the subchapter ``Tracks vs Trackless''). + Let's first examine trim side selection by mouse. This is generally as simple as clicking near the edge of a clip, or on the edge between two clips to select both sides for a roll edit. + Adding additional trim sides often works by using modifier like Ctrl + left click (Premiere, Resolve, Lightworks, Avid). FCP does not allow the selection of multiple trim sides and therefore does not -support asymmetric trimming. Such trims are still possible, but need to be performed in two steps +support _asymmetric trimming._ Such trims are still possible, but need to be performed in two steps rather than one. + Keyboard selection of trim sides happens in general by providing shortcuts for selecting the left (A) side, the right (B) side, or both, of a cut (Avid, Premiere, Resolve and FCP, although the latter does not have a shortcut for selecting both sides as it uses a dedicated Trim tool for roll edits). This - - applies to the cut nearest to the playhead. Lightworks is the only NLE with a slightly different, but +applies to the cut nearest to the playhead. Lightworks is the only NLE with a slightly different, but very powerful method: instead of A/B/both, it has four shortcuts: -• Trim last out -• Trim in + +* Trim last out +* Trim in + These two apply to all cuts on enabled tracks to the left of the playhead. -• Trim out -• Trim next in + +* Trim out +* Trim next in + These two apply to all cuts on enabled tracks to the right of the playhead. These commands can be combined: when pressing multiple keys, new trim sides are added to the selection. This allows for quickly selecting many trim sides on many tracks. -One keystroke led to the selection of these four trim sides in Lightworks +.One keystroke led to the selection of these four trim sides in Lightworks +image::{imgg}/wouter/10-trim-side.png["select trim side"] Another feature that was already mentioned in a previous chapter, is FCP's precision editor, which can be triggered by double clicking a cut or by keyboard shortcut. This shows how much footage from each clip is available for trimming and allows ripple trimming as well as roll edits to be performed by mouse or keyboard. + Performing the trim +^^^^^^^^^^^^^^^^^^^ Usually we see three ways to perform a trim: + 1. Frame by frame. This can be done by mouse by clicking and dragging the edges of a clip, or -by keyboard by using shortcuts for left one frame, right one frame, left 10/many frames, -right 10/many frames. Instead of using keyboard shortcuts, dedicated hardware can be used +by keyboard by using shortcuts for ``left one frame'', ``right one frame'', ``left 10/many frames'', +``right 10/many frames''. Instead of using keyboard shortcuts, dedicated hardware can be used to joggle left or right to perform trimming. 2. By specifying an exact amount of frames. Pretty much every NLE supports using the plus and minus keys on the keypad to enter exact frame numbers. Lightworks does an excellent @@ -830,263 +869,224 @@ entered amount of frames. cut, and pressing a key to mark a point in realtime where the cut should be placed. Avid and Lightworks have dynamic trimming support within their trim modes. Resolve has a separate switch for this that needs to be toggled, and Premiere has a separate mode for dynamic -trimming, simply called ‘Trim Mode'. FCP does not seem to support dynamic trimming at +trimming, simply called ``Trim Mode''. FCP does not seem to support dynamic trimming at the time of writing. - Previewing the cut + +Previewing the cut +^^^^^^^^^^^^^^^^^^ Most NLE's feature a Preview keyboard shortcut with user-adjustable pre-roll and post-roll duration. Avid always does a looped preview around the cut in trim mode when triggering playback. Entering and exiting trim mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Avid and Lightworks have keyboard commands to both enter and exit their trim modes. When used for entering, Lightworks will re-enable the previous trim side selection. FCP's precision editor can be closed with the Escape key, as can Avid's trim mode. + Analysis and proposal +^^^^^^^^^^^^^^^^^^^^^ My proposal is to leverage the same system as the clip selection system to highlight a clip, and then have three commands: -• -• -• -Select the clip's in point as trim side -Select the clip's out point as trim side -Select the clip's in point for a roll edit +* Select the clip's in point as trim side +* Select the clip's out point as trim side +* Select the clip's in point for a roll edit If the latter is pressed a second time, it will take the clip's out point for a roll edit. When the first two shortcuts are pressed once, they select the trim side for ripple trims. When pressed again, they will switch to non-ripple trims (and back again with another press). There should be a clear visual difference between these two (perhaps through the color of the brackets, as in Avid). + Note that this approach closely resembles Lightworks, and is different from Avid, FCP, Premiere and Resolve. Those apps take the cut closest to the playhead as the basis for choosing a trim side. Lightworks takes the underlying clip as its basis. Since we already have a mechanism for navigating clips, we should probably not add another mechanism just for navigating cuts. + I propose to not make use of sync locks. They apply to entire tracks and we previously established that clips that have no relation to each other might share a track, so it makes little sense to provide track based operations. We should instead take the actual clip connections that the user establishes into account. This way we also don't need to be able to select multiple trim sides at once (for complex asymmetric trimming operations), as this can create sync problems elsewhere on a track. + Trimming itself doesn't need to be reinvented. Trimming frame by frame, by a specific amount of frames or dynamically through playback make perfect sense and offer a full range of options, from extremely precise to trimming on gut feeling. Ideally trimming sides should stay active and we won't need to enter or exit a trim mode. However, -if we consider that we need the following keyboard shortcuts: -• -• -• -• +we should consider that we need the following keyboard shortcuts: -Trim left many frames -Trim left 1 frame -Trim right 1 frame -Trim right many frames +* Trim left many frames +* Trim left 1 frame +* Trim right 1 frame +* Trim right many frames These same keys can't double for nudging clips, the way it does in many apps, without using modes. Therefore my proposal is indeed to introduce a Trim mode. As said, it should be designed as a contextual mode that we fluidly enter and exit and that is visually easy to distinguish from the regular mode, which we can call the Position mode. Trim mode can be accentuated by marking the part of the timeline we'll be previewing. As in Avid, in trim mode playback could always preview -the selected cut, so we won't need a special Preview (sometimes called 'Play around') shortcut. Trim +the selected cut, so we won't need a special Preview (sometimes called ``Play around'') shortcut. Trim mode will be exited automatically whenever the user clicks in an empty spot of the timeline or presses the trim mode key (T). This key can also be used to return to the last-used trim configuration. - Mockup of the trim mode. The striped area marks the pre- and post-roll that will be previewed. +.Mockup of the trim mode. The striped area marks the pre- and post-roll that will be previewed. +image::{imgg}/wouter/11-trim-mode.png[width="100%", alt="using trim mode"] + Splitting and merging clips +~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tool-based NLE's offer a Blade or Cut tool that will cut clips wherever a user clicks. All NLE's offer a dedicated keyboard shortcut for creating a cut at the playhead as well. -Merging two timeline clips with so-called ‘through edits' is often possible by selecting the cut for a + +Merging two timeline clips with so-called ``through edits'' is often possible by selecting the cut for a roll edit and pressing the delete key. A through edit is a cut made within a clip, where the start of the second clip in the timeline matches the next frame from the source clip that corresponds to the first timeline clip. + A Blade tool, a shortcut for Add Cut and the ability to remove through edits with backspace seem all worth implementing. + Removing clips +~~~~~~~~~~~~~~ In general, we find the following options: -• -Select a clip, then: backspace or delete key, or (ripple) cut command. - -• - -In and out points, then lift or extract. - -• - -Lightworks lets you remove a clip by dragging it outside of the timeline window. +* Select a clip, then: backspace or delete key, or (ripple) cut command. +* In and out points, then lift or extract. +* Lightworks lets you remove a clip by dragging it outside of the timeline window. These operations are so common that I would not change them. + Organising the timeline: sections +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I would like to propose the ability to divide a timeline into multiple sections. Each of these sections will have a header in the ruler that can be edited, to give each section a name (similar to how duration markers in Premiere are displayed). - The benefits of sections: -• +image::{imgg}/wouter/12-sections.png[width="100%", alt="Timeline with sections"] -Creating a broad sense and clear overview of how a timeline is constructed. Background +The benefits of sections: + +* Creating a broad sense and clear overview of how a timeline is constructed. Background colors in the timeline will make it easy to differentiate between different sections. -• +* Easy navigation between sections by keyboard shortcuts. -Easy navigation between sections by keyboard shortcuts. - -• - -Keeping sync. All clips in a section are encapsulated. If you work in one section, you will +* Keeping sync. All clips in a section are encapsulated. If you work in one section, you will not be able to throw clips in other sections out of sync. Users could also time-lock a section, so it will stay in place regardless of other edit operations. This is especially useful when editing on music, but will also prevent losing sync between other elements that have been carefully lined up. Sections will not prevent anyone throwing anything out of sync within a section, but at least not the entire timeline will be affected. -• - -The order of sections can easily be changed by clicking and dragging. This way sections can +* The order of sections can easily be changed by clicking and dragging. This way sections can be used to, for example, easily change the order of scenes. The free-flowing editor for example, can construct different parts of their edit on different parts of the timeline in different sections, and then arrange them later. -• - -Sections could have a versioning system: this would allow the user to try different cuts +* Sections could have a versioning system: this would allow the user to try different cuts within a section and to quickly change between these different versions. Several other characteristics of sections: -• -Clips can be excluded from being part of a section. For example: music tracks could span +* Clips can be excluded from being part of a section. For example: music tracks could span the entire length of a video by not being included in any section. -• - -When working within a section, its size will adapt to your edit operations (so its edges will +* When working within a section, its size will adapt to your edit operations (so its edges will shrink or expand automatically while trimming or moving clips). -• - -A new timeline will have one large section spanning its entire length. A “split section” +* A new timeline will have one large section spanning its entire length. A “split section” button and keyboard shortcut will create new sections. Things to consider: -• -How to move clips from one section to another? +* How to move clips from one section to another? +* If sections can be time-locked then they will probably need to be able to overlap. -• - -If sections can be time-locked then they will probably need to be able to overlap. Adding and editing transitions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There's usually a variety of ways to add transitions: -• -Right clicking on a cut and choosing a transition from a context menu +* Right clicking on a cut and choosing a transition from a context menu -• +* Double clicking or dragging a transition from an effects or transitions panel -Double clicking or dragging a transition from an effects or transitions panel - - • - -With keyboard shortcuts. Premiere has separate shortcuts for audio and video transitions, +* With keyboard shortcuts. Premiere has separate shortcuts for audio and video transitions, others (Lightworks, Resolve) have a single transition shortcut that detects whether a video or audio transition needs to be added. The default length can often be adjusted in the app's settings, as well as the default transition type. Some apps have shortcuts to create a transition from a clip's start or end to the position of the playhead. -• +* Avid has a configuration panel for adding transitions: -Avid has a configuration panel for adding transitions: +image::{imgg}/wouter/13-transition.png[align="center", alt="transition properties"] -• - -Some apps allow adding transitions to every cut in the in-out range (Avid, Lightworks). Avid +* Some apps allow adding transitions to every cut in the in-out range (Avid, Lightworks). Avid gives you the option to skip cuts that already have a transition. Very useful for adding short (2-4 frame) audio transitions to each audio clip that doesn't have a specific transition applied already. -• +* Most apps allow adding transitions to a selection of clips. -Most apps allow adding transitions to a selection of clips. - -• - -Blackmagic's Speed Editor lets you select different transitions through a button press and the +* Blackmagic's Speed Editor lets you select different transitions through a button press and the big dial, and lets you adjust its length through the dial as well. Editing transitions: -• -Changing a transition's duration always works by dragging the transition handles in between +* Changing a transition's duration always works by dragging the transition handles in between clips (in Avid you will need to have Transition Manipulation enabled for this to work). -• - -Changing a transition's position sometimes works by dragging it left or right (Premiere, +* Changing a transition's position sometimes works by dragging it left or right (Premiere, Avid). -• +* Avid lets you type in the duration underneath the viewers. -Avid lets you type in the duration underneath the viewers. +* Often you can double click a transition to enter a duration. -• - -Often you can double click a transition to enter a duration. - -• - -Final Cut Pro has a right click context menu option called ‘Change Duration' (Ctrl+D) +* Final Cut Pro has a right click context menu option called ``Change Duration'' (Ctrl+D) which lets you enter the desired duration by keyboard and press enter, for video transitions. Audio transitions are actually performed by creating fades and having these fades between -clips overlap. They can be adjusted with the fade handles and require the ‘Show Audio -Lanes' or ‘Expand Audio' options to be enabled. +clips overlap. They can be adjusted with the fade handles and require the ``Show Audio +Lanes'' or ``Expand Audio'' options to be enabled. -• +* Lightworks lets you trim transitions via its trim mode like any other cut. -Lightworks lets you trim transitions via its trim mode like any other cut. - -• - -DaVinci Resolve and Final Cut Pro have a Transition tab on their Inspector panels where +* DaVinci Resolve and Final Cut Pro have a Transition tab on their Inspector panels where length and position of transitions can be adjusted, among other settings. Most of these established ways of working with transitions can be applied to Lumiera. I would like to suggest to also add Avid's option to add transitions to a large number of cuts while skipping existing transitions (and this should even be the default). - One thing we do need to address is how transitions magically disappear in pretty much any NLE +One thing we do need to address is how transitions magically disappear in pretty much any NLE except Avid and Final Cut Pro, the moment you move one of the two adjacent clips elsewhere, or whenever you replace a clip by another. Transitions take time to setup in the right way, and they shouldn't disappear by themselves. I would suggest to follow Avid and FCP's behaviour and leave transitions in place by default. + Changing timeline clip properties +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each NLE has an effect properties panel en most have a generic properties panel for changing all basic properties of clips in the timeline, such as: -• -• -• -• -• -• -X & Y position -scaling -orientation -rotation -opacity and blend mode -stabilization +* X & Y position +* scaling +* orientation +* rotation +* opacity and blend mode +* stabilization Avid is the only NLE out there that still requires adding an effect to change these basic clip -properties (‘3D DVE'). Quick access to such properties saves a lot of time, so enabling this is +properties (``3D DVE''). Quick access to such properties saves a lot of time, so enabling this is essential. Depending on the actual effects workflow we might want basic properties to be part of an effect that is automatically applied to each clip when it's added to the timeline. A separate Properties panel (as in Premiere) is less ideal: the fewer panels, the better. FCP and Resolve use a tabbed -approach for their panels (which is named ‘Inspector') to keep different categories of properties +approach for their panels (which is named ``Inspector'') to keep different categories of properties separated. Chapter 3: finishing @@ -1097,4 +1097,5 @@ Chapter 4: a broader GUI concept -------------------------------- [red]#To be written.# -Panels vs fixed layouts. Workspaces. +- Panels vs fixed layouts. +- Workspaces. From 4eb24220c929aefb632375a0a34d9a59833bcfba Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 23 Aug 2025 03:27:34 +0200 Subject: [PATCH 10/51] DOC: FrOSCon meeting -- minor fixes and cross-links --- doc/design/workflow/Verwijlen/FrosconMeeting.txt | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index 67e95cafe..d8af27fb5 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -12,15 +12,16 @@ Present:: End goal:: To produce a design document. -This Meeting is based on the document link:TODO[»Lumiera Workflow Proposals«] by Wouter Verwijlen. +This Meeting is based on the document link:WorkflowProposals.html[»Lumiera Workflow Proposals«] by Wouter Verwijlen. Wouter travelled to FrOSCon to meet the core team in person. This meeting discussed some central points of the planned workflow support in the Lumiera GUI. We discussed problems, agreed on various points and decided to produce a design document. Here we attempt to reconstruct and document the original meeting. Points discussed ---------------- -We agreed upon the importance of a _Magnetic Timeline,_ as introduced by Final Cut X. -However, our link:{ldoc}devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)] +We agreed upon the importance of a link:WorkflowProposals.html#\_tracks_vs_trackless[magnetic timeline], +as introduced by Final Cut X. +However, our link:{ldoc}/devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)] which predates FCPX's release,footnote:[Final Cut Pro X was link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic Timeline« is generally considered a novel concept introduced with this update. The initial reception @@ -53,7 +54,7 @@ navigation tool, with the option to lock moving of clips. _Wouter_ introduced a context sensitive tool palette which is rendered as an overlay in the timeline UI. The ability of Tools to support sub-modes is a simple extension of this proposal. -With this functionality, it would be then be possible to switch between trim-, roll-, slide- and slip-edit +With this functionality, it would then be possible to switch between trim-, roll-, slide- and slip-edit after activating the edit tool. Similarly, the _gear switch_ as proposed in a previous online discussion would be integrated as a sub-mode if a user decided to manipulate any setting value. @@ -126,8 +127,8 @@ important in determining whether a feature is implemented or not, e.g., effort required to implement a feature; but we focus solely on identifying our target audience here. -In his »Lumiera Workflow Proposals«, _Wouter_ identified five groups which mould -most likely be attracted to Lumiera and its goals. +In his link:WorkflowProposals.html[»Lumiera Workflow Proposals«], _Wouter_ +identified six groups which mould most likely be attracted to Lumiera and its goals. - The highly specialised editor who works in an environment where different parts of the post-production of a film are handled by different people: assistant editors, colourists, From 4dba1c816d4d4d558729378065f2a46a42862b08 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 23 Aug 2025 04:29:08 +0200 Subject: [PATCH 11/51] DOC: FrOSCon meeting -- integrate improvements from Benny --- .../workflow/Verwijlen/FrosconMeeting.txt | 35 ++- wiki/Workflow_Verwijlen.mm | 248 ++++++++++++++++++ 2 files changed, 264 insertions(+), 19 deletions(-) diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index d8af27fb5..7554ae0cd 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -117,34 +117,31 @@ the elements step wise while still retaining the ability to edit the contents. Target audience ~~~~~~~~~~~~~~~ -It is important to identify our target audience to be able to obtain a clear -vision of which features are more preferable to include and those features which -might be less suitable to incorporate into Lumiera. This will allow us to -fine-focus into the particular needs of these groups and provide us with a -mechanism to curtail our long feature list. Eventually we might have a list of -features ordered according to priority. Other factors are, of course, -important in determining whether a feature is implemented or not, e.g., effort -required to implement a feature; but we focus solely on identifying our target -audience here. +It is important to identify our target audience to be able to frame a clear +picture of which features are more preferable to include and those features which +might be less suitable to incorporate into Lumiera. +Define such groups will allow us to fine-focus into the particular needs of these groups +and provide us with a mechanism to curtail our long feature list. Eventually we might have +a list of features ordered according to priority. In his link:WorkflowProposals.html[»Lumiera Workflow Proposals«], _Wouter_ -identified six groups which mould most likely be attracted to Lumiera and its goals. +identified six groups which would most likely be attracted to Lumiera and its goals. - The highly specialised editor who works in an environment where different parts of the post-production of a film are handled by different people: assistant editors, colourists, audio engineers, etc. -- The allround contracted editor who handles all aspects of post-production -- The allround artistic filmmaker who also edits -- The allround social media creator who values the use of visual effects, +- The all-round contract editor who handles all aspects of post-production +- The all-round artistic filmmaker who also edits +- The all-round social media creator who appreciates the use of visual effects, motion graphics and sound effects. -- The free-flowing editor who does not have a fixed idea of how the edit should be - and instead wants to play and move things around, and who might not work in a linear - fashion: they might do a bit of colour correction to get a better sense of how a scene feels, - then go back to editing, etc. +- The free-flowing editor without a fixed idea of the edit, who prefers to explore the + footage and move things around, and who might not work in a linear fashion: + they might, for example, do a bit of colour correction to acquire a better feel for a scene + and then go back to coarse-grained editing. - The editor who has the film already cut in their head and have a very strong sense of - what they want to do and work in a very structured way towards accomplishing this vision. + what they want to do and progress through structured and precise steps towards realising their vision. -These groupings are naturally provisional and will mostly likely change -- which +These groupings are naturally provisional and will most likely change -- which is very good -- as we add important features that are deemed essential but fit to no group in our selection. diff --git a/wiki/Workflow_Verwijlen.mm b/wiki/Workflow_Verwijlen.mm index 8437bde0b..c0946a5f0 100644 --- a/wiki/Workflow_Verwijlen.mm +++ b/wiki/Workflow_Verwijlen.mm @@ -143,6 +143,254 @@ + + + + +

+ Mail-Thread "Workflow and Structure" +

+ + + + + + + + + +

+ Mail-Thread "Workflow document update" +

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

+ desen Bilder liegen im Website-Repository +

+ + + + + +

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

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

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

+ + + + + + + + +

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

+ + + + + + + + +

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

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

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

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

+ Zeile 297: +

+

+ +

+

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

+

+ span.image img { +

+

+     border-style: none; +

+

+ } +

+

+ +

+

+ div.imageblock img { +

+

+     padding-left: 13%;  +

+

+     border: 0px solid silver; +

+

+ } +

+ + + + + + +

+ commit 694ade36042c420efdeface2c80c0906ea3f5fa6 +

+

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

+

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

+

+ +

+

+     small CSS tweaks/fixes +

+

+ +

+

+ +

+

+ commit ed7a397aecb0c5b3b284663bb09e08494adb087d +

+

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

+

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

+

+ +

+

+     Added tools for building a web page with asciidoc +

+ + + + + + + +

+ commit 8ee898954a38d9d68ef6fac0a93ceb5ffa587a6e +

+

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

+

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

+

+ +

+

+     Added 13% padding to images +

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

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

+ + + + + + From f6427474ad9e3e2db709606ba1d872d1aa8df6e1 Mon Sep 17 00:00:00 2001 From: Wouter Verwijlen Date: Tue, 19 Aug 2025 19:26:22 +0200 Subject: [PATCH 12/51] Workflow-discussion: Lumiera Workflow Proposals (draft v3) ...fine-tuned a few small bits here and there in the current chapter of the workflow document =========================================================== Remark from Ichthyo(committer): Converted from PDF to raw text with pdftotext wouter250819v3.pdf WorkflowProposals.txt Images extracted with: pdfimages -png -j wouter250819v3.pdf wouter/wouter250819v3 Again adding the images separately to the Website-repository, in order to save storage space in the main repository.... --- .../workflow/Verwijlen/WorkflowProposals.txt | 128 ++++++++++-------- 1 file changed, 69 insertions(+), 59 deletions(-) diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt index 213459eb9..c28a1f4ed 100644 --- a/doc/design/workflow/Verwijlen/WorkflowProposals.txt +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -1,7 +1,7 @@ Lumiera Workflow Proposals ========================== :Author: Wouter Verwijlen -:Date: 29 June 2025 +:Date: 19 August 2025 :TOC: I would like to share a first version of a collection of workflow ideas for Lumiera. These ideas come @@ -54,9 +54,12 @@ Examples of such personas could be: post-production of a film are handled by different people: assisant editors, colorists, audio engineers, etc. ** The allround contracted editor who handles all aspects of post-production -** The allround artistic filmmaker who also edits + + ◦ The freelance editor who does both commisioned work and passion projects +** The allround artistic/indie filmmaker, who also edits ** The allround social media creator who values the use of visual effects, motion graphics and sound effects. +And a few subtypes: ** The free-flowing editor who doesn't have a fixed idea of how the edit should be and instead wants to play and move things around, and who might not work in a linear fashion: they might do a bit of color correction to get a better sense of how a scene feels, @@ -83,7 +86,9 @@ was, we should make an attempt to understand this reasoning. Some designs might come from technical limitations, and others might have had really clever thinking behind them. Let's see what we can learn from that. -* Ideally we should also include workflows for editors using XR headsets in combination with +• + +Ideally we should also include workflows for editors using XR headsets in combination with controllers or even hand tracking. While I do have a headset at work that I experiment with, we might want someone with actual XR design skills to be involved here. @@ -109,7 +114,7 @@ course. The current NLE landscape ------------------------- A few decades ago there was this idea that only a single application could be called ``the best'', in -other words: the one true NLE to rule them all. Some even went as far as calling it ``the NLE wars''. +other words: the one true NLE to rule them all. Some even went as far as calling it »the NLE wars«. There was fierce competition between Avid Media Composer, Final Cut Pro, and Adobe Premiere and each had its fans. Over the years this discussion faded away. Final Cut Pro was disregarded by many after the radical rewrite that was released as Final Cut Pro X. Avid Media Composer retained @@ -217,7 +222,7 @@ later during their development. Final Cut Pro was from its core designed to be u It's fast, and in combination with the clip connections and magnetic timeline, it's the least destructive way to edit. Trimming and editing by mouse is less precise though, which is why even FCP offers many keyboard shortcuts for precise trimming by keyboard. Using a mouse -feel slightly less tactile than using physical buttons and dials. +feels slightly less tactile than using physical buttons and dials. + In this same category we can also mention touch screens (as they offer similar interactions as a mouse, with the addition of finger gestures). Editing on a smartphone or tablet, when @@ -411,6 +416,8 @@ Currently I'm thinking of using this bar on two or three occasions: + -> See the next subchapter: »Adding clips to the timeline«. +Colors could be used (for example as an outline around the bar) to indicate which contextual mode +is active. A limitation of such a bar is that it might overlap with content that a user wishes to interact with. If this is the case, then clicking on the grid with dots will let a user drag this bar out of the way. As an extra option I would like to suggest to use a modifier key (Ctrl?) which temporarily hides the @@ -425,7 +432,8 @@ Adding clips to the timeline All NLE's offer multiple ways to get your material in the timeline, and those methods fall into the following categories: -* Drag and drop from either the project contents panel or directly from a file browser +* Drag and drop from either the project contents panel, another timeline, or directly from a file +browser * By creating a timeline out of selected clips in a bin * N point editing, of which the most commonly used is three point editing: you load a source clip (or timeline) into a (source) viewer/monitor, mark an in point, out point and use one of @@ -449,21 +457,12 @@ selected duration in the source clip match the selected duration in the timeline * Avid features a Replace Edit option: a selected clip on the timeline can be replaced by the contents in the source browser with a single click or keystroke. -All of these options make sense, but in general I find it easier to remember two options (insert and +All of these options make sense, but in general I rarely remember more than two options (insert and overwrite) and easily forget any surplus options that NLE's offer. We should also try to limit the -amount of keyboard shortcuts that a user needs to memorize, so two options seems like a proper -number. In that case, I would suggest one key/function for an Insert operation. - -The second key/function will be a more generic ``Add Clip'' action, which might display a pop-up in -which we can select which method to use. TAB will cycle between Overwrite, Place on Top, -Append and Replace, followed by Enter to confirm. It will remember the last used option. Double -tapping the keyboard shortcut for this action will skip the pop-up. - -Having to repeatedly view a pop-up menu (or double tapping a key) might feel cumbersome, so an -alternative could be to let the ``Add Clip'' action insert a clip by default and show all different -options via the contextual bar. You can then change the behaviour after the fact, until you commit -by doing something else. In this case, adding a clip will enter and exit another contextual mode. - +amount of keyboard shortcuts that a user needs to memorize, so I would like to propose a single +``Add Clip'' action. This will insert a clip and will show the different options via the contextual bar. +You can then change the desired method after the fact, until you commit by doing something else. +In this case, adding a clip will enter and exit another contextual mode. One last thing I would like to address is the destruction that an insert operation can cause. Usually this can be prevented by proper track management, but you can wonder why you would ever want an insert action to cause the following: @@ -552,8 +551,9 @@ Premiere you can choose how large the steps are, Resolve only supports single se Combining mouse and keyboard: -* Adobe Premiere has a "move playhead to cursor" feature that can be bound to a key. - Very useful! +* Adobe Premiere and several DAWs (Ardour, Reaper) have a "move playhead to cursor" +feature that can be bound to a key. Very useful! Resolve has added this in version 20.1 as +well. Using other devices: @@ -633,6 +633,7 @@ increase. This will also work vertically. The playhead will move along as well. .Autoscroll widget image::{imgg}/wouter/07-2-autoscroll.png[width="100%", alt="A widget for auto-scrolling"] + Zoom widget:: moving the mouse left or right from the center will zoom horizontally, up and down will zoom vertically. + @@ -710,15 +711,22 @@ good reason to go in this direction. image::{imgg}/wouter/08-selection.png[width="100%", alt="selecting clips"] For selecting, we can introduce an ``add to selection'' key which adds the highlighted clip to the -current selection (apart from the convention of using Ctrl+mouse click). Selected clips can have a -differently colored box, yellow, for example. - +current selection (apart from the convention of using Ctrl+mouse click). We could also think of +adding box-select by keyboard, by using a system with grid coordinates. One thing to note is that we do still need extra keyboard shortcuts to move the playhead frame by frame, indepently from the clip selection. See the navigation subchapter for more details. Selection will be one of the previously mentioned _contextual modes._ The user can always return to their previous selection until they make a new one, by pressing the corresponding keyboard shortcut (S). + Most NLE's have functions for selecting many clips at once, called ‘select forward’ and ‘select +backward’. In Adobe Premiere these are tools: click and you select all clips to either the left or right +of the mouse cursor, and using Shift will toggle between selecting all clips on a single track or on +all tracks (it doesn’t respect track activation status though, which it should). Other NLE's (Resolve, +Avid, Lightworks) only have keyboard shortcuts for these functions, which do only affect activated +tracks. This is a bit faster: in Premiere you need to switch to the Select Forward/Backward Tool, +make your selection, then switch back to your previous tool. With a keyboard shortcut you only +have to press a single key (if your track selection is correct). Arranging clips ~~~~~~~~~~~~~~~ @@ -821,11 +829,10 @@ on clip connections (this is discussed in the subchapter ``Tracks vs Trackless'' Let's first examine trim side selection by mouse. This is generally as simple as clicking near the edge of a clip, or on the edge between two clips to select both sides for a roll edit. -Adding additional trim sides often works by using modifier like Ctrl + left click (Premiere, Resolve, +Adding additional trim sides often works by using a modifier like Ctrl + left click (Premiere, Resolve, Lightworks, Avid). FCP does not allow the selection of multiple trim sides and therefore does not -support _asymmetric trimming._ Such trims are still possible, but need to be performed in two steps -rather than one. - +support _asymmetric trimming._ Such trims are still possible, but need to be performed in +multiple steps rather than one. Keyboard selection of trim sides happens in general by providing shortcuts for selecting the left (A) side, the right (B) side, or both, of a cut (Avid, Premiere, Resolve and FCP, although the latter does not have a shortcut for selecting both sides as it uses a dedicated Trim tool for roll edits). This @@ -834,13 +841,10 @@ very powerful method: instead of A/B/both, it has four shortcuts: * Trim last out * Trim in - -These two apply to all cuts on enabled tracks to the left of the playhead. - * Trim out * Trim next in -These two apply to all cuts on enabled tracks to the right of the playhead. +These apply to all clips (or gaps) on enabled tracks underneath the playhead. These commands can be combined: when pressing multiple keys, new trim sides are added to the selection. This allows for quickly selecting many trim sides on many tracks. @@ -850,28 +854,30 @@ image::{imgg}/wouter/10-trim-side.png["select trim side"] Another feature that was already mentioned in a previous chapter, is FCP's precision editor, which can be triggered by double clicking a cut or by keyboard shortcut. This shows how much footage from each clip is available for trimming and allows ripple trimming as well as roll edits to be -performed by mouse or keyboard. - +performed by mouse or keyboard. DaVinci Resolve added a similar thing called Trim Editor, but +positions it at the bottom of the Timeline Viewer. Performing the trim ^^^^^^^^^^^^^^^^^^^ -Usually we see three ways to perform a trim: +Usually we see four ways to perform a trim: 1. Frame by frame. This can be done by mouse by clicking and dragging the edges of a clip, or by keyboard by using shortcuts for ``left one frame'', ``right one frame'', ``left 10/many frames'', ``right 10/many frames''. Instead of using keyboard shortcuts, dedicated hardware can be used to joggle left or right to perform trimming. 2. By specifying an exact amount of frames. Pretty much every NLE supports using the plus -and minus keys on the keypad to enter exact frame numbers. Lightworks does an excellent -job at this: when not entering any amount (so just plus/minus + enter) it will repeat the last +and minus keys on the keypad to enter exact frame numbers. Lightworks and Avid do an excellent +job at this: when not entering any amount (so just plus/minus + enter) they will repeat the last entered amount of frames. -3. Dynamic trimming. This means starting playback of the timeline around the position of the -cut, and pressing a key to mark a point in realtime where the cut should be placed. Avid and -Lightworks have dynamic trimming support within their trim modes. Resolve has a separate -switch for this that needs to be toggled, and Premiere has a separate mode for dynamic -trimming, simply called ``Trim Mode''. FCP does not seem to support dynamic trimming at -the time of writing. +3. Dynamic trimming. This means moving the cut (or slipping or sliding a clip) by using the +JKL-playback controls. Avid and Lightworks have dynamic trimming support within their +trim modes. Resolve has a separate switch for this that needs to be toggled, and Premiere has + a separate mode for dynamic trimming, simply called ‘Trim Mode’. FCP does not seem to +support dynamic trimming at the time of writing - although some people disagree and say +that the ‘Extend Edit’ function, when used in the Precision Editor, achieves a similar result. +4. All of the big NLE's have keyboard shortcuts that will trim either the start or the end of a +clip to the position of the playhead, in ripple and non-ripple flavors. Previewing the cut ^^^^^^^^^^^^^^^^^^ @@ -887,8 +893,7 @@ be closed with the Escape key, as can Avid's trim mode. Analysis and proposal ^^^^^^^^^^^^^^^^^^^^^ -My proposal is to leverage the same system as the clip selection system to highlight a clip, and then -have three commands: +My proposal is to use the clip selection system to highlight a clip, and then have three commands: * Select the clip's in point as trim side * Select the clip's out point as trim side @@ -899,8 +904,8 @@ two shortcuts are pressed once, they select the trim side for ripple trims. When will switch to non-ripple trims (and back again with another press). There should be a clear visual difference between these two (perhaps through the color of the brackets, as in Avid). -Note that this approach closely resembles Lightworks, and is different from Avid, FCP, Premiere -and Resolve. Those apps take the cut closest to the playhead as the basis for choosing a trim side. +Note that this approach resembles Lightworks, and is different from Avid, FCP, Premiere and +Resolve. Those apps take a cut (closest to the playhead) as the basis for choosing a trim side. Lightworks takes the underlying clip as its basis. Since we already have a mechanism for navigating clips, we should probably not add another mechanism just for navigating cuts. @@ -924,12 +929,12 @@ we should consider that we need the following keyboard shortcuts: These same keys can't double for nudging clips, the way it does in many apps, without using modes. Therefore my proposal is indeed to introduce a Trim mode. As said, it should be designed as a contextual mode that we fluidly enter and exit and that is visually easy to distinguish from the -regular mode, which we can call the Position mode. Trim mode can be accentuated by marking the -part of the timeline we'll be previewing. As in Avid, in trim mode playback could always preview -the selected cut, so we won't need a special Preview (sometimes called ``Play around'') shortcut. Trim -mode will be exited automatically whenever the user clicks in an empty spot of the timeline or -presses the trim mode key (T). This key can also be used to return to the last-used trim -configuration. +regular mode, which we can call the Navigation mode. Trim mode can be accentuated by marking +the part of the timeline we'll be previewing. As in Avid, in trim mode playback could always +preview the selected cut, so we won't need a special Preview (sometimes called ``Play around'') +shortcut, (editing transitions should also engage the trim mode, in that case). Trim mode will be +exited automatically whenever the user clicks in an empty spot of the timeline or presses the trim +mode key (T). This key can also be used to return to the last-used trim configuration. .Mockup of the trim mode. The striped area marks the pre- and post-roll that will be previewed. image::{imgg}/wouter/11-trim-mode.png[width="100%", alt="using trim mode"] @@ -941,24 +946,29 @@ Tool-based NLE's offer a Blade or Cut tool that will cut clips wherever a user c offer a dedicated keyboard shortcut for creating a cut at the playhead as well. Merging two timeline clips with so-called ``through edits'' is often possible by selecting the cut for a -roll edit and pressing the delete key. A through edit is a cut made within a clip, where the start of the -second clip in the timeline matches the next frame from the source clip that corresponds to the first -timeline clip. - +roll edit and pressing the delete key. A through edit occurs when two successive segments of the +same source clip are placed directly next to each other in the timeline (so as a result, it looks as if +there wasn't a cut at all). A Blade tool, a shortcut for Add Cut and the ability to remove through edits with backspace seem all worth implementing. Removing clips ~~~~~~~~~~~~~~ -In general, we find the following options: +In general, we find the following options to remove clip from a timeline: * Select a clip, then: backspace or delete key, or (ripple) cut command. * In and out points, then lift or extract. * Lightworks lets you remove a clip by dragging it outside of the timeline window. +• + +Trimming a clip so it will end up with a duration of 0 frames. + These operations are so common that I would not change them. +Dropping another clip on top. This is something that we could consider changing, especially +when the clips that will be removed are offscreen. Organising the timeline: sections ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From 592622d75017908df24949a0a2114931a48ed469 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 23 Aug 2025 18:43:46 +0200 Subject: [PATCH 13/51] Workflow-publish: adapt additions to Asciidoc --- .../workflow/Verwijlen/WorkflowProposals.txt | 37 +++++----- wiki/Workflow_Verwijlen.mm | 69 +++++++++++++++++-- 2 files changed, 80 insertions(+), 26 deletions(-) diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt index c28a1f4ed..407f03fb1 100644 --- a/doc/design/workflow/Verwijlen/WorkflowProposals.txt +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -54,17 +54,18 @@ Examples of such personas could be: post-production of a film are handled by different people: assisant editors, colorists, audio engineers, etc. ** The allround contracted editor who handles all aspects of post-production - - ◦ The freelance editor who does both commisioned work and passion projects +** The freelance editor who does both commisioned work and passion projects ** The allround artistic/indie filmmaker, who also edits ** The allround social media creator who values the use of visual effects, motion graphics and sound effects. ++ And a few subtypes: -** The free-flowing editor who doesn't have a fixed idea of how the edit should be and ++ +*** The free-flowing editor who doesn't have a fixed idea of how the edit should be and instead wants to play and move things around, and who might not work in a linear fashion: they might do a bit of color correction to get a better sense of how a scene feels, then go back to editing, etc. -** The editor who has the film already cut in their head and have a very strong sense of +*** The editor who has the film already cut in their head and have a very strong sense of what they want to do and work in a very structured way towards accomplishing this vision. + @@ -86,9 +87,7 @@ was, we should make an attempt to understand this reasoning. Some designs might come from technical limitations, and others might have had really clever thinking behind them. Let's see what we can learn from that. -• - -Ideally we should also include workflows for editors using XR headsets in combination with +* Ideally we should also include workflows for editors using XR headsets in combination with controllers or even hand tracking. While I do have a headset at work that I experiment with, we might want someone with actual XR design skills to be involved here. @@ -418,6 +417,7 @@ Currently I'm thinking of using this bar on two or three occasions: Colors could be used (for example as an outline around the bar) to indicate which contextual mode is active. + A limitation of such a bar is that it might overlap with content that a user wishes to interact with. If this is the case, then clicking on the grid with dots will let a user drag this bar out of the way. As an extra option I would like to suggest to use a modifier key (Ctrl?) which temporarily hides the @@ -551,7 +551,7 @@ Premiere you can choose how large the steps are, Resolve only supports single se Combining mouse and keyboard: -* Adobe Premiere and several DAWs (Ardour, Reaper) have a "move playhead to cursor" +* Adobe Premiere and several DAWs (Ardour, Reaper) have a ``move playhead to cursor'' feature that can be bound to a key. Very useful! Resolve has added this in version 20.1 as well. @@ -719,10 +719,10 @@ Selection will be one of the previously mentioned _contextual modes._ The user c their previous selection until they make a new one, by pressing the corresponding keyboard shortcut (S). - Most NLE's have functions for selecting many clips at once, called ‘select forward’ and ‘select -backward’. In Adobe Premiere these are tools: click and you select all clips to either the left or right +Most NLE's have functions for selecting many clips at once, called ``select forward'' and ``select +backward''. In Adobe Premiere these are tools: click and you select all clips to either the left or right of the mouse cursor, and using Shift will toggle between selecting all clips on a single track or on -all tracks (it doesn’t respect track activation status though, which it should). Other NLE's (Resolve, +all tracks (it doesn't respect track activation status though, which it should). Other NLE's (Resolve, Avid, Lightworks) only have keyboard shortcuts for these functions, which do only affect activated tracks. This is a bit faster: in Premiere you need to switch to the Select Forward/Backward Tool, make your selection, then switch back to your previous tool. With a keyboard shortcut you only @@ -780,7 +780,7 @@ pressing the Ctrl modifier will inverse a tool's mode of operation. * Resolve talks in terms of modes, not tools, and it has two modes related to trimming: the default Selection Mode and Trim Edit Mode. The latter lets you ripple trim (by dragging the edges of clips), slip (dragging inside a clip, upper half) and slide (dragging inside a clip, -lower half) - more on slip and slide edits later. +lower half) -- more on slip and slide edits later. * Avid has a trim mode that can be in overwrite trim or ripple trim mode, indicated by the color of the trim sides (red or yellow). The timeline will be in either of these modes when @@ -833,6 +833,7 @@ Adding additional trim sides often works by using a modifier like Ctrl + left cl Lightworks, Avid). FCP does not allow the selection of multiple trim sides and therefore does not support _asymmetric trimming._ Such trims are still possible, but need to be performed in multiple steps rather than one. + Keyboard selection of trim sides happens in general by providing shortcuts for selecting the left (A) side, the right (B) side, or both, of a cut (Avid, Premiere, Resolve and FCP, although the latter does not have a shortcut for selecting both sides as it uses a dedicated Trim tool for roll edits). This @@ -872,10 +873,9 @@ entered amount of frames. 3. Dynamic trimming. This means moving the cut (or slipping or sliding a clip) by using the JKL-playback controls. Avid and Lightworks have dynamic trimming support within their trim modes. Resolve has a separate switch for this that needs to be toggled, and Premiere has - - a separate mode for dynamic trimming, simply called ‘Trim Mode’. FCP does not seem to -support dynamic trimming at the time of writing - although some people disagree and say -that the ‘Extend Edit’ function, when used in the Precision Editor, achieves a similar result. +a separate mode for dynamic trimming, simply called ``Trim Mode''. FCP does not seem to +support dynamic trimming at the time of writing -- although some people disagree and say +that the ``Extend Edit'' function, when used in the Precision Editor, achieves a similar result. 4. All of the big NLE's have keyboard shortcuts that will trim either the start or the end of a clip to the position of the playhead, in ripple and non-ripple flavors. @@ -960,10 +960,7 @@ In general, we find the following options to remove clip from a timeline: * Select a clip, then: backspace or delete key, or (ripple) cut command. * In and out points, then lift or extract. * Lightworks lets you remove a clip by dragging it outside of the timeline window. - -• - -Trimming a clip so it will end up with a duration of 0 frames. +* Trimming a clip so it will end up with a duration of 0 frames. These operations are so common that I would not change them. diff --git a/wiki/Workflow_Verwijlen.mm b/wiki/Workflow_Verwijlen.mm index c0946a5f0..2f2013574 100644 --- a/wiki/Workflow_Verwijlen.mm +++ b/wiki/Workflow_Verwijlen.mm @@ -140,7 +140,8 @@ - + + @@ -151,8 +152,7 @@ Mail-Thread "Workflow and Structure"

- - + @@ -163,14 +163,71 @@ Mail-Thread "Workflow document update"

+ + + + + + + + + +

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

+ + + + + + + + +

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

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

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

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

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

+ + + + + + - + @@ -181,7 +238,7 @@ - + @@ -241,7 +298,7 @@ - + From 537c89298b1237aae0e3e5e9d0e6dcd126a53ba0 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 31 Aug 2025 00:47:39 +0200 Subject: [PATCH 14/51] DOC: FrOSCon meeting -- additions and corrections as proposed by Wouter --- doc/design/workflow/Verwijlen/FrosconMeeting.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index 7554ae0cd..6eca551c3 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -56,13 +56,13 @@ _Wouter_ introduced a context sensitive tool palette which is rendered as an ove The ability of Tools to support sub-modes is a simple extension of this proposal. With this functionality, it would then be possible to switch between trim-, roll-, slide- and slip-edit after activating the edit tool. Similarly, the _gear switch_ as proposed in a previous online discussion -would be integrated as a sub-mode if a user decided to manipulate any setting value. +would be integrated as a sub-mode into various other modes if a user decided to manipulate any setting value. Internationalisation ~~~~~~~~~~~~~~~~~~~ The language of the UI is English. This does not mean that we exclude any language (all contributions are welcome). Certain words and terminology should never be translated, e.g., -Track, Clip, Placement, ... . We also do not support translations that require a re-ordering +Track, Clip, Placement, ... . We have no plans to support translations that require a re-ordering of UI elements such as languages written right-to-left. This is due to priorities that we define. @@ -70,8 +70,10 @@ Unlimited Placement Constraints ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The use of fine-grained placement constraints is plagued with overwhelming the user with excessive relationships. This can be improved by using a small number of prototype set-ups: -magnetic, relative and music anchored. Moreover, we require a diagnostic to reveal the reason why -a given clip is positioned at where it is. +magnetic, relative and music anchored. _Wouter_ points out that a similar scheme can be applied +here as with the flavours of editing: A _placement prototype_ can be pre-selected for a newly added +clip -- with the ability for adjustment through the tool palette. Moreover, we require a diagnostic +to reveal the reason why a given clip is positioned at where it is. .Routing _Hermann_ explained how the routing in Render Engine is based on Placements. @@ -113,6 +115,8 @@ _Wouter_ was concerned that it might be tedious to navigate between different ch especially if it is necessary to expand or collapse these elements repeatedly. One countermeasure to relieve constant opening and closing elements would be to expand the elements step wise while still retaining the ability to edit the contents. +Furthermore, rendering a condensed preview of a virtual clip's internal structure +could help to avoid having to open and expand the clip in many situations. Target audience From 43a9036c0d29d319129a8adb630f7b864ad05e62 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 31 Aug 2025 00:48:44 +0200 Subject: [PATCH 15/51] Workflow-publish: minor layout tweaks and spelling fixes --- .../workflow/Verwijlen/WorkflowProposals.txt | 60 +++++++++---------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt index 407f03fb1..1b3e8c37b 100644 --- a/doc/design/workflow/Verwijlen/WorkflowProposals.txt +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -20,7 +20,7 @@ extension of their body, where interaction with the NLE will ultimately become n does not mean that a user should immediately understand everything without there being a certain learning curve. Some new concepts might take a while to master. -* An editor should not be able to accidentally overwite part of their work in the timeline when +* An editor should not be able to accidentally overwrite part of their work in the timeline when that part is not within sight (in other words: when it's offscreen). This includes throwing things out of sync, losing transitions, or overwriting clips. @@ -44,17 +44,17 @@ approach. * A big question is: who is "the user"? We aim to create a tool for professionals, but there are many types of professionals working in entirely different parts of the media industry or in other fields. In the previous paragraph it was mentioned that different types of content -require different types of workflows. How to accomodate all of these different people who +require different types of workflows. How to accommodate all of these different people who work on different things? + I would like to propose a set of personas to keep in mind while designing the application. Examples of such personas could be: + ** The highly specialised editor who works in an environment where different parts of the -post-production of a film are handled by different people: assisant editors, colorists, +post-production of a film are handled by different people: assistant editors, colourists, audio engineers, etc. ** The allround contracted editor who handles all aspects of post-production -** The freelance editor who does both commisioned work and passion projects +** The freelance editor who does both commissioned work and passion projects ** The allround artistic/indie filmmaker, who also edits ** The allround social media creator who values the use of visual effects, motion graphics and sound effects. @@ -63,7 +63,7 @@ And a few subtypes: + *** The free-flowing editor who doesn't have a fixed idea of how the edit should be and instead wants to play and move things around, and who might not work in a linear -fashion: they might do a bit of color correction to get a better sense of how a scene feels, +fashion: they might do a bit of colour correction to get a better sense of how a scene feels, then go back to editing, etc. *** The editor who has the film already cut in their head and have a very strong sense of what they want to do and work in a very structured way towards accomplishing this @@ -72,7 +72,7 @@ vision. Of course, there are many more types of people and many people who are a combination of personas. These are only meant to paint the spectrum of possibilities. -* Lumiera provides a chance to reimagine how an NLE could work, in other words: how it +* Lumiera provides a chance to re-imagine how an NLE could work, in other words: how it can be designed around modern ways of interacting with computers. In that sense there is total freedom to create innovative new solutions to improve how people edit videos. On the other hand, if we create paradigms that are too uncommon, new users might not understand @@ -94,10 +94,10 @@ we might want someone with actual XR design skills to be involved here. Initially I would like to focus on the most fundamental tasks that each and every editor has to deal with while creating a video: -1. Finding the parts you need out of a lot of source material (logging and organizing footage) +1. Finding the parts you need out of a lot of source material (logging and organising footage) 2. The timeline as the editor's canvas: inserting and grouping material, arranging clips, trimming and other timeline features -3. Finishing: audio mixing, color correction, titles, effects, exporting +3. Finishing: audio mixing, colour correction, titles, effects, exporting 4. The broader GUI concept Many of the ideas presented here are not necessarily unique: a lot of these either exist in one NLE @@ -135,11 +135,11 @@ Then in between sat Premiere Pro, comfortably. It profited massively from being Creative Suite, later the Creative Cloud: for many media companies it was very cost effective to pay Adobe a single sum of money (pre-Creative Cloud) and later subscription fees, and receive all the tools they could possibly need for media creation. But also the application itself was an all-in-one -solution for all parts of post-production: it offered many tools for audio mixing, color grading, +solution for all parts of post-production: it offered many tools for audio mixing, colour grading, visual effects, etc. Sure, Media Composer and FCPX also offered tools for these jobs, but were less developed in these areas and often required plugins to achieve many of the more advanced tasks. -Then came along DaVinci Resolve, a color grading application that was bought by Blackmagic +Then came along DaVinci Resolve, a colour grading application that was bought by Blackmagic Design and transformed into another all-in-one powerhouse, which slowly started to take a seat next to Premiere's throne. @@ -147,7 +147,7 @@ In the meantime the media landscape changed. NLE's became more affordable and ha capable, and the result was that editing was no longer a thing only done by professionals: everybody became an editor, and everybody could edit any moment, anywhere, on laptops, tablets or smartphones. Social media became a huge new platform where many new makers developed their -own channels and found an audience for their videos. And so came NLE's that were focussed on +own channels and found an audience for their videos. And so came NLE's that were focused on social media content, most notably CapCut. It took FCP's idea of easy to learn even farther and offered many one-click visual effects, automatic subtitles and mostly: a lot of effect presets and assets (titles, other graphics, music) available within the application. @@ -199,17 +199,17 @@ Tracks vs trackless ~~~~~~~~~~~~~~~~~~~ In general, we can observe two extremes when it comes to editing: -* On the one hand, there are NLE's modeled to resemble working with analog gear (i.e. +* On the one hand, there are NLE's modelled to resemble working with analogue gear (i.e. classic editing stations from KEM, Steenbeck, Moviola). A lot of terminology in editing -software (``bins'', ``reels'', ``cut'', ``mark in/out'', among many others) stems from the analog +software (``bins'', ``reels'', ``cut'', ``mark in/out'', among many others) stems from the analogue origins of editing. Lightworks is an example of this. When trimming you ``unjoin'' a cut, -make changes, and then ``join'' the cut again, as if working with analog film that needs to be +make changes, and then ``join'' the cut again, as if working with analogue film that needs to be taped together. It works best in conjunction with the Lightworks Console, a hardware device -that was designed specifically to make software editing feel as if editing analog film. Very +that was designed specifically to make software editing feel as if editing analogue film. Very hands-on, very tactile, according to editors who have worked with these consoles (unfortunately I haven't had a chance to try this myself). + -Not just Lightworks, but also Avid is said to have been greatly influenced by analog +Not just Lightworks, but also Avid is said to have been greatly influenced by analogue equipment, and Adobe Premiere's predecessor ReelTime was created to work like 3/4" tape decks. Blackmagic's Speed Editor (and corresponding Cut Page in Resolve) has also been designed according to this principle: to make editing feel like you're operating a machine. @@ -228,7 +228,7 @@ as a mouse, with the addition of finger gestures). Editing on a smartphone or ta not using a pen, feels even further removed from giving you a physical connection between your hands and the buttons on the screen. -Because of its analog roots, traditionally, NLE's have been track-based. I'd like to quote Randy +Because of its analogue roots, traditionally, NLE's have been track-based. I'd like to quote Randy Ubillos, original creator of ReelTime and Final Cut Pro: ____ ``In a track based system the layers at the beginning, middle and end all share the exact same tracks @@ -289,7 +289,7 @@ So naturally, a question would be: what will happen if we would let go of the tr is what Final Cut Pro has done, starting from the rewrite of Final Cut Pro X. At the time, a disastrous marketing campaign caused many editors to leave the application, although more and more people are starting to realise that many of its ideas were way ahead of its time. It's still the -only big NLE out there that was designed with computers in mind, and not analog hardware. +only big NLE out there that was designed with computers in mind, and not analogue hardware. It's not entirely trackless, but it manages to hide the concept of tracks from the user. There are no buttons to enable or disable tracks or other track controls, and instead, the tracks are called ``layers''. @@ -345,7 +345,7 @@ interaction methods would be preferred for Lumiera? which mode they're in) and can lead to user errors (an action in one mode might do something different than intended in another mode). Another thing about modes is that they require a user action for entering and exiting. -* A *tool*-based approach however, is very mouse-centered. It changes the behaviour of the mouse, not +* A *tool*-based approach however, is very mouse-centred. It changes the behaviour of the mouse, not of keyboard actions, and this change is visible in the cursor. Tools are of little use to the keyboard editor. * A *view*-based approach is not too different from using modes, with the difference that it drastically @@ -415,7 +415,7 @@ Currently I'm thinking of using this bar on two or three occasions: + -> See the next subchapter: »Adding clips to the timeline«. -Colors could be used (for example as an outline around the bar) to indicate which contextual mode +Colours could be used (for example as an outline around the bar) to indicate which contextual mode is active. A limitation of such a bar is that it might overlap with content that a user wishes to interact with. If @@ -459,7 +459,7 @@ contents in the source browser with a single click or keystroke. All of these options make sense, but in general I rarely remember more than two options (insert and overwrite) and easily forget any surplus options that NLE's offer. We should also try to limit the -amount of keyboard shortcuts that a user needs to memorize, so I would like to propose a single +amount of keyboard shortcuts that a user needs to memorise, so I would like to propose a single ``Add Clip'' action. This will insert a clip and will show the different options via the contextual bar. You can then change the desired method after the fact, until you commit by doing something else. In this case, adding a clip will enter and exit another contextual mode. @@ -634,7 +634,7 @@ increase. This will also work vertically. The playhead will move along as well. image::{imgg}/wouter/07-2-autoscroll.png[width="100%", alt="A widget for auto-scrolling"] -Zoom widget:: moving the mouse left or right from the center will zoom horizontally, up and +Zoom widget:: moving the mouse left or right from the centre will zoom horizontally, up and down will zoom vertically. + .Zoom widget @@ -654,7 +654,7 @@ image::{imgg}/wouter/07-4-combined.png[width="100%", alt="Overlay widget to comb Why popup widgets? ^^^^^^^^^^^^^^^^^^ I can't speak for others, but personally I dislike moving the mouse downwards towards the edge of -the screen to access scrollbars or zoom sliders. We'd like the mouse to stay in the center of where +the screen to access scrollbars or zoom sliders. We'd like the mouse to stay in the centre of where we're working. With popup widgets, we might be able to improve navigation speed, but at the cost of familiarity @@ -714,7 +714,7 @@ For selecting, we can introduce an ``add to selection'' key which adds the highl current selection (apart from the convention of using Ctrl+mouse click). We could also think of adding box-select by keyboard, by using a system with grid coordinates. One thing to note is that we do still need extra keyboard shortcuts to move the playhead frame by -frame, indepently from the clip selection. See the navigation subchapter for more details. +frame, independently from the clip selection. See the navigation subchapter for more details. Selection will be one of the previously mentioned _contextual modes._ The user can always return to their previous selection until they make a new one, by pressing the corresponding keyboard shortcut (S). @@ -783,7 +783,7 @@ edges of clips), slip (dragging inside a clip, upper half) and slide (dragging i lower half) -- more on slip and slide edits later. * Avid has a trim mode that can be in overwrite trim or ripple trim mode, indicated by the -color of the trim sides (red or yellow). The timeline will be in either of these modes when +colour of the trim sides (red or yellow). The timeline will be in either of these modes when entering trim mode. * Lightworks has a trim mode that defaults to ripple trimming, unless you specifically use the @@ -877,7 +877,7 @@ a separate mode for dynamic trimming, simply called ``Trim Mode''. FCP does not support dynamic trimming at the time of writing -- although some people disagree and say that the ``Extend Edit'' function, when used in the Precision Editor, achieves a similar result. 4. All of the big NLE's have keyboard shortcuts that will trim either the start or the end of a -clip to the position of the playhead, in ripple and non-ripple flavors. +clip to the position of the playhead, in ripple and non-ripple flavours. Previewing the cut ^^^^^^^^^^^^^^^^^^ @@ -902,7 +902,7 @@ My proposal is to use the clip selection system to highlight a clip, and then ha If the latter is pressed a second time, it will take the clip's out point for a roll edit. When the first two shortcuts are pressed once, they select the trim side for ripple trims. When pressed again, they will switch to non-ripple trims (and back again with another press). There should be a clear visual -difference between these two (perhaps through the color of the brackets, as in Avid). +difference between these two (perhaps through the colour of the brackets, as in Avid). Note that this approach resembles Lightworks, and is different from Avid, FCP, Premiere and Resolve. Those apps take a cut (closest to the playhead) as the basis for choosing a trim side. @@ -964,7 +964,7 @@ In general, we find the following options to remove clip from a timeline: These operations are so common that I would not change them. -Dropping another clip on top. This is something that we could consider changing, especially +* Dropping another clip on top. This is something that we could consider changing, especially when the clips that will be removed are offscreen. Organising the timeline: sections @@ -978,7 +978,7 @@ image::{imgg}/wouter/12-sections.png[width="100%", alt="Timeline with sections"] The benefits of sections: * Creating a broad sense and clear overview of how a timeline is constructed. Background -colors in the timeline will make it easy to differentiate between different sections. +colours in the timeline will make it easy to differentiate between different sections. * Easy navigation between sections by keyboard shortcuts. @@ -1086,7 +1086,7 @@ basic properties of clips in the timeline, such as: * orientation * rotation * opacity and blend mode -* stabilization +* stabilisation Avid is the only NLE out there that still requires adding an effect to change these basic clip properties (``3D DVE''). Quick access to such properties saves a lot of time, so enabling this is From 9225d868bb7096d8d8fa268fefc8f4195f279f0e Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 31 Aug 2025 01:02:34 +0200 Subject: [PATCH 16/51] DOC: Notes regarding the ongoing workflow-discussion --- wiki/Workflow_Verwijlen.mm | 361 ++++++++++++++++++++++++++++++++++++- wiki/thinkPad.ichthyo.mm | 106 ++++++++++- 2 files changed, 464 insertions(+), 3 deletions(-) diff --git a/wiki/Workflow_Verwijlen.mm b/wiki/Workflow_Verwijlen.mm index 2f2013574..5a1f71110 100644 --- a/wiki/Workflow_Verwijlen.mm +++ b/wiki/Workflow_Verwijlen.mm @@ -5,6 +5,182 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

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

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

+ siehe Blender! +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -69,6 +245,109 @@ + + + + + + + + + + +

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

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

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

+ + + + + + @@ -109,7 +388,7 @@ - + @@ -125,6 +404,86 @@ + + + + + + + + + + +

+ Commands operate at a current position +

+ + + + + + + + + + +

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

+ + + + + + + + + + +

+ parameters and qualifications can be adjusted immediately +

+ + + + + + + + + + +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 571f215f3..2b12745f2 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -160990,10 +160990,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + @@ -169992,6 +169992,108 @@ Since then others have made contributions, see the log for the history. + + + + + + + + + + + + + + + + + + + +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From 060cbae2cd6e0a64b76bf886f493ea4c16c10487 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20Th=C3=A4ter?= Date: Thu, 1 Nov 2018 01:17:10 +0100 Subject: [PATCH 17/51] DOC: Server and Mailinglists --- .../infra/Webserver/Mailinglists.txt | 47 ++++++++ doc/technical/infra/Webserver/Webserver.txt | 112 ++++++++++++++++++ 2 files changed, 159 insertions(+) create mode 100644 doc/technical/infra/Webserver/Mailinglists.txt create mode 100644 doc/technical/infra/Webserver/Webserver.txt diff --git a/doc/technical/infra/Webserver/Mailinglists.txt b/doc/technical/infra/Webserver/Mailinglists.txt new file mode 100644 index 000000000..46ab0a561 --- /dev/null +++ b/doc/technical/infra/Webserver/Mailinglists.txt @@ -0,0 +1,47 @@ +Mailinglists +============ +:Author: cehteh +:Date: Nov 2018 + + +The Lumiera related Mailinglists. + +Main Webpage:: https://lists.lumiera.org/cgi-bin/mailman/listinfo + +Lumiera +------- + +List address:: lumiera@lists.lumiera.org + +The main Lumiera Mailinglist. All Discussion, developers and users happens here. + + +Lumiera-work +------------ + +List where automatic generated mails by the issue tracker and +continious integration will go to. + +No users may post to this list (gets ignored/dropped). + +Lumiera-cc +---------- + +List address:: lumiera-cc@lists.lumiera.org + +Sometimes we have some emails we want to be archived and distributed +among the developers. Like conference material/infos, +invoices etc. These are CC:'ed to this ML. No discussion happens +here. No public content here, but it's not hidden either. + +Server +------ + +List address:: server@lists.lumiera.org + +The Server we have is shared between multiple people. Administration +discussion and issues which cover the Server as whole (and are not +Lumiera specific) happen here. This mailinglist is a closed group of +people and only people who are related to the server ins some way are +subscribed. + diff --git a/doc/technical/infra/Webserver/Webserver.txt b/doc/technical/infra/Webserver/Webserver.txt new file mode 100644 index 000000000..f110c1acc --- /dev/null +++ b/doc/technical/infra/Webserver/Webserver.txt @@ -0,0 +1,112 @@ +Webserver Configuration +======================= +:Author: cehteh +:Date: Nov 2018 + + +Here are some annotations which websites are available. Who is +responsible for the administration and how to improve the websites. + + +Websites +-------- + +https://lumiera.org https://www.lumiera.org +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The main Website. + +- Data is in '/var/www'. The Website is a git repository. +- Configuration is at '/etc/apache2/sites-available/lumiera.conf' +- cehteh cares for the administration. +- To proprose some changes clone the git repository and send a + notfication/merge-request to the mailinglist. + +Some directories symlink to other directories (see below). + + +https://staging.lumiera.org +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Testing repository for the Website. Web development is done and +reviewed here before it gets pushed to the main Website. + +- Data is in '/var/www-staging'. The Website is a git repository. +- Configuration is at '/etc/apache2/sites-available/staging.conf' +- cehteh cares for the administration. +- To proprose some changes clone the git repository and send a + notfication/merge-request to the mailinglist. + + +https://git.lumiera.org +~~~~~~~~~~~~~~~~~~~~~~~ + +The gitweb interface to all public git repositories hosted on the server. + +- Configuration is at '/etc/apache2/sites-available/gitweb.conf' +- cehteh (and sometimes ichthyo) cares for the administration. + + + +https://issues.lumiera.org +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Trac issue tracker. + +- Configuration is at '/etc/apache2/sites-available/trac.conf' +- ichthyo cares for the administration. + + +https://static.lumiera.org +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Hosting big static files (media, videos, pictures) + +- Data is in '/var/local/www_static'. The Website is a git-annex repository. +- Configuration is at '/etc/apache2/sites-available/static.conf' +- cehteh cares for the administration. +- we have a 'sample_archive' for some test-media/video files + there. People can contribute more media, ask on the mailinglist for + details. +- Data will be placed there 'on-demand'. Don't forget to 'git annex add' the files. + + +Directories +----------- + +Some noteable directories. + +/git /var/local/git/ +~~~~~~~~~~~~~~~~~~~~ +Directories and symlinks to public git repositories served by the git +daemon and gitweb. + +/var/local/tiddly/ +~~~~~~~~~~~~~~~~~~ +Git repository with the tiddlywiki used for some work notes during development. + +/var/local/www_debian/ +~~~~~~~~~~~~~~~~~~~~~~ +Debian package pool maintained by ichthyo. + + +/var/local/doxy/ +~~~~~~~~~~~~~~~~ +API-Documentation generated by 'doxygen'. + + +/var/local/gitmob/ +~~~~~~~~~~~~~~~~~~ +Public writable git repositories for receiving small and easy +contributions. + +/var/local/rsyncd_incoming/ +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Upload directory where people can rsync data. + +/var/local/www_documentation/ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Clone of the lumiera source repository to serve the documentation within. + + + From 643779c4a2864346cd6f23bfe8871b268286f0e8 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 2 Sep 2025 02:20:39 +0200 Subject: [PATCH 18/51] Review: integrate Christian's improvements to the website build Christian started a series of reworks in 2018; the result was considered experimental and was parked on website-staging ever since. As part of the current release- and clean-up activities I now reviewed and integrated those changes into the current website as far as applicable. --- wiki/thinkPad.ichthyo.mm | 534 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 516 insertions(+), 18 deletions(-) diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 2b12745f2..8b5f8105c 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -156275,7 +156275,7 @@ std::cout << tmpl.render({"what", "World"}) << s - + @@ -159529,6 +159529,71 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + +

+ in Debian: linkchecker +

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

+ +

+

+ Beispielaufruf: +

+

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

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

+ Vorsicht mit dem user agent +

+ + + + + + + + + + @@ -159715,7 +159780,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -160998,6 +161063,20 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + +

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

+

+ Subdir: ichthyo +

+ + + + @@ -161050,6 +161129,85 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + +

+ heute ist OpenGL ein Zugang zu einem computation device +

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

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

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

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

+ + + + + + + + + + + + + + + + @@ -161334,7 +161492,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + @@ -161455,6 +161617,56 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + +

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

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

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

+

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

+ + + + + + + + + + + + + + + + + + + + + @@ -161782,14 +161994,14 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - + @@ -162158,7 +162370,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -162216,7 +162428,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -162268,8 +162480,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + @@ -162306,7 +162518,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -162328,6 +162540,295 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + +

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

+ + + + + + + +

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

+

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

+

+ +

+

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

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

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

+

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

+

+ +

+

+ Review: Website infrastructure improvements by Cehteh from 2018 +

+

+ +

+

+ Regrouped thematically: +

+

+ - generic improvements of build_website.sh +

+

+ - additional features (Linkchecking, cleaning) +

+

+ - website maintainance and fixing of broken links +

+

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

+

+ +

+

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

+

+ Ad9LAP9rje8hIMWOY6gV5UnrbJ0+wnopy4j6GxRMWxMSoPpWVwD5AQ4HRKh9tdKe +

+

+ cz2r08O5G0ofTTc5fnV0GSXTZZq02g0= +

+

+ =ZDyL +

+

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

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

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

+ + + + + + + + +

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

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

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

+

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

+ + + + + + + + + + + + + + + + + + + + + @@ -170007,16 +170508,13 @@ Since then others have made contributions, see the log for the history. - - - +

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

- - + @@ -171231,7 +171729,7 @@ Since then others have made contributions, see the log for the history. - + @@ -171285,12 +171783,12 @@ Since then others have made contributions, see the log for the history. - +

- Wichtig: hier nur was wirklich gebaut ist und funktioniert! + Wichtig: auf der Doku-Seite zum Paket nur was wirklich gebaut ist und funktioniert!

From 25eb6a61e39e0f968a087f0ffce6af7cba025145 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 2 Sep 2025 19:42:49 +0200 Subject: [PATCH 19/51] clean-up: link maintenance - use HTTPS - avoid redirects - supply Archive.org snapshots for old resources --- doc/design/application/Config.txt | 2 +- doc/design/engine/PlayModes.txt | 3 +- .../GuiDiscussion/ConceptProposals/Barnes.txt | 2 +- .../GuiBrainstormingReviewed.txt | 7 ++-- .../GuiBrainstormingWontImplement.txt | 3 +- .../gui/GuiDiscussion/TimelineDiscussion.txt | 4 +- doc/design/gui/GuiDiscussion/Workspaces.txt | 2 +- doc/devel/meeting_summary/2008-09-04.txt | 2 +- doc/devel/meeting_summary/2008-12-10.txt | 4 +- doc/devel/meeting_summary/2011-03-09.txt | 2 +- doc/devel/meeting_summary/2011-04-13.txt | 2 +- doc/devel/meeting_summary/2012-09-12.txt | 5 ++- doc/devel/meeting_summary/2013-09-12.txt | 2 +- doc/devel/meeting_summary/2023-11-08.txt | 2 +- doc/devel/meeting_summary/2024-01-10.txt | 2 +- doc/devel/meeting_summary/index.txt | 4 +- doc/devel/report.txt | 12 ++---- doc/devel/rfc/AllPluginInterfacesAreC.txt | 2 +- doc/devel/rfc/ArchitectureOverview.txt | 7 +--- doc/devel/rfc/CCodingStyleGuide.txt | 3 +- doc/devel/rfc/CodingStyle.txt | 2 +- doc/devel/rfc/ConfigLoader.txt | 2 +- doc/devel/rfc/DelectusShotEvaluator.txt | 5 ++- doc/devel/rfc/DesignParamAutomation.txt | 2 +- doc/devel/rfc/DesignRenderNodesInterface.txt | 6 +-- doc/devel/rfc/LumieraDesignProcess.txt | 2 +- doc/devel/rfc/Manifest.txt | 6 +-- doc/devel/rfc/MarbleMode.txt | 2 +- doc/devel/rfc/MistakestoAvoid.txt | 2 +- doc/devel/rfc/NoBugFlags.txt | 9 ++-- doc/devel/rfc/OfficialAssemblyLanguage.txt | 4 +- doc/devel/rfc/TagCloudsOnResources.txt | 2 +- doc/devel/rfc/UnitTests_Python.txt | 4 +- doc/index.txt | 42 +++++++++---------- doc/technical/build/BuildDependencies.txt | 2 +- doc/technical/build/BuildDroneDraft.txt | 36 ++++++++-------- doc/technical/build/SCons.txt | 6 +-- doc/technical/build/index.txt | 2 +- doc/technical/code/CodingGuidelines.txt | 2 +- doc/technical/code/GitBranching.txt | 2 +- doc/technical/code/LinkingStructure.txt | 10 ++--- doc/technical/code/index.txt | 2 +- doc/technical/howto/DebugGdbPretty.txt | 2 +- doc/technical/howto/UsingBoost.txt | 2 +- doc/technical/howto/index.txt | 4 +- doc/technical/index.txt | 10 ++--- doc/technical/infra/debianDepot.txt | 4 +- doc/technical/library/Dependencies.txt | 6 +-- doc/technical/library/DiffFramework.txt | 4 +- doc/technical/library/iterator.txt | 4 +- doc/technical/overview.txt | 6 +-- doc/technical/stage/style/index.txt | 30 +++++++------ doc/technical/steam/index.txt | 2 +- doc/technical/vault/scheduler.txt | 2 +- doc/user/intro/intro.txt | 2 +- doc/user/tutorials/DebianBuilding.txt | 3 +- doc/user/tutorials/building.txt | 20 ++++----- doc/user/tutorials/contributing.txt | 6 +-- doc/user/tutorials/index.txt | 2 +- 59 files changed, 170 insertions(+), 163 deletions(-) diff --git a/doc/design/application/Config.txt b/doc/design/application/Config.txt index e6cbaf1e7..dec73272b 100644 --- a/doc/design/application/Config.txt +++ b/doc/design/application/Config.txt @@ -10,6 +10,6 @@ The Lumiera application uses two quite different sources for configuration to be resolve employing a rules based system '(planned)'. Configuration rules will be provided by the application (defaults), a session template and rules stored in the actual session. --> see also the link:{ldoc}/technical/vault/ConfigLoader.html[Config Loader brainstorming from 2008] (implementation details) +-> see also the link:rfc/ConfigLoaderDraft2008.html[Config Loader brainstorming from 2008] (implementation details) diff --git a/doc/design/engine/PlayModes.txt b/doc/design/engine/PlayModes.txt index d616aff9e..8e95583a3 100644 --- a/doc/design/engine/PlayModes.txt +++ b/doc/design/engine/PlayModes.txt @@ -55,8 +55,7 @@ Requirement analysis of playback modes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For the task of editing a piece of media, the following modes of playback presentation can be determined + See also the more -link:wiki/renderengine.html#NonLinearPlayback%20PlayService%20PlayProcess%20CalcStream%20FrameDispatcher%20OutputManagement[ -technical discussion of playback in the TiddlyWiki] +link:imp/NonLinearPlayback.html[technical discussion of non-linear playback] regular playback:: diff --git a/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt b/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt index b97a18128..b91be4aed 100644 --- a/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt +++ b/doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt @@ -3,7 +3,7 @@ GUI Proposal by Clay Barnes :Author: R. Clayton Barnes (»rcbarnes«) :Date: 2008-05-21 --> https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry] +-> https://web.archive.org/web/20120128160238/https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry] .About the Author *********************************************************************************************************** diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt index ca21bc5ab..5e63fa8af 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt @@ -112,7 +112,8 @@ Can open Windows on different heads of the same server, and is aware of the exis -- * Multi-Head != Xinerama ... This is very important and quite common, We want to support monitors driven at the native Video Format (resolution, framerate, interlacing, overscan, ....). For a professional setup this is really required! -- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] + -Xinerama and twinView test comparison http://www.phoronix.com/scan.php?page=article&item=387&num=1[] + +* Xinerama and twinView test comparison -> https://www.phoronix.com/review/387[see @Phoronix...] -- * Automatic Clip Creation based on video content. + @@ -182,7 +183,7 @@ Widgets * Generalized Fader + -image:images/fader.png[fader.png] +image:/images/fader.png[fader.png] + All faders are the same kind of custom widget, that is: @@ -222,7 +223,7 @@ Partially, this is covered by the Adaptive Mouse Wheel too; but, especially when - Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below). -- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] - - This concept of "magnifying faders", is well explained in http://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation. + - This concept of "magnifying faders", is well explained in https://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation. -- link:oracle2025[] [[DateTime(2008-02-08T00:40:05Z)]] - Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate. diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt index 8a3f92e15..55c0fdddc 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt @@ -10,7 +10,8 @@ Sometimes help files and tutorials are improvable. Keeping track of which help i -- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:47:35Z)]] * Suggest an improvement Feature - for users to help improvement + -Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. Or get sent to a link:BrainStorming[] page like this one (specifically for the panel they were in). +Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. +Or get sent to a ``BrainStorming'' page like this one (but marked specifically for the panel they were in). -- link:Tree[][[DateTime(2008-05-26T12:01:00NZ)]] - This isn't really a GUI issue - much of this is more for the website, which the GUI will probably link to from an item in the help menu. diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt index 6c6c2a6e9..502cd8f21 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt @@ -6,10 +6,12 @@ Timeline: Discussion This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome. * Avid vs FCP 2006 - http://www.fini.tv/articles/avidfcp2006.html[] + Archived 2008 from https://web.archive.org/web/20071211184722/http://www.fini.tv/articles/avidfcp2006.html[fini.tv] * Final Cut Pro 5 - A First Look - http://www.kenstone.net/fcp_homepage/fcp_5_new_martin.html[] - * SpeedEdit Tutorials - http://www.newtek.com/speededit/tutorials/index.php[] + * SpeedEdit Tutorials + + 'http://www.newtek.com/speededit/tutorials/index.php' ~[red]#dead link#~ Brainstorming diff --git a/doc/design/gui/GuiDiscussion/Workspaces.txt b/doc/design/gui/GuiDiscussion/Workspaces.txt index 3e42239f0..937458a5e 100644 --- a/doc/design/gui/GuiDiscussion/Workspaces.txt +++ b/doc/design/gui/GuiDiscussion/Workspaces.txt @@ -83,7 +83,7 @@ reach a menu entry. (same for looking around to check information on the status of the window which has focus anyways). And last but not least, the current GDL docks implement thir own drag handles, moving windows around has a big performance problem with some window managers, moving windows shall be the job of the window manager and not the job of the application, the only thing the application may do is hinting positions to the -WM. These second class dock windows are neither ICCCM conforming (http://tronche.com/gui/x/icccm/[]) nor do they add any +WM. These second class dock windows are neither https://tronche.com/gui/x/icccm/[ICCCM] conforming nor do they add any extra user experience, instead the user has to learn a new kind of window class. + -- link:ct[] [[DateTime(2009-01-29T03:15:03Z)]] diff --git a/doc/devel/meeting_summary/2008-09-04.txt b/doc/devel/meeting_summary/2008-09-04.txt index dbb7b0e5a..903756d79 100644 --- a/doc/devel/meeting_summary/2008-09-04.txt +++ b/doc/devel/meeting_summary/2008-09-04.txt @@ -71,4 +71,4 @@ Comment ~~~~~~~ re "ichthyo asks for help setting up a test/build server" for "Debian" -see "Build Server" at http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming?action=edit&editor=gui[] +see "Build Server" at [purple]## diff --git a/doc/devel/meeting_summary/2008-12-10.txt b/doc/devel/meeting_summary/2008-12-10.txt index 412a89a95..8e65b80fc 100644 --- a/doc/devel/meeting_summary/2008-12-10.txt +++ b/doc/devel/meeting_summary/2008-12-10.txt @@ -23,12 +23,12 @@ __Participants__ The Lumiera Logo ---------------- -The logo contest is a great success: http://www.pipapo.org/pipawiki/Lumiera/Logos[105 entries]. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection[presented] so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight. +The logo contest is a great success: *105 entries*. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are presented ([purple]#`http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection`#) so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight. Recurring Topics ---------------- -Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. EDL vs Sequence diff --git a/doc/devel/meeting_summary/2011-03-09.txt b/doc/devel/meeting_summary/2011-03-09.txt index 34d372a44..3e30b4da6 100644 --- a/doc/devel/meeting_summary/2011-03-09.txt +++ b/doc/devel/meeting_summary/2011-03-09.txt @@ -100,7 +100,7 @@ are fine though. VoIP discussions over Mumble? ----------------------------- -There seems to be link:http://kitenet.net/~joey/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux. +There seems to be https://joeyh.name/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux. It was decided that while the idea is nice, it will not be used for developer meetings. We might use it for developer discussions outside meetings if we feel diff --git a/doc/devel/meeting_summary/2011-04-13.txt b/doc/devel/meeting_summary/2011-04-13.txt index 08de58437..af8d619b6 100644 --- a/doc/devel/meeting_summary/2011-04-13.txt +++ b/doc/devel/meeting_summary/2011-04-13.txt @@ -28,7 +28,7 @@ _Francesco Siddi_ has augmented his Layout proposal and already built up two pag cover most of the layout needs of the Lumiera website and documentation resources. However, some points with the code generated by Asciidoc turned out to be problematic. -In a link:http://permalink.gmane.org/gmane.comp.video.lumiera.general/2330[message preceeding the meeting], +In a https://lists.lumiera.org/pipermail/lumiera/2011-April/002418.html[message preceeding the meeting], today _ichthyo_ highlighted some general concerns which might need further discussion and maybe a decision. diff --git a/doc/devel/meeting_summary/2012-09-12.txt b/doc/devel/meeting_summary/2012-09-12.txt index 97d961efa..3b52a5331 100644 --- a/doc/devel/meeting_summary/2012-09-12.txt +++ b/doc/devel/meeting_summary/2012-09-12.txt @@ -20,7 +20,7 @@ RFCs ---- It was not clear what state -link:{ldoc}/devel/rfc.html[RFCs] have in our +link:/x/DesignProcess.html[RFCs] have in our documentation structure. The question was if they should, after becoming finalized integrated into some other document or stay first class and be referenced from other documents. @@ -101,7 +101,8 @@ A complete rewrite of Builddrone (a continuous integration system) is now (almost) finished and will be deployed on our build server within the next days. It has numerous improvements over the old one. More information and documentation will appear at -https://builddrone.pipapo.org/ soon. Stay tuned. +https://web.archive.org/web/20221205192908/https://builddrone.pipapo.org/[builddrone.pipapo.org] +soon. Stay tuned. Thanks to Lenny for helping with the documentation and Simon for the Logo. diff --git a/doc/devel/meeting_summary/2013-09-12.txt b/doc/devel/meeting_summary/2013-09-12.txt index ae5ab1243..1130824d7 100644 --- a/doc/devel/meeting_summary/2013-09-12.txt +++ b/doc/devel/meeting_summary/2013-09-12.txt @@ -60,7 +60,7 @@ Scheduler: Interface and requirements ------------------------------------- _Benny_ showed interest to work on that topic. The first step would be to build or use a priority queue textbook implementation as starting point. Some time ago, _cehteh_ included -a suitable implementation in his link:http://git.pipapo.org/?p=cehsrc;a=summary[cehlib],a +a suitable implementation in his https://git.pipapo.org/cehteh/cehsrc[cehlib],a collection of basic C library routines, mostly extracted from Lumiera's library. _ichthyo_ integrates this priority queue into the Lumiera tree. diff --git a/doc/devel/meeting_summary/2023-11-08.txt b/doc/devel/meeting_summary/2023-11-08.txt index 4bbde8449..920ec6fed 100644 --- a/doc/devel/meeting_summary/2023-11-08.txt +++ b/doc/devel/meeting_summary/2023-11-08.txt @@ -35,7 +35,7 @@ https://web.archive.org/web/20090129083001/https://www.linux.com/feature/126441[ and remove a ^[citation needed]^ tag. -> see the reworked -{l}/project/index.html[``About''] and {l}/project/faq.html[``FAQ''] pages + +link:/project/index.html[``About''] and link:/project/faq.html[``FAQ''] pages + -> section in the https://en.wikipedia.org/wiki/Cinelerra#Lumiera[Wikipedia page for Cinelerra]. diff --git a/doc/devel/meeting_summary/2024-01-10.txt b/doc/devel/meeting_summary/2024-01-10.txt index 90265a892..e6c6ed32e 100644 --- a/doc/devel/meeting_summary/2024-01-10.txt +++ b/doc/devel/meeting_summary/2024-01-10.txt @@ -4,7 +4,7 @@ :Date: 2024-01-20 Jan 10, 2024 -on {l}/project/contact.html#_irc[`#lumiera`] +on link:/project/contact.html#_irc[`#lumiera`] 20:00 - 23:00 UTC + __Participants__ diff --git a/doc/devel/meeting_summary/index.txt b/doc/devel/meeting_summary/index.txt index 52c26ee7f..0649bf9f6 100644 --- a/doc/devel/meeting_summary/index.txt +++ b/doc/devel/meeting_summary/index.txt @@ -327,7 +327,7 @@ Topics * organisational (protocol, agenda, leftovers?) * Logo Contest progress, discussion about how to do the pre selection * rename "EDL" into "Sequence" - * link:DesignProcess/TimelineSequenceOutput[Project, Timeline(s), Sequence(s) and Output] + * link:/documentation/devel/rfc/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] * GUI/Proc Interface and collaboration * Threading questions regarding gtk-main and main() @@ -522,7 +522,7 @@ Summary Topics ~~~~~~ * Who will write the protocol below - * Discuss the open points in link:Lumiera/DesignProcess[] do we need this formalism? + * Discuss the open points in a link:/x/DesignProcess[»Design Process«] -- do we need this formalism? * Who works on what, what are the short term goals, what tasks are open * State of the new-name search for the was-intended-as-cinelerra-3 project (no name discussion, just how we will progress!) * Introduce the development model diff --git a/doc/devel/report.txt b/doc/devel/report.txt index 4d7bca080..1faa55e65 100644 --- a/doc/devel/report.txt +++ b/doc/devel/report.txt @@ -6,29 +6,23 @@ Statistics and Reports ++++++++++++++++++++++++++++++++++++++
- +
++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++
- +

++++++++++++++++++++++++++++++++++++++ '''' -^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://blog.openhub.net/about/[OpenHub]«, +^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://openhub.net[OpenHub]«, formerly known as »Ohloh« is a public directory and networking site for free and open source software (FOSS), offering analytics and search services for evaluating and comparing open source projects.]^ -Mailing List ------------- - -image:http://gmane.org/plot-rate.php?group=gmane.comp.video.lumiera.general[Lumiera Mailinglist activity] + -^activity stats by link:http://dir.gmane.org/gmane.comp.video.lumiera.general[Gmane.org]^ - Tickets ------- diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 2ee7b40ca..00558497e 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -39,7 +39,7 @@ Implementation Proposal * first member is a _size_ which will be initialized by the actual implementation * followed by function pointers defining the interface, see: - link:Lumiera/DesignProcess/CCodingStyleGuide[] + link:{ldoc}/devel/rfc/CCodingStyleGuide.html[C-coding style guide] * everything added is considered immutable for this interface version * new functions are added to the end (thus changing size) diff --git a/doc/devel/rfc/ArchitectureOverview.txt b/doc/devel/rfc/ArchitectureOverview.txt index 4ece11a7c..79a03f1fc 100644 --- a/doc/devel/rfc/ArchitectureOverview.txt +++ b/doc/devel/rfc/ArchitectureOverview.txt @@ -40,11 +40,8 @@ Description Comments -------- - * Alcarinque made link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.html[some - design drafts] for the UI. Here is the - link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.svg[SVG source] (converted - from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just - an idea. + * Alcarinque made link:/x/Proposal.Alcarinque.html[some design drafts] for the UI. + + This is not a technical draft at all, it is just an idea. * Wouldn't the Config Rules (embedded Prolog) also interact with the High Level Model? Or would that be expanding its scope too much? I imagine diff --git a/doc/devel/rfc/CCodingStyleGuide.txt b/doc/devel/rfc/CCodingStyleGuide.txt index 7325b3961..25281d8ef 100644 --- a/doc/devel/rfc/CCodingStyleGuide.txt +++ b/doc/devel/rfc/CCodingStyleGuide.txt @@ -23,7 +23,8 @@ Description In the following I'll explain a C coding style I used frequently for other projects. Take this as suggestion for parts written in C (it definitely makes no sense for C++). We probably don't need to enforce this style for normal C -code, but for the related link:Lumiera/DesignProcess/AllPluginInterfacesAreC[] +code, but for the related +link:/rfc/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«] it really makes sense to have some well defined style. diff --git a/doc/devel/rfc/CodingStyle.txt b/doc/devel/rfc/CodingStyle.txt index 73d79ba94..1cef4e0a1 100644 --- a/doc/devel/rfc/CodingStyle.txt +++ b/doc/devel/rfc/CodingStyle.txt @@ -23,7 +23,7 @@ Description We need to agree on some coding style, IMHO consistency is the most important part with this, no matter which style we use. -See http://en.wikipedia.org/wiki/Indent_style[] +See https://en.wikipedia.org/wiki/Indentation_style[Wikipedia: Indentation Style] .Notes: * no tabs, use spaces! diff --git a/doc/devel/rfc/ConfigLoader.txt b/doc/devel/rfc/ConfigLoader.txt index 71c7b799b..6daa255ab 100644 --- a/doc/devel/rfc/ConfigLoader.txt +++ b/doc/devel/rfc/ConfigLoader.txt @@ -314,7 +314,7 @@ semantics notes: anchor:anchor_links[]links ~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html[] +https://specifications.freedesktop.org/basedir-spec/0.6/[] anchor:anchor_internals[]internals/implementation sketch diff --git a/doc/devel/rfc/DelectusShotEvaluator.txt b/doc/devel/rfc/DelectusShotEvaluator.txt index becb61afd..186769f87 100644 --- a/doc/devel/rfc/DelectusShotEvaluator.txt +++ b/doc/devel/rfc/DelectusShotEvaluator.txt @@ -23,7 +23,7 @@ http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[] -- the main discussion thread Additionally, a lot of great concepts for how to streamline the interface are -derived in part from link:KPhotoAlbum[]. +derived in part from https://www.kphotoalbum.org/[KPhotoAlbum]. I use tags, keywords, and metadata almost interchangeably, with the exception that metadata includes computer generated metadata as well. These are not tags @@ -376,7 +376,8 @@ Possible Collaboration with the people from Ardour? I guess if the thing can do all the things we talked about here, it would be perfectly suitable for sound classification too, and maybe could fill another gap in FOSS: Audio Archival Software, like this: -http://www.soundminer.com/SM_Site/Home.html[] (which is very expensive)... +https://web.archive.org/web/20100618104752/http://www.soundminer.com/SM_Site/Why_Buy.html[soundminer.com] +(which is very expensive)... maybe the Ardour people would be interested in a collaboration on this? I like the suggestion of sound classification with a similar (or, even better, diff --git a/doc/devel/rfc/DesignParamAutomation.txt b/doc/devel/rfc/DesignParamAutomation.txt index 9ed2d9b4a..4d1fc201a 100644 --- a/doc/devel/rfc/DesignParamAutomation.txt +++ b/doc/devel/rfc/DesignParamAutomation.txt @@ -52,7 +52,7 @@ So... A closely related issue is the handling of *Automation*. The current draft calls for an abstract interface "ParamProvider", which just allows the -link:Plugin/RenderComponent[] to pull a current value, without knowing if the +Plugin or RenderComponent to pull a current value, without knowing if the ParamProvider is a GUI widget or an automation data set with interpolation. The component using the param value should not need to do any interpolation. We should re-asses and refine this draft as needed. Note: Render Nodes are diff --git a/doc/devel/rfc/DesignRenderNodesInterface.txt b/doc/devel/rfc/DesignRenderNodesInterface.txt index b55402ede..bac8623e3 100644 --- a/doc/devel/rfc/DesignRenderNodesInterface.txt +++ b/doc/devel/rfc/DesignRenderNodesInterface.txt @@ -100,11 +100,11 @@ Rationale ~~~~~~~~~ The purpose of this Design Entry is to give a summary; the questions and the details of carrying out the operations are much more involved. - + + Please see the -http://www.lumiera.org/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)] +link/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)] and the -http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code] +https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/proc/engine/procnode.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=f9452f654cf39a4abbbeecfd81bef51aa347b321[Draft: ProcNode (src)] for details (and/or contact Ichthyo for in-depth discussion of those technical details) diff --git a/doc/devel/rfc/LumieraDesignProcess.txt b/doc/devel/rfc/LumieraDesignProcess.txt index 1c8331e74..a19afab99 100644 --- a/doc/devel/rfc/LumieraDesignProcess.txt +++ b/doc/devel/rfc/LumieraDesignProcess.txt @@ -35,7 +35,7 @@ planning: Tasks ~~~~~ - * We need to refine link:Lumiera/DesignProcessTemplate[]. + * We need to refine the `Lumiera/DesignProcessTemplate`. Pros ~~~~ diff --git a/doc/devel/rfc/Manifest.txt b/doc/devel/rfc/Manifest.txt index 8d27ceeb3..d90b4a89b 100644 --- a/doc/devel/rfc/Manifest.txt +++ b/doc/devel/rfc/Manifest.txt @@ -27,7 +27,7 @@ Background ~~~~~~~~~~ Cinelerra is quite an old project, there is an original version from -heroinewarrior.com and a community fork link:https://cinelerra-cv.wikidot.com/[Cinelerra-CV]. +Heroinewarrior.com and a community fork http://cinelerra-cv.wikidot.com/[Cinelerra-CV]. The original author claims that there was no-one producing useable input despite their requests while cinelerra was in development, and indeed the Cinelerra-CV community only feeds back the source released by the original author into their SVN repository @@ -49,8 +49,8 @@ But there are some bad things too. Notably there is not much progress on the community development. Users don't benefit from new improvements which other people have made. There is a endlessly growing list of bugs and feature requests, when someone sends a patch to the ML he has to invest quite some time -to maintain it until it might be merged. Finally we don't know what heroine -virtual is working on, until we see his next tarball. +to maintain it until it might be merged. Finally we don't know what ``Heroine +Virtual'' is working on, until we see his next tarball. Solution for Lumiera diff --git a/doc/devel/rfc/MarbleMode.txt b/doc/devel/rfc/MarbleMode.txt index 1a7be25c4..75568dc33 100644 --- a/doc/devel/rfc/MarbleMode.txt +++ b/doc/devel/rfc/MarbleMode.txt @@ -24,7 +24,7 @@ This proposal stems from an discussion on the Mailinglist starting with the quote from Walter Murch "Marble and Clay". + It is thought to be in support and to complement nasa's -link:DelectusShotEvaluator.html[Delectus Shot Evaluator] +link:/rfc/DelectusShotEvaluator.html[RfC: Delectus Shot Evaluator] The central Idea is to remove the difference between "viewing", i.e. the media viewer and the timeline/Sequence on the other hand. Lumiera is designed to diff --git a/doc/devel/rfc/MistakestoAvoid.txt b/doc/devel/rfc/MistakestoAvoid.txt index 4c671b8c8..cf61b8df3 100644 --- a/doc/devel/rfc/MistakestoAvoid.txt +++ b/doc/devel/rfc/MistakestoAvoid.txt @@ -262,7 +262,7 @@ Nuff said. Comments ^^^^^^^^ -Quote from Ohloh.net: (http://www.ohloh.net/projects/lumiera)[] +Quote from https://openhub.net/p/lumiera/[Openhub.net]: ------------------------------------------------------------ Extremely well-commented source code diff --git a/doc/devel/rfc/NoBugFlags.txt b/doc/devel/rfc/NoBugFlags.txt index 753ecd452..c2094bae0 100644 --- a/doc/devel/rfc/NoBugFlags.txt +++ b/doc/devel/rfc/NoBugFlags.txt @@ -12,14 +12,13 @@ NoBug logging flag hierachy link:NoBug[] logging flag hierachy ---------------------------------- -link:NoBug[] allows hierachical organization of logging flags. Propose a -documentation/planning about the setup. +https://nobug.pipapo.org/[NoBug] allows hierachical organization of logging flags. +Propose a documentation/planning about the setup. Description ~~~~~~~~~~~ Take a look at my draft at: -link:http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=doc/devel/nobug_flags.t -t;h=74471e255e6ebfedb642e450bdfd3f79e346c600;hb=backend[NoBug_flags] +https://git.lumiera.org/?p=LUMIERA;a=blob;f=doc/devel/nobug_flags.txt;h=325141acb52a7be7f75425359b6057c74ed30253;hb=a03e3c5e73a4c0be2264ac4e4e0f02eb8749837b[nobug_flags.txt] I've added the things I planning for the backend, others might add their own plans there too. So far this is an early draft, comments welcome. @@ -29,7 +28,7 @@ NOTE: outdated information. Have a look at `include/logging.h` Tasks ~~~~~ * Needs a file.c defining the common root see - link:Lumiera/DesignProcess/GlobalInitialization[] + link:{ldoc}/devel/rfc/GlobalInitialization.html[RfC: Global Initialization] * Everyone needs to setup this hierachy by NOBUG_DEFINE_FLAG_PARENT (flag, parent_flag); diff --git a/doc/devel/rfc/OfficialAssemblyLanguage.txt b/doc/devel/rfc/OfficialAssemblyLanguage.txt index a60444951..237b9d5ad 100644 --- a/doc/devel/rfc/OfficialAssemblyLanguage.txt +++ b/doc/devel/rfc/OfficialAssemblyLanguage.txt @@ -85,14 +85,14 @@ Alternatives * We only consider auto-vectorization -- GCC is attempting to convert trivial loops into common SSE patterns. Newer or Higher level instructions may not be supported by GCC. This is turned on - http://gcc.gnu.org/projects/tree-ssa/vectorization.html[in GCC4.3 with + https://gcc.gnu.org/projects/tree-ssa/vectorization.html[in GCC4.3 with specific compiler flags] * We can consider assembly but we don't officially support it -- We leave the holes there for people to patch up later. Unofficial ports may come up, and maybe a few years down the line we can reconsider assembly and start to reimplement it down the road. * Find a SIMD library for C/C++ -- Intel's ICC and - http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Vector-Extensions.html[GCC] both + https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Vector-Extensions.html[GCC] both have non-standard extensions to C that roughly translate to these instructions. There is also the http://www.pixelglow.com/macstl/valarray/[macstl valarray library] mentioned diff --git a/doc/devel/rfc/TagCloudsOnResources.txt b/doc/devel/rfc/TagCloudsOnResources.txt index 2c36d76dc..e3589f15f 100644 --- a/doc/devel/rfc/TagCloudsOnResources.txt +++ b/doc/devel/rfc/TagCloudsOnResources.txt @@ -70,7 +70,7 @@ Conclusion ---------- This Design Proposal is 'superseded' by a much more advanced proposal: -link:DelectusShotEvaluator[Delectus] +link:/rfc/DelectusShotEvaluator.html[Delectus] (Dropping it doesn't mean disapproval) diff --git a/doc/devel/rfc/UnitTests_Python.txt b/doc/devel/rfc/UnitTests_Python.txt index 9d71205e6..27b203893 100644 --- a/doc/devel/rfc/UnitTests_Python.txt +++ b/doc/devel/rfc/UnitTests_Python.txt @@ -74,9 +74,9 @@ Comments use to drive tests, should be something smaller and more sane than python. Needs certainly more discussion. For simple unit tests some C/C++ harness and bit shell scripting would suffice, I really want to integrate this with - link:NoBug[]. + https://nobug.pipapo.org/[NoBug]. -- link:ct[] [[DateTime(2007-06-17T17:32:27Z)]] '''' -Back to link:../DesignProcess[] +Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] diff --git a/doc/index.txt b/doc/index.txt index 9bc0f11e6..676804e85 100644 --- a/doc/index.txt +++ b/doc/index.txt @@ -51,7 +51,7 @@ the hierarchy, ==== The Uppermost Layer At the highest, uppermost layer is the document -https://lumiera.org/documentation/user/intro/intro.html[Lumiera (as seen) from Outer Space]. This is the node +link:user/intro/intro.html[Lumiera (as seen) from Outer Space]. This is the node on the left in the illustration above. All new to Lumiera should read this document. You can always return to this document later if you are entirely lost and wish to find your bearings before navigating into the deeper documentation dungeons. @@ -76,15 +76,15 @@ section has two main sections: [width="90%",frame="topbot",options="header",cols="^,2<"] |================================================================================================ |Sub-System|Remarks -|https://lumiera.org/documentation/design/architecture/index.html[Architecture]|Structure of Lumiera -|https://lumiera.org/documentation/design/gui/index.html[GUI]|The Lumiera ⟷ user interaction layer -|https://lumiera.org/documentation/design/model/index.html[Model]|Low-level and high-level models -|https://lumiera.org/documentation/design/engine/index.html[Engine]|Renderer, output generation, ... -|https://lumiera.org/documentation/design/lowlevel/index.html[Low-level]|Low-level and system services -|https://lumiera.org/documentation/design/application/index.html[Application]|Application framework -|https://lumiera.org/documentation/design/plugins/index.html[Plugins]|Dynamically loaded Extensions -|https://lumiera.org/documentation/design/workflow/index.html[Workflow]|Workflow and Interaction Design -|https://lumiera.org/documentation/design/governance/index.html[Governance]|Meta project concerns +|link:design/architecture/[Architecture]|Structure of Lumiera +|link:design/gui/[GUI]|The Lumiera ⟷ user interaction layer +|link:design/model/[Model]|Low-level and high-level models +|link:design/engine/[Engine]|Renderer, output generation, ... +|link:design/lowlevel/[Low-level]|Low-level and system services +|link:design/application/[Application]|Application framework +|link:design/plugins/[Plugins]|Dynamically loaded Extensions +|link:design/workflow/[Workflow]|Workflow and Interaction Design +|link:design/governance/[Governance]|Meta project concerns |================================================================================================ @@ -94,15 +94,15 @@ section has two main sections: [width="90%",frame="topbot",options="header",cols="^,2<"] |================================================================================================ |Sub-System|Remarks -|https://lumiera.org/documentation/technical/build/index.html[Build System]|Build, Packaging and CI -|https://lumiera.org/documentation/technical/stage/index.html[Stage]|GUI (technical aspects) -|https://lumiera.org/documentation/technical/steam/index.html[Steam]|Session and processing coordination -|https://lumiera.org/documentation/technical/vault/index.html[Vault]|Low-level operations -|https://lumiera.org/documentation/technical/library/index.html[Support lib]|Interface and support libraries -|https://lumiera.org/documentation/technical/code/index.html[Code base]|Code management, organisation, ... -|https://lumiera.org/documentation/technical/infra/index.html[Infrastructure]|Website and developer tooling ... -|https://lumiera.org/documentation/technical/howto/index.html[Developer HowTos]|Instructions and guides for developers -|link:/doxy/index.html[API Doc]|Using link:http://doxygen.org[Doxygen] to generate doc from code +|link:technical/build/[Build System]|Build, Packaging and CI +|link:technical/stage/[Stage]|GUI (technical aspects) +|link:technical/steam/[Steam]|Session and processing coordination +|link:technical/vault/[Vault]|Low-level operations +|link:technical/library/[Support lib]|Interface and support libraries +|link:technical/code/[Code base]|Code management, organisation, ... +|link:technical/infra/[Infrastructure]|Website and developer tooling ... +|link:technical/howto/[Developer HowTos]|Instructions and guides for developers +|link:/doxy/[API Doc]|Using https://www.doxygen.nl/[Doxygen] to generate doc from code |================================================================================================ @@ -113,13 +113,13 @@ mostly used as design notebook, featuring day-to-day design sketches, notes but quite some more persistent planning. Finished documentation text is constantly moved over to the documentation section(s) of the Lumiera website. --> access the Development link:{l}/wiki/renderengine.html[TiddlyWiki online here] +-> access the Development link:/wiki/renderengine.html[TiddlyWiki online here] == Media and Presentations == This section holds documents and materials used to present and promote Lumiera, articles, summaries and whitepapers - -> link:/media/index.html[Index] + -> link:/media/[Index] diff --git a/doc/technical/build/BuildDependencies.txt b/doc/technical/build/BuildDependencies.txt index 20ca64f97..38dfe9581 100644 --- a/doc/technical/build/BuildDependencies.txt +++ b/doc/technical/build/BuildDependencies.txt @@ -89,7 +89,7 @@ Libraries * BOOST * link:http://nobug.pipapo.org/[NoBug] -* http://gmerlin.sourceforge.net/gavl.html[GAVL] (for raw media support) +* https://github.com/bplaum/gavl[GAVL] (for raw media support) * ALSA: libasound2-dev * for the GUI: (*GTK-3*) gtkmm-3.0 gdlmm-3.0 glibmm-2.4 cairomm-1.0 xv - libgtkmm-3.0-dev diff --git a/doc/technical/build/BuildDroneDraft.txt b/doc/technical/build/BuildDroneDraft.txt index b3da2fddd..84cb38fb0 100644 --- a/doc/technical/build/BuildDroneDraft.txt +++ b/doc/technical/build/BuildDroneDraft.txt @@ -59,25 +59,25 @@ Ok that above doesnt look good, but would do the job with some efforts Now lets factor this to some shell functions: ------------------------------------------------------------ -function link:AddToReport[]() +function AddToReport() { cat >>,build_drone_report } -function link:GitPull[]() +function GitPull() { local dir="$1" local repo="${2:-origin}" local branch="${3:-master}" ACTION="GitPull $*" RESULT=FAILURE - cd "$dir" 2>&1 | link:AddToReport[] , return 1 - git pull "$repo" "$branch" 2>&1 | link:AddToReport[] , return 1 + cd "$dir" 2>&1 | AddToReport , return 1 + git pull "$repo" "$branch" 2>&1 | AddToReport , return 1 RESULT=SUCCESS return 0 } -function link:SendMail[] +function SendMail { cat ,build_drone_mail <{nbsp}{l}/project/background/GitFlow.html[Background Article]. First + -> link:/project/background/GitFlow.html[Background Article]. First link:https://nvie.com/posts/a-successful-git-branching-model/[published in 2010] by _Vincent Driessen_, meanwhile it is widely applied in projects with regular releases and external liabilities -- and often seen as the counterpoint to trunk centred diff --git a/doc/technical/code/LinkingStructure.txt b/doc/technical/code/LinkingStructure.txt index 54e3c8971..c1ab3700a 100644 --- a/doc/technical/code/LinkingStructure.txt +++ b/doc/technical/code/LinkingStructure.txt @@ -351,7 +351,7 @@ actively step by step Gui.resourcepath:: the place where the GTK-UI looks for further resources, most notably... Gui.stylesheet:: the name of the CSS-stylesheet for GTK-3, which defines the - application specific look, link:{ldoc}/technical/stage/style[styling and theme]. + application specific look, link:{ldoc}/technical/stage/style/[styling and theme]. While the first two steps, the relative locations `$ORIGIN/modules` and `$ORIGIN/setup.ini` are hard-wired, the further resolution steps rely on the contents of 'setup.ini' and are @@ -426,8 +426,8 @@ https://wiki.debian.org/RpathIssue[this Debian page] ] -- with the exception of intended for usage by the given executable or other libraries within the same source package. In the new system, the precedence order is as follows footnote:[see -http://linux.die.net/man/8/ld.so[ld.so manpage on die.net] or -http://manpages.ubuntu.com/manpages/lucid/man8/ld.so.8.html[ld.so manpage ubuntu.com (more recent)] ] +https://linux.die.net/man/8/ld.so[ld.so manpage on die.net] or +https://manpages.ubuntu.com/manpages/jammy/man8/ld.so.8.html[ld.so manpage ubuntu.com (more recent)] ] . `LD_LIBRARY_PATH` entries, unless the executable is `setuid`/`setgid` . `DT_RUNPATH` from the `.dynamic` section of that ELF binary, library or executable @@ -444,9 +444,9 @@ NOTE: The new-style `DT_RUNPATH` is not extended recursively when resolving tran visit _only_ the `RUNPATH` given in 'libB.so', but _not_ the `RUNPATH` given in 'libA.so' (to the contrary, the old `RPATH` used to visit all these locations). + This behaviour was chosen deliberately, in compliance with the ELF spec, as can be seen in this - link:https://sourceware.org/bugzilla/show_bug.cgi?id=13945[glibc bug #13945] and the + https://sourceware.org/bugzilla/show_bug.cgi?id=13945[glibc bug #13945] and the developer comment by - link:https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html[Roland McGrath from 2002] + https://sourceware.org/legacy-ml/libc-hacker/2002-11/msg00011.html[Roland McGrath from 2002] mentioned therein. diff --git a/doc/technical/code/index.txt b/doc/technical/code/index.txt index eaaffa3e4..df26c567c 100644 --- a/doc/technical/code/index.txt +++ b/doc/technical/code/index.txt @@ -46,7 +46,7 @@ Guidelines //// '''' - * also see the link:{ldoc}/devel/rfc.html[Design Process] for ongoing discussions + * also see the link:{ldoc}/devel/rfc/index.html[Design Process] for ongoing discussions * see the link:/devs-vault/[Developers Vault] for frequently used developer's resources diff --git a/doc/technical/howto/DebugGdbPretty.txt b/doc/technical/howto/DebugGdbPretty.txt index f26d09315..9f10f5661 100644 --- a/doc/technical/howto/DebugGdbPretty.txt +++ b/doc/technical/howto/DebugGdbPretty.txt @@ -38,7 +38,7 @@ from libstdcxx.v6.printers import register_libstdcxx_printers register_libstdcxx_printers (None) end ---- -For more informations link:http://sourceware.org/gdb/wiki/STLSupport[see here..] +For more informations https://sourceware.org/gdb/wiki/STLSupport[see here..] .Hello World [source,C] diff --git a/doc/technical/howto/UsingBoost.txt b/doc/technical/howto/UsingBoost.txt index 6e68963c8..76a06869b 100644 --- a/doc/technical/howto/UsingBoost.txt +++ b/doc/technical/howto/UsingBoost.txt @@ -3,7 +3,7 @@ Using Boost Libraries //Menu: label using Boost -_some arbitrary hints and notes regarding the use of link::http://www.boost.org[Boost Libraries] in Lumiera_ +_some arbitrary hints and notes regarding the use of https://www.boost.org/[Boost Libraries] in Lumiera_ Notable Features ---------------- diff --git a/doc/technical/howto/index.txt b/doc/technical/howto/index.txt index 6a32b998f..0f06aaf60 100644 --- a/doc/technical/howto/index.txt +++ b/doc/technical/howto/index.txt @@ -8,12 +8,14 @@ Developer HOWTOs This section contains a loose collection of instructions, recipes, tutorials and similar usefull pieces of information targeted at Lumiera developers. See also -- the general link:{l}/project/faq.html[Lumiera FAQ] +- the general link:/project/faq.html[Lumiera FAQ] - the link:{ldoc}/user/index.html[User documentation] - link::{ldoc}/technical/code/index.html[Codebase organisation] == Notepad - a link:crackNuts.html[collection] of solution ideas - link:DebugGdbPretty.html[Python pretty printers for GDB] +- link:IdeSetup.html[hints for using some IDE(s)] +- link:UsingBoost.html[some remarks regarding libBoost] - link:HashFunctions.html[Notes regarding standard hash functions] diff --git a/doc/technical/index.txt b/doc/technical/index.txt index aa1452023..f3ace95bd 100644 --- a/doc/technical/index.txt +++ b/doc/technical/index.txt @@ -17,7 +17,7 @@ link:overview.html[Lumiera the Inner Core] The technical documentation is split in three parts, one for each of the three main layers of Lumiera. You may want to read the -link:../design/index.html[Design Documents] first to get an overview of all the +link:{ldoc}/design/index.html[Design Documents] first to get an overview of all the components. * link:stage/index.html[*Stage Layer*] : Documents related to the GTK based Lumiera GUI @@ -30,13 +30,13 @@ components. == Tools .Development -* link:http://www.lumiera.org/doxy/[*Doxygen generated documentation*] : API documentation of the Lumiera code. +* link:/doxy/[*Doxygen* generated documentation] : API documentation of the Lumiera code. * organisation of the link:code/index.html[Code Base] in general -* link:code/codingGuidelines.html[Coding Style] and further guidelines +* link:/x/CodingGuidelines.html[Coding Style] and further guidelines .Building -* link:build/index.html[*Buildsystem*] : Installation & compilation tools, dependencies and packaging. +* link:build/index.html[Buildsystem] : Installation & compilation tools, dependencies and packaging. .HOWTO -* link:howto/index.html[*Developer HOWTOs*] : Collection of instructions, recipes, hints and similar +* link:/x/DevHowto.html[Developer *HOWTOs*] : Collection of instructions, recipes, hints and similar materials intended for developers diff --git a/doc/technical/infra/debianDepot.txt b/doc/technical/infra/debianDepot.txt index 16a29719e..bd9b2e439 100644 --- a/doc/technical/infra/debianDepot.txt +++ b/doc/technical/infra/debianDepot.txt @@ -6,7 +6,9 @@ Lumiera Debian Package and Depot maintainance //Menu: label Debian Depot This Debian-Depot is part of the Lumiera build infrastructure. -It is managed automatically, based on the link:http://mirrorer.alioth.debian.org/[reprepro] tool by Bernhard Link +It is managed automatically, based on the +https://salsa.debian.org/brlink/reprepro[reprepro] tool by Bernhard Link +-> https://manpages.debian.org/trixie/reprepro/reprepro.1.en.html[man page] The Lumiera debian package diff --git a/doc/technical/library/Dependencies.txt b/doc/technical/library/Dependencies.txt index 6379c450e..de5124447 100644 --- a/doc/technical/library/Dependencies.txt +++ b/doc/technical/library/Dependencies.txt @@ -126,7 +126,7 @@ _assuming full portability and arbitrary target platform._ Since our focus is pr this argument seems to lean more to the theoretical side though, since the x86/64 platform is known to employ rather strong memory and cache coherency constraints. With the recent advent of ARM systems, the situation has changed however. Anyway, since C++11 there -link:http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11[is now a portable solution available] +https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/[is now a portable solution available] for writing a correct DCL implementation, based on `std::atomic`. The idea underlying Double Checked Locking is to optimise for the access path, which is achieved by moving the @@ -136,7 +136,7 @@ and lock-free concurrency implement this relation by establishing a *synchronise on a common *guard* entity -- for traditional locking, this would be a Lock, Mutex, Monitor or Semaphore, while lock-free concurrency uses the notion of a _fence_ connected with some well defined action on a userspace guard variable. In modern C++, typically we use _Atomic variables_ as guard. In addition to well defined semantics regarding concurrent -visibility of changes, these link:http://en.cppreference.com/w/cpp/atomic["atomics"] offer indivisible access and +visibility of changes, these https://en.cppreference.com/w/cpp/atomic.html["atomics"] offer indivisible access and exchange operations. A correct concurrent interaction must involve some kind of well defined handshake to establish the aforementioned _synchronises-with_ relation -- otherwise we just can not assume anything. Herein lies the problem with Double Checked Locking: when we move all concurrency precautions away from the optimised access path, we get @@ -177,7 +177,7 @@ the actual costs of object allocation. Some observations: - The numbers obtained pretty much confirm - link:http://www.modernescpp.com/index.php/thread-safe-initialization-of-a-singleton[other people's measurments]. + http://www.modernescpp.com/index.php/thread-safe-initialization-of-a-singleton/[other people's measurments]. - Synchronisation is indeed necessary; the unprotected lazy init crashed several times randomly during multithreaded tests. - Contention on concurrent access is very tangible; diff --git a/doc/technical/library/DiffFramework.txt b/doc/technical/library/DiffFramework.txt index f8502f7fc..c8048f45d 100644 --- a/doc/technical/library/DiffFramework.txt +++ b/doc/technical/library/DiffFramework.txt @@ -136,7 +136,7 @@ permutation diff. If we thus consider -- in theory -- the _inserts_ and _deletes filtered away, what remains is a permutation of index numbers to cause the re-ordering. We may describe this re-ordering by the index numbers in the new sequence, given in the order of the old sequence. For such a re-ordering permutation, the theoretically optimal result -can be achieved by http://wikipedia.org/wiki/Cycle_sort[Cycle Sort] in _linear time_.footnote:[ +can be achieved by https://en.wikipedia.org/wiki/Cycle_sort[Cycle Sort] in _linear time_.footnote:[ assuming random access by index is possible, *Cycle Sort* walks the sequence once. Whenever encountering an element out-of order, i.e. new postion != current position, we leap to the indicated new position, which necessarily will be out-of-order too, so we can leap from there @@ -201,7 +201,7 @@ changes in hierarchical data: traverse the structure and account for each elemen Such a description of changes won't be _optimal_ though. What appears as a insertion or deletion locally, might indeed be just the result of rearranging subtrees as a whole. The _tree diff problem_ in this general form is known to be a rather tough challenge. But our goals are different here. Lumiera relies on a -link:{ldoc}/design/architecture/ExternalTreeDescription.html[»External Tree Description«] for +link:{ldoc}/design/architecture/ETD.html[»External Tree Description«] for _symbolic representation_ of hierarchically structured elements, without actually implementing them. The purpose of this ``external'' description is to largely remove the need for a central data model to work against. A _symbolic diff message_ allows to propagate data and structure changes, diff --git a/doc/technical/library/iterator.txt b/doc/technical/library/iterator.txt index 16de43426..e622d3a37 100644 --- a/doc/technical/library/iterator.txt +++ b/doc/technical/library/iterator.txt @@ -1,7 +1,7 @@ Iterators and Pipelines ======================= -The link:http://c2.com/cgi/wiki?IteratorPattern[Iterator Pattern] allows to +The http://wiki.c2.com/?IteratorPattern[Iterator Pattern] allows to expose the contents or elements of any kind of collection, set or container for use by client code, without exposing the implementation of the underlying data structure. Thus, iterators are one of the primary API building blocks. @@ -14,7 +14,7 @@ Unfortunately the C++ standard library uses a very elaborate and rather low-leve notion of iterators, which does not mix well with the task of building clean interfaces. Thus, within the Lumiera core application, we're using our own Iterator concept, -initially defined as link:{ldoc}/devel/rfc/LumieraForwardIterator.html[RfC], +initially defined as link:/x/rfc/LumieraForwardIterator.html[RfC], which places the primary focus on interfaces and decoupling, trading off readability and simplicity for (lesser) performance. diff --git a/doc/technical/overview.txt b/doc/technical/overview.txt index b4cee81b9..6649057bf 100644 --- a/doc/technical/overview.txt +++ b/doc/technical/overview.txt @@ -67,14 +67,14 @@ website you're reading right now. Besides that, a summary and introduction for various components can be found in the file-level doxygen comments, while details are usually explained in the class and function level comments. -==== the TiddlyWiki +==== the Development TiddlyWiki Currently, Lumiera is still in the design- and evolution phase. Documentation is written as an ongoing effort. There is an embedded JavaScript wiki (TiddlyWiki) within the source tree, mostly used as design notebook, featuring day-to-day design sketches and notes, but also quite some more persistent planning. Finished documentation text is constantly moved over to the documentation section(s) of the Lumiera website. + --> access the development link:{l}/wiki/renderengine.html[TiddlyWiki online here] +-> access the development link:/wiki/renderengine.html[TiddlyWiki online here] Test Driven Development @@ -888,7 +888,7 @@ with an type specific access functor. Together, this allows to translate transparently and typesafe from symbolic ID to object instance, which is an prerequisite for integrating a rules based system. Besides, these tables allow unique IDs per type + --> more details about this concept link:{l}/wiki/renderengine.html#EntryID%20TypedID%20TypedLookup[in the TiddlyWiki] +-> more details about this concept link:/wiki/renderengine.html#EntryID%20TypedID%20TypedLookup[in the TiddlyWiki] Allocators diff --git a/doc/technical/stage/style/index.txt b/doc/technical/stage/style/index.txt index 4438d64c2..fb1039eee 100644 --- a/doc/technical/stage/style/index.txt +++ b/doc/technical/stage/style/index.txt @@ -48,23 +48,28 @@ class constructor,_ which makes them more or less hard wired. The `Gtk::Widget` their own naming scheme, apart from the basic GTK+ (C language) names, and it is _basically not possible_ for _custom widgets_ to expose their distinct type names -- rather they will show up under the name of the base class used from Gtkmm.] Widgets may also expose CSS classes for styling -- the standard widgets define a generic set -of https://developer.gnome.org/gtk3/3.4/GtkStyleContext.html#gtkstylecontext-classes[predefined CSS style classes], +of https://docs.gtk.org/gtk3/class.StyleContext.html#style-classes-gtkstylecontext-classes[predefined CSS style classes], which can be used to establish the foundation for theming. Obviously it is preferable to keep styling rules as concise, generic and systematic as possible; yet we may still refer to individual GUI elements by name (`#ID`) though. Recommended reading ~~~~~~~~~~~~~~~~~~~ * for technically precise coverage, consult the pages - https://developer.gnome.org/gtk3/3.4/GtkCssProvider.html[GtkCssProvider] + https://docs.gtk.org/gtk3/class.CssProvider.html[GtkCssProvider] and - https://developer.gnome.org/gtk3/3.4/GtkStyleContext.html#gtkstylecontext-classes[predefined style classes] + https://docs.gtk.org/gtk3/class.StyleContext.html#style-classes-gtkstylecontext-classes[predefined style classes] in the GTK-3 reference manual. - * there is an https://developer.gnome.org/gtk3/stable/chap-css-overview.html[overview page in the developer manual], - and a https://developer.gnome.org/gtk3/stable/chap-css-properties.html[reference of supported properties]. - * to start, look at this http://thegnomejournal.wordpress.com/2011/03/15/styling-gtk-with-css/[introductory text], - or the more http://worldofgnome.org/making-gtk3-themes-part-1-basics/[hands-on series of articles from world of gnome] - * this http://forums.fedoraforum.org/showthread.php?t=281568[post from fedora forum] features a concise description - of the task of theme creation + * there is an + https://docs.gtk.org/gtk3/css-overview.html[overview page in the developer manual], + and a + https://docs.gtk.org/gtk3/css-properties.html[reference of supported properties]. + * to start, look at this https://thegnomejournal.wordpress.com/2011/03/15/styling-gtk-with-css/[introductory text], + or the more + https://web.archive.org/web/20201112013720/http://worldofgnome.org/making-gtk3-themes-part-1-basics/[hands-on series of articles from world of gnome] + * this + https://forums.fedoraforum.org/showthread.php?281568-Tutorial-for-making-GTK3-themes[post from fedora forum] + (https://web.archive.org/web/20250703120330/https://forums.fedoraforum.org/showthread.php?281568-Tutorial-for-making-GTK3-themes[Archive.org]) + features a concise description of the task of theme creation * to understand the old (now obsolete) GTK-2 stylesheets, you might http://orford.org/gtk/[look here] @@ -86,7 +91,8 @@ A good recommendation is really to ``probe'' settings by changing them temporari the GTK+ inspector ~~~~~~~~~~~~~~~~~~ An essential tool when working with styles and Gtk widgets in general is the -https://wiki.gnome.org/Projects/GTK%2B/Inspector[GTK+ inspector], which is part of the standard GTK distribution. +https://developer.gnome.org/documentation/tools/inspector.html[GTK+ inspector] +, which is part of the standard GTK distribution. It allows to inspect all GTK objects with their properties, and to see the actual tree of CSS nodes and the corresponding selectors. You can even add a style class or state flag (like ``hover'') dynamically, and you may add style rules and verify the effect on the application immediately. To use this ispector, launch the @@ -96,11 +102,11 @@ application like `GTK_DEBUG=interactive target/lumiera` binary themes ~~~~~~~~~~~~~ GTK-3 supports binary theme bundles, which combine CSS style sheets and accompanying images and vector graphics -into a single archive file. See http://wibblystuff.blogspot.de/2012/06/building-binary-for-gtk3-theme.html[this blog entry] +into a single archive file. See https://wibblystuff.blogspot.com/2012/06/building-binary-for-gtk3-theme.html[this blog entry] for a tutorial. But when it comes to investigating an existing theme, we need a way to 'extract' the original sources from such a distribution bundle. This can be achieved with the help of the `gresource` command. The following bash script footnote:[published by mailto:peter@thecodergeek.com[Peter Gordon] to the Public Domain -http://projects.thecodergeek.com/scripts/gresource-extract[at his blog] in 2012] simplifies this process, allowing +https://projects.thecodergeek.com/scripts/gresource-extract[at his blog] in 2012] simplifies this process, allowing to extract all resource files in a given GResource file, with the given base URL. For example, if a GResource file contained the resource with the URL `/org/foo/bar/baz.txt`, and the base URL defined as `"/org/foo/"`, then the resource named `/org/foo/bar/baz.txt` in that file would be extracted and written to `bar/baz.txt` in the current directory. diff --git a/doc/technical/steam/index.txt b/doc/technical/steam/index.txt index af5f57e74..56c69524b 100644 --- a/doc/technical/steam/index.txt +++ b/doc/technical/steam/index.txt @@ -21,7 +21,7 @@ While additions to the TiddlyWiki generally propagate to Lumiera/Master through the normal merges, we've put up a rsynced version of the TiddlyWiki online for direct access (of course read-only). --> access the Proy-Layer link:{l}/wiki/renderengine.html[TiddlyWiki online here] +-> access the Proy-Layer link:/wiki/renderengine.html[TiddlyWiki online here] diff --git a/doc/technical/vault/scheduler.txt b/doc/technical/vault/scheduler.txt index 508cce15e..88bf9e9c0 100644 --- a/doc/technical/vault/scheduler.txt +++ b/doc/technical/vault/scheduler.txt @@ -7,7 +7,7 @@ ordered by priority and observing specific timing constraints. NOTE: Subject to [yellow-background]#active design and implementation# work as of 10/2023 Work-in-progress documentation can be found in the -link:{l}/wiki/renderengine.html#PlaybackVerticalSlice%20RenderEngine%20Scheduler%20SchedulerWorker%20SchedulerMemory%20RenderActivity%20Player%20FrameDispatcher%20JobPlanningPipeline%20PlayProcess%20Rendering%20ProcNode%20NodeOperationProtocol[Tiddly Wiki] +link:imp/PlaybackVerticalSlice.html[DevWiki: PlaybackVerticalSlice] About Jobs diff --git a/doc/user/intro/intro.txt b/doc/user/intro/intro.txt index 4a8f7e6d3..457d5b701 100755 --- a/doc/user/intro/intro.txt +++ b/doc/user/intro/intro.txt @@ -226,7 +226,7 @@ to facilitate automated processing. Now it is time to take a look at the preliminary Lumiera GUI: -image:{l}/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot] +image:/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot] We expect this GUI to change once we are at the point of having feedback from actual users. diff --git a/doc/user/tutorials/DebianBuilding.txt b/doc/user/tutorials/DebianBuilding.txt index 9337efb0a..1af8aa542 100644 --- a/doc/user/tutorials/DebianBuilding.txt +++ b/doc/user/tutorials/DebianBuilding.txt @@ -159,7 +159,8 @@ the package. With the exception of the following: - the top entry in the 'debian/changelog' defines the *actual package name and version* - the actual build process is conducted by invoking several pre defined targets in the 'debian/rules' *makefile*. But modern debian packages often make use of the ``common - debian build system'' link:http://build-common.alioth.debian.org/cdbs-doc.html[CDBS] -- + debian build system'' + https://web.archive.org/web/20170708155303/http://build-common.alioth.debian.org/cdbs-doc.html[CDBS] -- basically a set of macros allowing to write these _rules_ in a very short and concise fashion diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt index 68acaa3bf..becc7813f 100644 --- a/doc/user/tutorials/building.txt +++ b/doc/user/tutorials/building.txt @@ -49,19 +49,19 @@ then usually the build system is right...] More specifically, you'll need the GNU C/C\++ compiler with C++17 support (Version >= 7) in addition to the following tools and libraries: - * link:http://git-scm.com/[Git] (version management system) - * link:http://www.scons.org/[SCons build system] - * link:http://www.boost.org/[Boost libraries] - * link:http://gmerlin.sourceforge.net/[GAVL library] - * link:http://nobug.pipapo.org/[NoBug] (see below) + * https://git-scm.com/[Git] (version management system) + * https://www.scons.org/[SCons build system] + * https://www.boost.org/[Boost libraries] + * https://github.com/bplaum/gavl[GAVL library] + * https://nobug.pipapo.org/[NoBug] (see below) * Lumiera source code The GUI depends on the following: - * link:http://www.gtkmm.org/en/[gtkmm] - * link:http://cgit.freedesktop.org/xorg/lib/libXv[libXv] - * link:https://wiki.gnome.org/LibRsvg[lib rSVG] - * link:https://git.gnome.org/browse/gdl[lib GDL] + * https://gtkmm.gnome.org/en/[gtkmm] + * https://cgit.freedesktop.org/xorg/lib/libXv[libXv] + * https://wiki.gnome.org/Projects/LibRsvg[lib rSVG] + * https://gitlab.gnome.org/Archive/gdl.git[lib GDL] TIP: Generally speaking, when you want to build software, you'll need the _development_ version of the packages that contain the headers and pre-built @@ -213,7 +213,7 @@ Currently, this will bring up the GUI, _without any further functionality_ (!) You should see something like this: -image:{l}/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot] +image:/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot] What's next? diff --git a/doc/user/tutorials/contributing.txt b/doc/user/tutorials/contributing.txt index 5391bca0b..a647e7fcf 100644 --- a/doc/user/tutorials/contributing.txt +++ b/doc/user/tutorials/contributing.txt @@ -50,8 +50,8 @@ right away and present your first results to the _mob repository_. First steps with Git ^^^^^^^^^^^^^^^^^^^^ One very useful place to begin with learning Git is the -link:http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html[basic Git tutorial at Kernel.org]. + -For more specific questions, you might consulte a link:http://gitref.org/[Git reference] +https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html[basic Git tutorial at Kernel.org]. + +For more specific questions, you might consult a https://git-scm.com/docs[Git reference] In the following, we assume you have set up Git on your system. If you are experiencing problems with Git, just ask the Lumiera community. @@ -222,7 +222,7 @@ Besides, the Lumiera community generally meets on the second Thursday of each month at 20:00 UTC on IRC. All are more than welcome to join and to contribute to the discussions there. --> contact information link:{l}/project/contact.html[Mailing List & IRC] +-> contact information link:/project/contact.html[Mailing List & IRC] '''' diff --git a/doc/user/tutorials/index.txt b/doc/user/tutorials/index.txt index fd1d6ed59..eddb1bf03 100644 --- a/doc/user/tutorials/index.txt +++ b/doc/user/tutorials/index.txt @@ -8,5 +8,5 @@ This page contains tutorials for beginners interested in Lumiera development. * link:building.html[Building Lumiera from source] * link:DebianBuilding.html[Building from Debian source package] * link:contributing.html[Contributing to Lumiera] - ** link:{l}/project/contact.html[Mailing List & IRC] + ** link:/project/contact.html[Mailing List & IRC] From 217ec447c05b4e5f15661dd32c54f2637f92dc15 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 5 Sep 2025 03:17:43 +0200 Subject: [PATCH 20/51] DOC: reorganise time handling pages (use Linkfarm) Create a new subcategory "design/architecture/time" and rearrange several pages related to time handling and time codes. NOTE: starting with this changeset, a ''Link-Farm'' is required for cross-links; since we don't have an automatic solution for this task yet, I have created the necessary forwarding pages manually in the website repository. --- .../{playRender.txt => Playback.txt} | 16 +- doc/design/architecture/index.txt | 9 +- doc/design/architecture/time/TimeCode.txt | 13 + doc/design/architecture/time/TimeMutation.txt | 48 ++ .../architecture/{ => time}/TimeQuant.txt | 12 +- .../architecture/{ => time}/TimeUsage.txt | 18 +- doc/design/architecture/time/index.txt | 21 + doc/design/engine/PlayProcess.txt | 11 + doc/design/engine/index.txt | 2 +- doc/design/model/Segmentation.txt | 21 + doc/design/model/index.txt | 2 +- doc/devel/meeting_summary/2011-05-11.txt | 2 +- wiki/thinkPad.ichthyo.mm | 446 +++++++++++++++++- 13 files changed, 586 insertions(+), 35 deletions(-) rename doc/design/architecture/{playRender.txt => Playback.txt} (93%) create mode 100644 doc/design/architecture/time/TimeCode.txt create mode 100644 doc/design/architecture/time/TimeMutation.txt rename doc/design/architecture/{ => time}/TimeQuant.txt (97%) rename doc/design/architecture/{ => time}/TimeUsage.txt (93%) create mode 100644 doc/design/architecture/time/index.txt create mode 100644 doc/design/engine/PlayProcess.txt create mode 100644 doc/design/model/Segmentation.txt diff --git a/doc/design/architecture/playRender.txt b/doc/design/architecture/Playback.txt similarity index 93% rename from doc/design/architecture/playRender.txt rename to doc/design/architecture/Playback.txt index 9c866e0e1..f85f39685 100644 --- a/doc/design/architecture/playRender.txt +++ b/doc/design/architecture/Playback.txt @@ -3,7 +3,7 @@ Design: Playback and Render Control :Author: Ichthyostega :Date: 5/2011 -//MENU: label Player subsystem +//MENU: label Playback ************************************************************************************** This part of the architecture is concerned with how to initiate, coordinate and control @@ -24,10 +24,12 @@ discussions and brainstorming sessions. * discussions regarding time values and timecode handling shed some light on the requirements to be fulfilled by a player subsystem - - link:http://article.gmane.org/gmane.comp.video.lumiera.general/2116[Timecode Widget and Framerates] - - link:http://article.gmane.org/gmane.comp.video.lumiera.general/2109[Time, Time-spans, Quatisation and Timecode] - - link:{l}/wiki/renderengine.html#TimeQuant[Definition of Time entities] - from the implementation notes in the TiddlyWiki + - https://lists.lumiera.org/pipermail/lumiera/2010-July/001984.html[Timecode formats and time widget] + - https://lists.lumiera.org/pipermail/lumiera/2010-December/002197.html[Timecode Widget and Framerates] + - https://lists.lumiera.org/pipermail/lumiera/2010-December/002190.html[Time, Time-spans, Quatisation and Timecode] + + * at the _framework level_ a set of definitions has been created to handle + link:/x/TimeUsage.html[time values and quantisation]. Reasoning Behind the Player Subsystem's Structure @@ -152,8 +154,8 @@ reconfigure the vault layer services. Frame quantisation ^^^^^^^^^^^^^^^^^^ -link:../TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding, quantisation is -a dangerous operation because it kills information content. +link:/x/TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding, +quantisation is a dangerous operation because it kills information content. Thus, there are three fundamental guidelines when it comes to rounding: diff --git a/doc/design/architecture/index.txt b/doc/design/architecture/index.txt index 83dadaa02..f3b4468a0 100644 --- a/doc/design/architecture/index.txt +++ b/doc/design/architecture/index.txt @@ -5,7 +5,6 @@ Design Documents: Lumiera Architecture // Menu : prepend child Subsystems // Menu : prepend child ArchitectureSummary -// Menu : attach child TimeQuant after TimeUsage This section will feature some rather high-level considerations regarding the architecture of the application. @@ -14,6 +13,12 @@ the architecture of the application. See link:ArchitectureSummary.html[here] for a short summary of the core architecture ideas of the envisioned Lumiera Application. +.Time and Time-code +link:time/[Handling of time values] and link:time/TimeCode.html[Time Code] is +essential for an editing application and requires some forethought to avoid +some of the common inconsistencies and pitfalls; precision can be a challenge, +given the extremely large range of time scales to cover. + .Rendering and Playback Control This part of the architecture is concened with how to initiate, coordinate and control the calculation processes necessary to generate visible / audible data from our source @@ -21,6 +26,6 @@ media. This design is _not so much_ concerned with the actual calculations; inde takes on an ``bird eye's view'', treating the actual render engine mostly just as an opaque entity providing some service. --> link:playRender.html[Design: Playback and Rendering] +-> link:Playback.html[Design: Playback and Rendering] diff --git a/doc/design/architecture/time/TimeCode.txt b/doc/design/architecture/time/TimeCode.txt new file mode 100644 index 000000000..0baa901c9 --- /dev/null +++ b/doc/design/architecture/time/TimeCode.txt @@ -0,0 +1,13 @@ +Handling of Time Code Formats +============================= + +.A Design draft +Since handling of time values and time code formats is of uttermost importance +for editing film, a draft concept was created in the early phase of Lumiera design. +The chosen approach relies heavily on a framework for representation of temporal data +developed for this purpose in the Lumiera support library. However, the implementation +of various actual time code formats was deferred for later -- while the viability of +this design yet needs to be validated by actual usage. + +Detailed analysis and planning can be found in the +link:/x/fwd/DevWiki.TimeCode.html[DevWiki: TimeCode]. diff --git a/doc/design/architecture/time/TimeMutation.txt b/doc/design/architecture/time/TimeMutation.txt new file mode 100644 index 000000000..42c21b5fb --- /dev/null +++ b/doc/design/architecture/time/TimeMutation.txt @@ -0,0 +1,48 @@ +Modify Quantised Time Values +============================ + +.Challenges +Temporal data can be complex and given in several flavours; a request to _modify_ +some given time data adds a further layer of complexity, since the required modification +can itself be specified in various forms. And on top of that, the temporal data can be +quantised, or can be represented through a quantised view, while also the modification +can be given in any form of quantification, even based on a different time grid. +When it comes to resolving this kind of multi-layered complexity, it is crucial +to stick to the principles of logically sound reasoning; furthermore, especially +the situation where several disjoint time grids are involved may require some +additional decision rule to determine which grid has to take priority. + +.Problematic choices of design +While the Lumiera developers immediately recognised the danger of code quality problems, +there was no consensus how to approach these difficulties. Should everything in the +Render Engine be based on frame counts? Can questions of grid alignment be pushed out +to the system's boundaries? Is grid alignment mostly a problem of UI representation? +An attempt was made to base time handling on simple integral data types, with a plain-C +library to provide quantisation and timecode functions -- which however could not prevent +the proliferation of ad-hoc computations at various places, given that temporal data +seems to be ``just simple numbers''. In an attempt to get this situation under control +before problems start to accumulate and spread, _Ichthyo_ pushed for a radical approach +to rely on the _C++ type system_ and use _opaque_ entities with controlled arithmetic. +Unfortunately, those basic time entities were also defined to be _immutable_ -- following +a trend towards functional programming, which became increasingly popular at that time. + +This new framework proved itself successful as a device to identify and eliminate ad-hoc +solutions -- yet state, being a part of the real world, can not be eliminated by dictum, +and will claim it's right sooner or later. + +- very soon, a `TimeVar` datatype was introduced, since ``pure'' functional concepts + can never compete with the _intuitivity_ of ``just using numbers'' +- from a users point of view, the GUI exposes time-related entities which can be + manipulated -- notably the playback position. An attempt was made, to _encapsulate_ + these manipulations as a `time::Control` + +In this (slightly compromised) form, the new framework was able to support all +time-data related tasks encountered for the first (GTK-2) version of the UI. +Some more technical explanations can be found in the +link:/x/fwd/DevWiki.TimeMutation.html[DevWiki: TimeMutation]. + +In hindsight, using opaque types was very successful -- while the immutability seems +to be a mistake and induces a lot of unnatural complications. A design change to +rectify the situation was planned and documented as +link:/x/ticket/1261.html[#1261 »reconsider (im)mutability of time entities«] + diff --git a/doc/design/architecture/TimeQuant.txt b/doc/design/architecture/time/TimeQuant.txt similarity index 97% rename from doc/design/architecture/TimeQuant.txt rename to doc/design/architecture/time/TimeQuant.txt index 155fd7e00..083108606 100644 --- a/doc/design/architecture/TimeQuant.txt +++ b/doc/design/architecture/time/TimeQuant.txt @@ -44,7 +44,7 @@ changing time:: Time values are _immutable,_ like numbers. + Only a *time variable* can be changed -- yet some of the special time entities - can recieve link:TimeMutation[mutation messages], allowing e.g. for + can receive link:/x/TimeMutation.html[mutation messages], allowing e.g. for adjustments to a time interval selection from the GUI '''' @@ -99,7 +99,7 @@ frame count:: timecode:: Quantisation also is the foundation of all kinds of formalised time specifications actually even a frame count is some kind of (informal) timecode -- other timecodes - employ a standardised format. //Every// presentation of time values and every + employ a standardised format. _Every_ presentation of time values and every persistent storage and exchange of such values is based on time codes. Yet quantisation and time code aren't identical: a given quantised time value typically can be cast into multiple timecode formats. @@ -202,11 +202,9 @@ There is a common baseclass `TCode` though, which can be used as marker or for _type erasure._ -> more on link:TimeUsage.html[usage situations] -//// -// TODO integrate those cross links + --> Timecode link:TimecodeFormat[format and quantisation] +-> Timecode link:/x/TimeCode.html[format and quantisation] + --> Quantiser link:QuantiserImpl[implementation details] -//// +-> Quantiser link:/x/imp/TimeQuantiser.html[implementation details] + diff --git a/doc/design/architecture/TimeUsage.txt b/doc/design/architecture/time/TimeUsage.txt similarity index 93% rename from doc/design/architecture/TimeUsage.txt rename to doc/design/architecture/time/TimeUsage.txt index 10ef5cf16..4dd492716 100644 --- a/doc/design/architecture/TimeUsage.txt +++ b/doc/design/architecture/time/TimeUsage.txt @@ -8,7 +8,7 @@ Time Usage Situations the following collection of usage situations helps to shape the details of the time values and time quantisation design. + --> see also link:TimeQuant.html[more about time quantisation] +-> see also link:/x/TimeQuant.html[more about time quantisation] time position of an object:: indeed the term ``time position'' encompasses two quite different questions @@ -45,7 +45,7 @@ updating the playback position:: possible loop positions are way finer than the processing block size) dispatching individual frames for calculation:: - when a link:PlayProcess[render or playback process] is created, at some point + when a link:/x/PlayProcess.html[render or playback process] is created, at some point we need to translate this logical unit (``calculation stream'') into individual frame job entries. This requires to break continuous time into individual frames, and then ennumerating these frames. @@ -113,7 +113,7 @@ desirable somehow to move these distinctions out of the scope of this design and offload them onto the client (code using these time classes). Another closely related problem is *when to allow mutations*, if at all (-> see -link:TimeMutation[more here...]). We can't completely do away with mutations, +link:/x/TimeMutation.html[more here...]). We can't completely do away with mutations, simply because we don't have a pure functional language at our disposal. The whole concept of _reference semantics_ doesn't play so well with immutable objects. The Lumiera high-level (session) model certainly relies on objects @@ -140,8 +140,8 @@ in this case quantised values and quantisation are approached in the reverse direction, compared with the other uses. Here, after establishing a start point on the time scale, we proceed with ennumerating distinct frames and later on need to access the corresponding raw time, especially to find out about the -link:Segmentation[timeline segment] to address, or for retrieving parameter -automation. -> link:FrameDispatcher[see frame dispatching]. +link:/x/Segmentation.html[timeline segment] to address, or for retrieving parameter +automation. -> link:/x/FrameDispatcher.html[see frame dispatching]. Note that the *display window might be treated as just an independent instance of quantisation*. This is similar to the approach taken above for modifying @@ -176,11 +176,11 @@ closing the circle. substantial problems to be solved --------------------------------- -* how to link:TimeGridAlignment[align multiple grids] -* how to integrate link:TimeMutation[modifications of quantised values]. ([green]#✔ solved#) +* how to align multiple grids -- what grid to use for playback? +* how to integrate link:/x/TimeMutation.html[modifications of quantised values]. ([green]#✔ solved#) * how to isolate the Time/Quantisation part from the grid MetaAsset in the - session -> we use the link:Advice[Advice] system ([green]#✔ solved#) + session -> we use the link:/x/Advice.html[Advice] system ([green]#✔ solved#) * how to design the relation of Timecode, Timecode formatting and Quantisation - -> link:TimecodeFormat[more here] [yellow-background]#WIP# + -> link:/x/TimeCode.html[more here] [yellow-background]#WIP# diff --git a/doc/design/architecture/time/index.txt b/doc/design/architecture/time/index.txt new file mode 100644 index 000000000..9f86f33ea --- /dev/null +++ b/doc/design/architecture/time/index.txt @@ -0,0 +1,21 @@ +Time Handling +============= + +// Menu : sort children +// Menu : attach child TimeQuant after TimeUsage +// Menu : append child TimeMutation + + +While Lumiera will be able to handle various kinds of different content and data, +the task of _editing_ implies to arrange elements into a temporal dimension. +Thus representation of time and expression of relations in time plays a pivotal role. + +At first sight, time seems to we well-known, commonplace and trivial to understand -- +which however is a deception, since anything related to time, timings, duration and +time scales is notoriously difficult to spell out with precision and tricky to +handle in the practice of programming. A high-level discussion should thus + +- start with an analysis of link:TimeUsage.html[usage situations] +- alignment to a pre-determined grid scale, the so called + link:TimeQuant.html[Time Quantisation] requires careful attention +- formal representation of link:TimeCode.html[Time Code] is central to film editing. diff --git a/doc/design/engine/PlayProcess.txt b/doc/design/engine/PlayProcess.txt new file mode 100644 index 000000000..11cdffb90 --- /dev/null +++ b/doc/design/engine/PlayProcess.txt @@ -0,0 +1,11 @@ +Playback and Render Processing +============================== + +.Prototyping and Exploration +On a conceptual level, this topic reaches far beyond the mere data processing +and is undeniably one of the most complex and interwoven aspects of Lumiera. +As of 2025, most structures in this realm are in a state of prototyping -- +many topics are in flux and what works well needs to be figured out yet. + +Many detailed notes can be found in the +link:/x/fwd/DevWiki.PlayProcess.html[DevWiki: PlayProcess]. diff --git a/doc/design/engine/index.txt b/doc/design/engine/index.txt index 0852b6bac..75c1cb741 100644 --- a/doc/design/engine/index.txt +++ b/doc/design/engine/index.txt @@ -2,5 +2,5 @@ Design Documents: Renderengine ============================== This section contains design documents regarding the overall workings of the Render Engine, -and the handling of output generation and output connections. +data processing and the handling of output generation and output connections. diff --git a/doc/design/model/Segmentation.txt b/doc/design/model/Segmentation.txt new file mode 100644 index 000000000..dcd14e75b --- /dev/null +++ b/doc/design/model/Segmentation.txt @@ -0,0 +1,21 @@ +Segmentation of Timeline +======================== + +.A junction between the models +The term ``Segmentation of the Timeline'' describes both a data structure and a step in the +build process, which translates the structures of the *high-level-Model* into a corresponding +graph of Render Nodes. The latter is also known as the *low-level-Model* and can be seen +as a set of preconfigured render pipelines. When such a pipeline is ``pulled''. the render +computations are invoked. The _access points_ to all these pipelines are hooked into a +_backbone_ data structure, designated as the *Fixture* -- which breaks down each top-level +Timeline into a sequence of temporal segments: what differentiates these segments is the +topology of the Render Nodes in the pipeline; whenever a change in this topology is +necessary, a new segment is started. Such a change might e.g. be caused by a transition +between two clips, which has to cover a range of some frames. + +As of 2025, this part of the model is only roughly drafted, mostly using placeholder code +to achieve some level of functional integration. + +Detailed design planning and explanations can be found in the +link:/x/fwd/DevWiki.Segmentation.html[DevWiki: Segmentation]. + diff --git a/doc/design/model/index.txt b/doc/design/model/index.txt index 31dd74534..f1ba202d7 100644 --- a/doc/design/model/index.txt +++ b/doc/design/model/index.txt @@ -2,5 +2,5 @@ Design Documents: Model ======================= * two models: high-level and low-level - * RfC: link:{rfc}/../rfc/ProcHighLevelModel.html[high-level model basics] + * RfC: link:{rfc}/ProcHighLevelModel.html[high-level model basics] diff --git a/doc/devel/meeting_summary/2011-05-11.txt b/doc/devel/meeting_summary/2011-05-11.txt index a35a4b0d7..e23695660 100644 --- a/doc/devel/meeting_summary/2011-05-11.txt +++ b/doc/devel/meeting_summary/2011-05-11.txt @@ -20,7 +20,7 @@ Render Engine Interface _Ichthyo_ had prepared a new link:/documentation/devel/rfc_pending/EngineInterfaceSpec.html[RfC] about the actual interface between the -link:/documentation/design/architecture/playRender.html[Player subsystem] +link:/documentation/design/architecture/Playback.html[Player subsystem] and the Renderengine/Scheduler. The following discussion turned into considering several detaled and technical topics regarding the Jobs to be scheduled, how to create and attach new jobs, diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 8b5f8105c..19d878fb1 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -161542,6 +161542,33 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + +

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

+ + + + + + +

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

+ + + + + @@ -161617,6 +161644,190 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + +

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

+ + + + + + + +

+ es gibt einen RfC: »WebsiteSupportMarkup« +

+ + + + + + + + + +

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

+ + + + + + + + +

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

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

+ nun sind wohl 10 Jahre vergangen +

+

+ und das Problem besteht unverändert +

+ + + + + +

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

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

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

+ + + + + + + + +

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

+ + + + + + + + + +

+ Micro-HTTPD expandiert nicht automatisch *.html +

+ + + + + + + +

+ Aus mehrerlei Gründen +

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

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

+ + + + + + + + + + + + + + + + + + + + + + + + @@ -162538,10 +162749,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - - + + + + + + @@ -162589,13 +162802,14 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + - + @@ -162833,8 +163047,211 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + + + + + + + + + + + + + + + + + +

+ Stichworte allein sind ein flat namespace +

+ + + + + + + + +

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

+ + + + + + + +

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

+ + + + + + + +

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

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

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

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

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

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

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

+ + + + + + + + + + + + + + @@ -174582,6 +174999,21 @@ Since then others have made contributions, see the log for the history. + + + + + + + + + + + + + + + From 0c3cd9027c87db4ed1c01aacc8e7f2b4b3506f49 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 5 Sep 2025 20:33:10 +0200 Subject: [PATCH 21/51] DOC: clarify UI / discussion - indicate clearly that a ''past discussion'' is documented here - point out what is the primary focus for UI design ''currently'' - arrange some links better - use cross-links / Linkfarm; especially cross-link to the discussion regarding Wouter's Workflow proposals (2025) --- .../GuiBrainstormingReviewed.txt | 273 ++++++++++++------ .../GuiBrainstormingWontImplement.txt | 157 +++++++--- .../{MenuAndShortcuts.txt => PieMenu.txt} | 0 .../{scrolling.txt => Scrolling.txt} | 0 .../{TimelineDiscussion.txt => Timeline.txt} | 22 +- doc/design/gui/GuiDiscussion/index.txt | 25 +- doc/design/gui/index.txt | 34 ++- .../workflow/Verwijlen/FrosconMeeting.txt | 2 +- doc/design/workflow/index.txt | 3 +- wiki/thinkPad.ichthyo.mm | 76 +++++ 10 files changed, 447 insertions(+), 145 deletions(-) rename doc/design/gui/GuiDiscussion/{MenuAndShortcuts.txt => PieMenu.txt} (100%) rename doc/design/gui/GuiDiscussion/{scrolling.txt => Scrolling.txt} (100%) rename doc/design/gui/GuiDiscussion/{TimelineDiscussion.txt => Timeline.txt} (96%) diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt index 5e63fa8af..f091031d5 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt @@ -5,7 +5,7 @@ GUI Brainstorming Reviewed State of the GUI ---------------- -image:{l}/media/img/design.gui/screenshot090124-resources.jpg[Screenshot 090124] +image:/media/img/design.gui/screenshot090124-resources.jpg["Screenshot 090124",width="80%"] Updated 18/01/09 @@ -20,7 +20,8 @@ One Window can be tiled (horizontally/vertically) giving areas where screen elem * Multiple windows + Can open multiple windows on one head and (optionally) tile them as above --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' * My personal preference would be to produce the GUI in C++ with Gtkmm. Gnome is the most popular desktop for Linux, and GTK now has good support both for Win32, Mac and KDE (except that GTK on Mac still needs X11, probably for some more time) @@ -42,7 +43,8 @@ High Priority * A good entry level gui together with an advanced key driven system like about blender (not so much the ui) - Yes Blender's UI isn't that great a model to follow (though there is some good stuff in there). I agree about good keyboard support. A good place to start would be the standard + accelerators, as well as context menu mnemonics. We should be able cover the entire command set with the these. I don't see us needing anything more advanced than that. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:48:03Z)]] ++ +JoelHoldsworth:: '2008-07-22T20:48:03Z' Medium Priority @@ -50,17 +52,25 @@ Medium Priority * Fullscreen Support + Windows can be made fullscreen with no decorations (but tiling left intact) --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: This can be done with relative ease. We should add this feature. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Work well with tiling window managers + I propose that the future Lumiera GUI is designed without too much (or anything) about the user's screen apart from what is acceptable based on the X11 protocol(?) in order to work well with tiling window managers. The main problem to watch out for is assuming specific dimensions. The nature of tiling window managers is that most of the time, the windows without focus are dramatically downsized in one or two dimensions. This causes poorly designed GUIs to behave strangely, sometimes as bad as constantly jumping between layouts and thus causing unnecessary CPU load. --- link:MichaelPloujnikov[] [[DateTime(2008-04-14T22:29:12Z)]] ++ +MichaelPloujnikov:: '2008-04-14T22:29:12Z' - Comment: As much as anything this is a case for good testing on tiling window managers. People who use them need to do this, and file bugs, or better yet patches. It would be good for me to start using one as well, I think. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Window configurations can be stored/restored in customizable presets and are part of the project (see blender again) @@ -68,19 +78,25 @@ I propose that the future Lumiera GUI is designed without too much (or anything) A jog tool is a sliding ui element that when clicked and held, will play the video at a certain rate as the mouse drags left or right. As the mouse drags the the left the video plays forward faster (It should advance very slowly at first.). It acts the same way when the mouse drags to the right, except that the video plays in reverse. Again, it can be tedious trying to make frame-accurate cuts to long video files. Without a jog tool it makes it more tedious to get to the exact frame you want to cut on because you must scan through, then click the next frame button half a dozen times. A jog tool would remedy this because one could easily vary the playback rate, even reverse it, zeroing in on the frame much more quickly. Together these two features could really increase the speed at which one can edit precisely in Cinelerra. - Comment: This idea seems feasible, it could be worked together with cehteh shuttle slider proposal. --- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]] ++ +joelholdsworth:: '2008-07-19T19:42:04Z' * most numeric value entries (sliders, spinbuttons) can be changed when hovering the mouse over it and turn the scroll wheel (maybe with an additional modifier key?) -- The scroll wheel is accelerated depending on how fast it is operated by the user, snapping it slowly gives frame/interval precise increments, turning it faster will exponentially increases the increment (2,4,8.. frames per click) --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' * "Render AS" + The *process for creating a DVD* where Video and Audio have to be rendered separately is laborious. A script could easily handle this, and make the use of the program so much easier, attractive, inviting, productive, time efficient, bla bla. All the user needs to do is set the parameters and file name (once) and then "do". Many commonly used formats for saving could be saved as presets that completely avoid all the questions (say in the "File" drop down menu, as a customizable "Render AS" choice). This could also be done for HDTV, iPod, Ringtones, VCD, Various formats that give the best performance for uploading to Youtube and all the other video sharing sites. + When a whole magazine article(s) can be written about the task of exporting a file to make a DVD, you know the process is a long one. mmm ... Any well paid journalists out there want to sponsor programmed task efficiency? - "NO?" - oh well. --- link:Tree[] [[DateTime(2008-05-07T16:44:00Z)]] ++ +Tree:: '2008-05-07T16:44:00Z' - This could probably be solved by having a series of format presets in the Render dialog. The default set could contain settings for the values you mention. We could even allow the user to save their own presets. Cinelerra already has this functionality - these are called profiles, but it doesn't come with a default set at all. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:13:28Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:13:28Z' +-- * Reduced quality previews + There needs to be a way of giving the user the choice to see the movie at full quality - computationally expensive, or at reduced quality for times when full framerate would be impossible. @@ -89,14 +105,21 @@ There needs to be a way of giving the user the choice to see the movie at full q Let the user have more flexibility over the track view height. Some tracks can be set to minimal, others to visible (but basically iconic), others enough to see features, and one or two to good resolution. Some may even be blanked. + The track view height could be individually selectable , for example, by changing the "draw media" icon from toggle mode to drop down menu. The drop down selection options could include "don't show", followed by track sizes as per the drop down menu at the bottom of track view. --- link:Tree[][[DateTime(2008-05-07T17:30:00NZ)]] - - - Comment: Yes, I was thinking about this idea myself. At first I was thinking of just allowing the user to expand or collapse the track with a +/- button. But then I wondered if it would be good to have the track completely sizable. My current thinking is the best way would be to have it sizable but with a kind of snap-to-grid behaviour so the whole thing doesn't become really messy. --- link:JoelHoldsworth[] [[DateTime(2008-08-04T16:03:24Z)]] ++ +Tree:: '2008-05-07T17:30:00NZ' + -- -* Ardour provides an example for this: the track height can be changed (by buttons or with the mouse wheel + modifyer key), but there is only a fixed set of possible track heights, some of which have a preconfigured layout. For example, in "smallest" size the track head shows only the track label without any buttons and the track is reduced to a tiny waveform. --- link:Ichthyostega[] [[DateTime(2008-08-08T15:18:31Z)]] + ** Comment: Yes, I was thinking about this idea myself. At first I was thinking of just allowing the user to expand or collapse the track with a +/- button. But then I wondered if it would be good to have the track completely sizable. My current thinking is the best way would be to have it sizable but with a kind of snap-to-grid behaviour so the whole thing doesn't become really messy. ++ +-- +JoelHoldsworth:: '2008-08-04T16:03:24Z' +-- + + ** Ardour provides an example for this: the track height can be changed (by buttons or with the mouse wheel + modifyer key), but there is only a fixed set of possible track heights, some of which have a preconfigured layout. For example, in "smallest" size the track head shows only the track label without any buttons and the track is reduced to a tiny waveform. ++ +-- +Ichthyostega:: '2008-08-08T15:18:31Z' +-- -- @@ -106,12 +129,14 @@ Low Priority * Multi Head + Can open Windows on different heads of the same server, and is aware of the existence of different physical monitors (ie. Xinerama-aware) - - Comment: Xinerama seems to be a decreasingly popular way of doing multi-monitor. This probably could be implemented, but I don't have a Xinerama based setup, and I've never talked to anyone who does. I use link:TwinView[], and it seems like a more practical way of doing dual screen to me. Surely RandR based multi-monitor is the main need today. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + - Comment: _Xinerama_ seems to be a decreasingly popular way of doing multi-monitor. This probably could be implemented, but I don't have a _Xinerama_ based setup, and I've never talked to anyone who does. I use _TwinView_, and it seems like a more practical way of doing dual screen to me. Surely _RandR_ based multi-monitor is the main need today. ++ +joelholdsworth:: '2008-07-21T21:58:48Z' + -- * Multi-Head != Xinerama ... This is very important and quite common, We want to support monitors driven at the native Video Format (resolution, framerate, interlacing, overscan, ....). For a professional setup this is really required! --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] + ++ +ct:: '2008-07-22T07:11:11Z' * Xinerama and twinView test comparison -> https://www.phoronix.com/review/387[see @Phoronix...] -- @@ -120,16 +145,21 @@ Can open Windows on different heads of the same server, and is aware of the exis When scanning through an hour long video clip, it can be tedious to go through it all making clips. It would allow the user to get right to work if Lumiera could split the video into clips based on scene changes. Each clip would begin at precisely the frame the current shot begins and end at the last frame before the next shot. As long as the user could then edit these clips on the timeline, this would decrease the time spent sifting through the raw footage. - Comment: This seems like a good idea, and quite easy to implement. I think that when we get the video-capture and media manager code working this would a be a good subproject for someone to take on. --- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]] ++ +joelholdsworth:: '2008-07-19T19:42:04Z' * Import and Export SMIL files + Many current cinelerra users probably use kino for their capturing of DV. it uses less resources, so less system demand during capture. Good display monitor while capturing. Open Movie Editor is a good multitrack editor that can share Kino's SMIL files. A good progression in complexity of editing is start with kino, move to OME, then cinelerra (lumiera). A really convenient way to assist stepping up from Kino is to handle the SMIL files. + Automatic scene detection is a great feature in Kino. The simpler editors make it easy for less skilled people to look after the selection of preliminary clips, while lumiera is used by the folks who put it all together, and finish it off. ---link:Tree[][[DateTime(2008-05-09T15:10:00NZ)]] . ++ +Tree:: '2008-05-09T15:10:00NZ' - Comment: SMIL is quite cool technology. It's not just a Kino thing. It'd be quite good to be able to import this standard format. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:41:02Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:41:02Z' +-- More Discussion Needed @@ -142,40 +172,66 @@ Timeline Make the timeline view _sparse_, that means the time on top is not continuous anymore but \'boring' sequences get omitted and \'interesting' sequences get displayed, probably even stretched to cover at least a single thumbnail. + This needs an ui (menu or whatever) to turn this feature on and some selection which events the user is interested in (scene cuts, transitions begin/end/mids, keyframes (begin/mid), labels, ...) --- link:ct[] [[DateTime(2008-05-21T13:46:51Z)]] - - - Comment: Do you think we could use view splitting to accomplish this? You can see this sort of thing OpenOffice.org calc. Where you drag a splitter out from the ends of the scrollbar, this allows you compare 2 or 4 parts of a big spreadsheet at the same time. Implementing something like that might be reasonably doable. But if you're talking about hiding periods on the timeline, that sounds a lot less easy to me, and it feels like a bit a bit of an odd thing to do. What do you think ct? --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* No, view-splitting is something different, usually one splits the timeline to few places (2 or 3). Managing those splits requires a lot manual interaction (resizing the splits, zooming into the right time resolution, scrolling to the desired range, ...). In contrast this 'sparse' timeline does that all automatically by possibly adding hundreds of those split points (there should be no split bar on the gui). One just has to select POI's with some menu or such. Well and the timeline ruler needs to adapt to it, that might be tricky --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +ct:: '2008-05-21T13:46:51Z' +-- + +** Comment: Do you think we could use view splitting to accomplish this? You can see this sort of thing OpenOffice.org calc. Where you drag a splitter out from the ends of the scrollbar, this allows you compare 2 or 4 parts of a big spreadsheet at the same time. Implementing something like that might be reasonably doable. But if you're talking about hiding periods on the timeline, that sounds a lot less easy to me, and it feels like a bit a bit of an odd thing to do. What do you think ct? ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- + +*** No, view-splitting is something different, usually one splits the timeline to few places (2 or 3). Managing those splits requires a lot manual interaction (resizing the splits, zooming into the right time resolution, scrolling to the desired range, ...). In contrast this 'sparse' timeline does that all automatically by possibly adding hundreds of those split points (there should be no split bar on the gui). One just has to select POI's with some menu or such. Well and the timeline ruler needs to adapt to it, that might be tricky ++ +-- +ct:: '2008-07-22T07:11:11Z' -- * "Sparse Timeline" is in Trackview" - see Track view section lower down the page + This is the kind of features I have suggested in the Trackview section lower down the page. I like the name you give it - "Sparse" because it allows the user to not have to bother viewing OR scrolling past all the stuff in between two end points (or more items) just to tweak the ends of a segment. But I would emphasize that instead of reducing the width of the timeline because of the narrow time span needs for the one task, that more tasks can be carried out in the same view. This is because the view just misses out all the stuff in between, for each task. + I am playing around with a few thoughts and maybe might attach an image of how it might work. But in conjunction with "tabbed views" it would result in the convenient ability to display all the work areas in a concentrated display, meaning a whole lot less scrolling around, and clicking to bring windows to the foreground. --- link:Tree[][[DateTime(2008-05-23T16:59:00NZ)]] - - - Comment: See above. With regards to tabbed based UI in the timeline view, I do have this in mind, and it seems reasonably straightforward to allow two tabs which contain views of the same timeline - just scrolled to different places. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] - -* Clip Mode + -This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there. -- link:rexbron[] + -The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together. +-- +Tree:: '2008-05-23T16:59:00NZ' +-- - - Comment: This sounds a bit odd in some ways. But I'd be interested to find out more. I'll probably do some research into it at some stage. Maybe you can post some screenshots. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] +** Comment: See above. With regards to tabbed based UI in the timeline view, I do have this in mind, and it seems reasonably straightforward to allow two tabs which contain views of the same timeline - just scrolled to different places. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- + +* Clip Mode ++ +This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there. ++ +rexbron:: '2008-05' ++ +-- +* The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together. + +** Comment: This sounds a bit odd in some ways. But I'd be interested to find out more. I'll probably do some research into it at some stage. Maybe you can post some screenshots. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- +-- * I propose an assembly system where the source material is left untouched where effects are added on the fly similar to html and dtp packages. In this system the system is linked together using an node system similar to gstreamer and jack. - - Comment: Yes the core of lumiera will work on a scen graph of connected nodes, and we want to provide the user with a way of using that power. We need to discuss how node wiring and the timeline-track tree go together. Note that node wiring only seems to make good UI when the node graph is fixed for the duration of the whole project timeline. We need to work out how this fits together with the timeline tree, and if metaclips help this problem at all. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] - -Comment to all those sparse timeline and clip mode proposals: The benefits of those are obvious, as they directly correspond to the working with storyboards. Almost every serious movie uses storyboards to quite some extent. But for the implementation, I'd propose not to see it as an alternative view/mode of the timeline. Rather, I'd treat it like a media/asset folder. Probably we'll have the ability for the user to group the media asset into various "bins" (virtual sub folders). Moreover, pre-cut clips appear as clip assets as well (similar in Cinelerra and most other video editors). Thus, we just need a function to "play" such a clip bin. It could be implemented by defining a ordering on the clips in the bin (from top to bottom and from left to right?). Then, this function would create an transient EDL on-the-fly, containing just these clips, and hand it over to the engine for building/playback. Thus, the user can see his "draft-cut" played back in real time, and thats all what is really needed. When satisfied, he could mark the clips in the bin and drag them to the timeline, which would add them in the same order starting at the current position. I don't think we need to go though all the pain of creating an separate, dedicated UI for this purpose. --- link:Ichthyostega[] [[DateTime(2008-07-27T23:20:19Z)]] +** Comment: Yes the core of lumiera will work on a scen graph of connected nodes, and we want to provide the user with a way of using that power. We need to discuss how node wiring and the timeline-track tree go together. Note that node wiring only seems to make good UI when the node graph is fixed for the duration of the whole project timeline. We need to work out how this fits together with the timeline tree, and if metaclips help this problem at all. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- +*** Comment to all those sparse timeline and clip mode proposals: The benefits of those are obvious, as they directly correspond to the working with storyboards. Almost every serious movie uses storyboards to quite some extent. But for the implementation, I'd propose not to see it as an alternative view/mode of the timeline. Rather, I'd treat it like a media/asset folder. Probably we'll have the ability for the user to group the media asset into various "bins" (virtual sub folders). Moreover, pre-cut clips appear as clip assets as well (similar in Cinelerra and most other video editors). Thus, we just need a function to "play" such a clip bin. It could be implemented by defining a ordering on the clips in the bin (from top to bottom and from left to right?). Then, this function would create an transient EDL on-the-fly, containing just these clips, and hand it over to the engine for building/playback. Thus, the user can see his "draft-cut" played back in real time, and thats all what is really needed. When satisfied, he could mark the clips in the bin and drag them to the timeline, which would add them in the same order starting at the current position. I don't think we need to go though all the pain of creating an separate, dedicated UI for this purpose. ++ +-- +Ichthyostega:: '2008-07-27T23:20:19Z' +-- Widgets @@ -204,43 +260,69 @@ All faders are the same kind of custom widget, that is: -- + for the application all faders provide a float (or double) value, nothing else. --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: I think making some kind standardized fader widget is probably going to be necessary for this project. We need a good way of combining together the artistic "genstural" elements of a slider widget with the precise numerical behavior of an edit widget, and it needs to be compact - the UI will have a lot of these. I'm not sure how often we'll need to see a level meter with these. Most of the time a control is either an input or a readout - very rarely both. Generally speaking I'm against the idea of having a popup menu to configure this widget. I believe that it should be configured to work in a way which is user friendly by default. There may be many of these widgets and asking the user to configure each of these before they behave well seems a bit unfair to me. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* I agree, the defaults should be reasonable set per-item, that will be that the meter is in most cases off and the spinner will be off on many cases too. I tried to show whats needed for the most generic case with all bells and whistles. When we generalize this we need to support all eventualities even if turned off by default. Note that some things could be done in tooltips, see below "about tooltips and statusbar", the above fader is just an early proposal/brainstorm --- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' ++ + +** I agree, the defaults should be reasonable set per-item, that will be that the meter is in most cases off and the spinner will be off on many cases too. I tried to show whats needed for the most generic case with all bells and whistles. When we generalize this we need to support all eventualities even if turned off by default. Note that some things could be done in tooltips, see below "about tooltips and statusbar", the above fader is just an early proposal/brainstorm ++ +-- +ct:: '2008-07-23T09:41:25Z' +-- -- * Magnifying Glass for the Faders + Faders should have a "magnifying glass" mode, which can be activated by a key combination or modifier key. When activated, you can fine tune the current value: The step increment is lowered ideally to the real limit of the underlaying parameter, or, if this is too much, at least it should be much smaller than anything you get by dividing the possible value range by the fader length in screen pixels. In this mode, the fader doesn't cover the whole range, rather it is centered at the current value. Changing the value by these small increments should give an obvious visible feedback. Ideally, an accompanying automation curve display will switch to the extreme vertical zoom as well. And it's important that you don't have to zoom, you enter/leave with one keypress. + Partially, this is covered by the Adaptive Mouse Wheel too; but, especially when working with sound, the problem is that the parameter range cover several orders of magnitude. For example, even 16bit PCM sound has a volume parameter which can be adjusted in 32768 steps, and yes, there are situations when these fine steps make an audible difference, while most software faders give you not much more then a view hundred subdivisions even under optimal circumstances. --- link:Ichthyostega[] [[DateTime(2008-02-07T22:34:08Z)]] - - - Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below). --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] - - - This concept of "magnifying faders", is well explained in https://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation. --- link:oracle2025[] [[DateTime(2008-02-08T00:40:05Z)]] - - - Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +Ichthyostega:: '2008-02-07T22:34:08Z' +-- +** Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below). ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- ++ +*** This concept of "magnifying faders", is well explained in https://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation. ++ +-- +oracle2025:: '2008-02-08T00:40:05Z' +-- ++ +**** Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate. ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- Scripting ^^^^^^^^^ * Usability (ease of use) - mouse clicks and motions, inputs decisions, etc required to achieve tasks. Macros are really handy for allowing the user to speed up repetitive tasks that the program designers have not anticipated and made easy to do from the outset. Macros can be shared on a central web site. Plus developers can look and see what the macros are being used for, as this gives a very important indication of where vital tasks are. --- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]] ++ +-- +Tree:: '2008-05-07T16:44:00NZ' +-- - Comment: We need to have some discussion about scripting. To do macro scripting we'll need to implement a DOM interfaces etc. into 2 or even all 3 layers of the system. If we want to do this, then we'll need to begin planning for it early. We have talked already about making scripting the movie itself AviSynth style. Both are worth talking about. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:58:22Z)]] + - - See also rcbarnes compound filters proposal. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:25:57Z)]] +-- +JoelHoldsworth:: '2008-07-22T21:58:22Z' +-- + + ** See also rcbarnes compound filters proposal. ++ +-- +JoelHoldsworth:: '2008-07-24T16:25:57Z' +-- Others @@ -248,10 +330,14 @@ Others * Time estimates for lengthy Tasks before committing to the action. + Handy to have time estimates for lengthy task indicated even before committing to the task. Also an estimate for the % increase or reduction in time of adjusting parameters. So you can make a good tradeoff between the result and and the time taken to get it. When a task is carried out, measurements are made to improve the accuracy of future guesses. ---link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]] ++ +Tree:: '2008-05-07T21:34:00NZ' - Comment: This would be quite a nice feature if we can do it. Though it's often hard to know how long something will take until you start doing it. For example estimating the time to render a 1000 frame animation might involve rendering the first 10 frames, then multiplying that time by 100. Problem is that could potentially be quite complex to set up - especially when we're working with render farms. The backend guys would need to think about this I think. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:24:50Z' +-- Joelholdsworth is Skeptical @@ -259,40 +345,58 @@ Joelholdsworth is Skeptical * Multi server + Display GUI components on different Xservers, some critical components (GL rendering etc) might be only supported on local displays --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: This doesn't seem like a very common use case. I can't see any immediate advantage in doing this, and I'm struggling to think of a scenario where this would be helpful. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* Having more than one workstation each driving a display on its own, getting more bang. But I agree this is not a important feature and rather a corner case. --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' ++ + +** Having more than one workstation each driving a display on its own, getting more bang. But I agree this is not a important feature and rather a corner case. ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- * 3x3 Menus + Have a mostly quadratic 3x3 dialpad like popup menu poping up so that the center is the mouse position (adjusted when near screen corners). The middle field is always the close/cancel functionality and the 8 fields around offer the menu entries. Navigation can be done by mouse, cursor keys or numpad! Menu entries can open 3x3 submenus again, either incremental so that closing brings you up to the higher menu or exclusive that closing aborts the whole menu. --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: Cehteh really want this feature. Personally I'm skeptical. It seems clumsy and non-standard to me, and not good in terms of command discoverability, so I don't want to implement it. But then he does seem to want it pretty badly, so I'm a bit cautious about putting it straight in the "Won't Implement" category. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* not only me, but ichthyo and simav too and anyone i talked with liked this idea but you --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' ++ + +** not only me, but ichthyo and simav too and anyone i talked with liked this idea but you ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- -* User Precautions get built out of user interface and into program.+ +* User Precautions get built out of user interface and into program. ++ When attaching such and such effect to a track, disable "play" before attaching it, then re-enable play aft attaching it. (we don't tell you this before hand, and we never will, unless you ask the question and search the net, then you might find out in the "secrets manual", And you'll have to remember this (always)!! If there are circumstances that apply to an effect (or for that matter any other part of the program), then the feature could have a flag in it that warns the system to take note of it, and it then reports what its requirement or tweak feature is, so the system can automatically handle it the best way. (A sort of OO process handler). This not only saves potential lengthy wastes of time, but saves concentration on sideline issues, speeds up work, adds to reliability and good time user experience. ---link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]] ++ +Tree:: '2008-05-07T21:34:00NZ' - Comment: I'm not sure I quite understand what this is about. Your explanation is a bit hard to read. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]] + -- -* I wouldn't even be skeptical, I am against such a proposal. Any feature we add should just work, without crashing the application and trashing the users efforts. If a feature doesn't work, it needs to be fixed, instead of automatically warning the user that this feature is broken. The fact that for Cinelerra you need the "secrets" tells quite a lot about the state of affairs regarding Cinelerra, and because we wanted to change this, Lumiera was born. ;-) --- link:Ichthyostega[] [[DateTime(2008-07-27T23:04:42Z)]] --- +JoelHoldsworth:: '2008-07-24T16:24:50Z' ++ + ** I wouldn't even be skeptical, I am against such a proposal. Any feature we add should just work, without crashing the application and trashing the users efforts. If a feature doesn't work, it needs to be fixed, instead of automatically warning the user that this feature is broken. The fact that for Cinelerra you need the "secrets" tells quite a lot about the state of affairs regarding Cinelerra, and because we wanted to change this, Lumiera was born. ;-) ++ +-- +Ichthyostega:: '2008-07-27T23:04:42Z' +-- +-- May Implement Some Day ~~~~~~~~~~~~~~~~~~~~~~ @@ -300,14 +404,19 @@ May Implement Some Day * Widget overlay/Fullscreen + Some Widgets can be made half transparent and overlay video giving a head up display editing while the video is at native resolution in background. Window configurations can be stored/restored in customizable presets and are part of the project (see blender again) --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '2008-02-07T20:42:54Z' - Comment: This is difficult to do. XVideo and Gtk don't really mix. But I can't think of any controls that need to be overlaid. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* Would be nice but not a primary feature. I'd rather think about some some special on-screen-menu overlay, not necessary gtk (libosd?) maybe this can be implemented with OpenGL overlay or so. As noted before, having a monitor which runs on the native Video resolution is a requirement. Giving this Monitor some (limited) GUI features, like mask editing or other simple manipulations gains extra points. Not a primary/important feature but I'd rather like it seen as "Will implement _someday_" The window configuration customization should be its own point, I think thats easy with GTK (Gimp does that) adding a small Configuration management GUI shouldn't be hard. --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +joelholdsworth:: '2008-07-21T21:58:48Z' + + * Would be nice but not a primary feature. I'd rather think about some some special on-screen-menu overlay, not necessary gtk (libosd?) maybe this can be implemented with OpenGL overlay or so. As noted before, having a monitor which runs on the native Video resolution is a requirement. Giving this Monitor some (limited) GUI features, like mask editing or other simple manipulations gains extra points. Not a primary/important feature but I'd rather like it seen as "Will implement _someday_" The window configuration customization should be its own point, I think thats easy with GTK (Gimp does that) adding a small Configuration management GUI shouldn't be hard. ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt index 55c0fdddc..49b63eacc 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt @@ -7,15 +7,24 @@ GuiBrainstorming Reviewed - Won't Implement Sometimes help files and tutorials are improvable. Keeping track of which help is to which amount useful for a majority of users will provide data about which help files are improvable. It will also provide data about which features most often users use help and might be candidate for usability consideration. like: []solved my problem []got me on the right way []needed to find help elsewhere []problem not solved - This is surprisingly hard to implement (I think), and in a sense it's already obvious to us whether the docs are quality - filled with nice graphics, simple steps, and lots of clear information or whether they need improvement. This feature might have some use on the website. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:47:35Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:47:35Z' +-- * Suggest an improvement Feature - for users to help improvement + Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. Or get sent to a ``BrainStorming'' page like this one (but marked specifically for the panel they were in). --- link:Tree[][[DateTime(2008-05-26T12:01:00NZ)]] ++ +-- +Tree:: '2008-05-26T12:01:00NZ' +-- - This isn't really a GUI issue - much of this is more for the website, which the GUI will probably link to from an item in the help menu. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:45:00Z' +-- * Help System - rolling tips and tutorials + Sometimes, when a beginner is using the program, they just sit back and look at the general picture. It's a behaviour that gets down naturally. It looks like a "break", but going through their minds are questions like ; "Am I doing this efficiently?", "What would make this easier, and is there already an easy way to do it in the program?", "How long do I think this will take, and what can I do to make it in time?", and much more. Sit back, look at the whole screen, maybe cruise around the menu, conceptualise the project and steps involved - it's a kind of task oriented learning - on the job (self) training. @@ -27,66 +36,117 @@ Because of the creative effort needed when composing video projects, there is qu If it was context sensitive, then it would provide relevant information, similar to having a tutor or an expert leaning over your shoulder, explaining further possibilities and applications. + Video tips and Tutorials could be available via Youtube, which also doubles as promotion for the project. Users could choose to download groups of videos on selected topics. --- link:Tree[][[DateTime(2008-06-11T17:04:00NZ)]] ++ +-- +Tree:: '2008-06-11T17:04:00NZ' +-- - If the user stops to thing I think we should give them some peace while they get their thoughts together. I'm sure if they want help they'll ask for it. Remember how annoying Clippy was in MS Office? :-P --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:45:00Z' +-- * Help and visual prompts use GIFs for visual cue as to time behaviour of feature. + Icons are handy when they portray some sort of cue for the task that they do. A number of tasks in video editing are time related. It would be handy to have some form of visual que as to what the time related task does. Since Gifs can show motion, they would be very good for this task. PNGs could also do it it they were timed to cycle through their images. Example uses would be to show the difference between "track" and "stabilise" in motion tracker - a strip showing a pogo stick going along a footpath would be suitable to show the differences between track and stabilise (and could also be used to show the differences between the forms of vector calculation. GIFs could also be used to show editing functions that involve several important steps. ---link:Tree[][[DateTime(2008-05-26T08:45:00NZ)]] ++ +-- +Tree:: '2008-05-26T08:45:00NZ' +-- - If we did want animated icons we'd be better off with MNG or a PNG image strip because then we'd get transparency. There are 2 reasons why I think this is a bad idea. 1. There's an aweful lot of drawing to be done. We already need to produce perhaps 100 high quality tango style icons for the user interface. If they're animate someone would have to draw 1000s of these, with all the quality control problems that go with it. 2. I'm not sure it's something people will find very helpful. Even if the animation only begins when we hover over the icon, it could even be quite annoying and distracting. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:39:36Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:39:36Z' +-- * Help System - available for user improvement + _Similar to tool tip and status bar suggestion above._ A *"hover" hint / help* facility would be a major bonus. Just make the function available, the box can start with an index number, and users can type in their own help comments (either in a *help text entry management* section, or directly into the pop-up hover box - in optional help edit mode). + These can be pooled at a central web site in to languages, and brevity/completeness (options to links to further help, links to examples, links to video tutorials). So the developers do not have to spend time writing help files - just make it possible for the users to. The developers might like to add a few comments to the verbose files at some later point, or clear up inaccuracies. translators can also do the work for other languages. Very quickly the supporting documentation's usefulness would add to the attractiveness of the program. --- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]] ++ +-- +Tree:: '2008-05-07T16:44:00NZ' +-- - A wiki style approach is often an effective way to get community input on documentation. This may be a good way to get people working on it. But it's best for us to publish a tidied up documentation set and ship that, instead of creating a complex editable help system - which is vulnerable to vandalism. --- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:29:25Z)]] ++ +-- +JoelHoldsworth:: '2008-07-23T20:29:25Z' +-- * User selectable Experience Level - Task Oriented Layout + The user could be asked to choose their experience level, and more complex options then get greyed out. The user could be asked the common tasks that the want to do, and other options could be greyed out. They can choose whether they want "grayed" out options to be available, or viewable, or not. The options which are advanced (or 2 levels greater than their current expertise level) could be "dark grayed" out and the user could have similar choices about their display). ---link:Tree[][[DateTime(2008-05-09T20:50:00NZ)]] ++ +-- +Tree:: '2008-05-09T20:50:00NZ' +-- - Comments: I can't see any good reason for this. The user interface ought to be usable for everyone. The problem is that we want to enable everyone to be an "expert" by making power intuitively available even to beginners. The other problems is that light users might use only 10% of the functionality - but different light users use a different 10% from each other. So hiding things doesn't actually help make things simpler. It's much better to have things tidily arranged with clear descriptions etc. to help the user understand what a command might do - rather than hiding the command from them. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T22:25:58Z)]] ++ +-- +JoelHoldsworth:: '2008-07-22T22:25:58Z' +-- * SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compisitor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency bluring and the ability to interpolate these events over time...things that can be incorperated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better. -- jb [[DateTime(2008-07-21T21:58:48Z)]] - Comment: I am hoping that we can implement a simple set of skins for Lumiera. But we will be using the GTK based styles system, which is the standard. This allows theming to be done with a simple script file. These styles files are the more natural choice for UI theming, because WebKit is designed primarily for web, and would add a lot of unnecessary bloat to the app. Icons will be drawn as SVGs; a good choice for drawing the graphics, but these will be prerendered into PNGs at compile time as is standard practice for most free-desktop apps. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Client / Server Model + The server process will act as the master coordinator for the system, and will accept input from multiple GUI clients, and dictate tasks to multiple slave processes (even on separate physical servers). The GUI client application could be multi-platform. File transfer and communication could take place over SSH and make use of SVN for project management. Proxy editing will be the norm, due to the higher resolutions of final videos (the RED Epic will handle 5K). The entire system could easily work on a single Linux workstation, for easy adaptibility from handling home videos to expand to editing cinema films (which could benefit from dedicated GUIs to handle video, sound, etc.). - Comment: Because the different parts of a project are so tightly integrated, it won't be possible to have one instance of the GUI that only has audio, and another that only does video etc. Moreover, the controller PC will hold the source video data. It is true that we plan to make a distributed backend, but the core and GUI layers will remain on the controller PC. It's very hard to make a distributed GUI, and even harder to make lumiera have both a distributed front and backend. --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Navigation Systems + There may be several methods to make menu selections, and other choices. The Gui could be made quite adaptable/customisable. Using a "skin" approach to the Gui, would provide a system for users who are not programmers, to help develop improved user interfaces. Mouse "gestures" (may be patent considerations) are another option. The way that options are communicated with the program functions could be made so that even as yet undesigned "user chooser systems" can be added. --- link:Tree[] [[DateTime(2008-05-14T08:40:00NZ)]] - - - Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone! --- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]] + -- -* I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile. --- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +Tree:: '2008-05-14T08:40:00NZ' -- +** Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone! ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- + + +*** I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile. ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- + + * Burst frames to graphics card. + I am not sure how the current video play system works, but speed might be increased if several frames got sent to the video card at once. The video card can act as a video cache and play them as required. The number of interrupts to the process is reduced, to much less than one per frame, freeing up more CPU time for calculating the effects etc.. ---link:Tree[][[DateTime(2008-07-18T18:18:00NZ)]]. ++ +-- +Tree:: '2008-07-18T18:18:00NZ' +-- - Comment: Good idea, but not really necessarily. Firstly because XVideo is pretty fast, and the bottle neck is in rendering not drawing. Second, we can't get direct access to video RAM anyway because X abstracts it away. --- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]] ++ +-- +joelholdsworth:: '2008-07-19T19:42:04Z' +-- -* GUI development - flexible approach - using "Skin Methods" + +* GUI development ++ +-- + - flexible approach + - using "Skin Methods" +-- ++ In developing a GUI, the approach would normally be for the developers to design the Gui as the project progresses, and it comes out at the end. This is not bad, especially as there is a GUI to be had. But if there is a desire (which there appears to be a healthy desire here) to try new things, and look at options, then it would be quite useful to have a development method that allows for experimentation with options, side by side comparisons and assessments. Assessments by users and developers. + GUI design could be available for release for whoever wants to do a spin-off project re-GUI. So a GUI gets made by default by the development team, but the _skin kit_, and _methods of activating/interaction with the "engine"_ are made available. Users can then run their own tests and some sort of concensus arrived at later as to what is considered to work well, in what sorts of different user situations (newbie, small, large/expert). @@ -94,10 +154,16 @@ GUI design could be available for release for whoever wants to do a spin-off pro If there is vibrant enthusiasm for teams to work on alternative GUIs, then the developers may even avoid the need to do much of the work on GUI, and just announce what the interface requirements are - the (choices of) GUIs for some sections could be ready before the program is finished. The GUIs could be developed and discussed concurrently (or advance of) the respective program code. On the other hand the GUIs could lag behind the developemnt of the engine, but not hold the engine up. Some GUI groups could be ahead of others in some parts of the program and behind in others - the user could even choose to the GUI (widget appearance) from one theme for one part of the interface, and GUI from another theme for other parts. + There could be agreement between GUI teams working on different themes, to cover separate parts of the interface first, so that there is at least some type of theme for the GUI for the whole program ASAP. ---link:Tree[] [[DateTime(2008-06-05T20:33:00NZ)]] ++ +-- +Tree:: '2008-06-05T20:33:00NZ' +-- - Comment: To achieve that sort of thing one would normally expect the project to be forked. If our architecture is any good (and I think it will be), then a Lumiera fork would have no problem attaching a different UI to the system because there will be clear separation between the layers. But I can't see any good reason to help people fragment the project. If there are problems with the standard UI then we should fix them for everyone. If people want to write code for better UI they should contribute it patches. We really don't want to encourage people to fork any part of Lumiera. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:56:07Z)]] ++ +-- +JoelHoldsworth:: '2008-07-22T20:56:07Z' +-- * About Tooltips and Statusbar + Tooltips are really valuable items, they should not be wasted for simple things like brief help texts. Instead they might display the actual state of the underlying widget in a textual form (numeric+unit) with _maybe_ some hints. Long time ago I proposed for Cinelerra to add a special mode to make tooltips editable, that is with a shortcut the actual tooltip becomes a small text input field where the user can enter exact values for some things, this value is committed with the return key and leaving this mode should be really easy (as simple as just moving the mouse, ESC key). @@ -105,17 +171,26 @@ Tooltips are really valuable items, they should not be wasted for simple things The Status bar can show more information but isn't directly in the users view, here we may play help infos like available options on the mouse buttons, important keyboard shortcuts etc. take a look at \'qcad' .. xfig has also static area where it shows available (mouse) options, just not a status bar but in the upper right of the screen. + This might be a bit different to some common other user interfaces (M$...) but I think this is much more valuable. --- link:ct[] [[DateTime(2008-04-08T01:26:06Z)]] - - - Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change. --- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:42:32Z)]] + -- -* My argument is, that the \'figure out' thing could be done in the status bar, thats slightly less convinient but a user who searches for help will discover it (xfig, qcad and other programs do such kinds of dedicated help places instead tooltips). Popping up Tooltips only help _very_ early beginners, for someone who is even marginally used to the programm they don't add any value anymore, yet to be at a very prominent screenspace, right at your cursor. I think thats really a waste. I want interactive tips and help, but please where they are disciverable for help, but don't waste screen estate with information one might not really need. In contrast, the numeric value of a fader is a very important thing to know, at least when you want to alter it (cinelerra does that with its round knobs). And having a direct enter mode would be even more powerful for experienced users while not disturb anyone else. This might only complement the 'generalized fader' fader above, means when the fader is configured to show only a small scroller entry (to safe screen space) then displaying the numeric value and/or offer to edit it in a tooltip would be a good way to make it precise, without needing to reconfigure the fader, taking more screen space. --- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]] +ct:: '2008-04-08T01:26:06Z' -- -* Default settings after install set to most reliable and least requirements + +** Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change. ++ +-- +JoelHoldsworth:: '2008-07-22T21:42:32Z' +-- + +*** My argument is, that the ``figure out'' thing could be done in the status bar, thats slightly less convinient but a user who searches for help will discover it (xfig, qcad and other programs do such kinds of dedicated help places instead tooltips). Popping up Tooltips only help _very_ early beginners, for someone who is even marginally used to the programm they don't add any value anymore, yet to be at a very prominent screenspace, right at your cursor. I think thats really a waste. I want interactive tips and help, but please where they are disciverable for help, but don't waste screen estate with information one might not really need. In contrast, the numeric value of a fader is a very important thing to know, at least when you want to alter it (cinelerra does that with its round knobs). And having a direct enter mode would be even more powerful for experienced users while not disturb anyone else. This might only complement the 'generalized fader' fader above, means when the fader is configured to show only a small scroller entry (to safe screen space) then displaying the numeric value and/or offer to edit it in a tooltip would be a good way to make it precise, without needing to reconfigure the fader, taking more screen space. ++ +-- +ct:: '2008-07-23T09:41:25Z' +-- + + +* Default settings after install set to most reliable and least requirements ++ The program may be tweaked to get performance on PC with great graphics systems, plenty of Ram and good hard drive speed. For people with lower spec'd gear, there may be some tuning needed, just to get going. There is the likelihood that people with low spec'd gear are not so able or inclined to read up on their hardware, and "search" for help on their video editor, to find out the solution to a problem (which they may not even have much idea of what the problem is). Consequently, they are likely to give up and not use the program. + Everybody enjoys a program that can be easily installed, and is ready to run. Few are upset by a program that is easy to install, setup, and is ready to run. But quite a few have nothing but disappointment with a program that is relatively easy to install, no idea how to set up, won't run or crashes, and not much clue about where to get help which is much further away than a click. @@ -133,16 +208,28 @@ A similar colour coding for speed could be used ; blue for low speed, green for This colour coding for the two parameters (reliability and speed) means that when new driver/setup options are available that provide a speed increase, (yet are unreliable or unknown reliability at the time), the user has a very easy visual prompt to help them make decisions, and adapt their trial and error path to optimisation. + Feature to save different hardware settings, with notes in the hardware specs, and share them. Upload to Lumiera web site, so that better first guesses for new users are available. And if an intelligent system is used for hardware detection in future, then the information for best choices will already be available. --- link:Tree[] [[DateTime(2008-05-28T09:41:00NZ)]] ++ +-- +Tree:: '2008-05-28T09:41:00NZ' +-- - Comment: The problem is that unlike games, in movie editors there isn't very much that can be done in the way of tweaking. With video editing, by and large there are no shortcuts. So the calculations that must take place to render a video on a Quad Core workstation are the same as the ones that need to happen on an EeePC. Lumiera needs to be intelligent about how much RAM it uses etc. but that sort of thing ought to be automatic. The only thing that this could apply to is reduced quality previews, which I've put in the blueprint list. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:34:20Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:34:20Z' +-- * Menu Bar disconnectable from track view + The menu bar could be made disconnected from the track view. This would allow the track view to be covered by a window, but the menu still kept on top. The menu bar could by default start at the top left and run across the screen. It could remain on top view. It could include easy single click tabs to jump from one window view to another. + The menu items that are specific to track view could be separated out and left as dedicated menu attached to the top of the track view. --- link:Tree[][[DateTime(2008-05-07T21:06:00NZ)]] ++ +-- +Tree:: '2008-05-07T21:06:00NZ' +-- - Comment: Actually if you look at the state-of-ui you can see that the menu bar will be shown at the top of workspace. We might make it detachable, but actually it's not very useful to be able to attach the menu bar to the sides or bottoms of windows. --- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:47:08Z)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:47:08Z' +-- diff --git a/doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt b/doc/design/gui/GuiDiscussion/PieMenu.txt similarity index 100% rename from doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt rename to doc/design/gui/GuiDiscussion/PieMenu.txt diff --git a/doc/design/gui/GuiDiscussion/scrolling.txt b/doc/design/gui/GuiDiscussion/Scrolling.txt similarity index 100% rename from doc/design/gui/GuiDiscussion/scrolling.txt rename to doc/design/gui/GuiDiscussion/Scrolling.txt diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/Timeline.txt similarity index 96% rename from doc/design/gui/GuiDiscussion/TimelineDiscussion.txt rename to doc/design/gui/GuiDiscussion/Timeline.txt index 502cd8f21..b0ad5835f 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/Timeline.txt @@ -1,9 +1,11 @@ -Timeline: Discussion -==================== +Timeline: Extended Discussion +============================= :Author: Joel Holdsworth :Date: Fall 2008 -This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome. +This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming +to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. +Comments are welcome. * Avid vs FCP 2006 - http://www.fini.tv/articles/avidfcp2006.html[] Archived 2008 from https://web.archive.org/web/20071211184722/http://www.fini.tv/articles/avidfcp2006.html[fini.tv] @@ -222,14 +224,14 @@ Christian asked "why then not also controlling plugin parameters by placement?". I must admit, both of you have a point. Christians proposal goes even beyond what I proposed. It is completely straight forward when considered structurally, but it is also clearly beyond the meaning of the term/idea/concept "placement". -But what, if we re-adjust the concepts and think in terms of ''Advice'' ? +But what, if we re-adjust the concepts and think in terms of _Advice_ ? Thus, a placement would bind an media object into the session/sequence and also attach additional advice? As an example, to apply this re-adjusted Idea to the gain control: When a track group head has an gain/fade control this would just denote an advice to set the -gain. It does ''not'' mean that signal data has to flow "through" this -track/track group, it does ''not'' mean the gain is actually applied at this -point and it does ''not'' mean that any routing decision is tied to this gain. +gain. It does _not_ mean that signal data has to flow "through" this +track/track group, it does _not_ mean the gain is actually applied at this +point and it does _not_ mean that any routing decision is tied to this gain. Even signal chains being routed to quite different master busses can receive this advice, given the source clips are placed within the scope of this track group. The only difference needed on the GUI to implement this approach would be @@ -294,7 +296,7 @@ otherwise just normal effects in a master sequence)? Regarding effects, I should point out that in our concept, mask, "camera" and "projector" (Cinelerra's terms) are just some specific effects. Given that, it -is clear that effects need to be applicable ''both'' pre transition and post +is clear that effects need to be applicable _both_ pre transition and post transition. But the following limitation seems reasonable to me and seems to match the actual use: @@ -314,14 +316,14 @@ Btw. I very much agree with you that putting clips on group head tracks would be rather confusing, while I think placing an effect at a group head track is OK and feels natural. It will just be applied post-transition to all media within the covered range. And, note again the power of the placement+advice concept: -this does ''not'' mean the data need to be merged together and piped through the +this does _not_ mean the data need to be merged together and piped through the effect at this point. Rather, it means that each signal processing chain in the covered range will get an instance of this plugin wired in at a position equivalent to the place the effect is found on the group track with respect to the track hierarchy. I.e. after wiring in the transition(s), instances for effects placed at tracks are wired in order and ascending the track tree, and finally the connection will be made to the mixing step or output destination -according to the output advice found for ''this individual'' object (but in most +according to the output advice found for _this individual_ object (but in most cases this output destination advice will be inherited from the context, i.e. some root track) diff --git a/doc/design/gui/GuiDiscussion/index.txt b/doc/design/gui/GuiDiscussion/index.txt index ce300e896..f6479285b 100644 --- a/doc/design/gui/GuiDiscussion/index.txt +++ b/doc/design/gui/GuiDiscussion/index.txt @@ -1,11 +1,18 @@ GUI Design and Feature Discussion ================================= +//Menu: prepend child GuiBrainstormingWontImplement +//Menu: prepend child GuiBrainstormingReviewed //Menu: put child ConceptProposals after GuiBrainstormingWontImplement -//Menu: put child TimelineDiscussion after ConceptProposals +//Menu: put child GuiDiscussion/Timeline after ConceptProposals -In the early days of the Lumiera project, there was a lot of debate regarding -GUI concepts, -features and proposals. +In the early days of the Lumiera project, there was an extended debate regarding +GUI concepts and -features, including many proposals from the community. +Bearing in mind that we have meanwhile gained a clearer understanding what wee +need to build for the GUI, this _brainstorming phase_ is completed. + +However, a more focused discussion regarding »Workflow« +link:/x/Verweijlen.html[ensued in 2025]. GUI Brainstorming:: We got a lot of proposed cool features. In order to channel this great influx of ideas, @@ -22,13 +29,15 @@ GUI Proposals:: * link:ConceptProposals/Alcarinque.html[Alcarinque] * link:ConceptProposals/Barnes.html[Clay Barnes] * link:ConceptProposals/RichardSpindler.html[Richard Spindler] + +Feature discussion:: + Some topics spurred some heightened interest and (controversial) discussion * link:Workspaces.html[about Workspace organisation] - * link:scrolling.html[about scrolling..] - * link:MenuAndShortcuts.html[Ideas for menus and shortcuts] + * link:Scrolling.html[about scrolling..] + * link:PieMenu.html[menu / shortcuts] Timeline Discussion:: In 2008, Joel reviewed all the available proposals and distilled a more coherent vision - especially about the timeline, which certainly is at the heart of any video editor. - This page with link:TimelineDiscussion.html[Conclusions by Joel Holdsworth] is - _must read_ for anyone engaged into Lumiera GUI development. + especially about the timeline, which certainly is at the heart of any video editor. + + 💡 Note the link:Timeline.html#_joel_conclusions[Conclusions by Joel Holdsworth] as a summary. diff --git a/doc/design/gui/index.txt b/doc/design/gui/index.txt index 082c70684..eebcd27fa 100644 --- a/doc/design/gui/index.txt +++ b/doc/design/gui/index.txt @@ -1,20 +1,38 @@ Design Documents: GUI ===================== -In the early stages of the project, there was a lot of debate regarding -GUI concepts and -features and proposals. +//MENU: append child GuiDiscussion -link:GuiDiscussion/index.html[Here] is a collection of documents from these early + +In the early stages of the project, there was a lot of debate regarding +GUI concepts and -features and proposals. Extended discussions ensued on +the Mailinglist and several people provided concept drawings. + +-> link:GuiDiscussion/index.html[Here] is a collection of documents from these early discussions. +'''' + +In the current phase of the project, the UI conception focuses on a way +to build the interface in a systematic way, to support complex workflows +with low friction. The following questions need to be addressed: + +- How to use _Perspectives_, Views, Docking Panels and Layout +- how to adapt the Layout, ranging from a single Laptop screen to multiple monitors +- how to allocate and place new views and property panes intelligently +- how to allow for a coherent navigation scheme that works seamlessly + and intuitively over a mixture of several _Control Systems_.footnote:[The term »Control System« + refers to one technical realisation of an human-computer-interface, which is used coherently and + can coexist with other such interfaces + -> link:/x/InteractionControl.FoundationConcepts.html[more here]... + + The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...] +- how to build such a link:/x/InteractionControl.html[Layer of Interaction-Control] + without interfering with the evolution of the underlying UI toolkit ⚠ ... -.[red]#TODO# more contributions please... ;-) -We had several additional discussions and contributions on the mailinglist, -several people did even concept drawings. Collect these and add them here NOTE: We use the term *Workflow* in our discussions to denote the more integral concerns of how to achieve given tasks within the application in the most suitable and stringent fashion. We tend to separate those more global - considerations from the discussion of individual GUI features. - -> link:../workflow/index.html[read more here...] + considerations from the discussion of individual GUI features. + + -> link:/x/Workflow.html[more about Workflow...] diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index 6eca551c3..16027e1fd 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -30,7 +30,7 @@ shares similar goals but its scope is more far-reaching. We consider _Magnetic T important advancement to legacy track oriented GUI schemes; but it is more mouse confined and does not support several Control Systems footnote:[The term »Control System« refers to one technical realisation of an human-computer-interface, which is used coherently and can coexist with other -such interfaces -> link:{ldoc}/design/gui/InteractionControl.html#_foundation_concepts[more]. + +such interfaces -> link:/x/InteractionControl.FoundationConcepts.html[more]. + The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...] on an equal footing, which is our vision. diff --git a/doc/design/workflow/index.txt b/doc/design/workflow/index.txt index abfc5248d..9e2c03a0f 100644 --- a/doc/design/workflow/index.txt +++ b/doc/design/workflow/index.txt @@ -11,6 +11,7 @@ so we tend to treat it as a distinct effort, separate from the design of individ * link:LumieraWorkflowOutline.html[Workflow/Requirements outline by BJMR] * link:InterfaceConcept_Varga.html[Interface Concept by Christoph Varga] +* link:/x/Verweijlen.html[Workflow Proposals by Wouter Verweijlen] --> see also link:../gui/index.html[general GUI discussion...] +-> see also link:/x/GuiDiscussion.html[general GUI discussion...] diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 19d878fb1..948fdda74 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -163213,6 +163213,23 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + +

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

+ + + + + + @@ -163244,6 +163261,65 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + +

+ klar machen: Diskusssion ist abgeschlossen +

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

+ Name + Datum als Asciidoc-Delimited-Block +

+ + + + + + + + +

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

+ + + + + + + + + From 8dc6580da1955281921d28f4f3a4c2acab93bd53 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 8 Sep 2025 01:54:16 +0200 Subject: [PATCH 22/51] clean-up: update links embedded into API-doc (Doxygen) Notably some links on the **Gnome documentation** pages are problematic, since there was seemingly an infrastructure change -- which unfortunately leads to loosing several deep-links into the GTK-3 related documentation and tutorials. While the differences to GTK-4 are often rather minimal, I would still prefer to link to those documentation pages used as reference at implementation time of our related library and GUI functionality. In several cases I have thus looked up the old URLs at Archive.org --- src/common/option.hpp | 2 +- src/lib/format-obj.cpp | 2 +- src/lib/hash-standard.hpp | 2 +- src/lib/ios-savepoint.hpp | 2 +- src/lib/meta/function.hpp | 4 ++-- src/lib/meta/typeseq-util.hpp | 2 +- src/lib/meta/util.hpp | 2 +- src/lib/nocopy.hpp | 2 +- src/lib/random.hpp | 2 +- src/lib/thread.hpp | 2 +- src/lib/time/timevalue.hpp | 2 +- src/lib/uninitialised-storage.hpp | 2 +- src/lib/util-quant.hpp | 2 +- src/lib/verb-visitor.hpp | 4 ++-- src/stage/ctrl/state-map-grouping-storage.hpp | 4 ++-- src/stage/ctrl/ui-dispatcher.hpp | 4 ++-- src/stage/dialog/test-control.hpp | 4 ++-- src/stage/model/tangible.hpp | 4 ++-- src/stage/model/w-link.hpp | 2 +- src/stage/ui-bus.hpp | 2 +- src/stage/widget/error-log-display.hpp | 8 ++++---- src/steam/control/command-def.hpp | 2 +- tests/library/util-identity-test.cpp | 2 +- 23 files changed, 32 insertions(+), 32 deletions(-) diff --git a/src/common/option.hpp b/src/common/option.hpp index 1f4a21fd8..89bbf59bc 100644 --- a/src/common/option.hpp +++ b/src/common/option.hpp @@ -25,7 +25,7 @@ ** various _alternative modes,_ like starting "headless" (without UI), script ** driven or as node in a renderfarm network. ** - ** [Boost program options library] : http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.html + ** [Boost program options library] : https://www.boost.org/doc/libs/1_83_0/doc/html/program_options.html ** ** @see basic-setup.hpp ** @see lumiera::AppState diff --git a/src/lib/format-obj.cpp b/src/lib/format-obj.cpp index 3b04b2faf..57dc1191c 100644 --- a/src/lib/format-obj.cpp +++ b/src/lib/format-obj.cpp @@ -184,7 +184,7 @@ apologies for that." * the cache, so it doesn't make much of a difference if we scan * the same comparatively short string multiple times * - * [stdRegEx-threadsafe]: http://stackoverflow.com/questions/15752910/is-stdregex-thread-safe + * [stdRegEx-threadsafe]: https://stackoverflow.com/questions/15752910/is-stdregex-thread-safe */ string humanReadableTypeID (Literal rawType) diff --git a/src/lib/hash-standard.hpp b/src/lib/hash-standard.hpp index 5afdecdc7..b603c8e6f 100644 --- a/src/lib/hash-standard.hpp +++ b/src/lib/hash-standard.hpp @@ -38,7 +38,7 @@ ** push it aside and plant our own definition instead. ** ** @note this trick was proposed by user "enobayram" on Stackoverflow at Oct 5, 2012 - ** http://stackoverflow.com/questions/12753997/check-if-type-is-hashable + ** https://stackoverflow.com/questions/12753997/check-if-type-is-hashable ** ** @warning this header includes and manipulates the standard header ``. ** Please ensure it is always included _before_ the latter. Failing to do so will result diff --git a/src/lib/ios-savepoint.hpp b/src/lib/ios-savepoint.hpp index 3ae0ec796..49bcbc012 100644 --- a/src/lib/ios-savepoint.hpp +++ b/src/lib/ios-savepoint.hpp @@ -25,7 +25,7 @@ ** @see IosSavepoint_test ** ** [qbert220]: https://stackoverflow.com/users/617617/qbert220 - ** [stackoverflow]: https://stackoverflow.com/a/18822888 "Restore state of `std::cout` after manipulating it" + ** [stackoverflow]: https://stackoverflow.com/questions/2273330/restore-the-state-of-stdcout-after-manipulating-it/18822888#18822888 "Restore state of `std::cout` after manipulating it" ** ** */ diff --git a/src/lib/meta/function.hpp b/src/lib/meta/function.hpp index e5ffd4a5a..0717d16e4 100644 --- a/src/lib/meta/function.hpp +++ b/src/lib/meta/function.hpp @@ -135,8 +135,8 @@ namespace meta{ * unless you bind it beforehand into a std::function with correct signature. * @see FunctionSignature_test * - * [kennytm]: http://stackoverflow.com/users/224671/kennytm - * [stackoverflow]: http://stackoverflow.com/questions/7943525/is-it-possible-to-figure-out-the-parameter-type-and-return-type-of-a-lambda/7943765#7943765 "figure out parameter and return type of a Lambda" + * [kennytm]: https://stackoverflow.com/users/224671/kennytm + * [stackoverflow]: https://stackoverflow.com/questions/7943525/is-it-possible-to-figure-out-the-parameter-type-and-return-type-of-a-lambda/7943765#7943765 "figure out parameter and return type of a Lambda" */ template struct _Fun diff --git a/src/lib/meta/typeseq-util.hpp b/src/lib/meta/typeseq-util.hpp index 67f6e5909..33756c0ac 100644 --- a/src/lib/meta/typeseq-util.hpp +++ b/src/lib/meta/typeseq-util.hpp @@ -48,7 +48,7 @@ namespace meta { /** * Find the index of the first incidence of a type in a type-sequence. * @note static assertion if the type is not in the type sequence - * @see https://stackoverflow.com/a/60868425/444796 + * @see https://stackoverflow.com/questions/18063451/get-index-of-a-tuple-elements-type/60868425#60868425 */ template constexpr size_t diff --git a/src/lib/meta/util.hpp b/src/lib/meta/util.hpp index fce8b979c..12a455e90 100644 --- a/src/lib/meta/util.hpp +++ b/src/lib/meta/util.hpp @@ -81,7 +81,7 @@ namespace meta { * variant here, which is slightly stripped down and a tiny bit * more concise than the boost variant. This way, we can avoid * a lot of boost inclusions, which always bear some weight. - * @see [std::enable_if](http://en.cppreference.com/w/cpp/types/enable_if) + * @see [std::enable_if](https://en.cppreference.com/w/cpp/types/enable_if.html) */ template using enable_if = enable_if_c::type; diff --git a/src/lib/nocopy.hpp b/src/lib/nocopy.hpp index ca9691efc..0b8332a82 100644 --- a/src/lib/nocopy.hpp +++ b/src/lib/nocopy.hpp @@ -20,7 +20,7 @@ ** with mutable state and confusion regarding equality. ** @remark inspired by [Boost-Noncopyable] ** - ** [Boost-Noncopyable]: http://www.boost.org/doc/libs/1_55_0/libs/utility/utility.htm#Class_noncopyable + ** [Boost-Noncopyable]: https://www.boost.org/doc/libs/1_55_0/libs/utility/utility.htm#Class_noncopyable */ diff --git a/src/lib/random.hpp b/src/lib/random.hpp index 44ce7abe9..fb2c800b3 100644 --- a/src/lib/random.hpp +++ b/src/lib/random.hpp @@ -19,7 +19,7 @@ ** For simplified usage, two default instances are exposed as global variable ** - lib::defaultGen uses fixed seeding (planned: make this configurable) ** - lib::entropyGen always uses true randomness as seed value. - ** [C++ random number framework]: https://en.cppreference.com/w/cpp/numeric/random + ** [C++ random number framework]: https://en.cppreference.com/w/cpp/numeric/random.html ** @see Random_test */ diff --git a/src/lib/thread.hpp b/src/lib/thread.hpp index 1e57b01f1..abfbdfc7f 100644 --- a/src/lib/thread.hpp +++ b/src/lib/thread.hpp @@ -108,7 +108,7 @@ ** C++ standard library. Design and semantics were retained, while implemented ** using modern features, notably the new _Atomics_ synchronisation framework. ** - ** [syncs-with definition] : https://en.cppreference.com/w/cpp/atomic/memory_order#Synchronizes_with + ** [syncs-with definition] : https://en.cppreference.com/w/cpp/atomic/memory_order.html#Synchronizes_with */ diff --git a/src/lib/time/timevalue.hpp b/src/lib/time/timevalue.hpp index fbb85baa3..183cd58ba 100644 --- a/src/lib/time/timevalue.hpp +++ b/src/lib/time/timevalue.hpp @@ -735,7 +735,7 @@ namespace time { /** derive a hash from the µ-tick value * @return rotation of the raw value to produce a suitable spacing for consecutive time * @remark picked up by Boost-hash, or std. hashtables with the help of `hash-standard.h` - * @see https://stackoverflow.com/a/31488147 + * @see https://stackoverflow.com/questions/31387778/near-constant-time-rotate-that-does-not-violate-the-standards/31488147#31488147 */ inline HashVal hash_value (TimeValue const& time) diff --git a/src/lib/uninitialised-storage.hpp b/src/lib/uninitialised-storage.hpp index 29ecf9b88..6b3ab6960 100644 --- a/src/lib/uninitialised-storage.hpp +++ b/src/lib/uninitialised-storage.hpp @@ -52,7 +52,7 @@ ** - an implicit conversion path to the corresponding array type is provided ** - subscript operators enable direct access to the raw storage ** - helper functions allow for placement new and delete. - ** [deprecated again]: https://stackoverflow.com/a/71828512 + ** [deprecated again]: https://stackoverflow.com/questions/71828288/why-is-stdaligned-storage-to-be-deprecated-in-c23-and-what-to-use-instead/71828512#71828512 ** @see extent-family.hpp ** @see vault::gear::TestChainLoad::Rule where this setup matters */ diff --git a/src/lib/util-quant.hpp b/src/lib/util-quant.hpp index d7612c596..a9f67f9eb 100644 --- a/src/lib/util-quant.hpp +++ b/src/lib/util-quant.hpp @@ -171,7 +171,7 @@ namespace util { * @see ZoomWindow_test * * [ToddLehman]: https://stackoverflow.com/users/267551/todd-lehman - * [stackoverflow]: https://stackoverflow.com/a/24748637 "How to do an integer log2()" + * [stackoverflow]: https://stackoverflow.com/questions/994593/how-to-do-an-integer-log2-in-c/24748637#24748637 "How to do an integer log2()" */ template inline constexpr int diff --git a/src/lib/verb-visitor.hpp b/src/lib/verb-visitor.hpp index 1efe6950f..c8265ce91 100644 --- a/src/lib/verb-visitor.hpp +++ b/src/lib/verb-visitor.hpp @@ -64,8 +64,8 @@ ** special twist that we don't use a pre-bound function, but rather need to combine the ** actual invocation target at the moment of the invocation. ** - ** [member pointer]: https://en.cppreference.com/w/cpp/language/pointer - ** [std::apply]: https://en.cppreference.com/w/cpp/utility/apply + ** [member pointer]: https://en.cppreference.com/w/cpp/language/pointer.html + ** [std::apply]: https://en.cppreference.com/w/cpp/utility/apply.html ** ** @see [drawing on the track canvas](\ref body-canvas-widget.cpp) ** @see VerbVisitorDispatch_test diff --git a/src/stage/ctrl/state-map-grouping-storage.hpp b/src/stage/ctrl/state-map-grouping-storage.hpp index 514b0285b..b939c52d7 100644 --- a/src/stage/ctrl/state-map-grouping-storage.hpp +++ b/src/stage/ctrl/state-map-grouping-storage.hpp @@ -183,8 +183,8 @@ namespace ctrl { * comparator has to define a suitable `operator()` and in addition a marker type * `is_transparent`. See [transparent-cmp] and the [reference][cind-cpp14] for explanation. * //////////////////////////////////TICKET #991 - * [find-cpp14]: http://en.cppreference.com/w/cpp/container/set/find - * [transparent-cmp]: http://stackoverflow.com/questions/20317413/what-are-transparent-comparators + * [find-cpp14]: https://en.cppreference.com/w/cpp/container/set/find + * [transparent-cmp]: https://stackoverflow.com/questions/20317413/what-are-transparent-comparators */ static GenNode const& getState (Record const& entry, string propertyKey) diff --git a/src/stage/ctrl/ui-dispatcher.hpp b/src/stage/ctrl/ui-dispatcher.hpp index 9ab580651..e6b5d5e3f 100644 --- a/src/stage/ctrl/ui-dispatcher.hpp +++ b/src/stage/ctrl/ui-dispatcher.hpp @@ -56,8 +56,8 @@ ** given receiver thread (here the UI event loop thread) will _share a single pipe for signalling._ ** Under heavy load this queue might fill up and block the sender on dispatch. ** - ** [Glib-Dispatcher]: https://developer.gnome.org/glibmm/2.42/classGlib_1_1Dispatcher.html - ** [GTKmm-tutorial]: https://developer.gnome.org/gtkmm-tutorial/3.12/sec-using-glib-dispatcher.html.en + ** [Glib-Dispatcher]: https://web.archive.org/web/20210306110019/https://developer.gnome.org/glibmm/2.42/classGlib_1_1Dispatcher.html + ** [GTKmm-tutorial]: https://gnome.pages.gitlab.gnome.org/gtkmm-documentation/sec-using-glib-dispatcher.html ** @see NotificationService ** @see CallQueue_test */ diff --git a/src/stage/dialog/test-control.hpp b/src/stage/dialog/test-control.hpp index d7e27bc67..45ccf97a4 100644 --- a/src/stage/dialog/test-control.hpp +++ b/src/stage/dialog/test-control.hpp @@ -113,7 +113,7 @@ namespace dialog { * struct, which is actually heap allocated and managed automatically. This way, each child page * gets its own namespace, and wiring to other components is made explicit by passing named ctor * arguments -- while the overall structure of building and wiring of widgets stays close to the - * habits of [programming with GTKmm](https://developer.gnome.org/gtkmm-tutorial/stable/). + * habits of [programming with GTKmm](https://gnome.pages.gitlab.gnome.org/gtkmm-documentation/). * - define the pages as custom widgets, typically just as locally known struct types * - invoke #buildPage passing the type and tab label for each page * - define the wiring of the components within a page in the page's ctor @@ -121,7 +121,7 @@ namespace dialog { * @note the page widgets are actually heap allocated and managed automatically * @see stage::dialog::TestControl as a usage example * - * [Notebook]: https://developer.gnome.org/gtkmm-tutorial/stable/sec-multi-item-containers.html.en#sec-notebook + * [Notebook]: https://gnome.pages.gitlab.gnome.org/gtkmm-documentation/sec-multi-item-containers.html#sec-notebook */ class Notebook : public Gtk::Notebook diff --git a/src/stage/model/tangible.hpp b/src/stage/model/tangible.hpp index 41fb96beb..039362078 100644 --- a/src/stage/model/tangible.hpp +++ b/src/stage/model/tangible.hpp @@ -108,8 +108,8 @@ ** These slots are defined to be `sigc::trackable` for automated disconnection ** see [sigc-track] for an explanation. ** - ** [MVC-Pattern]: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller - ** [sigc-track]: http://issues.lumiera.org/ticket/940#comment:3 "Ticket #940" + ** [MVC-Pattern]: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller + ** [sigc-track]: https://issues.lumiera.org/ticket/940#comment:3 "Ticket #940" ** ** @see \ref AbstractTangible_test ** @see \ref BusTerm_test diff --git a/src/stage/model/w-link.hpp b/src/stage/model/w-link.hpp index bf793d351..210b0a27b 100644 --- a/src/stage/model/w-link.hpp +++ b/src/stage/model/w-link.hpp @@ -37,7 +37,7 @@ ** a dead functor. We make use of the same mechanism here to ** install a callback to invalidate this smart-handle. ** - ** [trackable]: https://developer.gnome.org/libsigc++/stable/structsigc_1_1trackable.html#details "`sigc::trackable`" + ** [trackable]: https://libsigcplusplus.github.io/libsigcplusplus/reference/html/structsigc_1_1trackable.html#details "`sigc::trackable`" ** ** @see \ref WLink_test ** @see \ref NotificationHub (usage example) diff --git a/src/stage/ui-bus.hpp b/src/stage/ui-bus.hpp index 63e35401f..88388345c 100644 --- a/src/stage/ui-bus.hpp +++ b/src/stage/ui-bus.hpp @@ -83,7 +83,7 @@ ** @see ctrl/nexus.hpp ** @see ctrl/core-service.hpp ** - ** [MVC-Pattern]: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller + ** [MVC-Pattern]: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller */ diff --git a/src/stage/widget/error-log-display.hpp b/src/stage/widget/error-log-display.hpp index 5a8f3b3ae..b2e6c3c69 100644 --- a/src/stage/widget/error-log-display.hpp +++ b/src/stage/widget/error-log-display.hpp @@ -190,7 +190,7 @@ namespace widget { * but also stores a [Mark] to bookmark the presence of this * error entry. And finally expand the display if collapsed. * - * [Mark]: https://developer.gnome.org/gtkmm-tutorial/stable/sec-textview-buffer.html.en#textview-marks + * [Mark]: https://gnome.pages.gitlab.gnome.org/gtkmm-documentation/chapter-textview.html#textview-marks */ void addError (string text) @@ -303,9 +303,9 @@ namespace widget { * The handling of marks and tags is described in the [GTKmm tutorial]. * @warning Each entry creates a new pair of marks. Not sure about the impact on performance... * - * [GTKmm tutorial]: https://developer.gnome.org/gtkmm-tutorial/stable/sec-textview-buffer.html.en#textview-marks - * [insert-mark]: https://developer.gnome.org/gtkmm/3.22/classGtk_1_1TextMark.html#details - * [API doc]: https://developer.gnome.org/gtkmm/3.22/classGtk_1_1TextView.html#a8412941c4da9a71a381052d6049164e4 + * [GTKmm tutorial]: https://gnome.pages.gitlab.gnome.org/gtkmm-documentation/chapter-textview.html#textview-marks + * [insert-mark]: https://web.archive.org/web/20210306120221/https://developer.gnome.org/gtkmm/3.22/classGtk_1_1TextMark.html#details + * [API doc]: https://web.archive.org/web/20210306120223/https://developer.gnome.org/gtkmm/3.22/classGtk_1_1TextView.html#a8412941c4da9a71a381052d6049164e4 */ Entry addEntry (string const& text, Literal markupTagName =nullptr) diff --git a/src/steam/control/command-def.hpp b/src/steam/control/command-def.hpp index 0260af1bd..1c7dd59f1 100644 --- a/src/steam/control/command-def.hpp +++ b/src/steam/control/command-def.hpp @@ -247,7 +247,7 @@ namespace control { /** * Helper class used solely for _defining_ a Command-Object. - * This technique is known as "fluent API", see http://en.wikipedia.org/wiki/Fluent_interface + * This technique is known as "fluent API", see https://en.wikipedia.org/wiki/Fluent_interface * The basic idea is for the user to create a disposable instance of this definition helper, * only for calling a chain of definition functions, which internally build the actual Command object. * Finally, the created Command object will be stored into a registry or handed over to the diff --git a/tests/library/util-identity-test.cpp b/tests/library/util-identity-test.cpp index 455fa6d1b..7caca2033 100644 --- a/tests/library/util-identity-test.cpp +++ b/tests/library/util-identity-test.cpp @@ -48,7 +48,7 @@ namespace test { * pointers, disregarding any type information, thereby * _»unpacking«_ the address information contained in a * pointer is (i.e. the address of the pointee is used) - * [object]: https://en.cppreference.com/w/cpp/language/type + * [object]: https://en.cppreference.com/w/cpp/language/type.html */ class UtilIdentity_test : public Test { From ab2a3636537a7dd12ea98e743d6bf71c8a0c52a8 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 8 Sep 2025 02:56:51 +0200 Subject: [PATCH 23/51] clean-up: remove the GCH builder from the SCons tools MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `BuilderGCH` was added as an experimental feature many years ago; this is code found ''somewhere'' on the net and was use ''as-is'' — however, precompiled headers turned out as a feature of GCC with a lot of quality problems and, furthermore seems of questionable usability — we thus decided to adhere strictly to the »Borland model« of template instantiation and recommend against using precompiled headers. Rather, in the Lumiera code base, much care is taken to avoid unnecessary header includes — this, together with the incremental build feature of SCons largely obsoletes the necessity to resort to precompiled headers and similar facilities (as CCache). --- admin/scons/BuilderGCH.py | 109 -------------------------------------- 1 file changed, 109 deletions(-) delete mode 100644 admin/scons/BuilderGCH.py diff --git a/admin/scons/BuilderGCH.py b/admin/scons/BuilderGCH.py deleted file mode 100644 index a8705885f..000000000 --- a/admin/scons/BuilderGCH.py +++ /dev/null @@ -1,109 +0,0 @@ -# coding: utf-8 -## -## BuilderGCH.py - SCons builder for gcc's precompiled headers -## - -# Copyright (C) scons.org/wiki/GchBuilder -# 2006, Tim Blechmann -# 2008, Hermann Vosseler -# -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License as -# published by the Free Software Foundation; either version 2 of -# the License, or (at your option) any later version. -##################################################################### - -# history: 8/2008 adapted for Lumiera build system -# changed to accept a list of precompiled header defs - -# TODO: WIP-remove these comments when port to Python 3.x is DONE -# types.py does not contain ListType in Python 3.x -# # Why do we require ListType? -# To do something like -# if type(item) is ListType: -# .... -# But types.py does not have ListType anymore -# if isinstance(item, list): -#from types import ListType - -import SCons.Action -import SCons.Builder -import SCons.Scanner.C -import SCons.Util -import SCons.Script - -SCons.Script.EnsureSConsVersion(0,96,92) - -GchAction = SCons.Action.Action('$GCHCOM', '$GCHCOMSTR') -GchShAction = SCons.Action.Action('$GCHSHCOM', '$GCHSHCOMSTR') - -def gen_suffix(env, sources): - return sources[0].get_suffix() + env['GCHSUFFIX'] - - -GchShBuilder = SCons.Builder.Builder(action = GchShAction, - source_scanner = SCons.Scanner.C.CScanner(), - suffix = gen_suffix) - -GchBuilder = SCons.Builder.Builder(action = GchAction, - source_scanner = SCons.Scanner.C.CScanner(), - suffix = gen_suffix) - -def setup_dependency(target,source,env, key): - scanner = SCons.Scanner.C.CScanner() - path = scanner.path(env) - deps = scanner(source[0], env, path) - - if key in env and env[key]: - for header in env[key]: - header_path = header.path.strip('.gch') - if header_path in [x.path for x in deps]: - print("Precompiled header(%s) %s \t <--- %s" % (key,header_path,source[0])) - env.Depends(target, header) - - -def static_pch_emitter(target,source,env): - SCons.Defaults.StaticObjectEmitter( target, source, env ) - setup_dependency(target,source,env, key='GCH') - return (target, source) - -def shared_pch_emitter(target,source,env): - SCons.Defaults.SharedObjectEmitter( target, source, env ) - setup_dependency(target,source,env, key='GCH-sh') - return (target, source) - - -def generate(env): - """ Add builders and construction variables for the Gch builder. - """ - env.Append(BUILDERS = { - 'gch': env.Builder( - action = GchAction, - target_factory = env.fs.File, - ), - 'gchsh': env.Builder( - action = GchShAction, - target_factory = env.fs.File, - ), - }) - - try: - bld = env['BUILDERS']['GCH'] - bldsh = env['BUILDERS']['GCH-sh'] - except KeyError: - bld = GchBuilder - bldsh = GchShBuilder - env['BUILDERS']['PrecompiledHeader'] = bld - env['BUILDERS']['PrecompiledHeaderShared'] = bldsh - - env['GCHCOM'] = '$CXX -o $TARGET -x c++-header -c $CXXFLAGS $_CCCOMCOM $SOURCE' - env['GCHSHCOM'] = '$CXX -o $TARGET -x c++-header -c $SHCXXFLAGS $_CCCOMCOM $SOURCE' - env['GCHSUFFIX'] = '.gch' - - for suffix in SCons.Util.Split('.c .C .cc .cxx .cpp .c++'): - env['BUILDERS']['StaticObject'].add_emitter( suffix, static_pch_emitter ) - env['BUILDERS']['SharedObject'].add_emitter( suffix, shared_pch_emitter ) - - -def exists(env): - return env.Detect('g++') From b556d2b770fc794a6dae7dc5bfe050a6beba51cf Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 8 Sep 2025 04:04:39 +0200 Subject: [PATCH 24/51] clean-up: comb through the historical pages to fix markup errors MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run. --- doc/design/application/ApplicationStart.txt | 2 +- .../GuiBrainstormingWontImplement.txt | 2 +- doc/design/gui/GuiDiscussion/PieMenu.txt | 2 +- doc/design/gui/GuiDiscussion/Workspaces.txt | 48 ++- .../workflow/Verwijlen/FrosconMeeting.txt | 2 +- .../workflow/Verwijlen/WorkflowProposals.txt | 6 +- doc/devel/meeting_summary/2008-02-01.txt | 41 +- doc/devel/meeting_summary/2008-03-06.txt | 143 ++++--- doc/devel/meeting_summary/2008-04-03.txt | 113 +++-- doc/devel/meeting_summary/2008-05-08.txt | 134 +++--- doc/devel/meeting_summary/2008-06-06.txt | 46 +- doc/devel/meeting_summary/2008-07-06.txt | 65 ++- doc/devel/meeting_summary/2008-09-04.txt | 12 +- doc/devel/meeting_summary/2008-10-10.txt | 100 +++-- doc/devel/meeting_summary/2008-11-12.txt | 4 +- doc/devel/meeting_summary/2008-12-10.txt | 8 +- doc/devel/meeting_summary/2009-01-14.txt | 56 ++- doc/devel/meeting_summary/2009-09-09.txt | 6 +- doc/devel/meeting_summary/2011-03-09.txt | 14 +- doc/devel/meeting_summary/2011-04-13.txt | 41 +- doc/devel/meeting_summary/2012-09-12.txt | 4 +- doc/devel/meeting_summary/2023-09-13.txt | 4 +- doc/devel/meeting_summary/2023-10-11.txt | 2 +- doc/devel/meeting_summary/2023-11-08.txt | 2 +- doc/devel/meeting_summary/2024-01-10.txt | 2 +- doc/devel/meeting_summary/index.txt | 4 +- doc/devel/rfc/AllPluginInterfacesAreC.txt | 20 +- doc/devel/rfc/ApplicationInstall.txt | 20 +- doc/devel/rfc/ApplicationStructure.txt | 90 ++-- doc/devel/rfc/ArchitectureOverview.txt | 39 +- doc/devel/rfc/CCodingStyleGuide.txt | 95 +++-- doc/devel/rfc/ClipCatalogingSystem.txt | 75 ++-- doc/devel/rfc/CodingStyle.txt | 38 +- doc/devel/rfc/ConfigLoader.txt | 45 +- doc/devel/rfc/DataBackend.txt | 67 +-- doc/devel/rfc/DelectusShotEvaluator.txt | 117 +++--- doc/devel/rfc/DesignParamAutomation.txt | 57 ++- doc/devel/rfc/DesignRenderNodesInterface.txt | 51 ++- .../rfc/DeveloperDocumentationStructure.txt | 26 +- doc/devel/rfc/DevelopmentFramework.txt | 78 ++-- .../rfc/DistributedDevelopmentFramework.txt | 50 ++- doc/devel/rfc/EDLsAreMetaClips.txt | 164 +++++--- doc/devel/rfc/EngineInterfaceOverview.txt | 46 +- doc/devel/rfc/EngineInterfaceSpec.txt | 33 +- .../rfc/FeatureBundle_PluggableModules.txt | 75 ++-- doc/devel/rfc/GitCommitMessageFormat.txt | 16 +- doc/devel/rfc/GitSubmoduleTransistion.txt | 45 +- doc/devel/rfc/GlobalInitialization.txt | 52 +-- doc/devel/rfc/HowToProceed.txt | 56 ++- doc/devel/rfc/InterfaceNamespaces.txt | 87 ++-- doc/devel/rfc/LayerNames.txt | 16 +- doc/devel/rfc/LumieraDesignProcess.txt | 55 +-- doc/devel/rfc/LumieraForwardIterator.txt | 133 +++--- .../rfc/MakeSconsTheOfficialBuildSystem.txt | 21 +- doc/devel/rfc/Manifest.txt | 52 ++- doc/devel/rfc/MarbleMode.txt | 80 ++-- doc/devel/rfc/MasterRepositorySetup.txt | 90 ++-- doc/devel/rfc/MistakestoAvoid.txt | 396 +++++++++++------- .../rfc/MonthlyDeveloperMeetingOnIRC.txt | 50 +-- doc/devel/rfc/NoBugFlags.txt | 25 +- doc/devel/rfc/NormalizedDeviceCoordinates.txt | 51 +-- doc/devel/rfc/OfficialAssemblyLanguage.txt | 124 +++--- doc/devel/rfc/ProcBuilder.txt | 28 +- doc/devel/rfc/ProcHighLevelModel.txt | 61 +-- doc/devel/rfc/ProcPlacementMetaphor.txt | 73 ++-- doc/devel/rfc/RefactorLiblumieraOut.txt | 111 +++-- doc/devel/rfc/RenderOptimizer.txt | 68 +-- doc/devel/rfc/RepositorySetup.txt | 130 +++--- doc/devel/rfc/ResourceManagementBudgeting.txt | 143 ++++--- doc/devel/rfc/ResourceManagementProfiling.txt | 152 ++++--- doc/devel/rfc/Roadmap-first.txt | 144 ++++--- doc/devel/rfc/SchedulerRequirements.txt | 16 +- doc/devel/rfc/ScriptingLanguage.txt | 34 +- doc/devel/rfc/SemanticTags.txt | 30 +- doc/devel/rfc/SkillsCollection.txt | 44 +- doc/devel/rfc/StreamTypeSystem.txt | 99 +++-- doc/devel/rfc/SystematicMetadata.txt | 43 +- doc/devel/rfc/TagCloudsOnResources.txt | 78 ++-- ...eadsSignalsAndImportantManagementTasks.txt | 54 +-- doc/devel/rfc/TimeHandling.txt | 102 +++-- doc/devel/rfc/TimelineSequenceOutput.txt | 122 +++--- doc/devel/rfc/TodoLists.txt | 17 +- doc/devel/rfc/UnitTests_Python.txt | 50 +-- doc/devel/rfc/UseCases.txt | 41 +- doc/devel/rfc/VersionNumberScheme.txt | 34 +- doc/devel/rfc/WebsiteNavigation.txt | 27 +- doc/devel/rfc/WebsiteSupportMarkup.txt | 26 +- .../YYYY-MM-DD-developerMeetingSummary.txt | 4 +- doc/devel/template/new_rfc.sh | 2 +- doc/technical/code/index.txt | 2 +- doc/technical/infra/MenuGen.txt | 42 +- doc/technical/overview.txt | 2 +- doc/technical/vault/scheduler.txt | 2 +- wiki/thinkPad.ichthyo.mm | 99 ++++- 94 files changed, 2987 insertions(+), 2291 deletions(-) diff --git a/doc/design/application/ApplicationStart.txt b/doc/design/application/ApplicationStart.txt index 41206a4c5..a460039e4 100644 --- a/doc/design/application/ApplicationStart.txt +++ b/doc/design/application/ApplicationStart.txt @@ -98,7 +98,7 @@ within the engine independently, relying on worker jobs and a thread pool. Initialisation and Lifecycle ---------------------------- After some discussion,footnote:[See the -link:{ldoc}/devel/rfc/GlobalInitialization.html[GlobalInitialisation] RfC +link:{rfc}/GlobalInitialization.html[GlobalInitialisation] RfC from spring 2008. In the beginning, we all agreed to ``keep matters simple'' and build an `init()` function within one central piece of code everyone knows and hooks into. However, while the outline of the application emerged, there diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt index 49b63eacc..7db552ef7 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt @@ -89,7 +89,7 @@ JoelHoldsworth:: '2008-07-22T22:25:58Z' -- * SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compisitor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency bluring and the ability to interpolate these events over time...things that can be incorperated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better. --- jb [[DateTime(2008-07-21T21:58:48Z)]] +-- jb '2008-07-21T21:58:48Z' - Comment: I am hoping that we can implement a simple set of skins for Lumiera. But we will be using the GTK based styles system, which is the standard. This allows theming to be done with a simple script file. These styles files are the more natural choice for UI theming, because WebKit is designed primarily for web, and would add a lot of unnecessary bloat to the app. Icons will be drawn as SVGs; a good choice for drawing the graphics, but these will be prerendered into PNGs at compile time as is standard practice for most free-desktop apps. + diff --git a/doc/design/gui/GuiDiscussion/PieMenu.txt b/doc/design/gui/GuiDiscussion/PieMenu.txt index 16ddfa042..01b88b116 100644 --- a/doc/design/gui/GuiDiscussion/PieMenu.txt +++ b/doc/design/gui/GuiDiscussion/PieMenu.txt @@ -4,7 +4,7 @@ Menu and Shortcuts :Date: 2008-05-14 -link:Lumiera/GuiBrainstorming/MenuAndShortcuts[] should explain most heavily discussed GUI features being related to Lumiera's GUI. +This pace is a place where to discuss some of the more controversial GUI features proposed for Lumiera's GUI. 3x3 Menus, Version 1 diff --git a/doc/design/gui/GuiDiscussion/Workspaces.txt b/doc/design/gui/GuiDiscussion/Workspaces.txt index 937458a5e..e11b303bd 100644 --- a/doc/design/gui/GuiDiscussion/Workspaces.txt +++ b/doc/design/gui/GuiDiscussion/Workspaces.txt @@ -7,7 +7,7 @@ Workspaces After some debate on IRC last night, it emerged that there are some differing ideas about how projects, sessions, panels and main-windows should work together, and it seems that there are different paradigms for workspaces. -I have my personal preferences, but my thinking is definitely incomplete - I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences. +I have my personal preferences, but my thinking is definitely incomplete -- I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences. Paradigm 1: Super-IDE Style @@ -18,7 +18,7 @@ The end result would be like getting multiple Xnests of Ion, and bear some simil This would make sense if the normal workflow would involves many projects, and a lot of inter-project work. -There are some plusses: +There are some pluses: * It's very orthogonal, and it lets the user configure their window layout to be exactly what they want. Lots of flexibility. @@ -48,7 +48,7 @@ joelholdsworths's Conclusion ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I favour this paradigm #2. The freedom from paradigm #1 enables some extra possibilities for window arrangement, but at the cost of a lot of extra complexity, and at the cost of allowing some pretty ugly configurations that both the programmer and the user would rather not have to think about. It seems to me that if you're doing a lot of inter-project work, you can drag windows into a formation - that's pretty normal for this rare case. -I wonder what the proffessional video editors think. Please leave comments. +I wonder what the professional video editors think. Please leave comments. @@ -57,48 +57,64 @@ Comments -------- Basically I agree/you convinced me with #2, Initially I was more after #1 but you pointed out some problems. But still -I would like to make some execptions from the rule, because I see viable use-cases. +I would like to make some exceptions from the rule, because I see viable use-cases. As you suggest, a window is related to a project, I would like to have a \'import' feature there where one can include/dock a component from another project. This then becomes a \'real' import which means the first project notes "display the timeline of project 2 in my window". This gives clean semantics for working with projects and windows and gives a clean abstraction of an \'import' we can even store in the session down. This imported components are then not -part of project 2's session. Usecases are side by side comparsion and work on 2 or more pojects, arrange timelines for -easier drag and drop operations, make this config a project setting (you dont have to open all dependent projects and +part of project 2's session. Use-cases are side by side comparison and work on 2 or more projects, arrange timelines for +easier drag and drop operations, make this config a project setting (you don't have to open all dependent projects and arrange a multitude of windows). Prolly the same (to a lesser extent) counts for importing the \'resources' of another project (hey have you thought about some collection of boilerplace footage, logos, intro sequence etc as clips stored -in a site-wide project withot timeline, but then you have all your production companies \'default' resources at +in a site-wide project without timeline, but then you have all your production companies \'default' resources at hand?). Next sharing viewers in one window, possible fullscreen on a 2nd monitor then you can have a 2x2 tiling or such for all kinds of previews, even external projects. + --- link:ct[] [[DateTime(2009-01-29T03:03:22Z)]] + +ct:: '2009-01-29T03:03:22Z' - Agreed. A nice "include" feature, so one project could refer to another would cover most of what you could imagine to do with multiple projects + --- link:Ichthyostega[] [[DateTime(2009-01-29T03:36:08Z)]] ++ +Ichthyostega:: '2009-01-29T03:36:08Z' Ah just to have it noted, I told that often on irc: Dock windows shall not be a second class citizen. You mentioned that you want one able to open more windows for a project, undocking a pane shall just do that too. All windows can then be treated equal, can have a (toggleable) menu, toolbar and statusbar etc. Especially when working with big and/or multiple monitors it becomes really ugly when you have to move the mouse over your whole desktop setup just to reach a menu entry. (same for looking around to check information on the status bar, which shall represent the status -of the window which has focus anyways). And last but not least, the current GDL docks implement thir own drag handles, +of the window which has focus anyways). And last but not least, the current GDL docks implement their own drag handles, moving windows around has a big performance problem with some window managers, moving windows shall be the job of the window manager and not the job of the application, the only thing the application may do is hinting positions to the WM. These second class dock windows are neither https://tronche.com/gui/x/icccm/[ICCCM] conforming nor do they add any extra user experience, instead the user has to learn a new kind of window class. + --- link:ct[] [[DateTime(2009-01-29T03:15:03Z)]] + +ct:: '2009-01-29T03:15:03Z' To chime in with the commenting... this comparison rather strengthened my preference for paradigm #2 _for our situation here._ But I think we should try to exploit some of the extended possibilities which you usually rather find in those Super-IDE type applications: -perspectives, freely configurable pannels, multiple top level windows, something like palettes or tiling. +perspectives, freely configurable panels, multiple top level windows, something like palettes or tiling. When you compare the situation when working on software with the situation when working on a feature film, it seems to me that the situation don't match up. The rationale of having multiple software projects opened is (a) "lets see how I solved the same problem 2 months ago there..." and (b) working on a larger software compound, comprised of multiple parts, which may even be deployed distributed. I think none of these applies to film editing. (Maybe the situation is a bit different for putting together a TV show) -According to my own editing experiences, both film and sound, the "bringing in media into the project"-phase makes only a very small percentage of the overall time spent with a given project. Initially, after bringing in the raw footage, for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage and maybe try out some possible cuts and combinations in a throwaway fashion, just to get a feeling about the material. Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having muliple projects opened at the same time). What follows is a long fine tuning and augmenting phase. So, for me, setting things up so I can work comfortably in a rather focussed and limited part of the application couold be more important then exploring multiple projects at the same time. + --- link:Ichthyostega[] [[DateTime(2009-01-29T03:31:54Z)]] +According to my own editing experiences, both film and sound, the ``bringing media into the project''-phase makes only a very small percentage +of the overall time spent with a given project. Initially, after bringing in the raw footage, +for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage +and maybe try out some possible cuts and combinations in a throw-away fashion, just to get a feeling about the material. +Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having +multiple projects opened at the same time). What follows is a long fine tuning and augmenting phase. +So, for me, setting things up so I can work comfortably in a rather focused and limited part of the application could be +more important then exploring multiple projects at the same time. + -Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes) must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window (with one exception, that is fatal errors which will block the application until resolved). Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to cinelerra, but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log. + --- link:ct[] [[DateTime(2009-02-01T09:40:08Z)]] +Ichthyostega:: '2009-01-29T03:31:54Z' + +Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes) +must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window +(with one exception, that is fatal errors which will block the application until resolved). +Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to Cinelerra, +but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log. + +ct:: '2009-02-01T09:40:08Z' diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index 16027e1fd..1d884f7f0 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -21,7 +21,7 @@ Points discussed ---------------- We agreed upon the importance of a link:WorkflowProposals.html#\_tracks_vs_trackless[magnetic timeline], as introduced by Final Cut X. -However, our link:{ldoc}/devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)] +However, our link:{rfc}/ProcPlacementMetaphor.html[Placement concept (2008)] which predates FCPX's release,footnote:[Final Cut Pro X was link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic Timeline« is generally considered a novel concept introduced with this update. The initial reception diff --git a/doc/design/workflow/Verwijlen/WorkflowProposals.txt b/doc/design/workflow/Verwijlen/WorkflowProposals.txt index 1b3e8c37b..cfe579ef4 100644 --- a/doc/design/workflow/Verwijlen/WorkflowProposals.txt +++ b/doc/design/workflow/Verwijlen/WorkflowProposals.txt @@ -37,11 +37,11 @@ I've seen different editors using different ways of working. So if the aim for Lumiera is to be a general purpose video editing application, then we can not force any specific way of doing things and instead we should support many different workflows, in other words: provide a platform with possibilities for each editor to make it -their own (which will arguably be a harder goal to achieve). Instead of a "we know what's -best for you" approach I propose a "smart defaults with many options for configuration" +their own (which will arguably be a harder goal to achieve). Instead of a ``we know what's +best for you'' approach I propose a ``smart defaults with many options for configuration'' approach. -* A big question is: who is "the user"? We aim to create a tool for professionals, but there are +* A big question is: who is »the user«? We aim to create a tool for professionals, but there are many types of professionals working in entirely different parts of the media industry or in other fields. In the previous paragraph it was mentioned that different types of content require different types of workflows. How to accommodate all of these different people who diff --git a/doc/devel/meeting_summary/2008-02-01.txt b/doc/devel/meeting_summary/2008-02-01.txt index 98a2655ef..1f4767144 100644 --- a/doc/devel/meeting_summary/2008-02-01.txt +++ b/doc/devel/meeting_summary/2008-02-01.txt @@ -18,24 +18,35 @@ __Participants__ * Velmont -Discuss the open points in [Lumiera/DesignProcess] --- do we need this formalism? ---------------------------------------------------------------------------------- -At start of the project last summer, Cehteh made a http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process proposal]. We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. One point in the agenda of future meetings will be to work through proposals in the queue +Discuss the open points in the link:/x/DesignProcess.html[Design Process] +------------------------------------------------------------------------- - * proposals in the "idea" state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page. - * proposals in the "draft" state are ready for conclusive discussion and will be treated in one of the next meetings - * "final" proposals are either "accepted" or "dropped". We don't differentiate the latter, but should write a short note why it was dropped. +Do we need this formalism? -- + +At start of the project last summer, _Cehteh_ made a link:{rfc}/LumieraDesignProcess.html[»Design Process« proposal]. +We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. +One point in the agenda of future meetings will be to work through proposals in the queue. + + * proposals in the `Idea' state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page. + * proposals in the `Draft' state are ready for conclusive discussion and will be treated in one of the next meetings + * `Final' proposals are either `Accepted' or `Dropped'. We don't differentiate the latter, but should write a short note why it was dropped. * if there is need for more or finer grained categories, we'll extend the page and the template as needed or provide different views The development model --------------------- -We employ a distributed model based on GIT. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a "Mob GIT", i.e. anonymously pushable git (which is untrusted of course). Cehteh is currently working on a git web frontend which makes the codebase in the mob-repo web-editable like a wiki. -Will we need a stable version or an official branch? not yet — as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it. -Ichthyo proposes a new requirement: All devs should ensure the "master" branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator. -A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature — esp. when it fits into the core focus of the project — instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits. +We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course)._ Cehteh_ is currently working on a Git web frontend which makes the codebase in the mob-repo web-editable like a wiki. + +Will we need a stable version or an official branch? not yet -- as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it. + +Ichthyo proposes a new requirement: All devs should ensure the `master' branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator. + +A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature -- esp. when it fits into the core focus of the project -- instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits. + And, pretty much obvious, we try to stick to modern programming standards. Read: modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion. + Currently, the project can be separated into three layers, which could evolve into sub-projects: Backend, Proc-Layer, GUI. For each part, the dev most deeply involved and most knowledgeable will take on the sometimes necessary leadership and have the last word in case of quarrels. Currently, Cehteh cares for the Backend and Ichthyo headed for the Proc-Layer. We have postponed any work on the GUI for now and don't participate in GUI toolkit discussions. If there is a dev willing to care for the GUI, collect proposals, care for usability and the users needs and finally code it up, then he will the one to decide what toolkit to use. + We plan to make the discussion about GPL v3 a point on the agenda of the next meeting. @@ -43,11 +54,11 @@ Monthly meetings ---------------- * make it thursday, not friday - * time for now 21:00 GMT — if some (potential) participants have problems with this time, please speak up (maybe alternating times?) + * time for now 21:00 GMT -- if some (potential) participants have problems with this time, please speak up (maybe alternating times?) * write a short status report for each mayor part *prior* to the meeting (saves us time). Maybe add an TODO list there * go through the open issues for the design process drafts - * publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the link:TiddlyWiki[] and on pipapo.org - * News, Protocols and the agenda of the next meeting can be found at link:MonthlyMeetings[this page here] + * publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the TiddlyWiki and on `pipapo.org` + * News, Protocols and the agenda of the next meeting can be found at link:{ldoc}/devel/meeting_summary/index.html[Monthly meetings page] * next meeting on first Thursday in March (6.3.2008) @@ -71,11 +82,11 @@ Since the render nodes are stateless they can be driven in multiple threads (but The naming discussion --------------------- -The discussion looks healthy so far... People can add new proposals on the http://www.pipapo.org/pipawiki/Lumiera/Names[pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-) +The discussion looks healthy so far... People can add new proposals on the [pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-) Let's say, we need a person volonteering to guide/moderate the selection, going over the list and scratching inammprobiate ones. Criteria for good names being: * should not be an existing project - * should be "googleable" + * should be ``googleable'' * should not be offensive * should have one of the free top level domains (.net, .org) * should be compatible with educational institutions (sorry, no pr0nedit :) diff --git a/doc/devel/meeting_summary/2008-03-06.txt b/doc/devel/meeting_summary/2008-03-06.txt index 4b28897b8..131d1868d 100644 --- a/doc/devel/meeting_summary/2008-03-06.txt +++ b/doc/devel/meeting_summary/2008-03-06.txt @@ -26,8 +26,8 @@ Boilerplate Organization of this meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - * cehteh writes the protocol - * hermanr does chairman + * _Cehteh_ writes the protocol + * _Hermanr_ does chairman Leftovers from last meeting @@ -41,80 +41,93 @@ Go through Ideas and Drafts in design process Idea: time_handling ~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[] +link:{rfc}/TimeHandling.html[time handling] -Point 1 is superseded by using gavl. +Point 1 is superseded by using Gavl. Points 2 and 3 are still valid. -Ichthyo asked gmerlin if there are any problems according gavl for the points 2 (position of frames) and 3 (position for keyframes and automation). Gmerlin acknowledges that he doesnt see any problems. +_Ichthyo_ asked _Gmerlin_ if there are any problems according Gavl for the points 2 (position of frames) and 3 (position for keyframes and automation). +_Gmerlin_ acknowledges that he does not see any problems. -Oracle2025 brings interlacing on topic "are you aware that automations and keyframes could/should also apply to fields?". We agree that this must be handled "in interlacing, a frame is a pair of 2 subsequent fields". +_Oracle2025_ brings interlacing on topic ``are you aware that automations and keyframes could/should also apply to fields?''. +We agree that this must be handled ``in interlacing, a frame is a pair of 2 subsequent fields''. -Conclusion: - Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting +Conclusion:: Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting Idea: Unit tests in Python ~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UnitTests_Python[] +link:{rfc}/UnitTests_Python.html[RfC: Unit Tests in Python] -We have a testsuite based on cehtehs 'test.sh' which superseedes this proposal. +We have a testsuite based on _Cehtehs_ `test.sh` which superseeds this proposal. -Conclusion: - Drop it. +Conclusion:: Drop it. Idea: Todo Lists ~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TodoLists[] +link:{rfc}/TodoLists.html[Todo Lists] to organise tasks to be done.... -This Idea is in a very early state an not yet mature. -Cehteh explains: "I want something which doesn't need much human care and i want one big \'milestones' thing and a small \'mini-task' thing". Ichthyo refines this as "Roadmap" and "Near time task list". We agree that this shall not be too strict. There are some ideas floating, like adding this things to the testsuite or use the wiki. Ichthyo shows how he uses the tiddlywiki's task macro (http://ichthyostega.de/cin3/wiki/renderengine.html#PlanningNodeCreatorTool[]). He likes it but doubts its usefulness when it is used without guessing the hours/days of work. +This idea is in a very early state an not yet mature. +Cehteh explains: ``I want something which doesn't need much human care and i want one big »milestones« +thing and a small »mini-task« thing''. Ichthyo refines this as »Roadmap« and »Near time task list«. +We agree that this shall not be too strict. There are some ideas floating, like adding this things +to the testsuite or use the wiki. _Ichthyo_ shows how he uses the TiddlyWiki's `task macro`. +He likes it but doubts its usefulness when it is used without guessing the hours/days of work. -Conclusion: - We use the Tiddlywiki task macro thing for now. +Conclusion:: We use the TiddlyWiki task macro thing for now... Draft: CCodingStyleGuide ~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/CCodingStyleGuide[] +link:{rfc}/CCodingStyleGuide.html[C-coding style guide] -Ichthyo tells that the discussion on the wiki page made this clear now. Cehteh explains that he uses this style with success for diffrent projects. We make clear that this is meant for C, in C++ we use namespaces. Overall we agree that code shall be self-documenting. +_Ichthyo_ tells that the discussion on the wiki page made this clear now. +_Cehteh_ explains that he uses this style with success for different projects. +We make clear that this is meant for C, in C++ we use namespaces. +Overall we agree that code shall be self-documenting. -Conclusion: - Make it final. +Conclusion:: Make it final. Draft: DevelopmentFramework ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DevelopmentFramework[] +link:{rfc}/DevelopmentFramework.html[Development Framework] -Cehteh explains that he will transfer this propoal to a tiddlywiki covering compatibility guides and dependencies. We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet. +_Cehteh_ explains that he will transfer this propoasl to a TiddlyWiki covering compatibility guides and dependencies. +We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet. -A short discussion about build systems came up, we still use autotools and scons in parallel, delaying the decision later. oracle2025 mentioned that scons could be used for development and autotools for release. No decision about that everyone has different opinions. But we agree that it works as is. +A short discussion about build systems came up, we still use Autotools and SCons in parallel, delaying the decision later. +_Oracle2025_ mentioned that SCons could be used for development and Autotools for release. +No decision about that everyone has different opinions. But we agree that it works as is. -Conclusion: +Conclusion:: Cehteh will make the proposed wiki which shall be maintained to reflect the state and this topic will be finalized by that. Draft: Skills Collection ~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/SkillsCollection[] +link:{rfc}/SkillsCollection.html[RfC: Collection of Skills] This might be only useful if there are more developers working on the project. -Conclusion: +Conclusion:: Leave in draft state for now. Draft: Architecture Overview ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[] +link:{rfc}/ArchitectureOverview.html[Architecture Overview] -Ichthyo drawn a diagram showing the planned architecture. Cehteh raises concerns about codecs/plugins/effects in backend. After that there was some discussion about details. Cehteh suggests to place plugins in a extra box, gmerlin suggests that \'plugins' don't fit into the diagram, there should be "filters", "sources",..; Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements. +_Ichthyo_ has drawn a diagram to show the planned architecture. +_Cehteh_ raises concerns about codecs/plugins/effects in backend. +After that there was some discussion about details. +_Cehteh_ suggests to place plugins in a extra box, _Gmerlin_ suggests that ``plugins'' don't fit into the diagram, +there should be ``filters'', ``sources'',..; +Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements. -Conclusion: +Conclusion:: Good idea, needs some refinements, work in progress. @@ -122,47 +135,65 @@ Conclusion: Call for Design --------------- -Ichthyo explains that the wants the overall design a bit more formalized. He put this topic on the agenda to remind that we have to work it out in link:DesignProcess[] and already started to make some design proposals. +Ichthyo explains that the wants the overall design a bit more formalized. +He put this topic on the agenda to remind that we have to work it out in link:/x/DesignProcess.html[the Design Process] +and already started to make some design proposals. -Conclusion: - Things need to be worked out in link:DesignProcess[], take a look and review it. +Conclusion:: + Things need to be worked out as RfC -- take a look and review it. Naming ------ -Raffa, Velmont, goibhniu and others collected and managed proposed names past weeks which finally ended in a community voting. Results are at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_9fad0d1d10c23d38[] -Lumiera won, Lumiera.org is free and no one of in this meeting has objections against this name. Velmont offers to register and pay for the lumiera.org domain which will be hosted on our own server (see topic below). Hermanr raises concerns if it is ok when the name is registered on another site and by another person than the server, cehteh explains that he like this distribution where doable and no one other objects. Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds. After a short discussion we agree that we use the full name and no abbreviation. We now have to rename the source and the wiki. Anyone renames the sourcecode where he is responsible for. Cehteh will go over the pipapo.org wiki and rename things. +_Raffa_, _Velmont_, _Goibhniu_ and others collected and managed proposed names past weeks which finally ended in a community voting. +Results are at [purple]##. The name *Lumiera* won, +"`Lumiera.org`" is free and no one of in this meeting has objections against this name. +_Velmont_ offers to register and pay for the Lumiera.org domain which will be hosted on our own server (see topic below). +_Hermanr_ raises concerns if it is ok when the name is registered on another site and by another person than the server, +_Cehteh_ explains that he like this distribution of responsibilities where doable and no one other objects. +Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds. +After a short discussion we agree that we use the full name and no abbreviation. +We now have to rename the source and the wiki. Anyone renames the source code where he is responsible for. +_Cehteh_ will go over the `pipapo.org` wiki and rename things. -Finally we express our great thanks to the people who put the efforts into the name selection, thanks raffa, Velmont, goibhniu & co. +Finally we express our great thanks to the people who put the efforts into the name selection, thanks _Raffa_, _Velmont_, _Goibhniu_ & co. -Conclusion: - Projectname is Lumiera, we have a lot things to rename. +Conclusion:: + Project name is *Lumiera*, we have a lot things to rename. Project Server, setup, organization, administration --------------------------------------------------- -Some people gathered together and rented a server at http://www.hetzner.de[hetzner.de] which will host some free project pages and personal sites. Cehteh is the one who signed for the server and officially respobsible for it. +Some people gathered together and rented a server at https://www.hetzner.com/[hetzner.de] which will host some free project pages and personal sites. +_Cehteh_ is the one who signed for the server and will be officially responsible for it. -The server is split into isolated \'vservers' which are created as needed. Idea is to work cooperatively to get the best out of its resources. +The server is split into isolated »VServers« which are created as needed. Idea is to work cooperatively to get the best out of its resources. -For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things. Velmont offered to help with lumiera.org, hermanr takes care of cinelerra.org, raffa will help with maintaining the webpages. oracle2025 will care for developer chroots, build and test environments. cehteh will make a page on pipapo.org which reflects the current server setup http://www.pipapo.org/pipawiki/RootServerSetup[]. There are still a lot jobs to do! +For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things. +_Velmont_ offered to help with Lumiera.org, _Hermanr_ takes care of Cinelerra.org, _Raffa_ will help with maintaining the webpages. +_Oracle2025_ will care for developer `chroots`, build and test environments. +_Cehteh_ will make a page on pipapo.org which reflects the current server setup [purple]##. There are still a lot jobs to do! -Cehteh asked about how to manage emergency root access on the host/root server when he is unreachable. There where several suggestions between one root key for all who pay for the server to shared key schemes. We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access. +_Cehteh_ asked about how to manage emergency root access on the host/root server when he is unreachable. +There where several suggestions between one root key for all who pay for the server to shared key schemes. +We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access. -The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer vserver shared between all developers. Maybe a shared mail server. +The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer VServer shared between all developers. Maybe a shared mail server. -Hermanr asked about how to handle distribution of large media files. There was some discussion about bittorrent vs http. We concluded to work that out as needed. +_Hermanr_ asked about how to handle distribution of large media files. There was some discussion about Bittorrent vs HTTP. We concluded to work that out as needed. -In the forthcoming discussion about cehteh stresses that "it is a public server, if you place confidential information unencrypted on it, its you fault". Ssh keys shall be kept secret by the users but we can't enforce policies on those. +In the forthcoming discussion about security, _Cehteh_ stresses that ``it is a public server, if you place confidential information unencrypted on it, its you fault''. +SSH keys shall be kept secret by the users but we can't enforce policies on those. -Ichthyo asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, cehteh explains that webgit isn't ready yet but should be useable in a few days (pipapo.org will use that too). Velmont suggest a \'real' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org. +_Ichthyo_ asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, _Cehteh_ explains that webgit isn't ready yet but should be useble in a few days (pipapo.org will use that too). +_Velmont_ suggest a ``real'' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org. -Hermanr asked Velmont about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things. +_Hermanr_ asked _Velmont_ about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things. -Ichthyo asks about keeping the Lumiera project pages on pipapo.org until the server is ready, this is ok. +_Ichthyo_ asks about keeping the Lumiera project pages on pipapo.org until the server is ready, _Cehteh_ confirms this is OK. -Conclusions: +Conclusions:: We have our own server which now needs volunteers for maintenance. The projects will slowly move there, until ready Lumiera stays on pipapo.org. @@ -170,10 +201,16 @@ Conclusions: GPL3 pros cons, license rationale --------------------------------- -Ichthyo and cehteh would like to investigate a license change to GPLv3, neither of us has experience with problems this -might raise. Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses. The others here thinking that "GPLv2 or later" would be most-compatible. Gmerlin tells that he uses some "GPLv2 only" mplayer code in gavl which is itself "GPLv2 or later". Cehteh explains that "GPLv2 only" code is a problem, where "GPLv2 or later" is not. Ichthyo raises concerns that the Support library may need to be LGPL, cehteh mentions that it would likely be enough if we only apply that to the plugin-loader. After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner. +_Ichthyo_ and _Cehteh_ would like to investigate a license change to GPLv3, neither of us has experience with problems this might raise. +Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses. +The others here thinking that ``GPLv2 or later'' would be most-compatible. _Gmerlin_ tells that he uses some ``GPLv2 only'' MPlayer code in Gavl, +which is itself ``GPLv2 or later''. _Cehteh_ explains that ``GPLv2 only'' code is a problem, where ``GPLv2 or later'' is not. +_Ichthyo_ raises concerns that the Support library may need to be LGPL, +while _Cehteh_ mentions that it would likely be enough if we only apply that to the plugin-loader. +After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses +and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner. -Conclusion: +Conclusion:: Learn more about GPLv3, use GPLv2 or later and propose to switch to GPLv3 when we are ready to do public beta releases when possible. @@ -185,5 +222,5 @@ The next meeting will be at thuesday 3rd april 21:00GMT (if not rescheduled see Ichthyo tells that Martin Ellison wrote he couldn't attend because of the time. So again we made a short discussion about changing/alternating timings to allow people in downunder/japan to attend. They have to speak up an make time suggestions. -Conclusion: +Conclusion:: Next meeting 3rd april 21:00GMT. But Aussies, please speak up if you want the time changed! diff --git a/doc/devel/meeting_summary/2008-04-03.txt b/doc/devel/meeting_summary/2008-04-03.txt index 36cad109f..0cbeffcc6 100644 --- a/doc/devel/meeting_summary/2008-04-03.txt +++ b/doc/devel/meeting_summary/2008-04-03.txt @@ -20,7 +20,7 @@ Boilerplate Organization of this meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - * sakalli writes the protocol, ichthyo will help reviewing it + * _sakalli_ writes the protocol, ichthyo will help reviewing it Recurring Topics @@ -32,20 +32,25 @@ Call for volunteers ------------------- (which tasks are to do, how can we interest people...?) -There was a sense that there are people willing to help but they might need direction or cannot do actual coding. But there is also a lot of tasks that could be done by beginners and non-programmers. These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers. Examples of such tasks: +There was a sense that there are people willing to help but they might need direction or cannot do actual coding. +But there is also a lot of tasks that could be done by beginners and non-programmers. +These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers. +Examples of such tasks: * Protocol writing * maintaining to do lists and isolating tasks * constant code and documentation review * unit/functional testing - * header file "task force" - some fundamentals discussed by the developers on libopenvideo should find their way into basic .h files + * header file ``task force'' - some fundamentals discussed by the developers on libopenvideo should find their way into basic `.h` files * installing and maintaining project tracking and automated builds/tests on the server -See http://www.lumiera.org/wiki/todo.html#Tasks[] +See [purple]## -It was also noted that at current phase some basic development is still needed before we can accommodate a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example. +It was also noted that at current phase some basic development is still needed before we can accommodate +a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example. -To make it easier for "beginners" to get aquainted with the program it was decided that one *official Lumiera GIT repository* should be established. +To make it easier for ``beginners'' to get acquainted with the program it was decided that +one *official Lumiera GIT repository* should be established. (-> `git://git.lumiera.org/LUMIERA`) @@ -53,7 +58,17 @@ Project announcements/registration ---------------------------------- (freshmeat, gnu, etc...) any takers? -The discussion was about advertising the project on various sites. There were some concerns raised that it is too early to do too much publicity at the moment. That the right time should be shortly before the first public release. But there is also some value in registering to the project in planning/alpha stage to interest people such as prospective coders. It was noted that the http://www.linux.com/feature/126441[article on linux.com] resulted in a lot of people contacting ichthyo and cehteh. http://plot.bek.no/pipermail/piksel/2008-January/003328.html["I believe in Cinelerra"] by Leo Germani also generated a lot of traffic by developers. Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on. +The discussion was about advertising the project on various sites. +There were some concerns raised that it is too early to do too much publicity at the moment; +the right time should be shortly before the first public release. But there is also some value +in registering to the project in planning/alpha stage to interest people such as prospective coders. +It was noted that the +https://web.archive.org/web/20090601174640/http://www.linux.com/archive/feature/126441[article on Linux.com] +resulted in a lot of people contacting Ichthyo and Cehteh. +»I believe in Cinelerra« +by Leo Germani also generated a lot of traffic by developers. +[purple]## +Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on. Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful) @@ -62,51 +77,76 @@ Conclusion: volunteer needed to coordinate publicity (not overly urgent, but hel Informal talk about the GUI --------------------------- -Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo: GUI and backend should be completely separated and communicate via pipes. It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used. Some comments: +Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo: +GUI and backend should be completely separated and communicate via pipes. +It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used. +Some comments: - * cehteh standalone gui is a nice to have, but implementation details have to be worked out - * gmerlin Video playback can be separated in a separate X connection - * cehteh suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later - * rgareus IMHO you want to share memory for the video-frame buffer beween the player and backend - with pipes you'll go the video-jack way. + * _cehteh_: standalone gui is a nice to have, but implementation details have to be worked out + * _gmerlin_: Video playback can be separated in a separate X connection + * _cehteh_ suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later + * _rgareus_ IMHO you want to share memory for the video-frame buffer between the player and backend - with pipes you'll go the video-jack way. -joelholdsworth is a new developer in the group and had showed interest in developing the GUI. he stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm. There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME). Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language. +_JoelHoldsworth_ is a new developer in the group and had showed interest in developing the GUI. +He stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards +to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm. +There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME). +Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language. Cario was suggested to be used for implementing the canvas in the timeline view. -The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins. Tracks can be nested. Use tiling windows and dockeable views and tools palettes. For example some configuration within session/renderpipeline may cause some pluggable elements to be added to the gui. A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews). A video track renders thumbnails, automation curves on top. +The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins. +Tracks can be nested. Use tiling windows and dockable views and tools palettes. +For example some configuration within session / render-pipeline may cause some pluggable elements to be added to the gui. +A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews). +A video track renders thumbnails, automation curves on top. -Workflow is another important aspect to take into account in the design. A lot of information needs to come from editors and users in the design process. Different thoughts about the workflow: +Workflow is another important aspect to take into account in the design. +A lot of information needs to come from editors and users in the design process. +Some thoughts about the workflow: * Should not make a predefined workflow. Just produce a tool that can be adapted to different workflows. It can be predefined, but should not be fixed. - * We dont have the resources to develop a "workflow" in the formal manner, we will go the "propose and comment" route. + * We dont have the resources to develop a »workflow« in the formal manner, we will go the ``propose and comment'' route. * We should take the best ideas from popular competing products such as Final Cut Pro, AVID, Premiere plus After Effects. Customisation is deemed important. Some points brought up in the discussion: - * sakalli: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well. - * cehteh: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional + * _sakalli_: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well. + * _cehteh_: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional * Customization should be possible without recompile, but not too cheap. * There should be a working skeleton or some fixed anchor but gui operations should be bound to a scripting language to achieve customization. * The whole gui in a script with some performance critical widgets coded in C/C++ * Some parts should just be customizable, other parts should be kept fixed. - * cehteh suggested to start out by making a \'high level' description with no language/toolkit in mind .. what widgets do we need etc and after that to work on the skeleton mockup. - * cehteh / hermanr: Lumiera should allow to choose theme independently from desktop .. because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour + * cehteh suggested to start out by making a ``high level'' description with no language/toolkit in mind ... + what widgets do we need? etc and after that to work on the skeleton mockup. + * _cehteh_ + _hermanr_: Lumiera should allow to choose theme independently from desktop ... + because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour -ichthyo brings up the role of customization for the middle layer and gives an overview of his plans for the new participants. -He had good experiences with a rule based aproach in various projects. He wants to embed a Prolog interpreter that can answer to "configuration queries". There is a "builder" component in the middle layer to derive the render nodes graph based on a "high level model", which is visible to the user (in the GUI) and based on these configuration queries. +_Ichthyo_ brings up the role of customization for the middle layer and gives an overview of his plans for the new participants. +He had good experiences with a rule based approach in various projects. He wants to embed a Prolog interpreter that can answer +to ``configuration queries''. There is a ``builder'' component in the middle layer to derive the render nodes graph based on +a ``high level model'', which is visible to the user (in the GUI) and based on these configuration queries. -Rationale for using prolog is: The rules are very readable because they rather represent facts and relations, not the way "how dings are done" but the way "how things are related". Example: how to configure some effects when the footage is interlaced. Additionally, we want to have some global swithces, which could control these rules, like "I want maximum quality", or "I want as much as possible set up automatically". The prolog rules are stored in the session and can be editd by advanced users. Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue but it would have consequences for the GUI. +Rationale for using prolog is: The rules are very readable because they rather represent facts and relations, +not the way ``how things are done'' but the way ``how things are related''. +Example: how to configure some effects when the footage is interlaced. +Additionally, we want to have some global switches, which could control these rules, +like ``I want maximum quality'', or ``I want as much as possible set up automatically''. +The prolog rules are stored in the session and can be edited by advanced users. +Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue +but it would have consequences for the GUI. some discussion: - * joelholdsworth: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc. + * _joelholdsworth_: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc. * rules within the middle layer/session could bind to some properties exposed in the GUI - * gmerlin joelholdsworth: Agree, but point out that this can become difficult - * cehteh joelholdsworth: skeleton and plugins who attach into some gui areas, so you can add custom widgets - * ichthyo: also the ability to attach "tags" to various objects, so the rules can bind on those tags - * cehteh: maybe a standard set of widgets, not really completely custom ones (gmerlin agrees) - * joelholdsworth: probably you need to be able to do both well - * joelholdsworth in many apps the value/colour/string set works perfectly well, but in luminierra the controls will likely need to be much richer + * _gmerlin_, _joelholdsworth_: Agree, but point out that this can become difficult + * _cehteh_ + _joelholdsworth_: skeleton and plugins who attach into some GUI areas, so you can add custom widgets + * _ichthyo_: also the ability to attach ``tags'' to various objects, so the rules can bind on those tags + * _cehteh_: maybe a standard set of widgets, not really completely custom ones (_gmerlin_ agrees) + * _joelholdsworth_: probably you need to be able to do both well + * _joelholdsworth_ in many apps the value/colour/string set works perfectly well, + but in Lumiera the controls will likely need to be much richer Some brainstorming points about usability: @@ -116,20 +156,23 @@ Some brainstorming points about usability: One extra point: - * we have agreed to make all of the big interfaces between the layers as plain C interfaces, because this is the most widely supported common denominator. + * we have agreed to make all of the big interfaces between the layers as plain C interfaces, + because this is the most widely supported common denominator. GUI CONCLUSION ~~~~~~~~~~~~~~ - * joelholdsworth is now the official GUI maintainer for Lumiera! - * sakalli, hermanr, ichthyo announced interest in contributing to discussions about GUI, workflows and usability. gmerlin noted that he knows some gtk secrets and is willing to help out here too. + * _joelholdsworth_ is now the official GUI maintainer for Lumiera! + * _sakalli_, _hermanr_, _ichthyo_ announced interest in contributing to discussions about GUI, workflows and usability. + * _gmerlin_ noted that he knows some GTK secrets and is willing to help out here too. Froscon application ------------------- -http://www.froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented. Cehteh will be there as well as Ichthyo. Question is wether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june. +https://froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented. +Cehteh will be there as well as Ichthyo. Question is whether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june. We made no decision about official presence but most likely there will be a developer meeting if nothing else. @@ -139,7 +182,7 @@ Timecode metadata discussion ---------------------------- This Discussion started out on the libopenvideo list: The question was wether we agree on one uniform format solution from decoder up to app level regarding timecode. And what this format would be: arithmetic or struct type. Regarding metadata (including type of timecode) the question is if we should work out a rather fixed data format, or go the route towards rather open description records. -Conclusion: Gmerlin does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further. +Conclusion: _Gmerlin_ does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further. _A (shortended) digest of the timecode and metadata discussion is attached below_ diff --git a/doc/devel/meeting_summary/2008-05-08.txt b/doc/devel/meeting_summary/2008-05-08.txt index 6ab08ebde..d435521ad 100644 --- a/doc/devel/meeting_summary/2008-05-08.txt +++ b/doc/devel/meeting_summary/2008-05-08.txt @@ -24,44 +24,45 @@ Organization of this meeting Webpage-Infrastructure, Maintenance ----------------------------------- -Cehteh put this on topic because it's really urgent to bring up some +_Cehteh_ put this on topic because it's really urgent to bring up some infrastructure to manage the information we produce. The Lumiera pages on pipapo.org were always meant as intermediary -solution. Pipapo.org gets much spam on the moinmoin wiki and cehteh +solution. Pipapo.org gets much spam on the MoinMoin wiki and _Cehteh_ expresses that he wants to move pipapo.org to a new infrastructure -based on asciidoc and git he created -(see http://git.pipapo.org/uWiki.html[]). This system is barely useable +based on Asciidoc and Git he created +(see [purple]#`http://git.pipapo.org/uWiki.html` #). +This system is barely usable and needs lots of work to be completed. It would be nice to use it for Lumiera too, if the others agree. Maintaining and extending (scripting) needs someone who knows shell scripting and doesn't need to be done by the core devs freeing their resources to work on -Lumiera. Cehteh expresses that none of the people who proposed to +Lumiera. _Cehteh_ expresses that none of the people who proposed to help before showed up yet. WesLappy tells he might help (addendum not this week, because he is busy). -Next there was a suggestion by cehteh to convert the tiddlywikis to -asciidoc. Ichthyo expresses that he likes the tiddlywikis, Joel +Next there was a suggestion by _Cehteh_ to convert the TiddlyWikis to +Asciidoc. Ichthyo expresses that he likes the TiddlyWikis, Joel mentions that they feel a little odd. Generally we all agree that they have some problems in sense of workflow and merging. -Ichthyo makes the suggestion to keep the tiddlywikis as scrapbook and -build up \'official' documentation based on their content in -whatever-we-use-then (asciidoc) documentation system. All agree on +_Ichthyo_ makes the suggestion to keep the TiddlyWikis as scrapbook and +build up ``official'' documentation based on their content in +whatever-we-use-then (Asciidoc) documentation system. All agree on this approach. -Back to the new wiki, cehteh suggests to make stricter access rules to -prevent spam: "There will be a group of \'Validated' people which -following rules: only Validated people can edit general content and -\'Validated' people can add new people to \'Validated' themselves". That +Back to the new wiki, _Cehteh_ suggests to make stricter access rules to +prevent spam: ``There will be a group of `Validated' people which +following rules: only `Validated' people can edit general content and +`Validated' people can add new people to `Validated' themselves''. That means that we can have a lightweight self-administrating authentication where new people have to be introduced by someone who is already there. -Ichthyo suggests to send a reply to Serge G. who send an introduction +_Ichthyo_ suggests to send a reply to Serge G., who send an introduction to the cinelerra mailing list expressing that he would like to help. -Raffa will take care of content/design as much her time/knowledge permits. +_Raffa_ will take care of content/design as much her time/knowledge permits. Conclusion @@ -69,25 +70,25 @@ Conclusion * We really need someone to help with the webpage scripting. * Documentation needs to be well organized and moved over. - * Content of the pipapo.org moinmoin wiki should be moved over. - * The new website should be well organized with a nice looking frontpage + * Content of the pipapo.org MoinMoin wiki should be moved over. + * The new website should be well organized with a nice looking front page * All other documentation should be below that -Whats pending in link:DesignProcess[] -------------------------------------- +Whats pending in the DesignProcess / RfC +---------------------------------------- MistakestoAvoid ~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[] +link:{rfc}_dropped/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design] -rick_777 wrote a "MistakestoAvoid" page which explains some possible +_rick_777_ wrote a "MistakestoAvoid" page which explains some possible gotchas. We basically agree with most points there while we already decided to address some things differently than he suggested. One -noteable difference is that we do not intent to provide a windows -version of Lumiera, which was explained in serveral places. Cehteh +notable difference is that we do not intent to provide a windows +version of Lumiera, which was explained in several places. _Cehteh_ added some comments to the page explaining some things. @@ -96,29 +97,28 @@ nothing more to discuss in \'Ideas', we go over to \'Drafts' ArchitectureOverview ~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[] +link:{rfc}/ArchitectureOverview.html[RfC: Architecture Overview] -Cehteh suggests to put that drawing under version control, as .fig. -Ichthyo explains that it is already a .SVG and that he does not like -.fig. +_Cehteh_ suggests to put that drawing under version control, as .fig. +Ichthyo explains that it is already a `.SVG` and that he does not favour `.fig`. -Conclusion: We agree to keep it as .SVG, add it to the repository and +Conclusion:: We agree to keep it as `.SVG`, add it to the repository and improve/complete it. GitSubmoduleTransistion ~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GitSubmoduleTransistion[] +link:{rfc}/GitSubmoduleTransistion.html[RfC: Git Submodules] -Another suggestion made by cehteh is to make managing of subprojects -within the sourcetree easier. Joel and ichthyo oppose that it is not -really needed now and needs more understanding of git. Ichthyo -suggests that the documentation might be separated into its own git, +Another suggestion made by _Cehteh_ is to make managing of subprojects +within the sourcetree easier. _Joel_ and _Ichthyo_ object that it is not +really needed now and needs more understanding of Git. _Ichthyo_ +suggests that the documentation might be separated into its own Git, he further explains that the things are not settled yet and we don't know if we will some rearrangements and movements of files between modules. -Conclusion: We transform the documentation to a submodule and see how +Conclusion:: We transform the documentation to a submodule and see how it works. Other things will be decided much later. @@ -126,19 +126,19 @@ it works. Other things will be decided much later. GlobalInitialization ~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GlobalInitialization[] +link:{rfc}/GlobalInitialization.html[RfC: Global Init] -This topic is discussed and agreed on the link:DesignProcess[] page already. +This topic is discussed and agreed on the RfC page already. -Conclusion: finalize it +Conclusion:: finalize it MasterRepositorySetup ~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MasterRepositorySetup[] +link:{rfc}/MasterRepositorySetup.html[RfC: Shared Master Repository] Setting up an master repository was decided on the last meeting. -cehteh now set one up which also does some automatic, but intended +_Cehteh_ now set one up which also does some automatic, but intended fragile merging from subsystem maintainer branches. 1. it updates automatically for the maintainers repo for conflict free fast-forwards @@ -146,7 +146,7 @@ fragile merging from subsystem maintainer branches. The others agree on the setup. -Ichthyo stresses that maintainers shall watch that their \'master' +Ichthyo stresses that maintainers shall watch that their `master' branch should compile cleanly and pass the testsuite always, test which are not operational should be tagged as PLANNED. We all agree, while cehteh's master is currently in a broken state (note: @@ -155,9 +155,9 @@ fixed now). Then a short discussion about building and synchronizing the docs follows. Problem is that docs build in maintainer branches are different for each branch, rsyncing them up to the server will always -change a lot of things. We agree that the \'official' docs shall be -build from the LUMIERA/master repository, preferably on the \'devel' -vserver which has to be set up. +change a lot of things. We agree that the ``official'' docs shall be +build from the LUMIERA/master repository, preferably on the "devel" +VServer which has to be set up. Conclusions: Make this final, setup build environment in the devel server and build docs there. @@ -166,28 +166,28 @@ server and build docs there. NoBugFlags ~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/NoBugFlags[] +link:{rfc}/NoBugFlags.html[RfC: NoBug flags] Defining a debugging control hierarchy. This is work in progress and -cehteh explains that he works it out and deploys it, this depends on -the link:GlobalInitialization[] decided earlier. +_Cehteh_ explains that he works it out and deploys it, this depends on +the link:{rfc}/GlobalInitialization.html[GlobalInitialization] decided earlier. -Conclusion: accepted, finish and finalize it. +Conclusion:: accepted, finish and finalize it. Further Technical Discussion ---------------------------- -Ichthyo asks how the GUI will be pulled up. Since he didn't attend IRC +_Ichthyo_ asks how the GUI will be pulled up. Since he didn't attend IRC discussions recently he has no information yet whats going on. We explain him that we already made some discussions. Integrate the GUI into the build system probably linked as library, nothing finally decided yet. Communication will go over the plugin/interface facility (Plain C API). This things should be worked out and documented in -link:DesignProcess[]. +link:/x/DesignProcess.html[RfCs]. -Cehteh made a small tool `./admin/headercheck` which will gradually +_Cehteh_ made a small tool `./admin/headercheck` which will gradually extended to proof that headers are sufficiently selfstanding. @@ -195,42 +195,42 @@ extended to proof that headers are sufficiently selfstanding. Progress -------- -Cehteh finished low level file handling and working in mmaping and +_Cehteh_ finished low level file handling and working on mmapping and frameprovider next. When thats finished, the finalization of the Plugin loader and interface definition things is the most urgent thing. -Ichthyo works on the builder internals and next on some sort of -"connection manager". +_Ichthyo_ works on the builder internals and next on some sort of +``connection manager''. -Joel goes on with GUI programming and integrating it into the source +_Joel_ goes on with GUI programming and integrating it into the source tree next. -Gmerlin and cehteh discuss about how to handle the index files which -avdecoder uses internally. cehteh would like to manage them in the +_Gmerlin_ and _cehteh_ discuss about how to handle the index files which +avdecoder uses internally. _cehteh_ would like to manage them in the Lumiera backend to, because filehandles are a precious resource. -Gmerlin explains that this index files are just loaded and kept in +_Gmerlin_ explains that this index files are just loaded and kept in memory. So this poses no problem for filehandle exhaustion. We will discuss this further via email. -Cehteh suggests that we should think about some kind of +_Cehteh_ suggests that we should think about some kind of preferences/registry sometime next to store default configs. -Following a discussion about how messages are passed between GUI and +A a discussion followed about how messages are passed between GUI and core. Generally we will use the interfaces defined by the plugin -system. Gmerlin says that he uses message queues in \'gmerlin', Joel +system. _Gmerlin_ says that he uses message queues in `gmerlin', _Joel_ requests that a lot of things should be done synchronous and he wants -to avoid message queues. Cehteh suggests to use use the scheduler for +to avoid message queues. _Cehteh_ suggests to use use the scheduler for GUI things too. For the parts where the GUI interacts with the high -level proc model ichthyo and joel agree on working something -(synchronous) out. Ichthyo stresses that the edit core is not +level proc model _ichthyo_ and _joel_ agree on working something +(synchronous) out. _Ichthyo_ stresses that the edit core is not threadsafe by design and relies on the backends scheduler. The underlying builder might sometimes to expensive for synchronous -calls (ichthyo plans a rule system there) this needs to be worked out. +calls (_ichthyo_ plans a rule system there) this needs to be worked out. -Ichthyo explains that the builder needs to detect cycles and check if +_Ichthyo_ explains that the builder needs to detect cycles and check if the high level model is translateable into the low level model (in case plugins git removed and so on). Parts in the render graph which -are not \'doable' should be flagged as erroneous but not dropped since +are not ``doable'' should be flagged as erroneous but not dropped since one doesn't want to loose project information when loading a project on a machine with different installed plugins. In any case it should be possible that the GUI gets immediate synchronous feedback for such diff --git a/doc/devel/meeting_summary/2008-06-06.txt b/doc/devel/meeting_summary/2008-06-06.txt index 20088b68c..d6dda871a 100644 --- a/doc/devel/meeting_summary/2008-06-06.txt +++ b/doc/devel/meeting_summary/2008-06-06.txt @@ -23,41 +23,61 @@ Discuss Ideas and Drafts in design process ------------------------------------------ There are no new design proposals and no proposals that can be finalized. -Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in "idea" state. Following that, most of the meeting is spent on discussing the details of two of these proposals. +Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in `Idea' state. +Following that, most of the meeting is spent on discussing the details of two of these proposals. Idea: Design the Render Nodes interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface[] +link:{rfc}/DesignRenderNodesInterface.html[RfC / Call for a Render Node interface] -*Cehteh* points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. Later on, interface versions will be numbered. If needed, we could add a special "draft" or "experimental" tag, or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface. +_Cehteh_ points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. +Later on, interface versions will be numbered. If needed, we could add a special ``draft'' or ``experimenta'' tag, +or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface. -*Ichthyo* agrees, but adds he also meant "interface" in this proposal in a wider sense, like in "what do we need and require from a processing node". Knowing how generally Lumiera will handle the processing nodes while rendering helps him with defining and implementing the builder +_Ichthyo_ agrees, but adds he also meant ``interface'' in this proposal in a wider sense, +like in ``what do we need and require from a processing node''. +Knowing how generally Lumiera will handle the processing nodes while rendering helps him +with defining and implementing the builder -__Conclusion__: "currently in work". For now, grow interfaces on demand. +Conclusion:: ``currently in work''. For now, grow interfaces on demand. Idea: Placement Metaphor used within the high-level view of Proc-Layer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[] +link:{rfc}/ProcPlacementMetaphor.html[RfC: Placement Metaphor] -In the course of the discussion, *Ichthyo* explains the rationale +In the course of the discussion, _Ichthyo_ explains the rationale * one common mechanism for sticking objects together and putting them into the session - * either specify the "placement"-parameters (time, output destination, track) directly, link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks) + * either specify the ``placement''-parameters (time, output destination, track) directly, + link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks) * ability to build a system of high-level media objects (clips, effects...) which re-adjust automatically on change - * extensible to handle or derive some parameters based on conditions and rules, e.g. for semi-automatic wiring of the output destination based on tags + * extensible to handle or derive some parameters based on conditions and rules, + e.g. for semi-automatic wiring of the output destination based on tags -*Joelholdsworth* is concerned that this proposal may go too far and tries to tie things together which aren't really connected. While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object, he can't see a clear benefit of controlling sound pan or video layer order from the placement. Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment. For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output, layer number or sound pan would be properties of the object. +_Joelholdsworth_ is concerned that this proposal may go too far and tries to tie things together which aren't really connected. +While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object, +he can't see a clear benefit of controlling sound pan or video layer order from the placement. +Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment. +For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output, +layer number or sound pan would be properties of the object. -But that's exactly what Ichthyo wants to avoid. Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases. But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing, working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video. +But that's exactly what _Ichthyo_ wants to avoid. +Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases. +But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing, +working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video. -On the whole, there is no conclusion yet. Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments), maybe parts of the functionality should be separated out. +On the whole, there is no conclusion yet. +Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments), +maybe parts of the functionality should be separated out. While in this discussion, several aspects of the cooperation of GUI and Proc layer are considered. - * it is not necessary to make all of the Placement proposal visible to the GUI (and the user). Proc layer may as well provide a simplyfied and hard wired API for the most common properties (layer index, pan) and only use this part of the Placement concept for building and wiring the nodes. + * it is not necessary to make all of the Placement proposal visible to the GUI (and the user). + Proc layer may as well provide a simplified and hard wired API for the most common properties (layer index, pan) + and only use this part of the Placement concept for building and wiring the nodes. * the adjustment of objects linked together by a placement can be handled as follows: . GUI notifies Proc of a position/parameter change of one object and gets immediate, synchronous feedback (OK or fail) . Proc detects the other linked objects affected by the change and notifies GUI (both synchronous and asynchronous is possible) to update information regarding those objects diff --git a/doc/devel/meeting_summary/2008-07-06.txt b/doc/devel/meeting_summary/2008-07-06.txt index a7255a802..55415dee9 100644 --- a/doc/devel/meeting_summary/2008-07-06.txt +++ b/doc/devel/meeting_summary/2008-07-06.txt @@ -23,7 +23,7 @@ Boilerplate Organization of this meeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * dmj726 intends to write the protocol - * ichtyo is chairman + * _Ichthyo_ is chairman * there is no agenda, so this is a freeform meeting Leftovers from last meeting @@ -37,18 +37,21 @@ Because there are quite some new participants, an introduction of the project Lu There are 3 core devs: - * ichthyo: proc layer, render graph, in the middle, C++, he maintains scons - * cehteh: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git - * joelholdsworth: GUI in C++/Gtkm + * _Ichthyo_: proc layer, render graph, in the middle, C++, he maintains SCons + * _Cehteh_: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git + * _JoelHoldsworth_: GUI in C++/Gtkmm + Other people involved: - * rcbarnes: ui designer and coder - * raffa: web content - * Simav: gives a hand when and where he can - * Teld: web infrastructure -The foundations of the design are already done but a lot of detail needs to be worked out. cehteh and ichtyo provide a non exhaustive list. + * _rcbarnes_: ui designer and coder + * _raffa_: web content + * _Simav_: gives a hand when and where he can + * _Teld_: web infrastructure -cehteh: +The foundations of the design are already done but a lot of detail needs to be worked out. +_Cehteh_ and _Ichtyo_ provide a non exhaustive list. + +_Cehteh_: * improvement of the testsuite (simple Bash) * start of a worker thread manager (Posix knowledge required) @@ -58,35 +61,53 @@ cehteh: * system administration * setup of a build/test environment on the server * setup and maintain postfix/dovecot by a mail administrator -ichtyo: + +_Ichthyo_: * asset management (keeping track of all media files, captures, clips, scenes) * session loading saving and the issues of compound documents * session structure related issues to be able to Import/Export/Connect via e.g. OSC (Open Sound Control) or JACK - * flesh out the more high level "edit operations" and the interface to UNDO - * Prolog integration after the first integration round has been reached. The Prolog interpreter will do some of the more advanced configuration (example: if effect XYZ is used, then deinterlace beforehand). + * flesh out the more high level ``edit operations'' and the interface to UNDO + * Prolog integration after the first integration round has been reached. + The Prolog interpreter will do some of the more advanced configuration + (example: if effect XYZ is used, then deinterlace beforehand). * integration with some sort of production support software (like Celtx) -cehteh emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit as long as he communicates and acknowledges with the persons involved. ichtyo points out that the plugin structure is very important: anything that is not legally completely clean (proprietary), should be factored out into a sister project and be loaded as plugin. + +_Cehteh_ emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit +as long as he communicates and acknowledges with the persons involved. +_Ichthyo_ points out that the plugin structure is very important: anything that is not legally completely clean +(e.g. proprietary technology), should be factored out into a sister project and be loaded as plugin. Issues and questions that come up --------------------------------- - * handling of config errors. -When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. Therefore, the config system will be built to log a warning and the user code does not need to care. The user just gets an alert and the application continues to work. + * handling of config errors. + +When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. +Therefore, the config system will be built to log a warning and the user code does not need to care. +The user just gets an alert and the application continues to work. * scripting language. -There will be a scripting interface. ichtyo does not want scripts everywhere, only at well defined interfaces. That implies also that scripts cannot just do anything, only that what is permitted in a controlled way. The meeting agrees on that. cehteh wants one default language and proposes Lua: light, simple. ++ +-- +There will be a scripting interface. _Ichthyo_ does not want scripts everywhere, only at *well defined interfaces*. +That implies also that scripts _cannot just do anything,_ only that what is permitted in a controlled way. +The meeting agrees on that. _Cehteh_ wants one default language and proposes Lua: light, simple. Other members suggestions: Python, Ruby, Scheme. However, Python and Ruby are very slow. Scheme has many variants. +-- - * editing on small devices (eeePC) -Problem: video editors GUIs are some of the most elaborate and complicated GUIs. However, basic functions consist of only a few buttons. Proxy editing could be a solution. It is decided that it is not a primary goal now. First the basics have to be implemented. + * editing on small devices (eeePC) + +Problem: video editors GUIs are some of the most elaborate and complicated GUIs. +However, basic functions consist of only a few buttons. Proxy editing could be a solution. +It is decided that it is not a primary goal now. First the basics have to be implemented. - * uWiki. + * uWiki. + uWiki is the glue between a markup driver (Asciidoc) and revision control (git). Haserl with Bash is used now. Haserl appears to have problems with conditional includes. Its limits have been reached while prototyping. Lua could very well be a valid replacement. It will be investigated. PHP is rejected because it is not stable and suffers from serious security problems. - * \'musical\' timeline in bars and beats -The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. Discussion is still going on, especially with the GUI developer joelholdsworth. See for detailed information: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[] + * ``musical'' timeline in bars and beats + +The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. +Discussion is still going on, especially with the GUI developer _JoelHoldsworth_. +See for detailed information: link:{rfc}/ProcPlacementMetaphor.html[RfC Placement Metaphor] Next meeting diff --git a/doc/devel/meeting_summary/2008-09-04.txt b/doc/devel/meeting_summary/2008-09-04.txt index 903756d79..697300b84 100644 --- a/doc/devel/meeting_summary/2008-09-04.txt +++ b/doc/devel/meeting_summary/2008-09-04.txt @@ -29,11 +29,11 @@ There are no leftovers Mailing Lists ------------- - * any improvements should be reported to cehteh - * need volunteers to be moderators. The only volunteers are cehteh and joelholdsworh_ + * any improvements should be reported to _cehteh_ + * need volunteers to be moderators. The only volunteers are _cehteh_ and _joelholdsworh_ * moderating the ML might not be that big a job - we might not get that much spam * it's preferable to allow people to post to the mailing list even if they're not subscribed - * cehteh eventually wants the mailing list to interact with uwiki. + * _cehteh_ eventually wants the mailing list to interact with uwiki. Plugin Interfaces ----------------- @@ -41,7 +41,7 @@ Plugin Interfaces * this includes enumerating structured data within the plugins. It might sometimes be desirable to store this in a text file, but in this case still the list will be exported through the interfaces. If this were not the case, it would not be possible to make plugins which are wrappers of LADSPA plugins for example. * For a lumiera plugin there is only one entry point, thats an interface itself which bootstraps all the other interfaces in that plugin. -Lib Dependancy Problems +Lib Dependency Problems ----------------------- * we've agreed to stick to one compatibility level: Debian/Lenny for perhaps up to 3 years from now * others will be supported - RedHat etc. @@ -49,7 +49,7 @@ Lib Dependancy Problems Builds and Buildbot ------------------- * ichthyo asks for help setting up a test/build server - * We now have build scripts based on scons and autotools. + * We now have build scripts based on SCons and Autotools. * All current build systems have different problems. * ichthyo will take care of the Debian packages for Lumiera and NoBug @@ -69,6 +69,6 @@ The next meeting will be held Thursday, 2 oct 21:00 utc. Comment ~~~~~~~ -re "ichthyo asks for help setting up a test/build server" for "Debian" +re ``ichthyo asks for help setting up a test/build server'' for "Debian" see "Build Server" at [purple]## diff --git a/doc/devel/meeting_summary/2008-10-10.txt b/doc/devel/meeting_summary/2008-10-10.txt index 93de6ca38..24aefc24d 100644 --- a/doc/devel/meeting_summary/2008-10-10.txt +++ b/doc/devel/meeting_summary/2008-10-10.txt @@ -11,7 +11,7 @@ __Participants__ * ichthyo * joelholdsworth * alcarinque - * !KenSentMe + * KenSentMe * Plouj * raffa * thorwil @@ -30,7 +30,7 @@ The Lumiera Logo ---------------- Summary of the situation: discussion regarding a logo for Lumiera is going on sporadically since quite some time. Several people from the community have made proposals. Also, there was discussion about the criteria a logo would have to fulfil. Especially the core devs raised the bar and required quite some professional level of design. On the contrary, several members of the community were concerned that such a demanding attitude will hinder creativity in a domain which is far off from coding. Moreover, many people complained they are really excited about Lumiera and strongly want to participate in some manner, but find it very difficult in the current phase of the project to give any valuable contribution. -This summer, one of the proposals by http://farm4.static.flickr.com/3060/2927333034_ac94be80ea_b.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and http://www.pipapo.org/pipawiki/JoelHoldsworth/LogoThoughts[explained] his reservation. Prior to this meeting some people joined a brainstorming session and came up with http://www.pipapo.org/pipawiki/Lumiera/Logos?action=AttachFile&do=get&target=combo.png[another design] compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users. +This summer, one of the proposals by link:{img}/LumieraLogoLeonardoRiberio.2008.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and explained [purple]## his reservation. Prior to this meeting some people joined a brainstorming session and came up with _another design_([purple]#broken-URL `combo.png`#) compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users. Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest: @@ -48,7 +48,7 @@ Conclusion There will be a Lumiera Logo contest. * we should further discuss requirements on the Mailinglist until the end of the next week - * the '''deadline for submissions''' will be the next meeting (Nov 12 2008) + * the *deadline for submissions* will be the next meeting (Nov 12 2008) * then, after a pre-selection phase, the vote shall be conducted prior to the December meeting. Some minimal technical requirements will be enforced: @@ -63,7 +63,7 @@ Some minimal technical requirements will be enforced: Besides, we give some artistic guidelines * it should be recognisable - * it should contain something like a sign, not just "Lumiera" in a fancy font + * it should contain something like a sign, not just ``Lumiera'' in a fancy font * it should not rely on transparencies, gradients and subtle shades, * it should be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented @@ -75,22 +75,22 @@ Raffa volunteers to help organizing the contest and the voting. Recurring Topics: design proposals ---------------------------------- -Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. Mistakes to avoid ~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[Mistakes to avoid in the Lumiera Design] +link:{rfc}/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design] We are carrying this one along since quite some time and we'd like to get rid of it, either by reworking it or by dropping it as-is. Because it contains a mixture of things * we fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic here. We are aware of the recurring problems with open source video editing. That's why we are here. - * the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements. + * the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to underpin these statements. -While it is certainly ''desirable'' to be cross-platform as much as possible and especially '''target Microsoft Windows''', we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform. +While it is certainly _desirable_ to be cross-platform as much as possible and especially *target Microsoft Windows*, we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform. -While it is certainly ''desirable'' to make the application as robust as possible, we don't see how '''using multiple separate processes''' could help us with this goal ''without creating major scalability or performance problems'' due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner. +While it is certainly _desirable_ to make the application as robust as possible, we don't see how *using multiple separate processes* could help us with this goal _without creating major scalability or performance problems_ due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner. -__Conclusion__: drop it +[underline]#Conclusion#: drop it on the question of separate processes @@ -101,8 +101,8 @@ The only practical solution would be to separate the GUI. Separating backend and Tag Clouds ~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TagCloudsOnResources[Tag clouds on resources] -Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DelectusShotEvaluator["Delectus"] +link:{rfc}/TagCloudsOnResources.html[Tag clouds on resources] + +Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: link:/x/Delectus.html[»Delectus«] __Conclusion__: drop it @@ -111,7 +111,7 @@ __Conclusion__: drop it Overview of Lumiera Architecture ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[Architecture Overview] +link:{rfc}/ArchitectureOverview.html[Architecture Overview]: The purpose of this drawing to give an first impression what subsystem is where and what the names mean. Since discussed last time, Ichthyo re-arranged the plugins as requested and added some details for the backend. Joelholdsworth points out that it's OK for him to show the GUI just as a single block here (and of course the GUI has much more internal structure). Cehteh adds that maintaining this drawing surely is a moving target, so we better remove the rendered image and just retain the textual description and link to the source (SVG), which is in GIT. __Conclusion__: accept it, change the image to a link @@ -121,7 +121,7 @@ __Conclusion__: accept it, change the image to a link EDLs as Meta-Clips ~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/EDLsAreMetaClips[EDLs are meta-clips] +link:{rfc}/EDLsAreMetaClips.html[EDLs are meta-clips] + This is just a high-level proposal, which doesn't go into technical details of implementing nested EDLs. It just poses the question "do we want to treat nested EDLs as being meta-clip" -- which we do. __Conclusion__: accepted @@ -131,7 +131,7 @@ __Conclusion__: accepted The Builder ~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcBuilder[Builder in the Proc-Layer] +link:{rfc}/ProcBuilder.html[Builder in the Proc-Layer] + Similar to the previous one, this is a high-level proposal. It covers the fundamental approach Ichthyo takes within the Proc-Layer. Cehteh adds that he agrees to 98% and the remaining 2% are just matter of favour. Personally, he would have preferred one large graph which gets garbage collected (instead of the segmented graph) __Conclusion__: accepted @@ -141,7 +141,7 @@ __Conclusion__: accepted High-level Model ~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcHighLevelModel[Overview of the High-level model within the Proc-Layer] +link:{rfc}/ProcHighLevelModel.html[Overview of the High-level model within the Proc-Layer] + Cehteh queries if this shouldn't be better moved over to the documentation? He is fine with the contents, but it seems to be a bit voluminous for a design proposal. Ichthyo asks to leave it there just for now, as he feels it still needs review. __Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation? @@ -151,8 +151,16 @@ __Conclusion__: leave it for now, maybe retract it from the design proposals and Lua scripting language ~~~~~~~~~~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ScriptingLanguage[use Lua as required scripting language] -All core devs agree with this decision. Joelholdsworth points out that he is fine with Lua, just he didn't want to write the GUI in it. Ichthyo adds that Lua is probably the best choice from today's mainstream scripting languages, because it is very lightweight. He further points out, that having Lua as ''required'' scripting language doesn't rule out using other popular languages (Python, Ruby) for scripting. Just they aren't required for running Lumiera. Cehteh will have a look at the details as soon as possible, but has currently other more urgent things in the queue. (Plouj shows interest to help here) +link:{rfc}/ScriptingLanguage.html[use Lua as required scripting language] + +All core devs agree with this decision. +_Joelholdsworth_ points out that he is fine with Lua, just he didn't want to write the GUI in it. +_Ichthyo_ adds that Lua is probably the best choice from today's mainstream scripting languages, +because it is very lightweight. He further points out, that having Lua as _required_ scripting language +does not rule out using other popular languages (Python, Ruby) for scripting. +Just they aren't required for running Lumiera. +_Cehteh_ will have a look at the details as soon as possible, +but has currently other more urgent things in the queue. +(_Plouj_ shows interest to help here) __Conclusion__: accepted @@ -161,8 +169,8 @@ __Conclusion__: accepted Time Handling ~~~~~~~~~~~~~ -http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[time handling] -A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done ''on demand.'' Joelholdsworth sais sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time. +link:{rfc}/TimeHandling.html[time handling] + +A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done _on demand._ Joelholdsworth says sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time. __Conclusion__: accepted @@ -171,7 +179,7 @@ Note: the proposed rigid testsuite for time handling is necessary only when we i Interface naming convention ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -See the design proposal http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/InterfaceNamespaces[Interface Namespaces]. While working on the plugin loader, '''Cehteh''' and '''nasa''' did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry. +See the design proposal link:{rfc}/InterfaceNamespaces.html[Interface Namespaces]. While working on the plugin loader, _Cehteh_ and _nasa_ did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry. __Conclusion__: accepted @@ -180,13 +188,23 @@ general Topics Config System ------------- -'''cehteh''' landed the first version of this subsystem and asked for review and testing. Currently it's "work with no progress", but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type). +_Cehteh_ landed the first version of this subsystem and asked for review and testing. Currently it's ``work with no progress'', but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type). Use of Namespaces ----------------- -Currently there is no clear uniform rule regarding namespaces use. *Joelholdsworth* places his code within lumiera::gui and below. He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies and all of Lumiera should comply and put anything below a lumiera:: root. On the contrary, *Ichthyo* deliberately moved his implementation code away from the central lumiera:: interface hierarchy into shallow namespaces and avoids nesting. He argues that having all code below lumiera:: effectively makes this namespace global or forces it to be void of any function; rather he'd prefer to import every interface explicitly into the implementation namespace. *Cehteh* argues that having a global lumiera::, even if empty, would mark a general claim and stand for the uniformity of the project. Generally, there should be some correspondence between folders and namespaces. +Currently there is no clear uniform rule regarding namespaces use. +_JoelHoldsworth_ places his code within lumiera::gui and below. +He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies +and all of Lumiera should comply and put anything below a lumiera:: root. +On the contrary, _Ichthyo_ deliberately moved his implementation code away from the central `lumiera::` +interface hierarchy into shallow namespaces and avoids nesting. +He argues that having all code below `lumiera::` effectively makes this namespace global or forces it to be void of any function; +rather he'd prefer to import every interface explicitly into the implementation namespace. +_Cehteh_ argues that having a global `lumiera::`, even if empty, +would mark a general claimand stand for the uniformity of the project. +Generally, there should be some correspondence between folders and namespaces. No conclusion yet, to be discussed further. @@ -194,9 +212,13 @@ No conclusion yet, to be discussed further. Interface Definition Language ----------------------------- -In his work on the plugin loader, '''Cehteh''' created a first draft how to export an interface, and calls for review. An example can be found in http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=tests/backend/test-interfaces.c;h=fb1c4d30a34414767a313d24df60e679c96ad2a7;hb=7323114e77348995ccaf03417136aef7ee332776[tests/backend/test-interfaces.c] +In his work on the plugin loader, _Cehteh_ created a first draft how to export an interface, and calls for review. +An example can be found in +https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/backend/test-interfaces.c;h=09fa25afa3cb57b79a2717d0bf3a8253afeba000;hb=ebcc5c7fd2d8700f3375e3309b724ac2517a0f40[tests/backend/test-interfaces.c] -An interface is a list of "slots" mapping functions. The interface descriptor is itself realised as interface, an thus can be versioned, extended and specialised. By use of some glue code and macros we create a simple Interface Definition Language +An interface is a list of »slots« mapping functions. The interface descriptor is itself realised as interface, +and thus can be versioned, extended and specialised. +By use of some glue code and macros we create a simple Interface Definition Language * after exporting a header with the C interface, including the types to be used... * LUMIERA_INTERFACE_DECLARE creates an interface description (i.e. the official interface) @@ -204,22 +226,33 @@ An interface is a list of "slots" mapping functions. The interface descriptor is * LUMIERA_INTERFACE_INSTANCE creates an instance on-the-fly (e.g. for descriptors) * LUMIERA_EXPORT for defining a table of functions/interfaces to export from the core * LUMIERA_PLUGIN for defining an interface table for functions located within a dynlib module (plugin) - * besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps onto an existing function directly + * besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps + onto an existing function directly -The plugin loading system cares for mapping the given implementation function to the interface slots. Interfaces from the core need to be registered before they can be used, while for plugins this is done automatically on loading the module. The client code later just calls {{{interface_open()}}} and {{{interface_close()}}} where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, registry and/or plugin-DB shall manage it transparently. +The plugin loading system cares for mapping the given implementation function to the interface slots. +Interfaces from the core need to be registered before they can be used, +while for plugins this is done automatically on loading the module. +The client code later just calls `interface_open()` and `interface_close()` +where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, +registry and/or plugin-DB shall manage it transparently. -Version numbering starts with 1 and uses minor version numbers for compatible changes and major version numbers for everything that breaks existing asumptions. Version number zero is reserved for experimental work and per definition always the most recent version number. +Version numbering starts with 1 and uses minor version numbers for compatible changes +and major version numbers for everything that breaks existing assumptions. +Version number zero is reserved for experimental work and per definition always the most recent version number. The system is designed to be very flexible and extensible, but this foundation really needs thorough review. -Joelholdworth expresses some concern regarding the UIDs in octal notation used within the interface description. Cehteh explains they never need to be specified by client code. They are just distinctive IDs and provided for some special case within the plugin loader / serializer. He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code. +_Joelholdworth_ expresses some concern regarding the UUIDs in octal notation used within the interface description. +_Cehteh_ explains they never need to be specified by client code. +They are just distinctive IDs and provided for some special case within the plugin loader / serializer. +He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. +The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code. Conclusion ~~~~~~~~~~ -looks good, agreement by all core devs. - + +Looks good, agreement by all core devs. + Should be reviewed and investigated in detail to find any hidden problems. @@ -227,6 +260,7 @@ Should be reviewed and investigated in detail to find any hidden problems. Next meeting ------------ -There were some problems with the meeting schedule. Using the first week of month seems to be problematic. We'll try with second wednesday... +There were some problems with the meeting schedule. Using the first week of month seems to be problematic. +We'll try with second Wednesday... -The next meeting is scheduled for '''Wednesday Nov 12 2008 19:30 UTC''' at #lumiera +The next meeting is scheduled for **Wednesday Nov 12 2008 19:30 UTC** at #lumiera diff --git a/doc/devel/meeting_summary/2008-11-12.txt b/doc/devel/meeting_summary/2008-11-12.txt index f48d4e6e0..7b5cc42bc 100644 --- a/doc/devel/meeting_summary/2008-11-12.txt +++ b/doc/devel/meeting_summary/2008-11-12.txt @@ -48,7 +48,7 @@ eg. fader, panner, blur. _joelholdsworth_ points out that configurability can't replace real GUI and workflow design. He quotes from a recent Blender GUI discussion -[quote, the Belnder UI reviews] +[quote, the Blender UI reviews] ____________________________________________________________________ Lastly, I’d like to address another misconception, this time about customizability. There has been a notion that the solution to most of the UI problems can be solved with added customizability. @@ -71,7 +71,7 @@ from the defaults to match another 3D application such as Maya or Softimage XSI for users of those applications to adapt to Blender. ____________________________________________________________________ -Consequently, Joel wants to try just doing the UI _right_, then add a little bit of customization back in here and there. +Consequently, _Joel_ wants to try just doing the UI _right_, then add a little bit of customization back in here and there. Additionally, agreement is to have a kind-of ``perspective switcher'' (like in Eclipse), so saving different panel layouts would be covered easily diff --git a/doc/devel/meeting_summary/2008-12-10.txt b/doc/devel/meeting_summary/2008-12-10.txt index 8e65b80fc..5f3290822 100644 --- a/doc/devel/meeting_summary/2008-12-10.txt +++ b/doc/devel/meeting_summary/2008-12-10.txt @@ -33,7 +33,7 @@ Discussion of open link:/x/DesignProcess.html[design process] drafts. EDL vs Sequence ~~~~~~~~~~~~~~~ -There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in [wiki:self:../DesignProcess/TimelineSequenceOutput Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows. +There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in link:{rfc}/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows. __Conclusion__: the name Sequence will be used instead of EDL @@ -45,7 +45,7 @@ Ichtyo explains that the idea is that between layers only the C Language interfa Threads ~~~~~~~ -The UI will mostly run on a single thread, i.e. gtk_main will run in this GUI thread and when it terminates, the GUI is "done" and signals back that it is done. Cehteh points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation +The UI will mostly run on a single thread, i.e. »gtk_main« will run in this GUI thread and when it terminates, the GUI __is ``done''__ and signals back that it is done. _Cehteh_ points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation. @@ -55,12 +55,12 @@ General Topics Video format ~~~~~~~~~~~~ -Kirk asks to what video format footage has to be converted so that it can be used in Lumiera. Ichtyo and cehteh point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way. +_Kirk_ asks to what video format footage has to be converted so that it can be used in Lumiera. _Ichtyo_ and _Cehteh_ point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way. Knowledge base ~~~~~~~~~~~~~~ -Kirk has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. Kirk proposes to help in this area. +_Kirk_ has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. _Kirk_ proposes to help in this area. diff --git a/doc/devel/meeting_summary/2009-01-14.txt b/doc/devel/meeting_summary/2009-01-14.txt index 2a6f0b4ba..4531e2702 100644 --- a/doc/devel/meeting_summary/2009-01-14.txt +++ b/doc/devel/meeting_summary/2009-01-14.txt @@ -36,54 +36,72 @@ Conclusion ~~~~~~~~~~ Two groups are created, each of these have someone responsible to bring them forward. -The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This 'supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it. +The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This `supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it. Work discussion will proceed on the Mailing List but following the directions stated during the IRC meetings. + -Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. [[BR]] Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization. +Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. + +Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization. Group 1 [WORKFLOW] ^^^^^^^^^^^^^^^^^^ - . director/supervisor: nikola_ (Nikola Duper) -Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout. + -The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs.[[BR]] The core dev responsible for the GUI is joelholdsworth (Joel Holdsworth).[[BR]] One of the group goals is to make the dev point of view dialogate with the editor point of view. + . director/supervisor: _nikola_ (Nikola Duper) +Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout. -The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs. + -It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. [[BR]] It thinks about ergonomics. +- The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs. + +- The core dev responsible for the GUI is _joelholdsworth_ (Joel Holdsworth). + +- One of the group goals is to create a dialogue between the developer's point of view and the editor's point of view. + +The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs. + +It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. + +It considers aspects of ergonomics. Group 2 [ARTWORK] ^^^^^^^^^^^^^^^^^ - . director/supervisor: raffa (Raffaella Traniello) + . director/supervisor: _raffa_ (Raffaella Traniello) The group discuss about logo, themes, the look and feel... Getting the 'non-coders' community to help ------------------------------------------ -goibhniu proposes an issue tracker. +_goibhniu_ proposes an issue tracker. -The documentation needs love: it's currently horribly scattered all around. + -All the content needs to be converted to asciidoc and to the git repo at lumiera.org.[[BR]] Waiting for uWiki, the site will be in asciidoc+git [[BR]] The site needs a structure or other means to increase discoverability of all our information[[BR]] goibhniu proposes organizing a "sprint" to help get people involved and set a date for it (documentation migration/organisation) +* The documentation needs love: it's currently horribly scattered all around. +* All the content needs to be converted to asciidoc and to the git repo at lumiera.org. +* Waiting for uWiki, the site will be in asciidoc+git +* The site needs a structure or other means to increase discoverability of all our information +* _goibhniu_ proposes organizing a ``sprint'' to help get people involved and set a date for it (documentation migration/organisation) Conclusion ~~~~~~~~~~ - * goibhniu volunteers to set up Trac. - * raevol volunteers to maintain it. - * The link:AsciiDoc[] Day idea will be discussed at the next meeting. + * _goibhniu_ volunteers to set up *Trac*. + * _raevol_ volunteers to maintain it. + * The »*AsciiDoc Day*« idea will be discussed at the next meeting. Possible GUI-Integration: Display a frame? ------------------------------------------ There was some discussion about the need for a component which does the timing and communicates with the scheduler and where it should sit in the stack. -For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality. The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend. It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning. It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server. It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks. For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later. +For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality. +The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend. +It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning. +It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server. +It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks. +For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later. The devs agreed to meet up on Saturday to get the latest version up and running. -http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=src/common/guifacade.cpp;h=7f781845ad79b4a3e2cd820b96b87f5e702a80d3;hb=8e89506d289f3986af133493a40e3705b7919c87#l64[] +NOTE: Demonstration in https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/common/guifacade.cpp;h=60a16d0f67bd95b43e44662daa9c0525235e14f5;hb=5f10e65852de2c51364c2e2a5a1cf29cae81c6b2#l64[guifacade.cpp] + (The thread shall be forked from within the GUI code not from the facade) This was discussed and ichthyo has already pushed a new cleaned up state and resolved most of the dependency problems with the liblumiera. It raised the question: do we prefer a UI facade to a GUI facade or do we want an extra script facade someday? -It was discussed whether joelholdsworth should wait for cehteh to make a playback interface or use a dummy one for now. Cehteh wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Icythyo has been using the link:GuiNotification[] as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which cehteh and joelholdsworth planned to flesh out in the near future. +It was discussed whether _joelholdsworth_ should wait for _cehteh_ to make a playback interface or use a dummy one for now. +_Cehteh_ wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Ichythyo has been using the `GuiNotification` as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which _cehteh_ and _joelholdsworth_ planned to flesh out in the near future. # Errors, Assertions, Checks, Dev- and Release-Builds @@ -97,7 +115,7 @@ in new nobug you can do: alpha code here ) it's the same for BETA RELEASE and there's a NOT variant for each but even then that should be avoided and higher level nobug facilities should be used instead. -(http://www.lumiera.org/nobug.html)[] +(https://nobug.pipapo.org/[NoBug]) beta and release builds shall be possible with nobug soon .. waiting for metta to integrate the new test.sh test.sh with regex is awesome because you can test output which contains no exact things like addresses, version numbers, times @@ -106,7 +124,7 @@ and running the testsuite under valgrind works properly now Workflow/Interface ~~~~~~~~~~~~~~~~~~ -Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say "don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup". This is where the tree of tracks plays an important role because each track with its children forms a group. +Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say ``don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup''. This is where the tree of tracks plays an important role because each track with its children forms a group. There was further discussion on the general aims, objectives and focus of Lumiera and the reasoning behind them. Integration with control surfaces, jog wheels, sliders etc. should also be considered for the workflow. Nikola expressed the importance of stability and a simple and clean UI. diff --git a/doc/devel/meeting_summary/2009-09-09.txt b/doc/devel/meeting_summary/2009-09-09.txt index c4a95db77..445a7160d 100644 --- a/doc/devel/meeting_summary/2009-09-09.txt +++ b/doc/devel/meeting_summary/2009-09-09.txt @@ -29,7 +29,7 @@ This success wouldn't be possible without a lot of people helping. + So lets say: *Thank you all*! We plan to be there again next year with another Lumiera meeting (possibly -all the 3 core devs present). _Ichthyo_ consideres to do a dedicate talk +all the 3 core devs present). _Ichthyo_ considers to do a dedicate talk (in German). Participation as a group to other possible events has been considered for + @@ -60,7 +60,7 @@ If later on there will be funding for development (not just covering expenses) that would require a different approach and special communication with the community. -_daniieel_ proposes to put a price to each request in "buglist". + +_daniieel_ proposes to put a price to each request in ``buglist''. + The proposal is discussed and dismissed. @@ -71,7 +71,7 @@ The news in the homepage makes the project look alive. But this is not enough to communicate the state of the Lumiera development. Two solutions are proposed: -* The website needs to be reorganized and made accessible. andrewjames +* The website needs to be reorganized and made accessible. _andrewjames_ volunteers to work on it. * Quarterly development news will be published in the devel section of the website. The devs will post drafts to the mailing list and encourage the diff --git a/doc/devel/meeting_summary/2011-03-09.txt b/doc/devel/meeting_summary/2011-03-09.txt index 3e30b4da6..6726d9099 100644 --- a/doc/devel/meeting_summary/2011-03-09.txt +++ b/doc/devel/meeting_summary/2011-03-09.txt @@ -25,6 +25,8 @@ The new website is finally online. How do we proceed with the graphical layout? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[caption="☉Transcript☉ "] +---------------------------- 21:37 the template code is not ready yet 21:37 and there are some incorrect uses of tags in the current one 21:37 so i will go on coding a static html layout @@ -32,6 +34,7 @@ How do we proceed with the graphical layout? ... 21:50 fsiddi: I liked the way you provided a slightly larger content area for the tutorial part +---------------------------- image:{img}/meetings/2011-03-09-mockup_dev_1.jpg["Website Proposal Mockup number 3", width=128, link="{img}/meetings/2011-03-09-mockup_dev_1.jpg"] @@ -69,6 +72,9 @@ until the sun burns out. engines will not respect it. Private logs or other logs not publically available are fine though. +.-- Discussion about relevance of IRC logs -- +[caption="☉Transcript☉ "] +---------------------------- 22:40 well ... IRC should *not* be for persistent documentation .. we shall force/educate ourself to document things (and decisions) properly, irc should be volatile @@ -96,6 +102,7 @@ are fine though. 22:50 This means I personally always prefer shorter summaries of a discussion to IRC logs, given that they do not leave anything important out. +---------------------------- VoIP discussions over Mumble? ----------------------------- @@ -116,8 +123,11 @@ highly insecure. Version numbering ----------------- -Hermann has written an rfc for version numbers. +_Ichthyo_ has written an link:{rfc}/VersionNumberScheme.html[RfC for version numbers]. +.-- Discussion about a version number scheme for Lumiera -- +[caption="☉Transcript☉ "] +---------------------------- 23:19 so in my words: we will have a usuall major.minor.patch for releases 23:20 and major+1~develtag for devel snapshots 23:20 where develtag is a timestamp @@ -201,6 +211,8 @@ Hermann has written an rfc for version numbers. could be automatized) 23:26 remember in test.sh i reserved the 90-99* area for 'bugs' 23:26 we may put some blocking tests there which prevent staging +---------------------------- + Next meeting ------------ diff --git a/doc/devel/meeting_summary/2011-04-13.txt b/doc/devel/meeting_summary/2011-04-13.txt index af8d619b6..8d388c9c3 100644 --- a/doc/devel/meeting_summary/2011-04-13.txt +++ b/doc/devel/meeting_summary/2011-04-13.txt @@ -16,9 +16,12 @@ _Protocol written by Ichthyo_ .organisational -- IRC meeting summaries will be moved into the main Git tree, below 'doc/devel' -- mostly shortened and tidied IRC logs, plus summary of conclusions \+ decisions -- ``winter quarterly coding news'': this time just paste _Ichthyo's_ contribution into the website +- IRC meeting summaries will be moved into the main Git tree, + + below 'doc/devel' +- mostly shortened and tidied IRC logs, + + plus summary of conclusions + decisions +- ``winter quarterly coding news'': + + this time just paste _Ichthyo's_ contribution into the website - the next ``coding news'' probably in May? @@ -344,17 +347,18 @@ _Cehteh_ points out that this new policy should at least be anounced on the Mail Recurring Topic: Design process entries --------------------------------------- -Discussion of open link:/documentation/devel/rfc.html[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. Since some time, no further discussion happened regarding the currently _pending_ RfC entries. Agreement is that we should again return to the former routine and revisit the relevant design process entries in each developer meeting. +-> link:{rfc}/ApplicationInstall.html[RfC: Application Install] .-- the Application Install proposal -- [caption="☉Transcript☉ "] ---------------------------- -[2011-04-14 00:48:25] link:{ldoc}/devel/rfc_pending/ApplicationInstall.html +[2011-04-14 00:48:25] the pending ApplicationInstall RfC [2011-04-14 00:48:40] maybe only pick out some interestin ones or some which are quick to decide [2011-04-14 00:49:06] well i want to go over all pending .. then we can put notes there "boring for the next meeting" [2011-04-14 00:49:42] for example this application install .. is boring .. you did a lot work, imo you can finalize it @@ -372,7 +376,9 @@ revisit the relevant design process entries in each developer meeting. Delectus Shot Evaluator ~~~~~~~~~~~~~~~~~~~~~~~ -Agreement to _park_ it until someone else comes up to advance this topic further. +Agreement to _park_ +link:{rfc}/DelectusShotEvaluator.html[the »Delectus« RfC], + +until someone else comes up to advance this topic further. Clip Cataloging System ~~~~~~~~~~~~~~~~~~~~~~ @@ -386,6 +392,7 @@ Keep _pending_ -- _ichthyo_ will expand on that Lumiera Forward Iterator ~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/LumieraForwardIterator.html[RfC] [caption="☉Transcript☉ "] ---------------------------- @@ -405,6 +412,7 @@ Lumiera Forward Iterator Design the Render Nodes interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/DesignRenderNodesInterface.html[RfC] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -421,7 +429,8 @@ Design the Render Nodes interface Developer Documentation Structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---> see link:https://issues.lumiera.org/ticket/763[Ticket #763] +- -> link:{rfc}/DeveloperDocumentationStructure.html[RfC] +- -> see link:https://issues.lumiera.org/ticket/763[Ticket #763] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -440,6 +449,7 @@ Developer Documentation Structure Engine Interface Overview ~~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/EngineInterfaceOverview.html[RfC] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -464,12 +474,14 @@ Engine Interface Overview Feature Bundle ~~~~~~~~~~~~~~ -Expected to be very important in the far future, but we don't have the +This link:{rfc}/FeatureBundle_PluggableModules.html[RfC: Reature Bundle] +is expected to be very important in the far future, but we don't have the resources to work on that right now, so _park_ it. Marble Mode ~~~~~~~~~~~ +-> link:{rfc}/MarbleMode.html[RfC: Marble Mode] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -492,7 +504,8 @@ Marble Mode Normalized Device Coordinates ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -still very rough, but basically agreed. + +The proposal for link:{rfc}/NormalizedDeviceCoordinates.html[Normalized Device Coordinates] +is still very rough, but basically agreed upon. While it needs more work, it's a bit out of focus right now, so _park it. @@ -509,6 +522,8 @@ link:{rfc}/ProcPlacementMetaphor.html[Placement] proposal Render Optimizer, Resource Management and Profiling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +- -> link:{rfc}/ResourceManagementProfiling.html[RfC: Profiling] +- -> link:{rfc}/ResourceManagementBudgeting.html[RfC: Budgeting] .-- Discussion of details -- [caption="☉Transcript☉ "] @@ -545,12 +560,13 @@ Render Optimizer, Resource Management and Profiling Roadmap ~~~~~~~ -The link:{rfc}/rfc/Roadmap-first.html[Roadmap document] +The link:{rfc}/Roadmap-first.html[Roadmap document] was erroneously not marked as final; + Seemingly it was decided upon in 2009 already ... Stream Type System ~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/StreamTypeSystem.html[RfC] [caption="☉Transcript☉ "] ---------------------------- @@ -577,6 +593,8 @@ Stream Type System Threads Signals and important management tasks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-> link:{rfc}/ThreadsSignalsAndImportantManagementTasks.html[RfC] + .-- Discussion of details -- [caption="☉Transcript☉ "] ---------------------------- @@ -620,7 +638,8 @@ in multiple timelines. We pretty much agree on that, thus it counts as _finalise Use Cases ~~~~~~~~~ -This is an heavyweight proposal regarding the high-level design and general handling of the +-> link:{rfc}/UseCases.html[This RfC] +is a heavyweight proposal regarding the high-level design and general handling of the Application. This would be really a topic to be discussed in conjection with the ``Workflow'' -- the idea was to have a working group focussed these topics entirely, but there is no one in charge of that right now. Thus _park_ it for the time being. diff --git a/doc/devel/meeting_summary/2012-09-12.txt b/doc/devel/meeting_summary/2012-09-12.txt index 3b52a5331..e266936f3 100644 --- a/doc/devel/meeting_summary/2012-09-12.txt +++ b/doc/devel/meeting_summary/2012-09-12.txt @@ -86,7 +86,6 @@ Workflow between the Master and the Documentation repository There was some confusion how the master and the documentation repository relate to each other. - We agreed on merging back and forth between in a bidirectional way, but doing this lazy on demand. @@ -104,8 +103,7 @@ information and documentation will appear at https://web.archive.org/web/20221205192908/https://builddrone.pipapo.org/[builddrone.pipapo.org] soon. Stay tuned. -Thanks to Lenny for helping with the documentation and Simon for the -Logo. +Thanks to Lenny for helping with the documentation and Simon for the Logo. diff --git a/doc/devel/meeting_summary/2023-09-13.txt b/doc/devel/meeting_summary/2023-09-13.txt index e8bdf4178..412ef9e13 100644 --- a/doc/devel/meeting_summary/2023-09-13.txt +++ b/doc/devel/meeting_summary/2023-09-13.txt @@ -92,7 +92,7 @@ integrated into the website infrastructure. Library solutions for Video Display ----------------------------------- _Benny_ conducted some research regarding library solutions for *video display*, notably -ffmpeg, GStreamer and libVLC. It was rather easy to code up an "hello world" example based on +ffmpeg, GStreamer and libVLC. It was rather easy to code up an ``hello world'' example based on GStreamer, while it was difficult to find suitable documentation regarding the ffmpeg based solution. Moreover, GStreamer seems to have a much more active and helpful community. @@ -116,7 +116,7 @@ support framework. Next meeting ------------ -The next meeting will be Wednesday Oct 11, 20:00 UTC. +The next meeting will be Wednesday **Oct 11, 20:00 UTC**. You are welcome to join. '''' diff --git a/doc/devel/meeting_summary/2023-10-11.txt b/doc/devel/meeting_summary/2023-10-11.txt index 45e75a2be..c48b6c95d 100644 --- a/doc/devel/meeting_summary/2023-10-11.txt +++ b/doc/devel/meeting_summary/2023-10-11.txt @@ -65,7 +65,7 @@ but a replacement solution was identified, which still needs to be integrated. Next meeting ------------ -The next meeting will be Wednesday Nov 8, 20:00 UTC. +The next meeting will be Wednesday **Nov 8, 20:00 UTC**. You are welcome to join. '''' diff --git a/doc/devel/meeting_summary/2023-11-08.txt b/doc/devel/meeting_summary/2023-11-08.txt index 920ec6fed..5c6dfed28 100644 --- a/doc/devel/meeting_summary/2023-11-08.txt +++ b/doc/devel/meeting_summary/2023-11-08.txt @@ -93,7 +93,7 @@ able to demonstrate running video display in the GUI. Next meeting ------------ -The next meeting will be Wednesday Dec 13, 20:00 UTC. +The next meeting will be Wednesday **Dec 13, 20:00 UTC**. You are welcome to join. '''' diff --git a/doc/devel/meeting_summary/2024-01-10.txt b/doc/devel/meeting_summary/2024-01-10.txt index e6c6ed32e..aa8626eea 100644 --- a/doc/devel/meeting_summary/2024-01-10.txt +++ b/doc/devel/meeting_summary/2024-01-10.txt @@ -78,7 +78,7 @@ process and resource management within the Lumiera render engine itself. Next meeting ------------ -The next Lumiera meeting is scheduled for Wednesday, Feb 14 at 20:00 UTC. +The next Lumiera meeting is scheduled for Wednesday, **Feb 14 at 20:00 UTC**. Should this be inconvenient for you, please speak up on, for example, link:http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera[lumiera@lists.lumiera.org] and let us know of when you would prefer to attend. diff --git a/doc/devel/meeting_summary/index.txt b/doc/devel/meeting_summary/index.txt index 0649bf9f6..e237f1526 100644 --- a/doc/devel/meeting_summary/index.txt +++ b/doc/devel/meeting_summary/index.txt @@ -326,7 +326,7 @@ Topics ~~~~~~ * organisational (protocol, agenda, leftovers?) * Logo Contest progress, discussion about how to do the pre selection - * rename "EDL" into "Sequence" + * rename »EDL« into »Sequence« * link:/documentation/devel/rfc/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] * GUI/Proc Interface and collaboration * Threading questions regarding gtk-main and main() @@ -500,7 +500,7 @@ Topics ~~~~~~ * boilerplate (protocol, whats left from last meeting, next meeting) * Go through Ideas and Drafts in design process - * "Call for design" for some features relevant for the whole Application: + * ``Call for design'' for some features relevant for the whole Application: - parameters and automation - render node interface - handling of compound sessions diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 00558497e..33683523b 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -1,12 +1,12 @@ Design Process : All Plugin Interfaces Are C ============================================ -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2007-06-29_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-06-29_ +|*Proposed by* | ct +|==================================== @@ -39,7 +39,7 @@ Implementation Proposal * first member is a _size_ which will be initialized by the actual implementation * followed by function pointers defining the interface, see: - link:{ldoc}/devel/rfc/CCodingStyleGuide.html[C-coding style guide] + link:{rfc}/CCodingStyleGuide.html[C-coding style guide] * everything added is considered immutable for this interface version * new functions are added to the end (thus changing size) @@ -162,7 +162,7 @@ outweigh the drawbacks. ct:: '2007-07-03 05:51:06' -C is the only viable choice here. Perhaps some sort of "test bench" could be +C is the only viable choice here. Perhaps some sort of ``test bench'' could be designed to rigorously test plugins for any problems which may cause Lumiera to become unstable (memory leaks etc). @@ -185,7 +185,7 @@ Ichthyostega:: '2023-10-24 22:55:23' Conclusion ---------- Initially there was agreement over the general direction set out by this proposal. -However, _Ichthyo_ was always sceptical regarding the benefits of a generic plug-in +However, _Ichthyo_ was always skeptical regarding the benefits of a generic plug-in Architecture. Experience with high-profile projects based on such a concept seem to show both tremendous possibilities, especially regarding user involvement, but at the same time also indicate serious problems with long-term sustainability. @@ -205,4 +205,4 @@ https://issues.lumiera.org/report/17[»Focus Topics«] for further development. ......... '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ApplicationInstall.txt b/doc/devel/rfc/ApplicationInstall.txt index 9fcbd62f5..60fa8990d 100644 --- a/doc/devel/rfc/ApplicationInstall.txt +++ b/doc/devel/rfc/ApplicationInstall.txt @@ -3,12 +3,12 @@ ApplicationInstall // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Di 11 Jan 2011 17:00:55 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _Di 11 Jan 2011 17:00:55 CET_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ********************************************************************************* @@ -121,7 +121,7 @@ Tasks * build the executables in a way to allow relative resolution of the internal shared modules ([green]#✔ done#) * replace the compiled-in path definitions for plugin loading by a - configurable bootstrap ([green]#✔#) + configurable bootstrap ([green]#✔ done#) * add an working library implementation for a config loader ([green]#✔ done#) * add a mechanism for establishing the path of the current execubable. + This is _non-portable_ ([green]#✔ done#) @@ -130,7 +130,7 @@ Tasks * try to extract the path search code from the existing config loader, or build a new solution based on standard libraries ([green]#✔ done#) * introduce an output root directory into the buildsystem, allowing - for package builds ([green]#✔#) + for package builds ([green]#✔ done#) * define a _Debian packaging_ as proof-of-concept ([green]#✔ done#) @@ -199,7 +199,7 @@ as they are known to lead to maintenance problems. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -219,7 +219,7 @@ which reminded me of several small issues, which seem to become unhealthy when l around unfixed for such a long time. Probably I'll start a clean-up initiative and try to bring these points to discussion separately. - So 13 Feb 2011 20:04:00 CET Ichthyostega +Ichthyostega:: 'So 13 Feb 2011 20:04:00 CET' //endof_comments: diff --git a/doc/devel/rfc/ApplicationStructure.txt b/doc/devel/rfc/ApplicationStructure.txt index f01128eb5..f8a01bfdf 100644 --- a/doc/devel/rfc/ApplicationStructure.txt +++ b/doc/devel/rfc/ApplicationStructure.txt @@ -1,12 +1,13 @@ Design Process : Application Structure ====================================== -[grid="all"]] -`------------`---------------------- -*State* _Dropped_ -*Date* _2008-11-05_ -*Proposed by* link:ct[] ------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-11-05_ +|*Proposed by* | ct +|==================================== + Application Structure --------------------- @@ -20,8 +21,8 @@ So far we came up with a simplified BACKEND/PROC/GUI structure where each of this entities defines its own sub subcomponents. We agreed to glue that all together with some portable versioned interfaces system, but details where not laid out yet. At the time of this writing the interface system and plugin -loader are reasonable finished to be usable (some small refinements to do). We -recently discussed some details on IRC on how to engage this without a +loader are reasonable finished to be usable (some small refinements to do). +We recently discussed some details on IRC on how to engage this without a definitive decision. The topic of this proposal is to make a detailed description towards how the application components being glued together. @@ -31,12 +32,12 @@ this parts are actually be, except that the GUI should be optional for headless operation. I suggested to make as much as possible pluginable to make it easier to validate our interfaces and try different things out. -Now I introduce 'lumiera' here, this will become a new component in -./src/lumiera being the driver application for bootstraping all the rest: +Now I introduce `"lumiera"` here, this will become a new component in +`./src/lumiera` being the driver application for bootstraping all the rest: Then our application structure looks somewhat like (please refine): - * the 'lumiera' loader + * the Lumiera loader - commandline handling - interface & plugin system - session manager core @@ -60,24 +61,24 @@ Then our application structure looks somewhat like (please refine): - preferences - ... -Furthermore the interface&plugin system is flexible enough to provide things +Furthermore the interface and plugin system is flexible enough to provide things independently of their origin (if it is build in or a plugin/dynamic library). So deployment (where to link these things) is secondary. -'lumiera' will then be the executable the user starts up, what exactly gets - initialized and booted up is then matter -of configuration and commmandline options (and maybe lua scripting?). +`"lumiera"` will then be the executable the user starts up, +what exactly gets initialized and booted up is then matter +of configuration and commandline options (and maybe Lua scripting?). Tasks ^^^^^ - * create the 'lumiera' directory + * create the `lumiera` directory - setup the build system - move config, plugin and interfaces therein - - lua support can be done later - * write the main() part of the application + - Lua support can be done later + * write the `main()` part of the application - start config system - parse commandline opts * librificate all other components (backend, proc gui) @@ -92,17 +93,17 @@ Pros ^^^^ * flexible plugin based architecture - - later: loads only things which are necessary for a given task + ** later: loads only things which are necessary for a given task * very fast startup - * things which cant be used on a given environment can be left out (no gui on - a headless system, no $DISPLAY set) + * things which can't be used on a given environment can be left out (no gui on + a headless system, no `$DISPLAY` set) * inter dependencies between interfaces and plugins are automatically tracked. Cons ^^^^ -Ichthyo raised concerns that this kind of flexibility might attract other +_Ichthyo_ raised concerns that this kind of flexibility might attract other people to write things which are not in our intention and break future design and compatibility. We need to carefully document and define interfaces that people don't abuse those! @@ -112,7 +113,7 @@ people don't abuse those! Alternatives ^^^^^^^^^^^^ -We discussed the startup/main() through the GUI as it is currently done, it +We discussed the startup / `main()` through the GUI as it is currently done, it would be also possible to produce some more executables (lumigui, luminode, lumiserver, ....). But I think we agreed that a common loader is the best way to go. @@ -122,7 +123,7 @@ Rationale ~~~~~~~~~ I just think this is the best way to ensure a enduring design even for future -changes we can not forsee yet. +changes we can not foresee yet. @@ -139,19 +140,21 @@ agreed on it. From reading the above text, this proposal seems to capture that. But I am somewhat unsure if the purpose of this proposal isn't rather to load just a -micro kernel and the pull up components according to configuration. Because I -wouldn't accept such an architecture, and I clearly stated so right at the +*micro kernel* and then pull up components according to configuration. Because +I wouldn't accept such an architecture, and I clearly stated so right at the beginning of our project. I accepted a very flexible and language neutral -plugin system on the condition the core remains in control, stays -''reasonable'' monolithic and componentization doesn't handicap us in creating +plugin system on the condition that the core remains in control, stays +``reasonable'' monolithic and componentization doesn't handicap us in creating an architecture based on abstractions and exploiting the proven design patterns. +Ichthyo:: '2008-11' + It has that flexibility, yes. But that means not that we have to abuse it in any way. The main() there and thus the bootstrap of the application is under our tight control, if we want to reject scriptable/highly configurable bootstrapping there then we can just do so. Thats more a social than a -technical decision. I personally don't like if a design is 'nannying' and puts +technical decision. I personally don't like if a design is ``nannying'' and puts too much constraints into unforeseen areas. If the computer can do some task better than we, it shall do it. This still means that I want to stay very much in control, it should only do some tedious, error-prone managing tasks for me. @@ -161,40 +164,43 @@ define anything. The interface system gets it right and we wont need to care for the order initialization. I added that because I consider such as absolutely important for plugins which might be supplied by third parties where we have no control over. But I now realized that we can nicely use that for our -own internal things too. Imo thats some very valuable service. - -- link:ct[] [[DateTime(2008-11-08T06:26:18Z)]] +own internal things too. IMO thats some very valuable service. + +ct:: '2008-11-08T06:26:18Z' Some further minor details: We didn't finish the discussion about namespaces on the last meeting. (I know I still have to write up a proposal showing the two or three alternatives I see regarding namespace organisation). But probably, -"lumiera::" will be our top level interface namespace and then probably the -lumiera directory will be taken by that. I see no problem also putting some +`"lumiera::"` will be our top level interface namespace and then probably the +`./lumiera` directory will be taken by that. I see no problem also putting some startup facilities in there, but generally, it shouldn't contain implementation code, only headers and abstract classes. If that's going to become a problem, we should consider to use a separate package for the startup, e.g. "src/boot". -Another point is, you need not write a main, because there is already one. +Another point is, you need not write a `main()`, because there is already one. Please have a look at it, especially with regards to the -[wiki:self:../GlobalInitialization global initialisation]. Further, last year +link:{rfc}/GlobalInitialization.html[global initialisation]. Furthermore, last year I've investigated boost::program_options and think it's fine. I use it for my test class runner since then. I don't think there is any reason why we should bother with parsing options (most config is pulled up from the session). I don't think we get much program options, maybe something to set a GUI skin. Moreover, I've written last year a thin wrapper around the commandline and integrated it with the boost options parser such that user code can receive the -remaining options as a vector of std::strings. Please have a look at -link:http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main] +remaining options as a vector of `std::string`s. Please have a look at +https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main] for an usage example. I really want our Lumiera main to be clean and expressive in the way showed there. Probably the most important part of the startup is pulling up the session core; because of that I think most of the startup process falls into the realm of the Proc-Layer. Within Proc, I don't want any significant string manipulations done with C-strings and I don't want raw arrays when we can use std::vector. - -- link:Ichthyostega[] [[DateTime(2008-11-06T19:28:13Z)]] -I 'dropped' this now because we do it somewhat differently now and I dont want -to document this here :P - -- link:ct[] [[DateTime(2009-02-03T17:28:28Z)]] +Ichthyostega:: '2008-11-06T19:28:13Z' + +I _dropped_ this now because we do it somewhat differently now and I don't want +to document this here 😛 + +ct:: '2009-02-03T17:28:28Z' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ArchitectureOverview.txt b/doc/devel/rfc/ArchitectureOverview.txt index 79a03f1fc..625060e25 100644 --- a/doc/devel/rfc/ArchitectureOverview.txt +++ b/doc/devel/rfc/ArchitectureOverview.txt @@ -1,12 +1,12 @@ Architecure Overview ==================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Architecure Overview -------------------- @@ -15,7 +15,8 @@ This proposal intends to capture envisioned Architecture of the Application. image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture] ^The SVG source of this drawing is -link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT]^ +https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT(2008)]· +https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=HEAD[(current: 2022)]^ Description @@ -33,7 +34,7 @@ Description * the user/GUI manipulates a high-level model whereas rendering is based on a corresponding low-level model * stored Session (state) is comprised of high-level model, a collection of - Assets and accompaning configuration + Assets and accompanying configuration * (possibly) several storage backends, abstracted out by a common interface @@ -52,27 +53,29 @@ Comments the next scene to appear relative to the last scene played. In the first, you want to keep the scenes always synced up against the audio, while in the latter, you just want the scenes to appear one after another. - --- link:PercivalTiglao[] [[DateTime(2008-07-16T05:32:45Z)]] + +PercivalTiglao:: '2008-07-16T05:32:45Z' * Yes, indeed, that is what I am planning. The drawing above just doesn't show every connection. The interaction between high-level model and rules system - mostly goes via the "session defaults", which are facts ''and'' rules. Thus, - in your example, the user would just use the "default placement". My - Intention was to use '''tags''' to quite some extent. The user would be able + mostly goes via the ``session defaults'"'', which are facts _and_ rules. Thus, + in your example, the user would just use the ``default placement'"''. My + Intention was to use *tags* to quite some extent. The user would be able to tag the source footage, and then rules can kick in when a certain tag applies. Incidentally, integrating prolog is immediately on the agenda, because first we want to flesh out the very basic system and get to work - basic rendering. Until then, I use a "mock" implementation of the + basic rendering. Until then, I use a _mock implementation_ of the query/rules system, which just returns some hard wired defaults. - -- link:Ichthyostega[] [[DateTime(2008-09-04T15:38:21Z)]] + +Ichthyostega:: '2008-09-04T15:38:21Z' Conclusion ---------- -Accepted. The drawing was moved into the GIT tree, hopefully it will be -maintained in future. +Accepted. The drawing was moved into the GIT tree. + +It was upgraded and reworked +https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=0b9f2e2c3139cad542013caac593cb5972a2e3f6[in 2022] - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/CCodingStyleGuide.txt b/doc/devel/rfc/CCodingStyleGuide.txt index 25281d8ef..917ad31f4 100644 --- a/doc/devel/rfc/CCodingStyleGuide.txt +++ b/doc/devel/rfc/CCodingStyleGuide.txt @@ -1,12 +1,12 @@ Design Process : C Coding Style Guide ===================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-07-03_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-07-03_ +|*Proposed by* | ct +|==================================== @@ -24,17 +24,17 @@ In the following I'll explain a C coding style I used frequently for other projects. Take this as suggestion for parts written in C (it definitely makes no sense for C++). We probably don't need to enforce this style for normal C code, but for the related -link:/rfc/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«] +link:{rfc}/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«] it really makes sense to have some well defined style. Function names follow the rule: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .`namespace[\_object][\_verb[\_subjects]][\_version]` -* namespace is \'lumiera_\' appended with some subsystem tag +* namespace is `lumiera_` appended with some subsystem tag (`lumiera_plugin_audio_`) -* object is the type of the \'this\' object we are addressing, maybe followed - by the object we are returning +* object is the type of the `this' (or `self') object we are addressing, + maybe followed by the object we are returning * verb is the action to take, (new, copy, free, set, clear,.. etc.) if omitted the action is `get` * subjects is a descriptive list of the arguments which the action takes, this @@ -51,11 +51,11 @@ Prototypes follow the rule: * function is the functionname as above * rettype is sensible to what object and verb define, setters return a pointer to the set'ed element if an allocation could be involved (or NULL on - failure), a int if the setter does some checks over the supplied argument (0 - indicates failure, !0 success), void for procedures and actions which can + failure), a int if the setter does some checks over the supplied argument + (`0` indicates failure, `!0` success), void for procedures and actions which can never fail. -* Object is a pointer to refered object (\'this\' like C++) in rare cases - (_new()) functions may be used without this self pointer, see below +* Object is a pointer to referred object (`this' like C++) in rare cases + (`_new()`) functions may be used without this self pointer, see below * `...` are the types and names of the arguments described in `subjects` of the name. @@ -76,9 +76,9 @@ typedef const namespace_foo ** const_NamespaceFoo_ref; // same for const object Examples: +++++++++ .`lumiera_plugin_audio_sample_normalize_limit_1 (AudioSample self, int limit)` -* namespace is \'lumiera_plugin_audio\' -* operates on a \'sample\' object (and likely returns a pointer) -* operation is \'normalize\' +* namespace is `lumiera_plugin_audio` +* operates on a `sample' object (and likely returns a pointer) +* operation is `normalize` * takes one additional parameter describing the limit for normalization * this is a version 1 interface we later define: @@ -97,9 +97,6 @@ Examples: -Tasks -^^^^^ - Pros ^^^^ @@ -130,20 +127,20 @@ overhead to encode arguments to functionnames. But the intention here is to make code easy readable and memorizeable, when one follows this scheme one does seldom need to lookup the docs about the API. In fact it sometimes even turns out that one wants to use a functionname which isn't defined in the API, which -is a good indicator to add such to to the API. +is a good indicator to add such a missing function to the API. This scheme is not fully unambiguous but suffices for all practical task. It encodes parameters like C++ does for overloading without strange mangling. All names are global in a well defined namespace which is very natural for C (other -OO like C styles involve structs and hand written vtables, with this scheme we -trampoline from this global names to vtables *only* if needed) +OO like C styles involve structs and hand written CTables, with this scheme we +trampoline from this global names to VTables _only if needed_) Conclusion ---------- -Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06 +Finalized at the link:{ldoc}/devel/meeting_summary/2008-03-06.html[2008-03-06 developer meeting] @@ -151,61 +148,69 @@ Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06 Comments -------- -I strongly object promoting such a thing as a general "Style Guide". It can be +I strongly object promoting such a scheme as a general ``Style Guide''. It can be a help or last resort if you are forced to work with improper tools (a situation that's rather frequent in practice though). __As such it is well -chosen and practical__. +chosen and practical__, however. But basically, it shows several things: + * you are using a global namespace * you deal with way to fat interfaces * you mix deployment metadata (a version/compatibility check) with functional code + All of this indicates some design style breakage, so it would be preferable to fix the design if possible. The only part I'd like to support as a Style Guide is the rule of using the "verb+object" pattern for creating function names - -- link:Ichthyostega[] [[DateTime(2007-07-08T11:42:39Z)]] + +Ichthyostega:: '2007-07-08T11:42:39Z' Probably needs little explanation: + * you are using a global namespace -This is only about C for names which get exported, C only has a global + +** This is only about C for names which get exported, C only has a global namespace and we need some way to get unique names. The -link:Lumiera/DesignProcess/AllPluginInterfacesAreC[] already uses -better/smaller namespaces by defining interfaces as C structs. The full blown -long names explained here are technically not needed when we use the plugin -system as proposed, I just shown them here for completeness. Next, when we -decide for alternative linking methods like static builds we would need to +link:{rfc}/AllPluginInterfacesAreC.html[RfC: Plugin Interfaces in C] +already uses better/smaller namespaces by defining interfaces as C structs. +The full blown long names explained here are technically not needed when we use +the plugin system as proposed, I just shown them here for completeness. Next, +when we decide for alternative linking methods like static builds we would need to declare all "verb+object" functions static, else there is a high probability of clashes. * you deal with way to fat interfaces -How can you tell that? This is only a nameing style. No interfaces mentioned + +** How can you tell that? This is only a nameing style. No interfaces mentioned here. I am all after small well defined specialized interfaces. -* you mix deployment metadata (a version/compatibility check) with functional - code -Yes, I cant figure out how to do it better but still lightweight in C. the -_version thing is something I added here after the interfaces proposal. I work +* you mix deployment metadata (a version/compatibility check) with functional code + +** Yes, I cant figure out how to do it better but still lightweight in C. the +`_version` thing is something I added here after the interfaces proposal. I work on a example how this will be used in a more friendly way. -Note again that this is a "nameing system", it is intended to be very verbose +Note again that this is a ``naming system'', it is intended to be very verbose and give unique declarative names. It is not about design! Design is done as usual and only when things have to be exported as C symbols (both, exported and C!!) this applies. This has zero implication for C++ code, zero implication for C functions which are not exported (while I personally still prefer this style) and finally when we do the interfaces thing like I proposed, then the naming can be much simpler, see examples there or in my repository. - -- link:ct[] [[DateTime(2007-07-10T08:03:06Z)]] + +ct:: '2007-07-10T08:03:06Z' Thanks, your explanation together with the example in git made the usage -pattern much more clear. I think the _version postfix is esp. helpful on the +pattern much more clear. I think the `_version` postfix is esp. helpful on the names of the plugin interfaces (structs in C), and probably it will be a good -practice, to have one such common plugin interface on every "plugin extension -point", i.e. every point in the sytem, that can be extended by plugins. - -- 217.110.94.1 [[DateTime(2007-07-10T17:23:33Z)]] +practice, to have one such common plugin interface on every ``plugin extension +point'', i.e. every point in the system, that can be extended by plugins. + +Ichthyostega:: '2007-07-10T17:23:33Z' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ClipCatalogingSystem.txt b/doc/devel/rfc/ClipCatalogingSystem.txt index 232a17ea5..75812f93c 100644 --- a/doc/devel/rfc/ClipCatalogingSystem.txt +++ b/doc/devel/rfc/ClipCatalogingSystem.txt @@ -1,12 +1,12 @@ Design Process : Clip Cataloging System ======================================= -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-07-26_ -*Proposed by* link:JordanN[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-07-26_ +|*Proposed by* | JordanN +|==================================== Clip Cataloging System ----------------------- @@ -22,7 +22,7 @@ Organizations that work with video, and even home users, tend to have massive collections of stock videos and images that they will need to find and use in their projects. A Linux-based system is needed to help them to organize, tag, and retrieve assets from those collections. Being able to find the clips the -user needs and bring them into his timeline, will mean that the user will be +user needs, and to bring them into his timeline, will mean that the user will be able to more rapidly complete his project. This could be implemented as a separate application, but integrated for use in @@ -57,8 +57,6 @@ them correctly. Not clip-based, so the entire video must be imported and the desired portion selected. -Rationale -~~~~~~~~~ Comments @@ -69,40 +67,49 @@ Comments development power to do that now. If someone wants to work on that, please contact me. General idea is to put all kinds of resources (Footage, Clips, Effects, Subprojects, Sounds ....) into a database with then gets - tagged/attributed in different ways (implicit things like 'filename', 'type', - 'length'; automatic deduceable things like 'Exposure', 'Timecode', ...; And - manual tags like: who was on set, location, ....). Then present this all in a + tagged/attributed in different ways (implicit things like `filename', `type', + `length'; automatic deducible things like `Exposure', `Timecode', ...; And + manual tags like: who was on set, location, ...). Then present this all in a *good* GUI (by default just showing filesysten like) but one can define queries on this database and the generated views will then be storeable. -Back to Lumiera, for now we will likely just use 'normal' file open dialogs + +Back to Lumiera, for now we will likely just use ``normal'' file open dialogs until the above system becomes available. - -- link:ct[] [[DateTime(2008-07-26T08:31:42Z)]] -* Yes, it's indeed an important feature we should care for. But cehteh is + +ct:: '2008-07-26T08:31:42Z' + +* Yes, it's indeed an important feature we should care for. But _cehteh_ is right, we have more important things to do first. But feel free to target it. * Also, we'd need integration with production support systems, for example http://celtx.com/[CELTX]. * The interface to the Lumiera App would be to populate the asset manager with the required assets - -- link:Ichthyostega[] [[DateTime(2008-07-27T22:19:38Z)]] + +Ichthyostega:: '2008-07-27T22:19:38Z' -Videos, Audio, Clips and Resources Manager by using plugins for FOSS GPL -"Library & Collections Management" programs. -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The video and audio raw material, clips, etc could be managed using code that -is already available in project that carry out the same tasks. For example as +Connect to existing FOSS applications by plugin +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A Video-, Audio-, Clips and Resources Manager can be built by using plugins +for existing ``Library and Collections Management'' programs available under GPL, +or at least code from such applications could be used to carry out similar tasks. +For example as library managers, or media (video, audio or CD) collections, Integrated Library Systems (ILS). -Examples of a library management program ; +Examples of a library management program: -. Kete - http://kete.net.nz/[] -. Koha - http://www.koha.org/[] -. link:GreenStone[] - http://www.greenstone.org/[] -. Evergreen - http://open-ils.org/faq.php[] +- https://web.archive.org/web/20080514220816/http://www.koha.org/[Koha] + · https://koha-community.org/[2025] + · https://en.wikipedia.org/wiki/Koha_(software)[Wikipedia] + · https://liblime.com/[LibLime (commercial)] +- https://web.archive.org/web/20080613192838/http://kete.net.nz/[Kete] +- https://www.greenstone.org/[GreenStone] +- https://evergreen-ils.org/frequently-anticipated-questions/[Evergreen] -An additional benefit to using "library" managers, is that it can handle -interloans, referencing of "other" (people's/organization's) libraries, +An additional benefit to using ``library'' managers, is that it can handle +interloans, referencing of ``other'' (people's / organization's) libraries, numbering systems, descriptions, and classifications, thousands to millions of items, search systems, review and comment systems, plus the benefits of open source that allow the expansion of features easily. The use of task oriented @@ -113,16 +120,18 @@ working with cataloging systems for a long time is likely to do well. Plus it can be readily improved, by people who do not have to know the first thing about how to design video editing programs. The program also gets improved because of it own community, which adds features or performance to Lumiera, -without even having to "drive" the development.. ---link:Tree[][[DateTime(2008-08-27T20:38:00NZ)]]. +without even having to ``drive'' the development.. + +Tree:: '2008-08-27T20:38:00NZ' '''' Parked until someone cares ~~~~~~~~~~~~~~~~~~~~~~~~~~ -Decided on Developer meeting +Decided in link:{ldoc}/devel/meeting_summary/2011-04-13.html#_clip_cataloging_system[Developer meeting] - Do 14 Apr 2011 02:52:30 CEST Christian Thaeter +Christian Thaeter:: 'Tur 14 Apr 2011 02:52:30 CEST' +'''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/CodingStyle.txt b/doc/devel/rfc/CodingStyle.txt index 1cef4e0a1..ff79ee1bb 100644 --- a/doc/devel/rfc/CodingStyle.txt +++ b/doc/devel/rfc/CodingStyle.txt @@ -1,12 +1,12 @@ Design Process : Coding Style ============================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-27_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-27_ +|*Proposed by* | ct +|==================================== @@ -30,10 +30,10 @@ See https://en.wikipedia.org/wiki/Indentation_style[Wikipedia: Indentation Style .Proposed: * K&R by _ichthyo_ -* compact and well known +** compact and well known * GNU by _cehteh_ -* imo the best readability (albeit little strange) -* Lumiera might apply as official GNU project someday +** imo the best readability (albeit little strange) +** Lumiera might apply as official GNU project someday Another question: __how to write identifiers?__ @@ -65,11 +65,11 @@ CT:: '2007-07-03 04:04' Comments -------- -Since link:ct[] called spaces instead of tabs first, we should stick to that. I +Since ct called spaces instead of tabs first, we should stick to that. I think all other reasons will lead us to nowhere! Although I'm used to a BSD/KNF-like coding style I will try the GNU one. After -all, the wikipedia page mentions no disadvantages of that style :) +all, the wikipedia page mentions no disadvantages of that style 😊 MichaelPloujnikov:: '2007-06-27 17:17' @@ -77,12 +77,22 @@ MichaelPloujnikov:: '2007-06-27 17:17' I just proposed K&R because it is widely accepted. Personally, I was never very fond of K&R style, I always preferred putting opening braces to the left. I never used GNU style until now, but it looks somewhat appealing to me. (btw, -ECLIPSE comes with presets for all this styles :-P ). Anyhow, I can adapt to +ECLIPSE comes with presets for all this styles 😛 ). Anyhow, I can adapt to most any style. The only thing I really dislike is using tabs (with the -exception of database DDLs and CSound files, where tab are actually helpful) :) +exception of database DDLs and CSound files, where tab are actually helpful) 😊 Ichthyo:: '2007-06-27 20:55' +Many years later -- we are still using GNU style and over time have developed +a »Lumiera flavour« which plays well with C++, templates and λ-functions. +A striking consequence is that the code looks light, favours short functions, +is rather vertically oriented and is easy to skim while scrolling. + +-> see our link:/x/CodeStyle.html[Style guide]. + +Ichthyo:: '2025-09-05' + + '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ConfigLoader.txt b/doc/devel/rfc/ConfigLoader.txt index 6daa255ab..7e19d21ef 100644 --- a/doc/devel/rfc/ConfigLoader.txt +++ b/doc/devel/rfc/ConfigLoader.txt @@ -4,12 +4,12 @@ Config Loader // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-08-07_ -*Proposed by* **ct** -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-08-07_ +|*Proposed by* | **ct** +|==================================== ******************************************************************************** .Abstract @@ -67,7 +67,7 @@ Ichthyostega:: '2023-10-24' ~~ //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -147,7 +147,7 @@ API - lumiera_config_init (const char* searchpath) searchpath is a buildin-default, can be changed via configure and can be appended and overridden by using a flag, e.g. `--config-path-append=""` or `--config-path=""` * `lumiera_config_destroy(...)` - - frees all space allocated by the link:ConfigLoader[]. + - frees all space allocated by the ConfigLoader. * `lumiera_config_load(...)` - reads *one* single configuration file that will include all settings from other files. @@ -205,10 +205,12 @@ API .foo.bar ======================================= `integer_set("foo.bar", 123)` + looks up "foo.bar" -this returns as well file and line -it will be decided whether it's a system file or a user's config file. -if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk + +- this returns as well file and line +- it will be decided whether it's a system file or a user's config file. +- if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk set the value in the line. ======================================= @@ -236,16 +238,15 @@ anchor:anchor_config[]lumiera_configfile anchor:anchor_types[]provided TYPES ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`--------------.--------------------------------------'------------------------------------------------------------ -config type C type semantic (example) -------------------------------------------------------------------------------------------------------------------- -number signed long long also hex and octal (foo.bar = 12345 #comment) -real long double differerent formats as well (foo.bar=1.2345 #comment) -string const char* optionaly quoted string (foo.bar="this string" #this not) -word const char* first optionaly quoted word of the config (foo.bar= first this # not) -bool int common representations for bools (0,1,true,false,yes,no,on,off,set,clear) -------------------------------------------------------------------------------------------------------------------- +[options="header", cols="^,2^m,6"] +|==================================== +|config type | C type | semantic (example) +|number |signed long long | also hex and octal (foo.bar = 12345 #comment) +|real |long double | differerent formats as well (foo.bar=1.2345 #comment) +|string |const char* | optionaly quoted string (foo.bar="this string" #this not) +|word |const char* | first optionaly quoted word of the config (foo.bar= first this # not) +|bool |int |common representations for bools (0,1,true,false,yes,no,on,off,set,clear) +|==================================== ... add more types on demand (ichthyo mentioned a tuple type for color triples etc.) @@ -591,7 +592,7 @@ Discussion on irc [02:06] <__nasa__> There should be a callback for a plugin to add a config file for that plugin. [02:06] <__nasa__> Ooh [02:06] <__nasa__> cool idea -[02:06] this is not really complicated to do but would give a big usage experience link:JustWorks[][TM] +[02:06] this is not really complicated to do but would give a big usage experience JustWorks[TM] [02:06] <__nasa__> ~/.lumi/config is the main configuration directory [02:06] <__nasa__> inside, there is a ~/.lumi/config/config.ini which is main configuration [02:07] no callbacks .. the idea is that the config system is independent and nothing else need to register there, that makes it much easier diff --git a/doc/devel/rfc/DataBackend.txt b/doc/devel/rfc/DataBackend.txt index a4710224f..380d37243 100644 --- a/doc/devel/rfc/DataBackend.txt +++ b/doc/devel/rfc/DataBackend.txt @@ -1,12 +1,12 @@ Design Process : Data Backend ============================= -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2007-06-04_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2007-06-04_ +|*Proposed by* | ct +|==================================== DataBackend ----------- @@ -17,36 +17,34 @@ Description ~~~~~~~~~~~ This just starts as braindump, I will refine it soon: -. handle all files lumiera uses at runtime (media, edl, temp data) -. manage filehandles, lumiera might use more more files than available - filehandles -. manage temporary data -. do caching -. io will be blocked where the backend tells the core where it can expect the - data (not read()/write() like) -. kindof garbage collector -. do prefetching -. no/low latency for the core the prefetcher and other things ensure that data - is available in time -. translate any input into a format which the lumiera core understands (demux, - decode) -. same for encoding to output formats -. offer a plugin API for encoders/decoders -. maybe network backend for serving data to distributed rendernodes -. can do some load control or management (trigger adaptive rendering if system - is idle etc) -. pull based arch +- handle all files lumiera uses at runtime (media, edl, temp data) +- manage filehandles, lumiera might use more more files than available filehandles +- manage temporary data +- do caching +- IO will be blocked where the backend tells the core where it can expect the data (not `read()`/`write()` like) +- kindof garbage collector +- do prefetching +- no/low latency for the core the prefetcher and other things ensure that data is available in time +- translate any input into a format which the lumiera core understands (demux, decode) +- same for encoding to output formats +- offer a plugin API for encoders/decoders +- maybe network backend for serving data to distributed rendernodes +- can do some load control or management (trigger adaptive rendering if system is idle etc) +- pull based architecture .Notes: -* ichthyo wrote also some ideas on - http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra3/Architecture[Architecture] and a sketch/draft about http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Possibilities_at_hand[things possible in the middle layer] +* ichthyo wrote also some ideas regarding + link:http://localhost:8888/project/background/history/PossibilitiesAtHand.html[things possible in the middle layer]... Parked ~~~~~~ The underlying principles remain valid, yet development took another direction during the last years. Special frameworks for high-performance -asynchronous IO will be used for dedicated use cases. +asynchronous IO will be used for dedicated use cases. A garbage collector +is not necessary, since Lumiera relies on deterministic memory management. +Furthermore, decoding, transcoding and encoding is handled as part of the +pipeline and not through a separate service. Ichthyostega:: '2023-10-24' ~~ @@ -56,15 +54,18 @@ Comments -------- Sounds fairly complete to me - -- link:Ichthyostega[] [[DateTime(2007-06-16T23:19:44Z)]] + +Ichthyostega:: '2007-06-16T23:19:44Z' Developement takes place in the repo now - -- link:ct[] [[DateTime(2007-06-27T16:14:56Z)]] + +ct:: '2007-06-27T16:14:56Z' Development took another direction over the last years; -the former »Backend« layer is restructured - -- link:Ichthyostega[] [[DateTime(2023-10-24T22:45:55Z)]] +the former »Backend« layer is called »Vault« now and structured differently. + +Ichthyostega:: '2023-10-24T22:45:55Z' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DelectusShotEvaluator.txt b/doc/devel/rfc/DelectusShotEvaluator.txt index 186769f87..07b9b8290 100644 --- a/doc/devel/rfc/DelectusShotEvaluator.txt +++ b/doc/devel/rfc/DelectusShotEvaluator.txt @@ -1,9 +1,12 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-09-21_ -*Proposed by* link:nasa[] -------------------------------------- +Design Process : Delectus +========================= + +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-09-21_ +|*Proposed by* | nasa +|==================================== Delectus Shot Evaluator @@ -14,13 +17,11 @@ This is a brain dump about the shot evaluator subproject. Description ~~~~~~~~~~~ - -Brainstorm on Delectus -~~~~~~~~~~~~~~~~~~~~~~ +.A collection of Ideas Some (many) of the ideas presented herein come from the various parties -involved in the Lumiera discussion list and IRC channel #lumiera. -http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[] -- the -main discussion thread +involved in the Lumiera Mailing List and IRC channel `#lumiera` -- here is the +http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[main discussion thread]. + Additionally, a lot of great concepts for how to streamline the interface are derived in part from https://www.kphotoalbum.org/[KPhotoAlbum]. @@ -42,7 +43,7 @@ support (please add more!) is: As such, the tags themselves can have metadata. You can see where this is going... -Also, the tags are applied to "clips" -- which I use interchangeably between +Also, the tags are applied to ``clips'' -- which I use interchangeably between source material imported into the application and slice of that material that tags are applied to. Any section of a video or audio source can have tags applied to it. @@ -68,9 +69,9 @@ Some key points: * Technically flawed footage can be both manual and computer classified. * In some cases (e.g. documentaries, dialog) audio and video clips/footage can follow different section processes. - It is possible to use video from footage with useless audio or use audio - from footage with useless video. - * "Interesting" is designed to be broad and is explained below. + - It is possible to use video from footage with useless audio or use audio + from footage with useless video. + * ``Interesting'' as a category is meant be broad and is explained below. * steps 2-5 can be performed in parallel by numerous people and can span many different individual clips. @@ -106,7 +107,7 @@ The key to adequate expressive power is as follows: * Connection to on site documentation and pre-production documentation. When making decisions about what material to use and how to classify it, it is essential to use any tools and resources available. The two most useful are - onsite documentation (what worked/didn't work, how the weather was, pictures + on-site documentation (what worked/didn't work, how the weather was, pictures of the setup, etc all at the shoot) and pre-production (what the ideal scene would be, what is intended, etc). Anything else that would be useful should be supported as well. @@ -143,7 +144,7 @@ vice-versa. Interesting ^^^^^^^^^^^ -An "interesting" clip is one that has potential -- either as a metadata piece +An _interesting clip_ is one that has potential -- either as a metadata piece (multimedia note, talent briefing, etc) or footage (for the final product OR intermediary step). The main goal of the application is to find and classify interesting clips of various types as quickly as possible. @@ -181,10 +182,10 @@ that by having parts of individual clips, metadata, or other files be specific to one aspect of the overall design. This allows for much more successful use of the related information and a cleaner, streamlined layout. As an example, metadata involving file size has no effect whatsoever on the vast majority of -most major decisions -- the answer is almost always "whatever it takes." Thus, +most major decisions -- the answer is almost always ``whatever it takes''. Thus, it would not appear most of the time. Content narrowing means that it is easy -to add back footage -- "widen the view" one step, add it back, and "narrow the -view" again. +to add back footage -- ``widen the view'' one step, add it back, and ``narrow +the view'' again. Multiple cuts @@ -206,7 +207,7 @@ THE SCENE), take (what is actually going on IN THIS SPECIFIC RUN), and instance (what is actually going on IN THIS CLIP). If editing a situation, the other referenced clips AUTOMATICALLY add metadata and relevant sections. This can be as precise and nested as desired, though rough cuts for level one editing -(first watchthrough after technically well executed clips have been selected) +(first watch-through after technically well executed clips have been selected) and more accurate ones for higher levels is the recommended method. @@ -223,12 +224,12 @@ nasa's Laws of Tagging (reasonable) number of tags. This is OK. All that is needed is the minimum set of unique tags to progress to the next cycle without losing editing intent or the ability to rapidly evaluate many situations. -. Many tags are used many times. "Outdoors" will be a very, very common tag; so - will "redub." If conventional names are decided upon and stuck to, it is +. Many tags are used many times. `Outdoors` will be a very, very common tag; so + will `redub`. If conventional names are decided upon and stuck to, it is significantly easier to map the complex interactions between different content situations. -. Avoid compound tags. Do not have "conversation_jill_joe" as a tag; use - "conversation," "jill," and "joe" instead. It is very easy to search for +. Avoid compound tags. Do not have ``conversation_jill_joe'' as a tag; use + ``conversation'', ``jill'', and ``joe'' instead. It is very easy to search for multiple tags and very hard to link data that doesn't use overlapping tags. @@ -257,15 +258,16 @@ sections are allowed. Prompting Prompting for metadata is a laborious, time-consuming process. There is no truly efficient way to do it. This application uses a method similar to -link:KPhotoAlbum[]. When the space key is held and a letter is pressed, the tag +_KPhotoAlbum_. When the space key is held and a letter is pressed, the tag that corresponds to that letter is assigned to the track for the duration of the press. (If the space is pressed and no other key is pressed at the same time, it stops the track.) For example, suppose that the following mapping is present: -o = outside -x = extra -p = protagonist -c = closeup + + o ⟼ outside + x ⟼ extra + p ⟼ protagonist + c ⟼ closeup Then holding SPACE over a section and pressing one of these keys would assign the tag to the audio AND video of the section over which the space was held. If @@ -277,15 +279,18 @@ If LALT is held down instead of SPACE, the audio is effected instead. If RALT is held, just the video is effected. In order to support scenario/take/clip tagging: - The default is situation. If the keybinding to x is: - x = t:extra ; effect only take - x = ts:extra ; effect take and scenario - x = c:extra ; extra only visible in this clip! - x = tc:extra ; this take and clip show the extra - etc + + - The default is situation. If the keybinding to x is: + + ** x = t:extra ; effect only take + ** x = ts:extra ; effect take and scenario + ** x = c:extra ; extra only visible in this clip! + ** x = tc:extra ; this take and clip show the extra + ** ... Other keyargs (the part in front of the colon) can be added to account for -other uses (e.g. l = all taken on the same location). +other uses + +(e.g. l = all taken on the same location). Tab is pressed to add metadata mappings. Tab is pressed to enter metadata edit mode; this pauses video. Then press any key to map; and type the tag to @@ -306,12 +311,9 @@ defined: If ESC is pressed, all currently ranged tags are ended. Finally, if single_quote is pressed without SPACE or {L,R}ALT down, it marks an -"interesting location." Pressing SHIFT+single_quote goes to the next -"interesting location" and pressing CNTRL+' goes to the previous "interesting -location." This allows for very quick review of footage. - - - +``interesting location''. Pressing SHIFT+single_quote goes to the next +``interesting location'' and pressing CNTRL+' goes to the previous +``interesting location''. This allows for very quick review of footage. @@ -335,28 +337,29 @@ The importance/value of the video for various factors uses, can vary through the video. It would be helpful to have the ability to create continuous ratings over the entire track. Ratings would be numerical. Automatic clip selection/suggestion could be generated by using algorithms to compute the -usefulness of video based on these ratings (aswell as "boolean -operations"/"binary decisions" done with tags). The ratings could be viewed +usefulness of video based on these ratings (as well as ``boolean operations'' +rsp. ``binary decisions'' done with tags). The ratings could be viewed just like levels are - color coded and ovelayed on track thumbnails. -- Tree 2008-10-25 +Tree:: '2008-10-25' -link:MultiView[] - useful for concurrent ratings input -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MultiView - useful for concurrent ratings input +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It would be convenient to have an ability to view the different tracks (of the same scene/time sequence) at once, so the viewer can input their ratings of the -video "on the fly", including a priority parameter that helps decide which +video ``on the fly'', including a priority parameter that helps decide which video is better than what other video.See the GUI brainstorming for a viewer widget, and key combinations that allow both right and left hand input, that could be used for raising/lowing ratings for up to six tracks at once. -- Tree 2008-10-25 +Tree:: 2008-10-25 I like the idea of rating clips (or rather, takes) a lot. It would be cool to -include both "hard," "relative," and "fuzzy" rating. Hard is an exactly defined +include both `hard', `relative', and `fuzzy' rating. Hard is an exactly defined value (scaled 0-1) that puts the clip in an exact location in the queue. Relative means that one is higher or lower rated than another. Fuzzy is a slider which is approximate value, and there is some randomness. The best part @@ -367,7 +370,7 @@ sort of heap (think binary heap, at least for the data structure) which determines the priorities and decides which clips are played. Then the highest rated clips are played first, down to the worst. -- link:NicholasSA[] 2009-01-04 +NicholasSA:: '2009-01-04' Possible Collaboration with the people from Ardour? @@ -384,7 +387,7 @@ I like the suggestion of sound classification with a similar (or, even better, identical) evaluator. link:SoundMiner[] looks interesting, but like you say very expensive. I'm a sound guy, so I feel your pain... -- link:NicholasSA[] 2009-01-04 +NicholasSA:: '2009-01-04' Parked @@ -392,7 +395,7 @@ Parked Decided on Developer meeting, until someone wants to investigate this further. - Do 14 Apr 2011 02:52:30 CEST Christian Thaeter +ct:: 'Thu 14 Apr 2011 02:52:30 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DesignParamAutomation.txt b/doc/devel/rfc/DesignParamAutomation.txt index 4d1fc201a..d7d1f18d1 100644 --- a/doc/devel/rfc/DesignParamAutomation.txt +++ b/doc/devel/rfc/DesignParamAutomation.txt @@ -1,23 +1,22 @@ -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Design the handling of Parameters and Automation ------------------------------------------------ Parameters of Plugin Components and/or Render Nodes play a role at various levels of the application. - + Thus it seems reasonable to do a formal requirements analysis and design prior to coding. Description ~~~~~~~~~~~ -Regarding components directly participating in the render (which may be +Regarding components directly participating in the render (which might be implemented by plugins), we distinguish between *configuration* (static) and *parameters* (dynamic). The point of reference for this distinction is the render process: a plugin configuration may well be variable in some manner, @@ -34,8 +33,7 @@ Tasks * we need to work out an introspection mechanism for parameters - asses what different types of parameters we need - - find out how much structured parameters will be (do simple values - suffice?) + - find out how much structured parameters will be (do simple values suffice?) - define how parameters can be discovered/enumerated - define a naming scheme for parameters, so they can be addressed unambiguously @@ -46,16 +44,16 @@ Tasks So... -. find out to which extend we need these properties +. find out to which extent we need these properties . find out what parts of the App will have what requirements? . chose a best fitting implementation based on this information A closely related issue is the handling of *Automation*. The current draft -calls for an abstract interface "ParamProvider", which just allows the +calls for an abstract interface `ParamProvider`, which just allows the Plugin or RenderComponent to pull a current value, without knowing if the -ParamProvider is a GUI widget or an automation data set with interpolation. The -component using the param value should not need to do any interpolation. We -should re-asses and refine this draft as needed. Note: Render Nodes are +`ParamProvider` is a GUI widget or an automation data set with interpolation. +The component using the param value should not need to do any interpolation. +We should re-asses and refine this draft as needed. Note: Render Nodes are stateless; this creates some tricky situations. @@ -68,17 +66,38 @@ Alternatives ^^^^^^^^^^^^ ?? (any ideas?) +One alternative would be _not to recognise_ that this is a problematic requirement, +and just to hack away and ``solve'' each obstacle in an ad-hoc manner. +Unfortunately I'm unable to take this ``alternative'' seriously. + +Another approach could be to reject the idea of ``parameters'' being _something special_ +and rather to treat them as some kind of _different medium_ -- which would subject +a _parameter stream_ to pull-processing. This seems to be an interesting angle, since +going that route would remove the topic of parameters and automation from the core +render engine altogether. However, I am not _bold enough_ to embrace this approach +as a solution -- since I can not see to what extent such a shift would _actually_ +change anything of the actual functionality to be implemented or remove any overhead. + +Ichthyostega:: '2025-09-10' + Rationale ~~~~~~~~~ - - - +The rationale of this RfC is to conduct some requirement analysis before the +point where the aforementioned features will actually be required to continue +with the coding work. In an ideal world, such analysis would be carried out +in parallel by someone knowledgeable enough to recognise the difficulties. Comments -------- +This seems to be one of those nasty features which do not garner any engagement +nor spur any creativity. At some point you'll just happen to need it, and then, +I'm afraid the analysis and planning work will incur significant delay... -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Ichthyostega:: '2025-09-10' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DesignRenderNodesInterface.txt b/doc/devel/rfc/DesignRenderNodesInterface.txt index bac8623e3..0dc00a399 100644 --- a/doc/devel/rfc/DesignRenderNodesInterface.txt +++ b/doc/devel/rfc/DesignRenderNodesInterface.txt @@ -1,17 +1,18 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Design the Render Nodes interface --------------------------------- -In the current design, the low-level model is comprised of "Render Nodes"; -Stean-Layer and Vault carry out some colaboration based on this node network. - + +In the current design, the low-level model is comprised of ``Render Nodes''; +Steam-Layer and Vault carry out some collaboration based on this node network. + Three different interfaces can be identified + * the node wiring interface * the node invocation interface * the processing function interface @@ -22,22 +23,22 @@ Description Render Nodes are created and wired by the Builder in the Steam-Layer. On the other hand, the rendering process is controlled by the vault layer, which also provides the implementation for the individual data processing tasks. To create -a result, output nodes are ''pulled'' via the invocation interface, resulting +a result, output nodes are _pulled_ via the invocation interface, resulting in the affected nodes to recursively pull their predecessor(s). In the course of this call sequence, the nodes activate their processing function to work on a given set of buffers. Moreover, we plan to use the render network also for gathering statistics. -'''Note''': Render Node is an internal interface used by Steam-Layer and - activated by the Vault. Plugins are planned to be added via Adapter nodes. - Thus the Render Node interface needs ''not'' to be exported. +NOTE: Render Node is an internal interface used by Steam-Layer and + activated by the Vault. Plugins are planned to be added via Adaptor nodes. + Thus the Render Node interface needs _not_ to be exported. the wiring interface ^^^^^^^^^^^^^^^^^^^^ This part of the design defines how nodes can be combined and wired up by the builder to form a network usable for rendering. For this purpose, the -link:ProcNode[] is used as a shell / container, which is then configured by a +`ProcNode' is used as a shell / container, which is then configured by a Connectivity descriptor. Thus, the node gets to know its predecessor(s) and is preselected to use a combination of specific working modes: @@ -59,18 +60,18 @@ corner case. the invocation interface ^^^^^^^^^^^^^^^^^^^^^^^^ -this is intended to be a rather simple "call-style" interface, without much -possibilites to influence the way things are happening. You pull a node and +this is intended to be a rather simple ``call-style'' interface, without much +possibilities to influence the way things are happening. You pull a node and will find the results in a provided buffer or the cache, but you can't even change the frame data type type of the result. Besides the node invocation, functions for collecting statistics will be accessible here too (Probably these -functions will be ''implemented'' in a classic-OO fashion by virtual functions, +functions will be _implemented_ in a classic-OO fashion by virtual functions, but that's another story) the processing interface ^^^^^^^^^^^^^^^^^^^^^^^^ -the individual nodes are configured to call a plain-C {{{process()}}} function +the individual nodes are configured to call a plain-C `process()` function and provide an array of buffer pointers to be used within this function. For the purpose of invoking actual data processing, it is irrelevant if this function is implemented somewhere in the vault layer or provided by a plugin. @@ -81,7 +82,7 @@ processing function is supposed to do The Right Thing ^TM^ Tasks ^^^^^ - * What services do we expect from Render Nodes. What do we plan to do with a + * What services do we expect from Render Nodes? What do we plan to do with a render node? * What different kinds (if any) of Render Nodes can be foreseen? * order the required functionality by Steam / Vault. Find out specific @@ -98,7 +99,8 @@ Tasks Rationale ~~~~~~~~~ -The purpose of this Design Entry is to give a summary; the questions and the +The purpose of this Design Entry is to give a summary and to spur the discussion +regarding the responsibilities of Steam vs Vault; the questions and the details of carrying out the operations are much more involved. Please see the @@ -113,15 +115,12 @@ for details -Comments --------- - - Parked ~~~~~~ We park this until we have time to revisit the details. It is accepted that we need to design this interfaces. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DeveloperDocumentationStructure.txt b/doc/devel/rfc/DeveloperDocumentationStructure.txt index 78640f20c..57ab7cbf3 100644 --- a/doc/devel/rfc/DeveloperDocumentationStructure.txt +++ b/doc/devel/rfc/DeveloperDocumentationStructure.txt @@ -3,12 +3,12 @@ Developer Documentation Structure // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Mon Aug 2 18:03:25 2010_ -*Proposed by* Cehteh + Ichthyo -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _Mon Aug 2 18:03:25 2010_ +|*Proposed by* | Cehteh + Ichthyo +|==================================== ******************************************************************************** We describe here how to bring the Lumiera Developer Documentation into an simple @@ -69,14 +69,16 @@ Tasks ~~~~~ // List what would need to be done to implement this Proposal in a few words: - * Go over the existing content and the remainder of the asciidoced tiddlywikis, - integrate this content either in directly into the "Lumiera: The inner Core" + * Go over the existing content and the remainder of the Asciidoced TiddlyWikis, + integrate this content either in directly into the + link:{ldoc}/technical/overview.html[»Lumiera: The inner Core«] document or write separate documentation pages or RFC's. ([green]#✔ done#) - * The 'proc' tiddlywiki is a bit special, we need a plan how to integrate this. - [red yellow-background]#TBD# + * The »Renderengine« TiddlyWiki is a bit special, we need a plan how to integrate this. * Create a facility to support the cross-linking between the various kinds of documents - [yellow-background]#WIP# + [red yellow-background]#TODO# +CAUTION: this issue with stable cross-links + -> link:{rfc}/WebsiteSupportMarkup.html[remains a concern] Pros @@ -121,7 +123,7 @@ developers. //Conclusion //---------- -//conclusion: When approbated (this proposal becomes a Final) +//conclusion: When approvedd (this proposal becomes a Final) // write some conclusions about its process: diff --git a/doc/devel/rfc/DevelopmentFramework.txt b/doc/devel/rfc/DevelopmentFramework.txt index 76a03255f..34c53cf8f 100644 --- a/doc/devel/rfc/DevelopmentFramework.txt +++ b/doc/devel/rfc/DevelopmentFramework.txt @@ -1,12 +1,12 @@ Design Process : Development Framework ====================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-08_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-08_ +|*Proposed by* | ct +|==================================== @@ -22,11 +22,11 @@ needed/required for working on lumiera. Description ~~~~~~~~~~~ .Tools required: -* unix like shell environment with standard tools +* Unix like shell environment with standard tools * we don't require a specific linux distribution -* git 1.5.3 (not out yet, but really soon, we want submodules support) -* GNU toolchain, autoconf/automake (maybe scons or something else?) -* bouml (version case unresolved) +* Git 1.5.3 (not out yet, but really soon, we want submodules support) +* GNU toolchain, autoconf/automake (maybe SCons or something else?) +* Bouml (version case unresolved) .Tools suggested: * doxygen @@ -36,45 +36,44 @@ Description Tasks ^^^^^ -* cehteh will setup a initial repository (see link:RepositorySetup[proposed - structure]) -* ichthyo has setup a debian-APT-depot at http://deb/ichthyostega.de[] and will +* cehteh will setup a initial repository + (see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure]) +* ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will add backport packages there if necessary so the debian-people can stay near Etch/stable in the next time * ichthyo volunteers to get the new source into a debian package structure from start (same as the current cinelerra is) .And for later: -* decide on a Unit Test framework (see link:UnitTests_Python[this Proposal]) +* decide on a Unit Test framework + (see -> link:rfc/UnitTestsPython.html[RfC Unit-Tests]) * can we get some continuous integration running somewhere (nightly builds, testsuite)? * find a viable toolchain for writing more formal documentation. - link:ReStructured[] Text, Docbook etc? + ReStructured Text, Docbook etc? -Pros -^^^^ Cons ^^^^ -* the GIT submodules are just not there atm. we need to come along with one +* Git submodules are just not usable yet; we need to come along with one monolitic large project until they are available. Alternatives ^^^^^^^^^^^^ -* use visual studio and .NET :P +* use visual studio and .NET [big]#😇# Rationale ~~~~~~~~~ -The project will be tied to a distributed infrastructure/git. With recent git -submodules support it should be easy to let contributors only checkpout/work on +The project will be tied to a distributed infrastructure based on Git. With recent +Git submodules support it should be easy to let contributors only checkpout/work on parts of the tree (plugins, documentation, i18n, ...). We want to build up a -set of maintenance scripts in a ./admin dir. +set of maintenance scripts in an `./admin` directory. At the moment we go for rather bleeding edge tools, because we want to stay at a given version to avoid incompatibility problems. Later on a version switch @@ -91,12 +90,13 @@ scripting up and running very early in a project. I would like if the project would take a rather conservative approach on the required Libs and Tools, so that finally, when we get into a beta state, we can run/compile on the major distros without too much pain. I wouldn't completely abandon the idea to target -\*bsd and osx as well later on. +*bsd and osX as well later on. -I would propose to move Doxygen to "required". The Idea to use scons sounds -quite appealing to me at the moment. Besides that, I think it could be moved to -"Draft". - -- link:Ichthyostega[] [[DateTime(2007-06-17T00:18:40Z)]] +I would propose to move Doxygen to ``required''. The Idea to use SCons sounds +quite appealing to me at the moment. Besides that, I think this RfC could be +moved to ``Draft''. + +Ichthyostega:: '2007-06-17T00:18:40Z' Moved to Draft. For Developer documentation I would prefer doxygen. For user documentation we can make a similar/same think like nicolasm did for @@ -106,26 +106,32 @@ current cin2 docs, i say its rather well done. We need to factor out some of the proposals from this page to subpages (scons, documentation, testing,...) - -- link:ct[] [[DateTime(2007-06-17T17:27:59Z)]] -It would really suck if we have to go through the experiences described -http://freshmeat.net/articles/view/889/[here]. I have experienced parts of that +ct:: '2007-06-17T17:27:59Z' + +It would really suck if we have to go through the experiences described in the article +https://web.archive.org/web/20060427005516/http://freshmeat.net/articles/view/889/[»Stop the autoconf insanity!«]. +I have experienced parts of that in the past. I have only some beginner experience with writing autotoolized projects (mostly based on trial-and-error) and no experience in any other build system (such as scons). As such, I still believe that autotools can be manageable (for me personally) once the initial hurdle of learning is overcome. I all for Doxygen documentation. Related to documentation are -http://www.splint.org/[splint] -http://www.splint.org/manual/html/appC.html[annotations] (comments). I suggest -that we consider using such a tool for QA. Like link:ct[] said, this should be +http://splint.org/[Splint: Annotation-Assisted Lightweight Static Checking]. +See also http://splint.org/manual/html/appC.html[descriptions of annotations (in comments)]. +I suggest +that we consider using such a tool for QA. Like ct said, this should be discussed in a subpage. I agree with using currently bleeding-edge tools. + * _historic remark(Ichthyo):_ who wrote that comment? (neither me nor ct) -We have now a \'compatibility wiki\', finalized this proposal - -- link:ct[] [[DateTime(2008-03-26T13:43:26Z)]] + +We have now a ``compatibility wiki'', finalized this proposal + +ct:: '2008-03-26T13:43:26Z' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DistributedDevelopmentFramework.txt b/doc/devel/rfc/DistributedDevelopmentFramework.txt index 926dc1549..eabc5dee9 100644 --- a/doc/devel/rfc/DistributedDevelopmentFramework.txt +++ b/doc/devel/rfc/DistributedDevelopmentFramework.txt @@ -1,12 +1,12 @@ Design Process : Distributed Development Framework ================================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-07_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-07_ +|*Proposed by* | ct +|==================================== Distributed Development Framework @@ -29,20 +29,6 @@ Tasks * Serveral (shell?) scripts which ease the use -Pros -~~~~ - - - -Cons -~~~~ - - - -Alternatives -~~~~~~~~~~~~ - - Rationale ~~~~~~~~~ @@ -57,9 +43,27 @@ Rationale Comments -------- -Made this 'final', this proposal got accepted and is already in use without +Made this `final', this proposal got accepted and is already in use without much discussion - -- link:ct[] [[DateTime(2007-06-27T16:07:13Z)]] +ct:: '2007-06-27T16:07:13Z' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +[underline]#Historical remark#: Not sure what this RfC was meant to propose; + +During the next year, an ambitious side-project named »*uwiki*« was started, +with the goal to provide a wiki-like web frontend based on completely self-contained +storage in a Git repository, without requiring any kind of data base. This project, +however -- in spite of some compelling prototype implementations -- was abandoned; +it became clear that such a system can not be bootstrapped from a lightweight, +minimalist setup and would require a significant amount of web development +rather -- a task no one was willing to take on. + +Yet the Lumiera project succeeded in building a web presence based on +https://asciidoc-py.github.io/[Asciidoc] sources checked into Git, with a lightweight +commit-hook script to automatically publish any changes on git-push -- a scheme +which comes close to the gist of this RfC. + +Ichthyo:: '2025-09-08' + +'''' + +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/EDLsAreMetaClips.txt b/doc/devel/rfc/EDLsAreMetaClips.txt index 3c58a3b29..990182b7a 100644 --- a/doc/devel/rfc/EDLsAreMetaClips.txt +++ b/doc/devel/rfc/EDLsAreMetaClips.txt @@ -1,18 +1,18 @@ EDL's Are Meta-Clips ==================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-07-15_ -*Proposed by* link:PercivalTiglao[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-07-15_ +|*Proposed by* | PercivalTiglao +|==================================== EDLs Are Meta-Clips ------------------- -One very useful property of EDLs is the ability to contain other EDLs and treat -these "inner" EDLs as a unit. The most logical implementation of this is to -have EDLs themselves be able to be treated as an Clip-MObject. Recursion is +One very useful property of EDLs is the ability to contain other EDLs and to +__treat these ``inner'' EDLs as an unit__. The most logical implementation of this +is to have EDLs themselves be able to be treated as an Clip-MObject. Recursion is known to be a powerful feature that is relatively simple to understand. By making EDLs recursive, some higher level features can be more easily implemented by taking advantage of this fact. @@ -39,14 +39,13 @@ being forced to render the file to disk first. The usability benefits are obvious. -In all examples, rendering the main EDL implies that all of the "inner EDLs" +In all examples, rendering the main EDL implies that all of the ``inner EDLs'' have to be re-rendered if the inner EDL was modified. That is one of the only requirements. Tasks -~~~~~ - +^^^^^ * Consider usability issues from the current Cinelerra userbase. * Have the EDL Object (or create a proxy class) that extends MObject, Clip, AbstractMO, or some other class that would create this kind of behaviour. @@ -54,21 +53,19 @@ Tasks File2 contains File1. This might produce infinite recursion while attempting to render the EDL. * Implement higher level features in the GUI. - * Create "Compound Tracks" which contain multiple tracks within them. + * Create ``Compound Tracks'' which contain multiple tracks within them. * Create a GUI that can handle multiple open EDLs at the same time. Pros -~~~~ - - * A low level feature that would greatly ease the creation of high level - features. +^^^^ + * A low level feature that would greatly ease the creation of high level features. * Multiple applications. * Eases the use and maintenance of Stock Footage. Cons -~~~~ +^^^^ * Possibly would have to rewrite a lot of code at the Engine level?? * Caching / Efficiency issues arise. - Handling multiple instances of Lumiera running might be difficult. E.g. @@ -77,53 +74,57 @@ Cons - Or maybe even multiple instances of Lumiera across computers that are connected to the same Drive. File1 is opened in Computer1 and File2 is opened in Computer2. - * A corrupted "inner EDL" or Stock Footage would "poison" the whole project. + * A corrupted ``inner EDL'' or Stock Footage would ``poison'' the whole project. Alternatives ~~~~~~~~~~~~ - * Pre-Rendering Clips - - Unlike the current proposal, you would be unable to reedit sock footage on - the mass scale and reapply it to the whole project. + - Unlike the current proposal, you would be unable to re-edit sock footage on + the mass scale and re-apply it to the whole project. - Moreover, rendering either introduces a generation loss or requires huge storage for raw (uncompressed) video. * Loading the resources of the EDL -- This is an alternative way to load EDLs. This should also be supported. It would be an expected feature from the old - Cinelerra2 userbase. + Cinelerra-2 user base. Comments -------- -* I got the inspiration of this idea from an email discussion between Rick777 - discussing the Saya Video Editor. -- link:PercivalTiglao[] - [[DateTime(2008-07-17T13:34:08Z)]] -* Hi Percival, thanks for writing this proposal. This is indeed a feature which - was much discussed in the last months and I consider it to be included almost - for sure. We always used the term '''meta-clip''' for this feature, thus I - edited the headline (I hope you don't mind). -* Regarding the implementation, I choose a slightly different approach for the - ``proc layer'' (actually, it's not yet there, but planned right from start, as I - consider this meta-clip feature to be of uttermost importance): I'd prefer to - add it at the level of the media source which is used by a clip. The - rationale is, that at the level of the clip, there is no (or almost no) - different behaviour if a clip pulls from a media file, from an life input or - from another EDL. Thus, the implementation would be for a meta-clip to use a - special media asset, which represents the output of the other EDL. -* Basically, the implementation is quite simple and doesn't necessiate much - additional code (the power of recursion at work!). Further, I don't see any - caching or efficiency problems. As you already pointed out, there are two - fundamental problems - - We need a cycle detector when building the low-level model. ''But'' we +I got the inspiration of this idea from an email discussion with _Rick777_ +discussing the Saya Video Editor. + +PercivalTiglao:: '2008-07-17T13:34:08Z' + +Hi Percival, thanks for writing this proposal. This is indeed a feature which +was much discussed in the last months and I consider it to be included almost +for sure. We always used the term *meta-clip* for this feature, thus I +edited the headline (I hope you don't mind). + +Regarding the implementation, I choose a slightly different approach for the +``proc layer'' (actually, it's not yet there, but planned right from start, as I +consider this meta-clip feature to be of uttermost importance): I'd prefer to +add it at the level of the media source which is used by a clip. The +rationale is, that at the level of the clip, there is no (or almost no) +different behaviour if a clip pulls from a media file, from an life input or +from another EDL. Thus, the implementation would be for a meta-clip to use a +special media asset, which represents the output of the other EDL. + +Basically, the implementation is quite simple and doesn't necessitate much +additional code (the power of recursion at work!). Further, I don't see any +caching or efficiency problems. As you already pointed out, there are two +fundamental problems + + - We need a cycle detector when building the low-level model. _But_ we don't need it solely because of meta-clips, we also need such a facility the moment we allow relatively free wiring of input-output connections (which we do plan anyway). My proposal is to flag the respective MObjects as erroneous, which should be visualized accordingly in the GUI - - We need a thouroughly complete handling for multichannel video and audio + - We need a thoroughly complete handling for multichannel video and audio throughout the whole application. We need to get rid of the distinction - into "video" and "audio" tracks. ''But'' again, this is not due to + into »video« and »audio« tracks. _But_ again, this is not due to meta-clips solely, we should do so anyway because of multichannel spatial audio, 3D video and other advanced media to come. Thus, when every media is multichannel by default, and the builder can sort and handle connections @@ -131,11 +132,13 @@ Comments to do right from start), putting a meta-clip which pulls output from N channels with various mixed stream types from another EDL is not really a problem. -* The other "cons" listed above actually aren't directly connected or due to - the existence of meta-clips, thus I wouldn't list them here. - - yes, it ''is'' true, concurrent changes to the session files may screw up - things. But is this really an issue the Lumiera App should handle at all?? - - yes, ''any corrupted part'' of the serialized session can mess up things. + +The other »cons« listed above actually aren't directly connected or due to +the existence of meta-clips, thus I wouldn't list them here. + + - yes, it _is_ true, concurrent changes to the session files may screw up things. + But is this really an issue the Lumiera App should handle at all? + - yes, _any corrupted part_ of the serialized session can mess up things. This is a real threat (see Cinelerra), but not limited to meta-clips. It is especially important, as you can expect users to work for months or years with a single session. Thus the integrity of the session is a value to be @@ -143,24 +146,53 @@ Comments layer that all important objects can only be created or re-created by some specialized factory, which in turn has the responsibility of never creating a corrupted object. - -- link:Ichthyostega[] [[DateTime(2008-07-27T22:15:01Z)]] -* I'll think about closures around seralized artefacts, the serialized stream - can then be validated, unsupported or corrupted parts can be tagged as - erroneous (means they become virtually readonly but they must be preserved) - and circumvented. A lot of details have to be worked out here, iirc ichthyo - already planned support for 'erroneous' nodes in the datamodell. I also think - about some debugable plaintext dump format (maybe XML) then real corrupt - things can be fixed manually with some efforts. Otherwise we handle gigabytes - of video data and our most valuable resource is the few MB sized session - file. I really aim to make that as robust as possible. Adding backups and - redundancy there wont hurt. - -- link:ct[] [[DateTime(2008-07-30T16:03:04Z)]] + +Ichthyostega:: '2008-07-27T22:15:01Z' + +I'll think about closures around seralized artifacts, the serialized stream +can then be validated, unsupported or corrupted parts can be tagged as +erroneous (means they become virtually readonly but they must be preserved) +and circumvented. A lot of details have to be worked out here, iirc ichthyo +already planned support for `erroneous' nodes in the data model. I also think +about some debuggable plaintext dump format (maybe XML) then real corrupt +things can be fixed manually with some efforts. Otherwise we handle gigabytes +of video data and our most valuable resource is the few MB sized session +file. I really aim to make that as robust as possible. Adding backups and +redundancy there wont hurt. + +ct:: '2008-07-30T16:03:04Z' Conclusion ---------- -This Design Entry concerns whether to include such a feature and discusses the -general questions when doing so. As we for sure include meta-clip, and so so -exactly in the way described here, this proposal is 'final' now. +This Design Entry deals with the question whether to include such a feature and +it discusses the general questions when doing so. Since we are determined to +include this kind of _meta-clip_ anyway, and will most likely do in a way +similar as described here, this can be considered __`final'__. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +This conclusion was drawn at the +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_edls_as_meta_clips[October.2008 developer meeting]. + +'''' + +[TIP] +=========== +Terminology is somewhat in flux regarding this topic: + +- »EDL« is a technical term from the Cinelerra-2 code base. The acronym actually + stands for **E**dit **D**ecision **L**ist, which is a term from traditional + film making and production organisation -- and does not really map properly + into the usage possible with digital technology. For that reason, the Lumiera + project _dropped_ this notion subsequently. +- close to the ideas presented in this text is the concept of a ``Sequence'', + which in Lumiera designates a ``Fork'' (tree of tracks) with an arrangement + of clips attached. +- as of 2025, we typically use the following terminology: + + ** a _Virtual Clip_ is how such a nested structure is integrated + ** such a clip in turn uses a _Virtual Medium_ + ** which is based on the _Binding_ of a _Nested Sequence_ +=========== + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/EngineInterfaceOverview.txt b/doc/devel/rfc/EngineInterfaceOverview.txt index bc4e190fe..8003acd8c 100644 --- a/doc/devel/rfc/EngineInterfaceOverview.txt +++ b/doc/devel/rfc/EngineInterfaceOverview.txt @@ -4,12 +4,12 @@ Engine Interface Overview // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _2010-04-16_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _2010-04-16_ +|*Proposed by* | Ichthyostega +|==================================== Overview Engine Interface(s) @@ -42,7 +42,7 @@ Render Process The render process brackets an ongoing calculation as a whole. It is not to be confused with a operating system process or thread; rather it is a point of reference for the relevant entities in the Stage and Steam-Layer in need to -connect to such a "rendering", and it holds the specific definitions for this +connect to such a ``rendering'', and it holds the specific definitions for this calculation series. A render process _corresponds to a single data stream_ to be rendered. Thus, when the play controller of some timeline in the model is @@ -51,7 +51,7 @@ processes exist. * there is an displayer- or output slot, which got allocated on creation of the process -* the process disposes calculated data frames "into" this slot +* the process disposes calculated data frames _into this slot_ * the process can be paused/started and stopped (aborted, halted). * some processes allow for changing parameters dynamically (e.g. speed, direction) @@ -60,7 +60,7 @@ processes exist. .Process parameters A process is linked to a single stream data format (a -> -link:StreamTypeSystem.html[stream implementation type]). + +link:{rfc}/StreamTypeSystem.html[stream implementation type]). + It is configured with _frame quantisation_ and _timings_, and a _model port_ identifier and _channel selector_. @@ -246,7 +246,7 @@ Rationale //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -261,11 +261,33 @@ Requirements and details of the design are sufficiently clear meanwhile. Ther seems to be not much room for alternative approaches, given our general planning for the application - Mi 11 Mai 2011 19:27:12 CEST Ichthyostega +Ichthyostega:: 'Wed 11 Mai 2011 19:27:12 CEST' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +[underline]#Historical remark#: In hindsight, it seems I did post that RfC +(and the corresponding link:{rfc}/EngineInterfaceSpec.html[Specification RfC]) not so much +to ask for input and further ideas, rather as a _call for help_. Last year (2024), I had +to revisit the code written in 2010/11, and it looks like I was struggling desperately at +that time to thread a pathway into a void. During the early stages of the project, _Cehteh_ +and myself had agreed to place the boundary between ``Proc'' and ``Backend'' (today designated +as Steam and Vault) at the entrance to the link:/x/Scheduler.html[Scheduler] -- but there was +no scheduler yet, not even a design draft at that time, and the scope of what it was assumed to do +seemed to be ``vanishing'': basically ``the Backend'' wanted a pool of lightweight, stateless, +unconnected requests, which could be treated as a problem of the ``embarrassingly parallel'' +kind (to use computer science parlance). So nothing to serve as an anchor or point of reference +for finding a pathway. + +This RfC is a summary of design work already completed, asking for validation. I could +not see if this path would lead to anywhere at that time -- and subsequently abandoned that +topic in half-finished state. Currently (since 2024) I am picking up that work and it seems +to be durable. However -- it might be worth mentioning that this RfC indeed spurred an +link:{ldoc}/devel/meeting_summary/2011-05-11.html#scheduler[extended technical discussion] +at the May-2011 developer meeting, maybe the last of this kind of inspiring exchanges +on equal terms. + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/EngineInterfaceSpec.txt b/doc/devel/rfc/EngineInterfaceSpec.txt index 2b4be964e..fad4c3041 100644 --- a/doc/devel/rfc/EngineInterfaceSpec.txt +++ b/doc/devel/rfc/EngineInterfaceSpec.txt @@ -3,12 +3,12 @@ Engine Interface Spec // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Mi 11 Mai 2011 17:53:16 CEST_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Mi 11 Mai 2011 17:53:16 CEST_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ******************************************************************************** @@ -54,7 +54,7 @@ Requirements Specification Functionality description in detail ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> see the link:EngineInterfaceOverview.html[Engine/Interface overview] for +-> see the link:{rfc}/EngineInterfaceOverview.html[Engine/Interface overview] for a description of the involved entities and for definitions for common terms. Definitions @@ -173,8 +173,8 @@ Tasks Discussion ~~~~~~~~~~ -Pros -^^^^ +//Pros +//^^^^ // add a fact list/enumeration which make this suitable: // * foo // * bar ... @@ -188,8 +188,8 @@ The requirements placed on life changes are quite high -Alternatives -^^^^^^^^^^^^ +//Alternatives +//^^^^^^^^^^^^ //alternatives: explain alternatives and tell why they are not viable: @@ -206,7 +206,7 @@ and break it down into tangible functionality on the implementation level. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -216,7 +216,9 @@ Comments -------- //comments: append below -Discussed in the May developers meeting. Seems to be basically acceptable. +Discussed in the +link:{ldoc}/devel/meeting_summary/2011-05-11.html#irctranscript[May.2011 developers meeting]. +Seems to be basically acceptable. _Cehteh_ proposed some small adjustments: - making the _QualityOfService_ rather a strategy to be queried @@ -225,10 +227,11 @@ _Cehteh_ proposed some small adjustments: - introducing a separate scheduler/queue for time scheduled tasks, like with rater soft realtime requirements - So 15 Mai 2011 00:55:24 CEST Ichthyostega +Ichthyostega:: 'Sun 15 Mai 2011 00:55:24 CEST' ~~ +TIP: see also the related link:{rfc}/EngineInterfaceOverview.html#_comments[overview RfC] //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/FeatureBundle_PluggableModules.txt b/doc/devel/rfc/FeatureBundle_PluggableModules.txt index 39958ca0d..947370c3d 100644 --- a/doc/devel/rfc/FeatureBundle_PluggableModules.txt +++ b/doc/devel/rfc/FeatureBundle_PluggableModules.txt @@ -1,20 +1,20 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-09-03_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-09-03_ +|*Proposed by* | Ichthyostega +|==================================== -Describe pluggable modules by a "Feature Bundle" +Describe pluggable modules by a »Feature Bundle« ------------------------------------------------ -This proposal builds upon Cehteh's Plugin Loader, which is the fundamental +This proposal builds upon _Cehteh_'s Plugin Loader, which is the fundamental mechanism for integrating variable parts into the application. It targets the special situation when several layers have to cooperate in order to provide some pluggable functionality. The most prominent example are the -"effects plugins" visible for the user. Because, in order to provide such an +``effect plugins'' visible for the user. Because, in order to provide such an effect * the engine needs a processing function @@ -38,8 +38,10 @@ base. Each extension point can be addressed by a fixed textual ID, e.g. Now, to provide a pluggable extension for such an Extension Point, we use a *Feature Bundle* Such a Feature Bundle is comprised of - * a Deployment Descriptor (provided as "structured data" -- TODO: define the - actual data format) + * a Deployment Descriptor (provided as ``structured data'' -- + + + ^[red]#TODO#: define the actual data format)^ + * the corresponding resources mentioned by this Deployment Descriptor The Deployment Descriptor contains @@ -77,7 +79,7 @@ We do _not_ provide a meta-language for defining requirements of an Extension Point, rather, each extension point has hard wired requirements for a Feature Bundle targeted at this extension point. There is an API which allows code within lumiera to access the data found in the Feature Bundle's Deployment -Descriptor. Using this API, the code operating and utilizing the Extension +Descriptor. Using this API, the code operating and utilising the Extension Point has to check if a given feature bundle is usable. It is assumed that these Feature Bundles are created / maintained by a third @@ -85,7 +87,7 @@ party, which we call a *Packager*. This packager may use other resources from different sources and assemble them as a Feature Bundle loadable by Lumiera. Of course, Lumiera will come with some basic Feature Bundles (e.g. for colour correction, sound panning,....) which are maintained by the core dev team. -(please don't confuse the "packager" mentioned here with the packager creating +(please don't confuse the ``packager'' mentioned here with the packager creating RPMs or DEBs or tarballs for installation in a specific distro). Additionally, we may allow for the auto-generation of Feature Bundles for some simple cases, if feasible (e.g. for LADSPA plugins). @@ -97,16 +99,16 @@ In most cases, the resources referred by a Feature Bundle will be Lumiera Plugins. Which means, there is an Interface (with version number), which can be used by the code within lumiera for accessing the functionality. Besides, we allow for a number of further plugin architectures which can be loaded by -specialized loader code found in the core application. E.g. Lumiera will +specialised loader code found in the core application. E.g. Lumiera will probably provide a LADSPA host and a GStreamer host. If such an adapter is applicable depends on the specific Extension point. -The ResourceID is the identifyer by which an Extension point tries to find +The ResourceID is the identifier by which an Extension point tries to find required resources. For example, the Extension Point "Effect" will try to find an ResourceID called "ProcFunction". There may be several Entries for the same ResourceID, but with distinct SubID. This can be used to provide several implementations for different platforms. It is up to the individual Extension -Pont to impose additional semantic requirements to this SubID datafield. (Which +Point to impose additional semantic requirements to this SubID data field. (Which means: define it as we go). Similarly, it is up to the code driving the individual Extension point to define when a Feature Bundle is fully usable, partially usable or to be rejected. For example, an @@ -117,32 +119,19 @@ can't access the properties describing the media stream type this effect is supposed to handle. Besides binary plugins, other types of resources include: + * a set of properties (key/value pairs) * a script, which is executed by the core code using the Extension Point and - which in turn may access certain interfaces provided by the core for "doing - things" + which in turn may access certain interfaces provided by the core for + ``doing things'' Probably there will be some discovery mechanism for finding (new) Feature Bundles similar to what we are planning for the bare plugins. It would be a good idea to store the metadata of Feature Bundles in the same manner as we plan to store the metadata of bare plugins in a plugin registry. - - - -Tasks -^^^^^ - - -Pros -^^^^ - - - -Cons -^^^^ - - +Discussion +~~~~~~~~~~ Alternatives ^^^^^^^^^^^^ @@ -156,7 +145,7 @@ The purpose of this framework is to decouple the core application code from the details of accessing external functionality, while providing a clean implementation with a basic set of sanity checks. Moreover, it allows us to create an unique internal description for each loaded module, and this -description data e.g. is what is stored as an "Asset" into the user session. +description data e.g. is what is stored as an _Asset_ into the user session. Today it is well understood what is necessary to make a real component architecture work. This design proposal deliberately avoids to create a @@ -179,17 +168,19 @@ Comments From a fast reading, I like this, some things might get refined. For example I'd strongly suggest to make the Deployment Descriptor itself an Interface which is offered by a plugin, all data will then be queried by functions on -this interface, not by some 'dataformat'. Also Resource ID's and a lot other -metadata can be boiled down to interfaces: names, versions, uuid of these -instead reiventing another system for storing metadata. My Idea is to make the -link:Plugin/Interface[] system self-describing this will also be used to +this interface, not by some ``dataformat''. Also Resource ID's and a lot other +metadata can be boiled down to interfaces: names, versions, UUID of these +instead reinventing another system for storing metadata. My Idea is to make the +Plugin/Interface system self-describing this will also be used to bootstrap a session on itself (by the serializer which is tightly integrated) - -- link:ct[] [[DateTime(2008-09-04T09:28:37Z)]] 2008-09-04 09:28:37 + +ct:: '2008-09-04T09:28:37Z' Parked ~~~~~~ Needs to ne reviewed some time later. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GitCommitMessageFormat.txt b/doc/devel/rfc/GitCommitMessageFormat.txt index 1d8de328b..9da865ffd 100644 --- a/doc/devel/rfc/GitCommitMessageFormat.txt +++ b/doc/devel/rfc/GitCommitMessageFormat.txt @@ -3,12 +3,12 @@ Git Commit Message Format // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Fr 31 Aug 2012 03:54:14 CEST_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Fr 31 Aug 2012 03:54:14 CEST_ +|*Proposed by* | Christian Thaeter +|==================================== ******************************************************************************** .Abstract @@ -156,7 +156,7 @@ confuse the toolchain (builddrone) but this failures shall not be critical. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -177,4 +177,4 @@ Christian Thaeter:: 'Do 13 Sep 2012 03:57:23 CEST' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GitSubmoduleTransistion.txt b/doc/devel/rfc/GitSubmoduleTransistion.txt index fdbcd69db..a2645b13c 100644 --- a/doc/devel/rfc/GitSubmoduleTransistion.txt +++ b/doc/devel/rfc/GitSubmoduleTransistion.txt @@ -1,9 +1,9 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-04-09_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-04-09_ +|*Proposed by* | ct +|==================================== Use Git Submodules to organize the project @@ -14,33 +14,34 @@ work out the details and define a turnover point in time. Description ~~~~~~~~~~~ -There is a git-filter-branch command which helps in doing the dirty work +There is a `git-filter-branch` command which helps in doing the dirty work isolating commits which touch certain dirs. This can moderately easily be used to create a new repository with a rewritten history containing only sub parts of the original history. The basic idea is that one developer who wants to works on a certain subsystem -clones the 'official' master and then updates and tracks only the development +clones the ``official'' master and then updates and tracks only the development state of a certain subsystem. Tasks ^^^^^ * what shall be in the master repository? - * boilerplate files, license, build infrastructure - * the _admin_ dir with supplemental scripts + ** boilerplate files, license, build infrastructure + ** the _admin_ dir with supplemental scripts * define which submodules shall be defined? - * _doc/devel_ - * _doc/user_ - * _wiki_ - * _uml_ - * _src/backend_ - * _src/proc_ - * _src/gui_ - * _src/lib_ + ** _doc/devel_ + ** _doc/user_ + ** _wiki_ + ** _uml_ + ** _src/backend_ + ** _src/proc_ + ** _src/gui_ + ** _src/lib_ Not yet decided: - * _tests_ move them into the _src/$subsystem_ as symlink? + + * _tests_ move them into the `"src/$subsystem"` as symlink? * _src/tool_ @@ -82,6 +83,8 @@ Comments We concluded that that submodules are not yet needed with exception for the ./doc folder. Parked for now. - -- ct 2008-07-26 09:09:57 -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-07-26 09:09:57' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GlobalInitialization.txt b/doc/devel/rfc/GlobalInitialization.txt index 5e5d6a71d..24359c7c8 100644 --- a/doc/devel/rfc/GlobalInitialization.txt +++ b/doc/devel/rfc/GlobalInitialization.txt @@ -3,12 +3,12 @@ GlobalInitialization // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-04-05_ -*Proposed by* CT -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-04-05_ +|*Proposed by* | CT +|==================================== ******************************************************************************** .Abstract @@ -21,7 +21,7 @@ Description Setup a `src/common/lumiera_init.c` file which contains following functions: * `int lumiera_init(s.b.)` initializes the subsystems, global registries, - link:NoBug[] and other things. Must be called once at startup. + NoBug and other things. Must be called once at startup. * `void lumiera_destroy(void)` shuts down, frees resources, cleans up. Calling 'lumiera_init()' twice or more should be a fatal abort, calling @@ -39,7 +39,9 @@ Tasks // * first step ([green]#✔ done#) // * second step [yellow-background]#WIP# // * third step [red yellow-background]#TBD# -Implement this. [red yellow-background]#it was never implemented this way# +Implement this. + +WARNING: [red yellow-background]#it was never implemented this way# Discussion @@ -90,7 +92,7 @@ order and makes debugging easier since it is a serial, well defined sequence. Conclusion ---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: _This RfC was the plan_. We agreed on it, and then we forgot about it. @@ -104,7 +106,8 @@ scheme: - by policy, clean-up and unwinding is always considered _optional_ -- but we care to implement a complete shutdown and memory unwinding for sake of sanity. -This RfC is marked as *dropped*, since it doesn't reflect what the implementation does. + +This RfC is marked as *dropped*, since it doesn't reflect what the implementation does. + Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~~ @@ -130,7 +133,8 @@ there too, so it gets issued automatically. loading of a existing session will bring the proc layer up into fully operational state + Ichthyo:: 'DateTime(2008-04-09T02:13:02Z' -* About link:NoBug[] initialization: I've seen that you made a `nobugcfg` where + +* About NoBug initialization: I've seen that you made a `nobugcfg` where you centralized all nobug setup. Problem here is that a change in that file forces a whole application rebuild. I'd like to factor that out that each subsystem and subsubsystem does its own `NOBUG_FLAG_INIT()` initializations, @@ -158,7 +162,7 @@ Backend tests then only call `lumiera_backend_init()` and don't need to do the whole initialization, same could be done for `lumiera_proc_init()` and `lumiera_gui_init()`. Note about the library: I think the lib shall not depend on such an init, but I would add one if really needed. -+ + CT:: '2008-04-09T19:19:17Z' @@ -171,7 +175,7 @@ After reconsidering I think we have several different problems intermixed here. usage pattern of the flags (btw. the idea of making a flag hierarchy is very good!) will be much different in the backend, the proc layer and the gui. - Initialisation of the very basic services is tricky, as always. Seemingly - this includes link:NoBug[]. Of course one wants to use assertions and some + this includes NoBug. Of course one wants to use assertions and some diagnostics logging already in constructor code, and, sadly enough it can't be avoided completely to run such already in the static initialisation phase before entering main(). My current solution (putting `NOBUG_INIT` it in the @@ -180,7 +184,7 @@ After reconsidering I think we have several different problems intermixed here. - Then there is the initialisation of common services. For these, it's just fine to do a dedicated call from main (e.g. to init the backend services and for creating the basic empty session for proc and firing off the event loop - for the GUI). I think it's no problem to ''disallow'' any IO, any accessing + for the GUI). I think it's no problem to __disallow any IO,__ any accessing of services in the other layers prior to this point. - What is with shutdown? personally, I'd like to call a explicit shutdown hook at the end of main and to disallow any IO and usage of services outside each @@ -188,7 +192,7 @@ After reconsidering I think we have several different problems intermixed here. to require every destructor to be called and everything to be deallocated, meaning that quite a lot of code is running after the end of main() -- most of which is library generated. + - Ichthyo:: '2008-04-12T04:56:49Z + Ichthyo:: '2008-04-12T04:56:49Z' Some comments... @@ -202,7 +206,7 @@ Some comments... - What is with shutdown?... * Mostly agreed, I suggest to make all initialization code once-only, a - second call shall bail out (under link:NoBug[]), all shutdown code shall be + second call shall bail out (under NoBug), all shutdown code shall be callable multiple times where subsequent calls are no-ops, this allows us to register at least some things in atexit() handlers, while we should add an explicit clean shutdown too, whenever that (or the atexit) handlers get @@ -219,7 +223,7 @@ OK. So now I've done the following: - Moved lumiera.h and nobugcfg.h to proc/lumiera.hpp and nobugcfg.hpp (i.e. consider them now as Proc-Layer only) - Changed Appconfig to support simple lifecycle hooks, especially a - `ON_BASIC_INIT`. Rationale is that I don't have a lot of "magic" code in the + `ON_BASIC_INIT`. Rationale is that I do not have a lot of ``magic'' code in the Appconfig ctor, rather each subsystem in need of a basic initialisation can install a small callback. It can do so for other lifecycle events too. - Added the usual magic static ctor to install those callbacks in case they @@ -233,7 +237,7 @@ OK. So now I've done the following: for the backend there too, either directly or by registering an callback, just as it fits in better. - This system is extensible: for example I plan to let the - link:SessionManager[] issue `ON_SESSION_INIT` and `ON_SESSION_CLOSE` events. + SessionManager issue `ON_SESSION_INIT` and `ON_SESSION_CLOSE` events. E.g. AssetManager could now just install his callbacks to clean up the internal Asset registry + Ichthyo:: '2008-04-14T03:40:54Z' @@ -243,8 +247,8 @@ absolutely necessary (like flushing the session file, closing display and network connections, writing a backup or committing to a database). I see no problem with bypassing the standard dtor calls in a release build (they add no value besides diagnostics and even may cause a lot of pages to be swapped -in). We could even make this a policy ("don't rely on destructors or -automatic shutdown code to do any cleanup of permanent importance") +in). We could even make this a policy (``don't rely on destructors or +automatic shutdown code to do any cleanup of permanent importance'') .State -> Final I made this final now, details are still in progress to be worked out, but we @@ -255,7 +259,7 @@ CT:: '2008-07-26T09:08:11Z' .State -> Dropped //add reason -Years later, I'm just stumbling accross this RfC, and it looks somewhat +Years later, I'm just stumbling across this RfC, and it looks somewhat outdated and ``misaligned'' IMHO. * this RfC proposes only one tiny and lightweight feature. @@ -267,16 +271,16 @@ outdated and ``misaligned'' IMHO. did take: today, Lumiera does the _exact opposite_ of this proposal, there is *no central init call* -- we use *modularised hooks* instead and each subsystem is self contained. We even have a subsystem manager - to handle dependencies in startup and shtudown. + to handle dependencies in startup and shutdown. For this reason, I mark this RfC as *dropped* now. + In case there is further need of discussion regarding this topic, we should preferably start a new RfC. - + Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/HowToProceed.txt b/doc/devel/rfc/HowToProceed.txt index 9efad43e0..16a8a2330 100644 --- a/doc/devel/rfc/HowToProceed.txt +++ b/doc/devel/rfc/HowToProceed.txt @@ -1,12 +1,12 @@ Design Process : How to proceed =============================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-16_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-16_ +|*Proposed by* | ct +|==================================== How To Proceed -------------- @@ -15,7 +15,7 @@ How we start... Description ~~~~~~~~~~~ -. Rewiew this wiki, link:DesignProcess[] .. do we want this formalism?. +. Rewiew this wiki, link:/x/DesignProcess.html[RfCs] ... do we want this formalism?. . Setup git repos. . Each developer makes a design sketch (bouml/wiki) about the subsystem he wants to care that is: @@ -25,32 +25,26 @@ Description Please add yourself above, contact people already working on something when you want to join. -Tasks -~~~~~ - -Pros -~~~~ - -Cons -~~~~ - -Alternatives -~~~~~~~~~~~~ - -Rationale -~~~~~~~~~ Comments -------- -* "Do we want this formalism": this level for formalism seems right at the - moment. It will work only if we agree on it and do it always in this way. - Every important (large scale) Issue, Question and Decision should be noted - here and we need to be sure that nothing gets lost. -* For the time being this formalism is enough. Later on, I fear, we will need a - bit more (and some Tool support) - -- link:Ichthyostega[] [[DateTime(2007-06-17T00:24:14Z)]] -* Accepted, deployed, done ... Final - -- link:ct[] [[DateTime(2007-06-27T16:13:25Z)]] +* ``Do we want this formalism'' -- it feels right at the moment. + + It will work only if we agree on it and do it always in this way. + Every important (large scale) Issue, Question and Decision should be noted + here and we need to be sure that nothing gets lost. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2007-06' + +* For the time being this degree of formalism is enough. + + Later on, I am afraid, we will need a bit more (and some Tool support)... + +Ichthyostega:: '2007-06-17T00:24:14Z' + +* Accepted, deployed, done ... Final + +ct:: '2007-06-27T16:13:25Z' + +'''' + +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/InterfaceNamespaces.txt b/doc/devel/rfc/InterfaceNamespaces.txt index 78e00b0a6..357bb75b7 100644 --- a/doc/devel/rfc/InterfaceNamespaces.txt +++ b/doc/devel/rfc/InterfaceNamespaces.txt @@ -1,12 +1,12 @@ Design Process : Interface Namespaces ===================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-09-18_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-09-18_ +|*Proposed by* | ct +|==================================== Interface Namespaces -------------------- @@ -18,17 +18,18 @@ Description What are the goals? * We need unique identifiers. - * We dont want anyone to register at us, this shall be a free system. - * There are 2 kinds, one bound to persons and one to projects as whole. - * Uniquenes, not identity is the goal, plugins could even be provided + * We do not require anyone to register with us, this shall be a free system. + * There are two kinds, one bound to persons and one to projects as whole. + * Uniqueness, not identity is the goal, plugins could even be provided anonymously. * This is the lowest level interface stuff, usually you'll deal with a high-level descriptor interface which provides much better (human readable) - metainformation about a plugin. - * The names should follow C identifier rules and either not to hard to deciper - for a human or completely abstracted into a numeric ID like gpg id or uuid - * Conclusion followed some mailinglist and IRC discussion: (see - http://lists.lumiera.org/pipermail/lumiera/2008-September/000054.html)[] + meta information about a plugin. + * The names should follow C identifier rules and either not to hard to decipher + for a human or completely abstracted into a numeric ID like GPG id or UUID + * Conclusion followed some discussion on IRC and in the + https://lists.lumiera.org/pipermail/lumiera/2008-September/000054.html[Mailinglist(2008-09)] + First part: unique prefix ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -36,7 +37,7 @@ First part: unique prefix Domain names and emails names encoding ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Domain names in lowercase, dots and special chars removed, first char must be a -aphphanumeric character (if it is numeric, just write it out): +alphanumeric character (if it is numeric, just write it out): ------------------------------------------------------------ lumiera.org -> lumieraorg @@ -47,7 +48,7 @@ aphphanumeric character (if it is numeric, just write it out): These are used when the provider is a project and not an individual person. If the provider of a interface is a individual person then he encodes his email -address in a similar way The @ sign is encoded as uppercase "AT": +address in a similar way The @ sign is encoded as uppercase `"AT"`: ------------------------------------------------------------ @@ -57,8 +58,8 @@ address in a similar way The @ sign is encoded as uppercase "AT": Abstract identifiers ^^^^^^^^^^^^^^^^^^^^ -As alternative method one can use his gpg (or pgp) key ids or full -fingerprints. These are encoded as uppercase 'PGP' or 'GPG' followed with a +As alternative method one can use his GPG (or PGP) key ids or full +fingerprints. These are encoded as uppercase `"PGP"` or `"GPG"` followed with a sequence of hex digits (both upper and lower case allowed): @@ -67,8 +68,8 @@ sequence of hex digits (both upper and lower case allowed): PGP09FF1387811ADFD4AE84310960DEA1B8AC4F4FF4 ------------------------------------------------------------ -Next completely random identifiers (uuid's) are used by prefixing them with -uppercase "UID" followed by some alphanumeric characters (no underline), no +Next completely random identifiers (UUIDs) are used by prefixing them with +uppercase `"UID"` followed by some alphanumeric characters (no underline), no encoding is specified but must conform to be a C identifier, shall give a entropy of 128 bits: @@ -76,27 +77,28 @@ entropy of 128 bits: UIDd557753400ad4ac6912773b1deb4d99d ------------------------------------------------------------ - Remarks: this are now quite a lot more or less unique encodings, notably we - could allow them all, they dont clash with each other. They would be parseable - if needed, but we never ever need to parse them, they are just taken as whole - and have no other meaning then being unique. +.Remarks +This are now quite a lot more or less unique encoding, notably we +could allow them all, they do not clash with each other. They would be parseable +if needed, but we never ever need to parse them, they are just taken as whole +and have no other meaning then being unique. -Following Parts: hierachic namespace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Lumiera itself will use some hierachic naming scheme for it interface +Following Parts: hierarchic namespace +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Lumiera itself will use some hierarchical naming scheme for it interface declarations and implementations. The details will be layed out next, -genereally thinks look like: +generally thinks look like: ------------------------------------------------------------ lumieraorg_backend_frameprovider lumieraorg_plugin_video ------------------------------------------------------------ -it is suggested that anyone providing plugins for lumiera follows this and +it is suggested that anyone providing plugins for Lumiera follows this and extends it with his own identifier: -for examle joecoder``@freevideo.org writes a ultrablur then its identifier +for example `joecoder@freevideo.org` writes a »ultrablur« then its identifier would look like: ------------------------------------------------------------ @@ -108,7 +110,7 @@ would look like: Tasks ~~~~~ -The above described scheme will be implemented and used by me (cehteh). +The above described scheme will be implemented and used by _cehteh_. @@ -117,26 +119,29 @@ Rationale ~~~~~~~~~ I believe that writing plugins for Lumiera shall be simple. We do not want some central registry or management. Anyone shall be able to just start to write -plugins. But that puts some reponsibility on the namespace so that all plugins +plugins. But that puts some responsibility on the namespace so that all plugins can coexist and their names don't clash. The above describes a very simple and -flexible nameing system which anyone can follow. It produces names which should +flexible naming system which anyone can follow. It produces names which should be sufficiently unique for practical purposes. It leaves alternatives for -providing plugins as institutuion, individual or even anonymously. +providing plugins as institution, individual or even anonymously. Conclusion ---------- -Accepted by October.2008 developer meeting +Accepted by the +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_interface_naming_convention[October.2008 developer meeting] -Addendum Internal Interfaces -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Addendum: Internal Interfaces +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interfaces which are internal and not meant for public use have 2 underscores -after the prefix (eg: `lumieraorg__`). These interfaces must not be used by +after the prefix (eg: `lumieraorg__` ). These interfaces must not be used by third party plugins, they are subject of unannounced changes or removal and make no guarantee about backwards compatibility. When we spot someone using -this interfaces we ''will break'' his plugin ''intentionally''! - -- link:ct[] [[DateTime(2008-10-24T03:43:43Z)]] +this interfaces we will *break this plugin* intentionally! -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-10-24T03:43:43Z' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/LayerNames.txt b/doc/devel/rfc/LayerNames.txt index 8e8698dd1..63a6152a4 100644 --- a/doc/devel/rfc/LayerNames.txt +++ b/doc/devel/rfc/LayerNames.txt @@ -3,12 +3,12 @@ LayerNames // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Fr 05 Oct 2018 15:05:58 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Fr 05 Oct 2018 15:05:58 CET_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract @@ -139,7 +139,7 @@ to consult anyone, since -- right now -- I am working alone on the code base. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -204,5 +204,5 @@ Ichthyostega:: '2018-11-15 19:38:32 +0100' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/LumieraDesignProcess.txt b/doc/devel/rfc/LumieraDesignProcess.txt index a19afab99..ae7313a63 100644 --- a/doc/devel/rfc/LumieraDesignProcess.txt +++ b/doc/devel/rfc/LumieraDesignProcess.txt @@ -1,12 +1,12 @@ Design Process : Lumiera Design Process ======================================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-03_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-03_ +|*Proposed by* | ct +|==================================== Define a Lumiera design process ------------------------------- @@ -17,25 +17,25 @@ Description ~~~~~~~~~~~ Just use this Wiki to make it easy to add proposals in a well defined manner. -I'd like to introduce a slightly formalized process for the ongoing Lumiera -planning: - * Every proposal is instantiated as 'Idea', the author gives other people the +I'd like to introduce a slightly formalized process for the ongoing Lumiera planning: + + * Every proposal is instantiated as `*Idea*', the author gives other people the opportunity to review and comment on it with extreme prejudice, while still working out details. - * When the the 'Idea' in a proper form and worked out in most details it - becomes a 'Draft'. This 'Draft' need to be carefully reviewed, commented, - perhaps corrected and rated by the other Developers. - * At some point we may decide that a 'Draft' becomes a 'Final' (I leave it - open how this decision shall be done for now). 'Final' Documents will be - imported into repository. + * When the the `Idea' in a proper form and worked out in most details it + becomes a `*Draft*' -- such a `Draft' need to be carefully reviewed, + commented and perhaps corrected and rated by the other Developers. + * At some point we may decide that a `Draft' becomes a `*Final*' (I leave it + open how this decision shall be done for now). `Final' RfC documents will be + imported into the Git repository. * Sometimes proposals will become dropped for some reason, this is indicated - by changing their state to 'Dropped', they still stay in the system for + by changing their state to `*Dropped*', they still stay in the system for further reference. Tasks ~~~~~ - * We need to refine the `Lumiera/DesignProcessTemplate`. + * We need to build and refine a ``Design Process Template''. Pros ~~~~ @@ -57,8 +57,10 @@ Alternatives ~~~~~~~~~~~~ * We could use some forum, Trac, Mailinglist or whatever instead. - * Just for Design documentation 0I would give http://bouml.free.fr/[Bouml] a - try. For myself, I am not very fond of UML Design tools, while Bouml looks + * Just for Design documentation I would give + https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml] a + try. + + For myself, I am not very fond of UML Design tools, while Bouml looks quite promising and we could maintain the UML model in git repositories which would be more favorable than this centralized wiki. The backside is that this needs even more agreement between the developers, everyone has to @@ -68,17 +70,16 @@ Alternatives Rationale ~~~~~~~~~ -Wiki works it is simple to use and just flexible enough to handle the task. I -don't go to install any other software for such tasks on my server. While the -design progresses I'd propose to move our work into git repositories and +Wiki already works, it is simple to use and just flexible enough to handle the task. +I won't go to install any other software for such tasks on my server. While the +design progresses I'd propose to move our work into Git repositories and eventually phase this wiki pages out anyways. I'd rather like to start out -distributed/git right away .. but git gives us only a fine storage layer, for a -design process we need some good presentation layer (later when using git and +distributed/git right away ... but git gives us only a fine storage layer, for a +design process we need some good presentation layer (later when using Git and starting the implementation everyones favorite editor serves for that) I have no better ideas yet to solve the presentation problem other than using this wiki (or maybe bouml). -Comments --------- +'''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/LumieraForwardIterator.txt b/doc/devel/rfc/LumieraForwardIterator.txt index c3fdee880..3c6c5c28f 100644 --- a/doc/devel/rfc/LumieraForwardIterator.txt +++ b/doc/devel/rfc/LumieraForwardIterator.txt @@ -1,20 +1,20 @@ -Design Process: Lumiera Forward Iterator -======================================== +Design Process: Forward Iterator +================================ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2009-11-01_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2009-11-01_ +|*Proposed by* | Ichthyostega +|==================================== -The situation focussed by this concept is when an API needs to expose a +The situation addressed by this concept is when an API needs to expose a sequence of results, values or objects, instead of just yielding a function -result value. As the naive solution of passing an pointer or array creates -coupling to internals, it was superseded by the GoF +result value. The naive solution of passing an pointer or array creates +coupling to internals, and thus was superseded by the GoF https://en.wikipedia.org/wiki/Iterator[Iterator pattern]. Iteration can be -implemented by convention, polymorphically or by generic programming; we use -the latter approach. +implemented by _convention_, _polymorphism_ or by _generic programming;_ +we use the latter approach. Lumiera Forward Iterator concept @@ -24,18 +24,18 @@ An Iterator is a self-contained token value, representing the promise to pull a sequence of data - rather then deriving from an specific interface, anything behaving - appropriately _is a Lumiera Forward Iterator._ + appropriately _can be used as Lumiera Forward Iterator._ - the client finds a typedef at a suitable, nearby location. Objects of this - type can be created, copied and compared. + iterator type can be created, copied and compared. - any Lumiera forward iterator can be in _exhausted_ (invalid) state, which - can be checked by +bool+ conversion. - - especially, default constructed iterators are fixed to that state. + can be checked by `bool` conversion. + - Notably, all default constructed iterators are fixed to that state. Non-exhausted iterators may only be obtained by API call. - - the exhausted state is final and can't be reset, meaning that any iterator + - the exhausted state is final and can not be reset, implying that any iterator is a disposable one-way-off object. - when an iterator is _not_ in the exhausted state, it may be _dereferenced_ - (+*i+), yielding the ``current'' value - - moreover, iterators may be incremented (+++i+) until exhaustion. + (`*i`) to yield the ``current value'' + - moreover, iterators may be incremented (`++i`) until exhaustion. Discussion @@ -43,26 +43,24 @@ Discussion The Lumiera Forward Iterator concept is a blend of the STL iterators and iterator concepts found in Java, C#, Python and Ruby. The chosen syntax should look familiar to C++ programmers and indeed is compatible to STL containers and -ranges. To the contrary, while a STL iterator can be thought off as being just -a disguised pointer, the semantics of Lumiera Forward Iterators is deliberately -reduced to a single, one-way-off forward iteration, they can't be reset, +ranges. However, while a STL iterator can be thought off as being actually ``just +a disguised pointer'', the semantics of Lumiera Forward Iterators is deliberately +reduced to a single, one-way-off forward iteration, they can't be reset or manipulated by any arithmetic, and the result of assigning to an dereferenced iterator is unspecified, as is the meaning of post-increment and stored copies -in general. You _should not think of an iterator as denoting a position_ -- -just a one-way off promise to yield data. +in general. You _should not think of an iterator as something to describe a position_ -- +rather it is a one-time promise to pull some data. Another notable difference to the STL iterators is the default ctor and the -+bool+ conversion. The latter allows using iterators painlessly within +for+ -and +while+ loops; a default constructed iterator is equivalent to the STL -container's +end()+ value -- indeed any _container-like_ object exposing -Lumiera Forward Iteration is encouraged to provide such an +end()+-function, -additionally enabling iteration by +std::for_each+ (or Lumiera's even more -convenient - +util::for_each()+). +`bool` conversion. The latter allows using iterators painlessly within `for` +and `while` loops; a default constructed iterator is equivalent to the STL +container's `end()` value -- and indeed, any _container-like_ object exposing +Lumiera Forward Iteration is encouraged to provide such an `end()`-function, +additionally enabling iteration by +std::for_each+. Implementation notes ^^^^^^^^^^^^^^^^^^^^ -*iter-adapter.hpp* provides some helper templates for building Lumiera Forward +*`iter-adapter.hpp`* provides some helper templates for building Lumiera Forward Iterators. - _IterAdapter_ is the most flexible variant, intended for use by custom @@ -80,7 +78,7 @@ Implementation notes Similar to the STL habits, Lumiera Forward Iterators should expose typedefs for +pointer+, +reference+ and +value_type+. Additionally, they may be used for -resource management purposes by ``hiding'' a ref-counting facility, e.g. +resource management purposes by ``carrying'' a ref-counting facility, e.g. allowing to keep a snapshot or restult set around until it can't be accessed anymore. @@ -94,7 +92,7 @@ relies on that interface for discovering session contents. Besides that, we need more implementation experience. Some existing iterators or collection-style interfaces should be retro-fitted. -See https://issues.lumiera.org/ticket/349[Ticket #349]. + +See https://issues.lumiera.org/ticket/349[Ticket #349]. Moreover, we need to gain experience about mapping this concept down into a flat C-style API. @@ -111,17 +109,16 @@ Alternatives Rationale ~~~~~~~~~ -APIs should be written such as not tie them to the current implementation. +APIs should be written in a way that avoids to tie them to the current implementation. Exposing iterators is known to create a strong incentive in this direction and thus furthers the creation of clean APIs. -Especially in Steam-Layer we utilise already several iterator implementations, +Especially in Steam-Layer we employ already several iterator implementations, but without an uniform concept, these remain just slightly disguised -implementation types of a specific container. Moreover, the STL defines various -and very elaborate iterator concepts. Ichthyo considers most of these an -overkill and an outdated aproach. Many modern programming languages build with -success on a very simple iterator concept, which allows once to pull a sequence -of values -- and nothing more. +implementation types of a specific container. Furthermore, the STL defines +several quite elaborate iterator concepts. _Ichthyo_ considers most of these an +overkill and an outdated implementation-centric approach. Many modern programming +languages rely on a very simple iterator concept with much success. Thus the idea is to formulate a concept in compliance with STL's forward iterator -- but augmented by an stop-iteration test. This would give us basic @@ -136,15 +133,15 @@ Comments -------- //comments: append below -Now in use since more then a year, without turning up any serious problems. -The only _minor concern_ I can see is that this concept, as such, doesn't solve -the problem with exposing implementation details of the underlying container on the API. +This scheme is now in use since more then a year, without turning up any serious problems. +The only _minor concern_ I can see is that this concept, as such, does not solve the +problem with exposing implementation details of the underlying container on the API. Similar to STL Iterators, the actual implementation representation is only disguised -behind a 'typedef'. But, generally speaking, this is an inevitable consequence of the +behind a `typedef'. But, generally speaking, this is an inevitable consequence of the ``zero overhead'' abstraction. For the cases when an indirection (via VTable) is feasible, -I've created the 'IterSource' template, which sticks to this Lumiera Forward Iterator -concept, but provides an opaque frontend, allowing to decouple completely from the -actual implementation. Besides that, over time I've written several standard adapters +I've created the **`IterSource`** template, which adheres to this Lumiera Forward Iterator +concept, yet provides an opaque frontend, allowing to decouple completely from the +actual implementation. Besides that, over time, I have written several standard adaptors for the most common STL containers, plus Map, key and value extractors. Ichthyostega:: 'Sa 16 Apr 2011 00:20:13 CEST' @@ -155,19 +152,21 @@ would require a ``deep copy'' of any underlying data structures. Ichthyostega:: 'Sa 07 Jan 2012 21:49:09 CET' ~~ -NOTE: Lumiera Forward Iterators can be made to work together with the - 'range for loop', as introduced with C++11. The preferred solution - is to define the necessary free functions `begin` and `end` for ADL. - This is best done on a per implementation base. We consider a generic - solution not worth the effort +NOTE: Lumiera Forward Iterators can be made to work together conveniently + with the »Range-for Loop«, as introduced with C++11. The preferred + solution is to define the necessary free functions `begin` and `end` + for ADL. This is best done on a per implementation base. -This is to say, these two concepts can be made to work together well. While, -at a conceptual level, they are not really compatible, and build on a -different understanding: The standard for-loop assumes ``a container'', -while our Forward Iterator Concept deals with ``abstract data sources''. -The user needs to understand the fine points of that conceptual difference: +Considered at a conceptual level, this may seem surprising, since the +Range-Iteration from the C++ standard and our Forward-Iteration do not mesh +up completely, and build upon a different understanding: The standard Range-`for` +Loop assumes ``a container'', or at least ``a data range'', while our +Forward Iterator Concept deals with ``abstract data sources''. So +these are two concepts operating at a different level of abstraction, +yet able to be stacked upon each other. However, the user needs +to understand the fine points of those conceptual differences: -- if you apply the range-`for` construct on a container, you can iterate +- if you apply the Range-`for` construct on a container, you can iterate as often as you like. Even if the iterators of that container are implemented in compliance with the Lumiera Forward Iterator concept. - but if you apply the range-`for` construct on _a given iterator_, @@ -184,9 +183,17 @@ Ichthyostega:: 'Sa 04 Jul 2015 22:57:51 CEST' ~~ Final ~~~~~ -Accepted on developer meeting +Accepted on +link:{ldoc}/devel/meeting_summary/2011-04-13.html#_lumiera_forward_iterator[developer meeting] - Do 14 Apr 2011 02:52:30 CEST Christian Thaeter +Christian Thaeter:: 'Thur 14 Apr 2011 02:52:30 CEST' +TIP: The Lumiera Forward Iterator became a widely used scheme. + One notable extension built on top is the _filter pipeline_ template `IterExplorer`. + Another point worth mentioning is that such an iterator can not only yield values + (as described in this RfC), but may also expose a reference into an underlying + _State Core_ -- which makes high-performance collaboration protocols possible, + while keeping all participants opaque. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt b/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt index 61be3df3c..3c6cdca8c 100644 --- a/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt +++ b/doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt @@ -3,23 +3,24 @@ Make Scons the official build System // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Mi 11 Jan 2012 21:45:58 CET_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Mi 11 Jan 2012 21:45:58 CET_ +|*Proposed by* | Christian Thaeter +|==================================== ******************************************************************************** .Abstract -_Bless SCons the default build system for Lumiera._ +_Bless SCons into the default build system for Lumiera._ ******************************************************************************** Description ----------- //description: add a detailed description: -So far we using autotools and scons in parallel. Over time the need arose to have one +So far we are using Autotools and SCons in parallel. +Over time the need arose to have one reliable supported build system. This shall be SCons. @@ -65,7 +66,7 @@ Rationale Conclusion ---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: result of discussions and evaluation during the last years @@ -84,5 +85,5 @@ Christian Thaeter:: 'Wed 11 Jan 2012 22:28:36 CET' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/Manifest.txt b/doc/devel/rfc/Manifest.txt index d90b4a89b..0c2d5db73 100644 --- a/doc/devel/rfc/Manifest.txt +++ b/doc/devel/rfc/Manifest.txt @@ -1,17 +1,17 @@ Design Process : Manifest ========================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-09_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-09_ +|*Proposed by* | ct +|==================================== -Manifest --------- +A Community Manifest +-------------------- -This Proposal describe the general ideas how the community will work together +This Proposal describes the general ideas how the community will work together to create Lumiera. @@ -27,13 +27,17 @@ Background ~~~~~~~~~~ Cinelerra is quite an old project, there is an original version from -Heroinewarrior.com and a community fork http://cinelerra-cv.wikidot.com/[Cinelerra-CV]. +https://web.archive.org/web/20070519111115/http://heroinewarrior.com/index.php3[»Heroine Virtual« LTD] +aka »Heroine Warrior« and a community maintained version +https://web.archive.org/web/20070519204838/http://cv.cinelerra.org/[Cinelerra-CV]. ~(http://cinelerra-cv.wikidot.com/[2025])~ + The original author claims that there was no-one producing useable input despite their -requests while cinelerra was in development, and indeed the Cinelerra-CV community only +requests while Cinelerra was in development, and indeed the Cinelerra-CV community only feeds back the source released by the original author into their SVN repository and maintains few fixes. There is not much development going on. Some people -have created new functionality/features from time to time which have rarely -been merged into the main repository and maintained by themselves. +have created new functionality/features from time to time which they need +to maintain by themselves, since extensions have rarely +been merged back into the main repository. The Cinelerra community is a quite loose group of individuals, there is some fluctation on the developer base and almost all developers have day jobs which @@ -62,7 +66,7 @@ without maintaining the bad sides again: . *Make it easy to contribute* Even if it is favorable when we have people which are continously working on -Lumiera, it's a fact that people show up, send a few patches and then +Cinelerra, it is a fact that people show up, send a few patches and then disappear. The development model should be prepared for this by: .. Good documentation .. Well defined design and interfaces @@ -104,9 +108,27 @@ things where they are not profound, help each other, make things right instead of blaming someone. Everyone should rate himself at what he can do best on the project. + Comments -------- +[underline]#This document is one of the **first RfC**s# published in *Summer 2007*, + +as a new community movement was about to form, with the goal to improve Cinelerra +for real, in a new version Cinelerra-3. +Early in 2008, this initiative had turned into a new project, with the +https://web.archive.org/web/20231026200633/https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-March/013474.html[community chosen] +name »*Lumiera*« -- years later, in 2010, documentation and existing RfC entries +were migrated from _Cehteh_'s `pipapo.org` Wiki to the +https://web.archive.org/web/20110513134311/http://lumiera.org/[new Lumiera website], +thereby mass-renaming all references Cinelerra -> Lumiera +While this »Manifest« captures well the open minded spirit of the new project, +actual development never happened in the ``community driven'' everyone pulls-from +everyone style; rather, there were immediately two, later three _core devs,_ +which integrated sometimes large, yet mostly small contributions by other people. +After 2012, _Ichthyo_ kept the project going as a single developer, backed by +a small group of supporters. +Ichthyostega:: '2025-09-15' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MarbleMode.txt b/doc/devel/rfc/MarbleMode.txt index 75568dc33..d00e50e98 100644 --- a/doc/devel/rfc/MarbleMode.txt +++ b/doc/devel/rfc/MarbleMode.txt @@ -1,16 +1,18 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-10-10_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-10-10_ +|*Proposed by* | Ichthyostega +|==================================== the Marble Mode --------------- -''dual working styles -- build up from small pieces of clay or cut away the - unneeded parts from a block of marble'' + +[quote] +``dual working styles -- build up from small pieces of clay + +or cut away the unneeded parts from a block of marble'' While the usual UI of video editors quite well supports a working style assembling the result from small building blocks by relying on clips (media @@ -21,43 +23,44 @@ objects) Description ~~~~~~~~~~~ This proposal stems from an discussion on the Mailinglist starting with the -quote from Walter Murch "Marble and Clay". +quote from Walter Murch »Marble and Clay«. + -It is thought to be in support and to complement nasa's +It is thought to be in support and to complement _nasa_'s link:/rfc/DelectusShotEvaluator.html[RfC: Delectus Shot Evaluator] -The central Idea is to remove the difference between "viewing", i.e. the media -viewer and the timeline/Sequence on the other hand. Lumiera is designed to -handle multiple Sequences, which can even arbitrarily be embedded in one -another (the so called _meta-clips_ ). Basically, Sequences are a comparatively +The central Idea is to remove the difference between ``viewing'' ⟷ ``editing'', +i.e. the media viewer and the timeline/Sequence on the other hand. +Lumiera is designed to handle multiple Sequences, which can even be embedded +arbitrarily in one another (the so called _virtual clips_ or _meta-clips_). +Basically, Sequences are a comparatively cheap resource, so the idea is to create a new Sequence on-the-fly to do the viewing already based on a complete timeline. It is up to the user finally to -promote one of these workbench-like timelines to become "the" master timeline. +promote one of these workbench-like timelines to become ``the'' master timeline. To make this usable, in the GUI there should be a slightly different representation which aims at reducing vertical screen usage. Also the track heads could be reduced, e.g. we don't need controls for mixing and panning, the effect stacks could be reduced to a simple mark indicating that there is any effect in a given time range, anything concerned with the fine points of -wiring, tweaking effects and controling automation could be left out -deliberately. This would allow us to have several independant timelines +wiring, tweaking effects and controlling automation could be left out +deliberately. This would allow us to have several independent timelines above/below each other. There could be at least two, maybe even three or four -"slots" which could be allocated by a timeline to display. Every time you open +``slots'' which could be allocated by a timeline to display. Every time you open a new media, a new Sequence will be created on the fly and a new timeline display of this Sequence will be available, replacing the least recently used timeline display slot. Of course, re-visiting an already opened media will bring back the corresponding timeline in the state you left it, with markers, notes, maybe even trimmings and added clips. Contrast this GUI mode with the -usual working mode (the "clay mode"), where there is _one_ central timeline, -probably with tabs to switch between multiple independant Sequences (including +usual working mode (the »clay mode«), where there is _one_ central timeline, +probably with tabs to switch between multiple independent Sequences (including the ones which actually are embedded in another timeline as meta-clips) -Basically, each of these timelines has a separate, independant transport, but +Basically, each of these timelines has a separate, independent transport, but transports can be locked together, and in locked state you can displace/offset the locked partners relative to one another. Moreover, there would be at least -two viewer windows which would be automatically connected to recieve the ouput +two viewer windows which would be automatically connected to receive the output of the timelines as new timelines are placed in the visible slots to work with. -To round things up, we need good keybindings for navigtation, and of course you +To round things up, we need good key bindings for navigation, and of course you can liberally mark parts and spill them over to another timeline, either overwriting or shifting existing footage there. @@ -72,7 +75,7 @@ Initially this new Sequence would be anonymous. But the moment you do the first non-trivial modification there (like adding a label, trimming off parts, adding /deleting tracks), the new Sequence would be promoted to be a named and persisted entity, which from then on could itself serve as a new -"pseudo-media". It would appear as an asset on its own (probably in a special +``pseudo-media''. It would appear as an asset on its own (probably in a special sub category), and it could be used as a source to create clips from. This way, you could work with your media, prepare it, augment it even by adding effects like colour correction. And because it's a real Sequence, you could do @@ -80,22 +83,22 @@ non-trivial things there right in-place, like adding new sub-tracks, placing other media on them -- and then later on use this prepared media like a real media captured from camera source. -Finally, there should be the possibility to "play" a clip bin, thereby +Finally, there should be the possibility to ``play'' a clip bin, thereby on-the-fly creating a new Sequence filled with all the clips in the order they were arranged in the bin. This would yield a bridge to the more clip-oriented -working style and also provide a cheap implementation of the "sparse timeline" -or "storyboard mode" +working style and also provide a cheap implementation of the ``sparse timeline'' +or ``storyboard mode'' Tasks ^^^^^ * have several switchable _perspectives_ or working modes in the GUI - * associate a _workflow state_ whith each Sequence, to track when an Sequence + * associate a _workflow state_ with each Sequence, to track when an Sequence is just anonymous, gets a named entity, is a clip-bin-tied Sequence, or finally is the master Sequence connected to the global output pipes section. - * work out the details of the "display slot allocation" - * provide an "opening media" compound function, comprised of + * work out the details of the ``display slot allocation'' + * provide an ``opening media'' compound function, comprised of * creating the clip covering the whole media (./) (already implemented) * creating a new Sequence and populating it with this clip * make locked-together transports work @@ -115,12 +118,12 @@ Tasks Rationale ^^^^^^^^^ Lumiera is not pioneering the video editing by computers. We are sort of -second-generation (or even third generation) of computer based editing systms. +second-generation (or even third generation) of computer based editing systems. The tradition of conventional, film based editing clearly shows us these two quite different working approaches, which obviously can have quite some impact -on the resulting style and rythm of the final movie. The distinguishing -property of the working style to be supported by the "marble mode" is that it -bypasses the state of creating and organizing clips, but rather directly +on the resulting style and rhythm of the final movie. The distinguishing +property of the working style to be supported by the »marble mode«s is that it +bypasses the state of creating and organising clips, but rather directly evolves the footage into the final cut. This working style is dual to the common clip based approach, none of them is superior or inferior, thus we should actively support both working styles. @@ -136,12 +139,13 @@ Comments Final ~~~~~ +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_marble_mode[Apr.2011 developer meeting]. + Everyone likes this and we want to have this. But this is rather a concept which needs a lot more discussion for the implementation. Further details may -follow where these thingsare worked out. +follow where these things are worked out. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MasterRepositorySetup.txt b/doc/devel/rfc/MasterRepositorySetup.txt index 366bd56c5..f0845a112 100644 --- a/doc/devel/rfc/MasterRepositorySetup.txt +++ b/doc/devel/rfc/MasterRepositorySetup.txt @@ -1,12 +1,12 @@ -Design Process : Shared Master Repository -========================================= +Design Process : Master Repository +================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-04-08_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-04-08_ +|*Proposed by* | ct +|==================================== Shared Master Repository setup ------------------------------ @@ -15,42 +15,66 @@ This describes how the shared MASTER is set up and syncronized. Description ~~~~~~~~~~~ -We have now a shared master repository in /git/LUMIERA. The public/anonymous -git url is 'git://git.lumiera.org/LUMIERA', for people with ssh access it is -pushable at 'git.lumiera.org:/git/LUMIERA'. +We have now a shared master repository in +https://git.lumiera.org/?p=LUMIERA;a=summary[/git/LUMIERA]. -The repository is maintained by cehteh. It updates daily by a script. +- The public/anonymous git url is [yellow-background]#`git://git.lumiera.org/LUMIERA`# +- for people with ssh access it is pushable at [purple]#`UID@git.lumiera.org:/git/LUMIERA`#. -There are the following branches updated from their respective maintainer -repositories: +The repository is maintained by _cehteh_. It updates daily by a script. -[grid="all"] -`-------------`----------------------------------------------------`---------------------------- -*BRANCHNAME* *DESCRIPTION* - *Automatic updated from* -'master' Stable branch, use this as generic entry point. cehteh, - ichthyo -'library' Support library development cehteh, - ichthyo -'proc' Render core development ichthyo -'backend' Data backend development, cehteh -'gui' GUI development joel ------------------------------------------------------------------------------------------------- +There are the following branches updated from their respective maintainer repositories: -Automatic syncronization is only done for 'fast-forward' updates, conflicting +[options="header", cols="^m,3<,2e"] +|==================================== +|BRANCHNAME | DESCRIPTION | Updated from... +| master | Stable branch; generic entry point. | cehteh, ichthyo +| library | Support library development | cehteh, ichthyo +| proc | Render core development | ichthyo +| backend | Data backend development, | cehteh +| gui | GUI development | joel +|==================================== + +Automatic syncronization is only done for `fast-forward' updates, conflicting changes are rejected. It is still possible to manually push to this repository to override automatic syncronization. -Please suggest changes for this setup when required (new branches, difefrent -maintainers, ...) - Comments -------- -Instead this polling @daily update maintainers might use git hooks on their +Instead of this polling @daily update, maintainers might use git hooks on their repos to push relevant things, be careful not to push cruft or tags (which tags shall be present here is not yet resolved -> no tags for now) - -- link:ct[] [[DateTime(2008-04-08T21:48:51Z)]] -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-04-08T21:48:51Z' + +'''' + +[underline]#Historical remark#: This RfC describes the setup we used up to ~2012. + +After that point, I was working alone basically (not counting occasional small contributions), +and consequently the current state could be found in the ``ichthyo'' Git repository +most of the time -- yet the shared master repository is still updated occasionally, +as is a mirror at https://github.com/Ichthyostega/Lumiera/[Github] + +This summer I decided to switch the project over to the +link:{ldoc}/technical/code/GitBranching.html[Git-flow] branching model, +knowing from my own professional background that this scheme is a good fit +for this kind of project. +This has the consequence however that the usage pattern described in this RfC +*becomes obsolete*, as actual development mostly takes place on development or +feature branches now, consolidating all progress into the branch `integration`. +The branch `master` carries only tested and released code going forward. + +That being said -- the shared master at [yellow-background]#`git://git.lumiera.org/LUMIERA`# +still contains the _official_ state of the Lumiera codebase, while +actual development is published first in a repository per developer +(so effectively in +https://git.lumiera.org/?p=lumiera/ichthyo;a=summary[the Ichthyo repository] +for the time being); +development is consolidated intermittently into the +https://git.lumiera.org/?p=LUMIERA;a=summary[LUMIERA Git]. + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MistakestoAvoid.txt b/doc/devel/rfc/MistakestoAvoid.txt index cf61b8df3..0a6e70084 100644 --- a/doc/devel/rfc/MistakestoAvoid.txt +++ b/doc/devel/rfc/MistakestoAvoid.txt @@ -1,18 +1,17 @@ Design Process : Mistakes to avoid ================================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-04-21_ -*Proposed by* link:rick_777[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-04-21_ +|*Proposed by* | rick_777 +|==================================== Mistakes to avoid in the Lumiera design --------------------------------------- - As a multimedia user and experienced programmer, I've found various flaws present in open source Non Linear Video editors. Here I will list the problems and their proposed (or mandatory) solutions. Please forgive me if some of the @@ -22,10 +21,8 @@ wiki. Description ~~~~~~~~~~~ - - As a multimedia user and experienced programmer, I've found the following flaws -present in open source Non Linear Video editors (your mileage may vary) : +present in open source Non Linear Video editors (your mileage may vary): . Frequent crashes (which most of the time make you lose your work) . Reinventing the wheel for every new project @@ -41,15 +38,14 @@ I will expand on the problems and their proposed (or mandatory) solutions. 1. Frequent crashes ~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Frequent Crashes and unsaved work. -*Severity* CRITICAL. -*Solution* Isolating the UI from the rendering and data handling (also - improves the extensibility) -*Required* Yes -*Workarounds* Auto-save (however it's not a real solution for the problem) --------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Frequent Crashes and unsaved work. +|*Severity* | CRITICAL. +|*Solution* | Isolating the UI from the rendering and data handling (also improves the extensibility) +|*Required* | Yes +|*Workarounds* | Auto-save (however it's not a real solution for the problem) +|==================================== Working with multimedia (video / audio) editing is a magnet for segfaults (crashes) due to the handling of pointers and compression algorithms. A bug in @@ -59,7 +55,7 @@ doesn't go to the root of the problem. My proposal is to move the low-level handling of video to a separate process, which then will do the processing - if it crashes, the UI will only report an -error with a dialog (i.e. "the process crashed. Try again?"), but you work will +error with a dialog (i.e. ``the process crashed. Try again?''), but you work will stay safe. I'm not sure of the implementation difficulties that arise from having a shared memory buffer for rendering / processing, but one thing is certain: Whenever you move the cursor or rewind a part of a clip in your @@ -73,34 +69,42 @@ Comments I am not sure yet about separating things into processes, generally it is clear that this would be more robust but there are some performance impacts and -programming problems (massisve amounts of data in shared memory). But most +programming problems (massive amounts of data in shared memory). But most importantly, when a subprocess gets a job and crashes on it, it won't complete the job, we don't have a choice except gracefully abort it. From a user -perspective "It doesn't work!" there is no much difference to a complete crash. +perspective ``It doesn't work!'' there is no much difference to a complete crash. Well and yes we aim to make it crash proof rather, crashes a bugs and have to -be fixed, point. +be fixed, period. Lumiera will never ever loose work, we don't plan to make a project file, -autosafe way. Lumiera will keep projects in an internal database like format -which consists of a Dumpfile and a contingous written logfile. After a -crash/powerdown whatever, this log just gets replayed. The advantages are +auto-save way. Lumiera will keep projects in an internal database like format +which consists of a Dumpfile and a continuous written logfile. After a +crash/power-down whatever, this log just gets replayed. The advantages are countless, imagine persistent, selective undo and so on. Any other format -(cinelerra2 XML, MXF, ...) will be realized by importer/exporter plugins. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +(Cinelerra2 XML, MXF, ...) will be realized by importer/exporter plugins. +ct:: '2008-04-21T11:27:23Z' + +Hereby I confirm that this comment still represents the stance of the +Lumiera project regarding this crucial issue. We _should not tolerate_ +crashes, rather report them and contribute to improvements or alternatives. + +And all user actions in Lumiera are captured as an _Event Log,_ which can +be replayed any time (and in altered form) to recreate any state of the edit. + +ichthyo:: '2025-09-15' 2. Reinventing the wheel for every new project ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Various projects compete and reinvent the wheel -*Severity* Serious (Slows down development time. A lot) -*Solution* Multi-tier design, turn the data handling into a backend and use - whatever UI you prefer -*Required* Yes. Better now that the project hasn't started ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Various projects compete and reinvent the wheel +|*Severity* | Serious (Slows down development time. A lot) +|*Solution* | Multi-tier design, turn the data handling into a backend and use whatever UI you prefer +|*Required* | Yes. Better now that the project hasn't started +|==================================== Imagine the Linux kernel was tied to the window manager. You would have to stick with KDE or GNOME and you couldn't improve it! Fortunately it's not like @@ -112,7 +116,7 @@ the project and change the UI to one that supports skinning, without having to do the complicated video-processing stuff. Separating the processes has an equivalent for web programming, it's called -"separation of concerns", or multi-tier design. When you suddenly change the +»Separation of Concerns«, or multi-tier design. When you suddenly change the database engine, you don't need to change the whole program, just the database module. Same goes for changing the UI from HTML to XML or Flash. If they're separate modules that only communicate through a clearly defined API. @@ -129,7 +133,7 @@ an engine to do the thinking. So I suggest to split the project into four separate tiers (not necessarily processes): -. User interface - communicates with the "project" tier, handles the user +. User interface - communicates with the ``project tier'', handles the user events and does the calls. . The project tier - the main part of the video editor. This one invokes the renderer and decides which effects to apply, saving them as mere parameters @@ -142,7 +146,7 @@ processes): the background while we keep working on the project (after all the project is just a set of data stating which effects to apply to which tracks, and which files are used for the tracks) - instead of just having a window saying - "Rendering, please wait". Even Adobe Premiere Pro suffered from this problem. + ``Rendering, please wait''. Even Adobe Premiere Pro suffered from this problem. This means that if we put enough effort, we can surpass commercial software in certain areas. Note that the rendering engine uses the same API than the project tier, as it works on a copy of the project when doing the final @@ -161,35 +165,47 @@ Comments ^^^^^^^^ Please look at our design drafts, things will be separated (little different -than you describe here). We reuse things which are benefitful (gavl, ffmpeg, +than you describe here). We reuse things which are beneficial (gavl, ffmpeg, ..) but we are also aware that we reinvent the wheel for some things by -intention. Lumieras goal is not just to glue some existing libraries together -under a new gui, there are already a lot projects trying this way. We rather +intention. Lumiera's goal is not just to glue some existing libraries together +under a new Gui, there are already a lot projects trying this way. We rather aim for a ''Professional'' high performance Video editing solution which does some things in a different (maybe more complex) way. We do not use existing -frameworks like MLT or gstreamer because we believe that these do not fit our -goals (gstreamer will be supported through plugins). We do not produce yet -another multimedia framework library (this only happen by coincidence) to be -used by others. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +frameworks like MLT or GStreamer because we believe that these do not fit our +goals (GStreamer will be supported through plugins). We do not intend to produce +yet another multimedia framework library to be used by others. + +ct:: '2008-04-21T11:27:23Z' + +This entry captures in a succinct way the reason *why we build Lumiera*. + +However, this also touches on a deeper theme: + +Whenever we solve a _substantial problem_, we are tied and bound to our solution, +and we have to stick to it. Thus, by solving such a problem _for real_, +we loose the ability to do ``anything we want, anytime''. +Since we are human, we have to pick one path and forgo all the +other, possible ones. _Doing so is not a ``mistake''._ + +Now one might try to escape from this dilemma, by defining _flexibility_ +or _sovereignty_ as the actual problem. It seems even feasible to address +this by turning it into a schematism -- and then you are bound to that one. + +ichthyo:: '2025-09-15' + 3. Lack of a user-friendly and extensible UI. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Often, editors provide a very poor and buggy interface. - Examples: Jahshaka doesn't even provide tooltips for the various tools, and - the documentation is poor; In Cinelerra I've noticed some bugs when using the - open dialog, I'd rather have the KDE one, thanks. -*Severity* From Annoying to Serious. -*Solution 1* Use a library that allows you to use different widget - libraries, like wxWidgets. -*Required* Recommended, but not obligatory. -*Solution 2* Write different user interfaces, but they'd be hard to maintain. -*Required*, No. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Often, editors provide a very poor and buggy interface. +|*Severity* | From Annoying to Serious. +|*Solution-1* | Use a library that allows you to use different widget libraries, like wxWidgets. +|*Required* | Recommended, but not obligatory. +|*Solution-2* | Write different user interfaces, but they'd be hard to maintain. +|*Required* | No. +|==================================== This problem is complicated, we need a good framework for handling the tracks. Perhaps this could become a separate project. Ideas are welcome. @@ -198,31 +214,49 @@ Perhaps this could become a separate project. Ideas are welcome. Comments ^^^^^^^^ -Joel started working on a GUI recently and making good progress. The UI should -finally be quite flexible as it mostly provides a skeletion where plugins +Joel started working on a GUI recently and makes good progress. The UI should +finally be quite flexible as it mostly provides a skeleton where plugins render to. We have quite a lot ideas about the UI and user input is welcome. The UI is currently the most separate tier in the design, i'd like to make it a -plugin itself which is loaded when lumiera is started in a gui mode, but it is -to early to say how exactlly it will be integrated, except that we all agree +plugin itself which is loaded when Lumiera is started in a Gui mode, but it is +to early to say how exactly it will be integrated, except that we all agree that GUI is optional and Lumiera can also run headless, script driven. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] + +ct:: '2008-04-21T11:27:23Z' + +It is many years later now; we indeed do load our GUI as a plug-in, +yet have not gained much by this move. The reason is, what we actually need +for editing video is hard to implement in _any_ toolkit. Once you start solving +_that_ problem, you are bound in very intricate ways to the specific toolkit +you just happened to choose (in our case, this is GTK). + +In a nutshell, being ``user-friendly and extensible'' is not something to +be solved at an _abstract, generic level_ -- we'll have to face the fact +that _a beginner_ will have quite different demands than a experienced +professional. And Lumiera is a tool for professionals. Being beginner +friendly is certainly desirable, yet it remains a secondary goal, and +we have not even made so much inroads regarding the primary goal. + +ichthyo:: '2025-09-15' + 4. Lack of support for certain video formats or codecs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Lack of support for certain video formats or codecs. -*Severity* Critical. -*Workarounds* 1. Give a help page for the user to do his own conversion, but - this is very inelegant, annoying, and a waste of time. 2. Provide conversion - on the fly, and keep a separate "preprocessed" copy of the imported clip in a - separate directory. This is a nice middle ground, IMHO. -*Solution* Use a wrapper library as stated in problem # 2, having a - plugin-based design is recommended. -*Required* Yes. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Lack of support for certain video formats or codecs. +|*Severity* | Critical. +|*Workarounds* | 1. Give a help page for the user to do his own conversion, but + this is very inelegant, annoying, and a waste of time. + 2. Provide conversion on the fly, and keep a separate + _preprocessed copy_ of the imported clip in a + separate directory. This is a nice middle ground, IMHO. +|*Solution* | Use a wrapper library as stated in problem # 2, having a + plugin-based design is recommended. +|*Required* | Yes. +|==================================== Some editors like Cinelerra are hardwired into using one format, or have a phobia to certain formats / codecs (i.e. DivX AVI's). If we separate the @@ -236,25 +270,33 @@ compatibility for future formats. Comments ^^^^^^^^ -Lumiera is a video editor we don't care (*cough*, not really true) about video +Lumiera is a video editor we don't care (\*cough*, not really true) about video formats. Everything which comes In and goes Out is defined in plugins which -handle video formats. We currently decided to use 'gavl' because it is a nice -small library which does exactly what we want. Later on gstreamer and other -such kinds of decoder/encoder/processing-pipe libs will be realized. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +handle video formats. + +ct:: '2008-04-21T11:27:23Z' + +So this point is not hard to solve (use plugins), yet this obvious +solution creates a lot of much more tricky problems. In Lumiera, +we attempt to actually solve those secondary problems, instead of +just stating ``this can be solved by plug-ins'' (as most other +existing software does). Unfortunately, this makes the project +very complex. The chosen path seems feasible, yet honestly, +I do not know if we'll ever make it. + +ichthyo:: '2025-09-15' 5. Lack of documentation ~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Some video editors have very poor documentation (and that's an - understatement *cough* Jahshaka *cough* ) -*Severity* Critical. -*Solution* Have a team for the documentation. -*Required* Yes. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Some video editors have very poor documentation (and that's an understatement) +|*Severity* | Critical. +|*Solution* | Have a team for the documentation. +|*Required* | Yes. +|==================================== Nuff said. @@ -262,7 +304,7 @@ Nuff said. Comments ^^^^^^^^ -Quote from https://openhub.net/p/lumiera/[Openhub.net]: +Quote from https://openhub.net/p/lumiera/[Openhub.net (formerly »Ohloh«)]: ------------------------------------------------------------ Extremely well-commented source code @@ -274,25 +316,37 @@ projects on Ohloh. ------------------------------------------------------------ -Nuff saied... Oh well, about user docs we like to get that impressive ratings -there too, any helpers? - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +``Nuff said''... + +Oh well, about user docs we like to get that impressive ratings there too, any helpers? + +ct:: '2008-04-21T11:27:23Z' + +Here I'd like to add that writing is hard -- any writing, not only writing code -- +and writing text that other people can understand and which is accurate at +the same time is even harder. It requires a lot of resources, and typically +developers are not good at writing in a way that is understandable by +``average joe'', while people good at writing nice text seem to have quite +some problems with understanding the thinking style pertinent to +software engineering. So, let's say: ``we keep trying'' + +ichthyo:: '2025-09-15' + 6. Lack of cross-platform support ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Where's my Windows version? -*Severity* Blocker -*Solution* Use a cross-platform toolkit for the UI. -*Required* Depends, do you plan to make it Cross-Platform? --------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Where's my Windows version? +|*Severity* | Blocker +|*Solution* | Use a cross-platform toolkit for the UI. +|*Required* | Depends, do you plan to make it Cross-Platform? +|==================================== A good example for this is the Code::Blocks IDE, which was thought of being cross-platform from the beginning. Curiously, at first the project was -Windows-only, and its only F/OSS alternative was Dev-C++ from Bloodshed (eew). +Windows-only, and its only F/OSS alternative was Dev-C\++ from Bloodshed (eew). Otherwise you'd have to stick with proprietary applications like Visual C++. In Linux there were various IDE's, but they were Linux-only. Since Code::Blocks @@ -310,27 +364,44 @@ Comments ^^^^^^^^ We refuse to make it cross platform intentionally. Most things are written -portable, POSIX compatible, some might need platform specific fixes. But our -target is primary Linux (because thats what we use) secondary any other Free OS -(hopefully we find some testers/maintainers for that). Lumiera ''might'' run on +in a portable style, and POSIX compatible; some might need platform specific fixes. +But our target is primary Linux (because that's what we use) secondary any other Free OS +(hopefully we find some testers/maintainers for that). Lumiera _might_ run on OSX and patches will be accepted, but it is not a free platform so we don't -care by ourself. Windows due its diffrent system interfaces will be hard to +care by ourselves. Windows due its different system interfaces will be hard to port, if someone wants to do that, have fun, we will accept patches to, but we -do not support it in *any* way by ourself. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +do not support it in *any* way by ourselves. + +ct:: '2008-04-21T11:27:23Z' + +For a typical ``business'' application, this is largely a problem of the UI; +we tend to solve that problem by using web technology nowadays, of relying +on similar _frameowork solutions_. Doing so however incurs significant cost; +the following point -- scripting languages -- is one of the symptoms. + +However, video processing is still a technology pushing the limits. +We can address this either by aiming at an industrial setup, where the +actual processing is done in a server farm. Or you can limit yourself +to what can be achieved on a personal computer -- which requires to +keep priorities straight and deliberately abandon unnecessary +secondary goals and ``nice to haves'' + +The Lumiera project follows the second path. + +What is _essential_ thus becomes a question of philosophy, or politics. + +ichthyo:: '2025-09-15' 7. Dependency on scripted languages like Python, which make installation a mess ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -[grid="all"] -`------------`------------------------------------------------------ -*Problem* Installation can be a mess if we depend on scripted languages. -*Severity* Annoying, the end user might just conform with another project - that "just works". -*Solution* Make it in C++ or other easily-compilable language. -*Required* VERY recommended. ---------------------------------------------------------------------- +[options="autowidth"] +|==================================== +|*Problem* | Installation can be a mess if we depend on scripted languages. +|*Severity* | Annoying, the end user might just conform with another project that ``just works''. +|*Solution* | Make it in C++ or other easily-compilable language. +|*Required* | VERY recommended. +|==================================== I've had to install several packages for my distro (whose repository is not as large as others like Ubuntu's) from source. Some of them depend on very @@ -342,62 +413,79 @@ work on a common language, like C++. Comments ^^^^^^^^ -At some point a scripting language ''will'' be required, yet to drive the -testsuite, make headless rendering work and so on. We need to provide -installation instructions and/or even bundle this language with Lumiera. This -will likely become a small embedded language like Lua or some kind of forth (or -maybe some scheme?) it should not depend on strange modules which are not part -of the core scripting language distribution (or we shall provide them too), -needs to be worked out. - -- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] +At some point a scripting language _will_ be required, be it to drive the +testsuite, make headless rendering work and so on. This +will likely become a small embedded language like Lua... +details need to be worked out. + +ct:: '2008-04-21T11:27:23Z' + +This decision was revised and changed. Lumiera is written in C++ and +will certainly require some special media processing plug-ins, but +it will _not require any scripting language_ for core tasks. + +Yet a script runner and script driven use is on the main agenda, +since that is an essential feature for large scale media editing projects, +where at least some kind of quality render happens on a cloud platform. +Our goal is to stick to widely used and commonly packaged software and +libraries whenever possible. + +ichthyo:: '2025-09-15' -Author's comments -^^^^^^^^^^^^^^^^^ - -Some of the measures stated in this document are optional, but separating the -processes for the rendering engine, editor and User Interface are the optimal -solution and required to avoid common problems. Discussion ---------- +Some of the measures stated in this document are optional, but separating the +processes for the rendering engine, editor and User Interface are the optimal +solution and required to avoid common problems. + +rick_777:: '2008-04' Mostly we agree with the general statements in this Design Entry. But there are some points which don't stand the test of a detailed technical discussion. For -example, you simply can't state it's a 'mistake' not to write code which +example, you simply can't state it's a ``mistake'' not to write code which similarly runs on windows and *nix. Well. You could try to write it in Java. See my point? While today it's quite feasible to write office stuff or banking applications in a cross-platform manner, a video editor still is a different kind of a beast. -A similar argumentation holds true for the question, wether or not to use +A similar argumentation applies to the question, whether or not to use separate processes and IPC. While it certainly is a good idea to have the X server or a database running in a separate process, the situation is really -quite different for editing video. Hopefully it's clear why. - -Could you please rework this Design Entry in a way that we can finalize -(accept) it? +quite different for editing video. Doing that with collaborating processes +and shared memory is anything than trivial, and brings its own set of +difficulties and limitations. So I would not rule it out, yet it +is clearly not the ``only true solution'' +Could you please rework this Design Entry in a way that we can finalise +(accept) it? + +-- * Please remove the section about windows * Please separate out things needing technical discussion and are not just - "mistakes", thus retaining only the big picture statements (on which we all - agree) -* How to secure the application against crashes -* If it is viable/desirable to run the gui in a separate process really needs - in-depth technical discussion (create a new Design Entry for this) -* How to deal with the dependencies problem in combination with - plugins/extensions and script languages - -- link:Ichthyostega[] [[DateTime(2008-10-05T01:51:50Z)]] + ``mistakes'', thus retaining only the big picture statements (to which + the core developers of Lumiera largely agree). Notably... + + ** Securing the application against crashes is a non-trivial task + ** If it is viable/desirable to run the Gui in a separate process really + needs in-depth technical discussion (create a new Design Entry for this) + ** How to deal with the dependencies problem in combination with + plugins/extensions and script languages +-- + +Ichthyostega:: '2008-10-05T01:51:50Z' Conclusion ---------- -The October.2008 dev meeting decided to 'drop' this design proposal as is. +The +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_mistakes_to_avoid[October.2008 dev meeting] +decided to __`drop'__ this design proposal as is. -Basically, this text just tells us "to make Lumiera good", and especially it -contains a mixture of topics +In a nutshell, leaving out all the technicalities, this text just tells us +``to make Lumiera good''. Beyond that, it contains a mixture of topics: * We fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic @@ -407,21 +495,21 @@ contains a mixture of topics which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements. -While it is certainly 'desirable' to be cross-platform as much as possible and -especially '''target Microsoft Windows''', we don't see much possibilities with +While it is certainly _desirable_ to be cross-platform as much as possible and +especially _target Microsoft Windows_, we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform. -While it is certainly 'desirable' to make the application as robust as -possible, we don't see how '''using multiple separate processes''' could help -us with this goal ''without creating major scalability or performance -problems'' due to the use of shared memory. And, yet more important: we don't +While it is certainly _desirable_ to make the application as _robust_ as +possible, we don't see how ``using multiple separate processes'' could help +us with this goal _without creating major scalability or performance +problems_, due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner. '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt b/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt index 68053e908..34f9057f0 100644 --- a/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt +++ b/doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt @@ -1,12 +1,12 @@ Design Process : IRC Developer Meeting ====================================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-15_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-15_ +|*Proposed by* | ct +|==================================== IRC Developer Meeting @@ -26,26 +26,19 @@ Things like: * Who needs help for something * Make Decisions about pending proposals -We should make small 'to be talked about' list beforehand (on the wiki) and +We should make small ``to be talked about'' list beforehand (on the wiki) and write an also small protocol afterwards about the decisions made. -I'd suggest to do this first Friday of each month at 21:00GMT, thats late +I'd suggest to do this first Friday of each month at 21:00GMT, that's late evening in Europe and afternoon in USA. Details need to be acknowledged. -Tasks -~~~~~ - - -Pros -~~~~ - Cons ~~~~ - * Inflexible - People's lives and schedules can easily change within a few + * Inflexible -- People's lives and schedules can easily change within a few months thus making them unavailable for further meetings @@ -57,41 +50,44 @@ Alternatives resolve scheduling conflicts. -Rationale -~~~~~~~~~ Comments -------- -* A short meeting every week is a must. "meeting" means a fair amount of the +* A short meeting every week is a must; ``meeting'' means a fair amount of the developers involved show up and there is a possibility to point at current problems. We could make a Full Meeting in the way proposed by - link:MichaelPloujnikov[] additionally. But even one week can be dangerousely + MichaelPloujnikov additionally. But even one week can be dangerousely long in software developement, esp. when the dev process is so open and distributed. * Personally, I am OK with Friday 21GMT - -- link:Ichthyostega[] [[DateTime(2007-06-17T00:29:54Z)]] + +Ichthyostega:: '2007-06-17T00:29:54Z' * Friday 21GMT is only good for me starting in two weeks until September. After that it's booked for the Winter. Thursday 21GMT would be better. - -- link:MichaelPloujnikov[] [[DateTime(2007-06-17T03:09:36Z)]] + +MichaelPloujnikov:: '2007-06-17T03:09:36Z' * Also Ok for me - -- link:ct[] [[DateTime(2007-06-17T17:20:37Z)]] + +ct:: '2007-06-17T17:20:37Z' * I think this (monthly) meeting should not be too frequent and address more global project directions, having a more frequent meeting rather makes it more unattractive and time consuming for slightly involved people. This does - not means that we cant meet more often, but this should be acknowledged + not mean that we can't meet more often, but this should be acknowledged between people who work together on some features/subsystems. That would also have the benefit that such small groups are very flexible to meet, even daily on hot phases and able to acknowledge times when all members can attend. And later if timing is not that good only one person of such a subproject/group may attend to the monthly meeting and report/collect information there. Its likely hard enough to get many developers to meet at one time in month (when - we have more devs than now :P) - -- link:ct[] [[DateTime(2007-06-17T17:20:37Z)]] + we have more devs than now 😜) -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2007-06-17T17:20:37Z' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/NoBugFlags.txt b/doc/devel/rfc/NoBugFlags.txt index c2094bae0..e6b4ad19d 100644 --- a/doc/devel/rfc/NoBugFlags.txt +++ b/doc/devel/rfc/NoBugFlags.txt @@ -1,16 +1,16 @@ NoBug logging flag hierachy =========================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-04-05_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-04-05_ +|*Proposed by* | ct +|==================================== -link:NoBug[] logging flag hierachy ----------------------------------- +NoBug logging flag hierachy +--------------------------- https://nobug.pipapo.org/[NoBug] allows hierachical organization of logging flags. Propose a documentation/planning about the setup. @@ -28,9 +28,8 @@ NOTE: outdated information. Have a look at `include/logging.h` Tasks ~~~~~ * Needs a file.c defining the common root see - link:{ldoc}/devel/rfc/GlobalInitialization.html[RfC: Global Initialization] - * Everyone needs to setup this hierachy by NOBUG_DEFINE_FLAG_PARENT (flag, - parent_flag); + link:{rfc}/GlobalInitialization.html[RfC: Global Initialization] + * Everyone needs to setup this hierachy by `NOBUG_DEFINE_FLAG_PARENT (flag, parent_flag);` Pros @@ -62,4 +61,6 @@ Ichthyostega:: 'Di 29 Okt 2013 05:52:34 CET' ~~ //endof_comments: -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/NormalizedDeviceCoordinates.txt b/doc/devel/rfc/NormalizedDeviceCoordinates.txt index b594cc3b2..1ec108230 100644 --- a/doc/devel/rfc/NormalizedDeviceCoordinates.txt +++ b/doc/devel/rfc/NormalizedDeviceCoordinates.txt @@ -1,16 +1,16 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2009-01-14_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2009-01-14_ +|*Proposed by* | ct +|==================================== Normalized Device Coordinates ----------------------------- -AkhIL pointed me out to some blender problem and how renderman fixes that. We -should use this too. +_AkhIL_ pointed out to me some blender problem and how ``renderman'' fixes that. +We should use this too. @@ -54,33 +54,14 @@ Just snippet from IRC log: -Tasks -^^^^^ -Discussion -~~~~~~~~~~ - -Pros -^^^^ - - - -Cons -^^^^ - - - -Alternatives -^^^^^^^^^^^^ - - Rationale ~~~~~~~~~ -TBD +^[red]#to be written#^ @@ -91,22 +72,22 @@ Comments One issue where I always assumed we'd need to define something of this sort is for proxy editing. Especially this is a problem in conjunction with masks. -Basically, this means a bit more of "vector graphics". With film/video editing, +Basically, this means a bit more of ``vector graphics''. With film/video editing, this was rather unusual, but with the advent of more and new digital video/film formats it gets more and more important. Also, our considerations regarding time handling and quantisation to single frames somewhat fit into this line of -thought. Up to now, rather the standard way of thinkin was to use a "project -framerate" and a fixed resolution in pixels. But we certainly can do better. +thought. Up to now, rather the standard way of thinking was to use a ``project +framerate'' and a fixed resolution in pixels. But we certainly can do better. - -- Ichthyostega 18:09:50 +Ichthyostega:: '2009-01-14 18:09:50' Parked ~~~~~~ deferred for later, generally accepted. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/OfficialAssemblyLanguage.txt b/doc/devel/rfc/OfficialAssemblyLanguage.txt index 237b9d5ad..43b5b75da 100644 --- a/doc/devel/rfc/OfficialAssemblyLanguage.txt +++ b/doc/devel/rfc/OfficialAssemblyLanguage.txt @@ -1,12 +1,12 @@ Design Process : Official Assembly Language =========================================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-08-01_ -*Proposed by* link:PercivalTiglao[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-08-01_ +|*Proposed by* | PercivalTiglao +|==================================== Official Assembly Language @@ -16,7 +16,7 @@ I describe here an optimization that might have to be be taken into account at the design level. At very least, we should design our code with auto-vectorization in mind. At the most, we can choose to manually write parts of our code in assembly language and manually vectorize it using x86 SSE -Instructions or !PowerPC !AltiVec instructions. By keeping these instructions +Instructions or PowerPC AltiVec instructions. By keeping these instructions in mind, we can easily achieve a large increase in speed. @@ -44,14 +44,14 @@ assembly-level libraries somewhere in our code. Tasks -~~~~~ - -* Choose an "Official" assembly language / platform. +^^^^^ +* Choose an ``Official'' assembly language / platform. * Review the SIMD instructions avaliable for that assembly language. -* For example, the Pentium 2 supports MMX instructions. Pentium 3 supports MMX - and SSE Instructions. Early Pentium4s support MMX, SSE, and SSE2 - instructions. Core Duo supports upto SSE4 instructions. AMD announced SSE5 - instructions to come in 2009. + ** For example, the Pentium 2 supports MMX instructions. + ** Pentium 3 supports MMX and SSE Instructions. + ** Early Pentium4s support MMX, SSE, and SSE2 instructions. + ** Core Duo supports upto SSE4 instructions. + ** AMD announced SSE5 instructions to come in 2009. * Consider SIMD instructions while designing the Render Nodes and Effects architecture. * Write the whole application in C/C++ / Lua while leaving sections to optimize @@ -60,8 +60,7 @@ Tasks Pros -~~~~ - +^^^^ Assuming we go all the way with an official assembly language / platform... * Significantly faster render and previews. (Even when using a high-level @@ -71,10 +70,8 @@ Assuming we go all the way with an official assembly language / platform... Cons -~~~~ - -* Earlier architectures of that family will be significantly slower or - unsupported +^^^^ +* Earlier architectures of that family will be significantly slower or unsupported * Other architectures will rely on C / C++ port instead of optimized assembly * Redundant Code @@ -112,50 +109,57 @@ optimization avaliable in the future, then we should be good. Comments -------- -* I have to admit that I don't know too much about SSE instructions aside from - the fact that they can operate on 128-bits at once in parallel and there are - some cache tricks involved when using them. (you can move data in from memory - without bringing in the whole cache line). Nonetheless, keeping these - assembly level instructions in mind will ease optimization of this Video - Editor. Some of the instructions are high-level enough that they may effect - design decisions. Considering them now while we are still in early stages of - development might prove to be advantagous. Optimize early? Definitely not. - However, if we don't consider this means of optimization, we may design - ourselves into a situation where this kind of optimization becomes - impossible. +I have to admit that I don't know too much about SSE instructions aside from +the fact that they can operate on 128-bits at once in parallel and there are +some cache tricks involved when using them. (you can move data in from memory +without bringing in the whole cache line). Nonetheless, keeping these +assembly level instructions in mind will ease optimization of this Video +Editor. Some of the instructions are high-level enough that they may effect +design decisions. Considering them now while we are still in early stages of +development might prove to be advantageous. Optimize early? Definitely not. +However, if we don't consider this means of optimization, we may design +ourselves into a situation where this kind of optimization becomes +impossible. -* I don't think we should change any major design decisions to allow for - vectorization. At most, we design a utility library that can be easily - optimized using SIMD instructions. Render Nodes and Effects can use this - library. When this library is optimized, then all Render Nodes and Effects - can be optimized as well. -- link:PercivalTiglao[] - [[DateTime(2008-08-01T16:12:11Z)]] +I don't think we should change any major design decisions to allow for +vectorization. At most, we design a utility library that can be easily +optimized using SIMD instructions. Render Nodes and Effects can use this +library. When this library is optimized, then all Render Nodes and Effects +can be optimized as well. -* Uhm, the Lumiera core (backend, proc, gui) doesn't do any numbercrunching. - This is all delegated to plugins (libgavl, effects, encoders). I think we - don't need any highly assembler/vector optimized code in the core (well, lets - see). This plugins and libraries are somewhat out of our scope and thats good - so, the people working on it know better than we how to optimize this stuff. - It might be even worthwile to try if when we leave all vectorization out, if - then the plugins can use the vector registers better and we gain overall - performance! - -- link:ct[] [[DateTime(2008-08-03T02:27:14Z)]] +PercivalTiglao:: '2008-08-01T16:12:11Z' -* Another idea about a probably worthwhile optimization: gcc can instumentate - code for profileing and then do arc profileing and build it a second time - with feedback what it learnd from the profile runs, this mostly affects - branch prediction and can give a reasonable performance boost. If somone - likes challenges, prepare the build system to do this: -. build it with -fprofile-arcs -. profile it by running ''carefully'' selected benchmarks and tests. -. rebuild it again this time with -fbranch-probabilities +The Lumiera core (backend, proc, gui) doesn't do any number crunching. +Any actual media processing will be delegated to plugins (lib-Gavl, effects, encoders). +I think we don't need any highly assembler/vector optimized code in the core (well, lets see). +This plugins and libraries are somewhat out of our scope and that's good so, the people working +on it know better than we how to optimize this stuff. + +It might be even worthwhile to try if when we leave all vectorization out, +if then the plugins can use the vector registers better and we gain overall +performance! + +ct:: '2008-08-03T02:27:14Z' + +Another idea about a probably worthwhile optimization: GCC can instrument +code for profiling and then do arc profiling and build it a second time +with feedback what it learned from the profile runs, this mostly affects +branch prediction and can give a reasonable performance boost. If someone +likes challenges, prepare the build system to do this: + +-- +. build it with `-fprofile-arcs` +. profile it by running _carefully selected_ benchmarks and tests. +. rebuild it again this time with `-fbranch-probabilities` . PROFIT - -- link:ct[] [[DateTime(2008-08-03T02:27:14Z)]] +-- -* I've discussed general ideas around, and I agree now that "core Lumiera" is - not the place to think of these kinds of optimizations. So I'll just move - this over to dropped. -- link:PercivalTiglao[] - [[DateTime(2008-08-04T18:33:58Z)]] +ct:: '2008-08-03T02:27:14Z' + +I've discussed general ideas around, and I agree now that ``core Lumiera'' +is not the place to think of these kinds of optimizations. +So I'll just move this RfC to dropped. + +PercivalTiglao:: '2008-08-04T18:33:58Z' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ProcBuilder.txt b/doc/devel/rfc/ProcBuilder.txt index ea8492220..1c6b5c63a 100644 --- a/doc/devel/rfc/ProcBuilder.txt +++ b/doc/devel/rfc/ProcBuilder.txt @@ -1,12 +1,12 @@ -Design Process: Builder within the Steam-Layer -============================================== +Design Process: Builder +======================= -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Builder within the Steam-Layer ------------------------------ @@ -42,7 +42,7 @@ configuration down into the low-level model using generic rules. Pros ^^^^ * Separation, decoupling - * Architectural approach instead of just hacking away... + * Architectural aproach instead of just hacking away... Cons ^^^^ @@ -55,14 +55,14 @@ This design was chosen as a direct consequence of the problems encountered in the Cinelerra-2 codebase. * Separating this way allows us to take on different viewpoints on what is - "good" and "efficient". + ``good'' and ``efficient''. * In the low-level view simplicity and efficiency of computation is the main criterion. * Whereas in the high-level view a good modeling of the problem domain and maximum flexibility is preferable. * The high-level view is taken out of the critical code path, allowing for advanced and even experimental technologies without endangering the whole - application's usability. In the low-level realm, 'speed' is measured in ms, + application's usability. In the low-level realm, _speed_ is measured in ms, whereas in the high-level domain, speed is rather measured in 100ms. * The separation creates distinct interfaces and allows people with very different skill sets to work in parallel at the various levels of the App. @@ -72,6 +72,8 @@ Conclusion ---------- This proposal reflects a distinct approach taken right from start. -Marked 'final' at October.2008 developer meeting +Marked __`final'__ at the +link:{}/devel/meeting_summary/2008-10-10.html#_the_builder[October.2008 developer meeting] -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ProcHighLevelModel.txt b/doc/devel/rfc/ProcHighLevelModel.txt index f253cf77b..6eb91cb7f 100644 --- a/doc/devel/rfc/ProcHighLevelModel.txt +++ b/doc/devel/rfc/ProcHighLevelModel.txt @@ -1,15 +1,15 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-08-16_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-08-16_ +|*Proposed by* | Ichthyostega +|==================================== High-level model in the Steam-Layer ----------------------------------- -The purpose of this link:DesignProcess[] entry is to collect together +The purpose of this DesignProcess entry is to collect together informations regarding the design and structure of the high-level model of Lumiera's Steam-Layer. Most of the information presented here is already written down somewhere, in the @@ -21,7 +21,7 @@ tracks, which further helped to shape the model as presented here. While the low-level model holds the data used for carrying out the actual media data processing (=rendering), the high-level model is what the user works upon when performing edit operations through the GUI (or script driven in -"headless"). Its building blocks and combination rules determine largely what +``headless''). Its building blocks and combination rules determine largely what structures can be created within the http://www.lumiera.org/wiki/renderengine.html#Session[Session]. On the whole, it is a collection of @@ -68,8 +68,8 @@ possible to create cyclic connections by such arbitrary wiring, which will be detected by the builder and flagged as an error. While pipes have a rather rigid and limited structure, it is allowed to make -several connections to and from any pipe — even connections requiring an -stream type conversion. It is not even necessary to specify ''any'' output +several connections to and from any pipe -- even connections requiring an +stream type conversion. It is not even necessary to specify _any_ output destination, because then the wiring will be figured out automatically by searching the context and finally using some general rule. Connecting multiple outputs to the input of another pipe automatically creates a *mixing step* @@ -96,9 +96,9 @@ sort of a loose clustering of objects: it will derive the position from the placement it is attached to. Note that while the length and the in/out points are a _property of the MObject_ , it's actual location depends on how it is _placed_ and thus can be maintained quite dynamically. Note further that -effects can have an length on their own, thus by using these attachement -mechaics, the wiring and configuration within the high-level model can be quite -time dependant. +effects can have an length on their own, thus by using these attachment +mechanics, the wiring and configuration within the high-level model can be quite +time defendant. image:{imgd}/high-level2.png[] @@ -122,10 +122,10 @@ Example of an complete Session image:{imgd}/high-level3.png[] The Session contains several independent -http://www.lumiera.org/wiki/renderengine.html#EDL[EDL]s plus an output bus -section ( *global Pipes* ). Each EDL holds a collection of MObjects placed +link:/wiki/renderengine.html#EDL[EDL]s plus an output bus +section (**global Pipes**). Each EDL holds a collection of MObjects placed within a *tree of tracks* . Within Lumiera, tracks are a rather passive means -for organizing media objects, but aren't involved into the data processing +for organising media objects, but aren't involved into the data processing themselves. The possibility of nesting tracks allows for easy grouping. Like the other objects, tracks are connected together by placements: A track holds the list of placements of its child tracks. Each EDL holds a single placement @@ -138,7 +138,7 @@ track is anchored to some external entity (label, sync point in sound, etc), all objects placed relatively to this track will adjust and follow automatically. This relation between the track tree and the individual objects is especially important for the wiring, which, if not defined locally within an -MObject's placement, is derived by searching up this track tree and utilizing +MObject's placement, is derived by searching up this track tree and utilising the wiring plug locating pins found there, if applicable. In the default configuration, the placement of an EDL's root track contains a wiring plug for video and another wiring plug for audio. This setup is sufficient for getting @@ -151,7 +151,7 @@ Besides routing to a global pipe, wiring plugs can also connect to the source port of an *meta-clip*. In this example session, the outputs of EDL-2 as defined by locating pins in it's root track's placement, are directed to the source ports of a -http://www.lumiera.org/wiki/renderengine.html#VirtualClip[meta-clip] placed +link:/wiki/renderengine.html#VirtualClip[meta-clip] placed within EDL-1. Thus, within EDL-1, the contents of EDL-2 appear like a pseudo-media, from which the (meta) clip has been taken. They can be adorned with effects and processed further completely similar to a real clip. @@ -159,7 +159,7 @@ with effects and processed further completely similar to a real clip. Finally, this example shows an *automation* data set controlling some parameter of an effect contained in one of the global pipes. From the effect's POV, the automation is simply a -http://www.lumiera.org/wiki/renderengine.html[ParamProvider], i.e a function +link:/wiki/renderengine.html#ParamProvider[ParamProvider], i.e a function yielding a scalar value over time. The automation data set may be implemented as a bézier curve, or by a mathematical function (e.g. sine or fractal pseudo random) or by some captured and interpolated data values. Interestingly, in @@ -186,7 +186,7 @@ Pros ^^^^ * very open and modular, allows for creating quite dynamic object behaviour in - the sessison + the Session * implementation is rather simple, because it relies on a small number of generic building blocks @@ -213,11 +213,11 @@ Alternatives _Use the conventional approach:_ hard-wire a _reasonable simple_ structure and code the behaviour of tracks, clips, effects and automation explicitly, providing separate code to deal with each of them. Use the hard-wired - assumption that a clip consists of "video and audio". Hack in any advanced + assumption that a clip consists of ``video and audio''. Hack in any advanced features (e.g. support multi-camera takes) as GUI macros. Just don't try to support things like 3D video and spatial audio (anything beyond stereo and - 5.1). Instead, add a global "node editor" to make the geeks happy, allowing to - wire everything to everything, just static and global of course. + 5.1). Instead, add a global »node editor« to make the geeks happy, allowing to + wire everything to everything, just static and global of course. 😈 @@ -226,9 +226,9 @@ Rationale Ichthyo developed this design because the goal was to start out with the level of flexibility we know from Cinelerra, but try to do it considering all consequences right from start. Besides, the observation is that the development -of non-mainstream media types like steroscopic (3D) film and really convincing -spatial audio (beyond the ubiquitous "panned mono" sound) is hindered not by -technological limitations, but by pragmatism preferring the "simple" hard wired +of non-mainstream media types like stereoscopic (3D) film and really convincing +spatial audio (beyond the ubiquitous ``panned mono'' sound) is hindered not by +technological limitations, but by pragmatism preferring the ``simple'' hard wired approach. @@ -242,10 +242,11 @@ Comments Final ~~~~~ -Description of the Lumiera high level model as is. +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_proc_high_level_model_and_placement_concept[Apr.2011 developer meeting]. + +This is a description of the Lumiera high level model as-is. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ProcPlacementMetaphor.txt b/doc/devel/rfc/ProcPlacementMetaphor.txt index c89f5faa4..de0d188c0 100644 --- a/doc/devel/rfc/ProcPlacementMetaphor.txt +++ b/doc/devel/rfc/ProcPlacementMetaphor.txt @@ -1,15 +1,19 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-03-06_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process : Placement Metaphor +==================================== + +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-03-06_ +|*Proposed by* | Ichthyostega +|==================================== Placement Metaphor used within the high-level view of Steam-Layer ----------------------------------------------------------------- -besides the [wiki:self:../ProcBuilder Builder], one of the core ideas of the -``Proc-Layer'' (as being currently implemented by Ichthyo) is to utilize + +besides the link:{rfc}/ProcBuilder.html[Builder], one of the core ideas of +the Lumiera application, as envisioned and implemented currently, is to utilise _Placement_ as a single central metaphor for object association, location and configuration within the high-level model. The intention is to prefer _rules_ over fixed _values._ Instead of ``having'' a property for this and that, we @@ -18,24 +22,24 @@ query for information when it is needed. The proposed use of *Placement* within the steam layer spans several, closely related ideas: - * use the placement as a universal means to stick the "media objects" together + * using the placement as a universal means to stick the ``media objects'' together and put them on some location in the timeline, with the consequence of a unified and simplified processing. - * recognize that various _location-like_ degrees of freedom actually form a + * recognise that various _location-like_ degrees of freedom actually form a single _``configuration space''_ with multiple (more than 3) dimensions. * distinguish between _properties_ of an object and qualities, which are caused by ``placing'' or ``locating'' the object in _configuration space_ - - _propetries_ belong to the object, like the blur value, the media source + - _properties_ belong to the object, like the blur value, the media source file, the sampling/frame rate of a source - _location qualities_ exist only because the object is ``at'' a given location in the graph or space, most notably the start time, the output connection, the layering order, the stereoscopic window depth, the sound pan position, the MIDI instrument * introduce a _way of placement_ independent of properties and location - qualities, describing if the placement _itself_ is _absolute, relative or + qualities, describing if the Placement _itself_ is _absolute, relative or even derived_ - * open especially the possibility to _derive_ parts of the placement from - the context by searching over connected objects and then up the fork (``tree of tracks''); + * open especially the possibility to _derive_ parts of the Placement from + the context by searching over connected objects and then up the _Fork_ (``tree of tracks''); this includes the possibility of having rules for resolving unspecified qualities. @@ -71,7 +75,7 @@ On the contrary, using the *Placement* metaphor has the implication of switching to a query-driven approach. * it gives us one single instrument to express the various kinds of relations - * the _kind of placement_ becomes an internal value of the _placement_ (as + * the _kind of placement_ becomes an internal value of the _Placement_ (as opposed to the object) * some kinds of placement can express rule-like relations in a natural fashion * while there remains only one single mechanism for treating a bunch of @@ -124,7 +128,7 @@ Pros * modular and extensible * allows much more elaborate handling of media objects then the conventional approach, while both the simple standard case and the elaborate special case - are "first class citizens" and completely integrated in all object + are ``first class citizens'' and completely integrated in all object treatment. @@ -133,7 +137,7 @@ Cons ^^^^ * difficult to grasp, breaks with some habits * requires a separate resolution step - * requires to ''query'' for object properties instead of just looking up a + * requires to _query_ for object properties instead of just looking up a fixed value * forces the GUI to invent means for handling object placement which may go beyond the conventional @@ -149,13 +153,12 @@ Use the conventional approach * media objects are assigned with fixed time positions * they are stored directly within a grid (or tree) of tracks * layering and pan are hard wired additional properties - * implement an additional auto-link macro facility to attach sound to video + * implement an additional auto-link macro facility to attach sound to a video clip * implement a magnetic snap-to for attaching clips seamless after each other * implement a splicing/sliding/shuffling mode in the UI * provide a output wiring tool in the GUI - * provide macro features for this and that.... - -^hopefully I made clear by now _why_ I don't want to take the conventional approach^ + * provide macro features for this and that.... + + ^(hopefully I made clear by now _why_ I don't want to take the conventional approach)^ @@ -171,23 +174,23 @@ the conventional approach was dictated by technological limitations. * the ususal layering based on tracks constantly forces the user to place clips in a unnatural and unrelated fashion and tear apart clips which belong closely together - * the conventional approach of having a fixed "pan control" in specialized - "audio tracks" constantly hinders the development of more natural and + * the conventional approach of having a fixed ``pan control'' in specialized + ``audio tracks'' constantly hinders the development of more natural and convincing sound mixing. It favors a single sound system (intensity based stereophony) for no good reason. * handling of stereoscopic (3D) video/film is notoriously difficult within the conventional, hard wired approach - * building more elaborate sound scapes and sound design is notoriously - difficult to maintain, because the user is forced to use hidden "side - chains", magic rules and re-build details in external applications, because - of the lack of flexible integration of control data alongside with the main - data. + * building more elaborate soundscapes and sound design is notoriously + difficult to maintain, because the user is forced to use hidden + ``side chains'', magic rules and re-build details in external applications, + because of the lack of flexible integration of control data alongside + with the main data. The high-level model is close to the problem domain, it should provide means to express the (naturally complex) relationships between media objects. Using an abstract and unified concept is always better then having a bunch of seemingly unrelated features, even if they may be more easy to grasp for beginners. -Moreover, the Placement concept deliberately brings in an rule based approach, +Moreover, the Placement concept deliberately leads to a _rule based approach_, which well fits into the problem domain. Finally, there is sort-of a visionary aspect involved here: _Ichthyo_ thinks that nowadays, after image and sound are no longer bound to physical media, there is potential for new workflows to be @@ -205,7 +208,7 @@ Comments Placement Metaphor ~~~~~~~~~~~~~~~~~~ -Re: +[quote] ``Finally, there is sort-of a visionary aspect involved here: Ichthyo thinks that nowadays, after image and sound are no longer bound to physical media, there is potential for _new workflows_ to be @@ -225,13 +228,15 @@ use, and decision rules based on these parameters. This feature/capability is likely to stamp the Lumiera project as a flagship benchmark in more ways than one, for some time. - . --link:Tree[][[DateTime(2008-08-23T12:54:00NZ)]]. + Tree:: '2008-08-23T12:54:00NZ' Final ~~~~~ - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_proc_high_level_model_and_placement_concept[Apr.2011 developer meeting]. + + +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/RefactorLiblumieraOut.txt b/doc/devel/rfc/RefactorLiblumieraOut.txt index c31fb06a2..31ad2c586 100644 --- a/doc/devel/rfc/RefactorLiblumieraOut.txt +++ b/doc/devel/rfc/RefactorLiblumieraOut.txt @@ -3,87 +3,81 @@ Refactor Liblumiera Out // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Fr 22 Apr 2011 10:46:50 CEST_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Fr 22 Apr 2011 10:46:50 CEST_ +|*Proposed by* | Christian Thaeter +|==================================== -[abstract] ******************************************************************************** -liblumiera contains alot useful and reuseable code which is already in use by -other projects +.Abstract +`liblumiera` contains a lot of useful and re-useable code +which is already in use by other projects ******************************************************************************** Description ----------- //description: add a detailed description: -Over the time we've put some efforts into the liblumiera. I've added -some from my code which predates the lumiera project which I am using -on many other projects. This now caused that I maintain this sources in -different unrelated projects and have to cross merge and update stuff -when I do updates and fixes somewhere. I think its time to factor the -reuseable parts out into a independent library (like glib does for -gtk), in fact I had this plan long ago. +Over the time we've put some efforts into the liblumiera. I have added +some from my code which predates the Lumiera project and which I am using +on many other projects. This means that I would have to maintain thsese +sources in different unrelated projects and have to cross merge and update +several copies of the same code when I do updates and fixes somewhere. +I think its time to factor the re-useable parts out into a independent +library (similar to what Glib does for GTK). In fact, I had this plan long ago. .What parts are eligible for a standalone library - Anything which is something tool alike and useful for other projects and not tied to Lumiera only. This are the algorithms/datastructures, allocators, tool macros. Additionally some of the src/common things should be moved into the library. I give some lists below. .How to name it - -Long time ago my plan was to name it 'ctlib' or 'cehlib' but meanwhile there is +Long time ago my plan was to name it `ctlib' or `cehlib' but meanwhile there is enough code done by others. So I'd propose a more neutral name, still -'lumieralib' or 'lulib' would be approbiate. The only thing we have to account +`lumieralib' or `lulib' would be appropriate. The only thing we have to account for is that some parts which are too specific for Lumiera and should not be integrated into this spinoff need either to stay in a lumiera-internal lib (src/lib/) as currently or being moved to the respective subsystems using them (src/backend, src/proc, src/common, ...), so the names should not clash. .C, C++ ... - -For myself I need the C parts, while there is C++ code which interfaces to the -C implementations and also a lot code which does nice C++ things on its own. +For myself I need the C parts, while there is C\++ code which interfaces to the +C implementations and also a lot code which does nice C\++ things on its own. This possibly means that we should in fact make 2 packages out of this, one C -and one C++ library (where the C++ part is more than just the wrappers, but -also the tools and tricks which are currently in src/lib/ and reuseable). +and one C\++ library (where the C++ part is more than just the wrappers, but +also the tools and tricks which are currently in 'src/lib/' and reuseable). .Who maintains it - -Despite a spin of I think we don't want to change anything from our current -practice and maintain it by the Lumiera developers. For many parts I feel -responsible for it, but its really a part of the Lumiera codebase, despite -independently useable. +Despite of being a spin-off I think we don't want to change anything from our +current practice and maintain it by the Lumiera developers. In part I feel +responsible for it, while it is really a part of the Lumiera codebase, +despite of being independently useable. .How to maintain it - We need to decide about build system and documentation system. As build system -we may right start using scons. For documentation the situation is a but +we may right start using SCons. For documentation the situation is somewhat different since some of my code uses pipadoc/asciidoc and other uses doxygen. .What not to do - Some of the code is currently quite specific to Lumiera while it could be made -more generic. This is *NOT* subject of this RFC we may or may not do such a -refactoring but this RFC and any work resulting from this should only restrict +more generic. This is _NOT_ subject of this RfC -- we may or may not do such a +refactoring but this RfC and any work resulting from this should be restricted to simple things like necessary namespace and variable renaming and integration in the build system. C Parts -------- +~~~~~~~ Library -~~~~~~~ +^^^^^^^ What belongs to the library Containers -^^^^^^^^^^ +++++++++++ * cuckoo hashing (cuckoo.c|h) * linked lists (llist.h slist.h) * cache lists (mrucache.c|h) @@ -91,29 +85,29 @@ Containers * priority queues (not done yet) Runtime tools -^^^^^^^^^^^^^ ++++++++++++++ * error handling (error.h error.c) used by the other facilities too * clib convinience wrapers (safeclib.c|h) needs better name, maybe refactor into new facilities Multithreading -^^^^^^^^^^^^^^ +++++++++++++++ * locking, condition variables etc. (condition.c|h (rec)mutex.c|h, rwlock ...) Memory management -^^^^^^^^^^^^^^^^^ ++++++++++++++++++ * Memory pools (mpool.c|h) * Temporary buffers (tmpbuf.c|h) Metaprogramming -^^^^^^^^^^^^^^^ ++++++++++++++++ * preprecessor tools (ppmpl.h) move common preprocessor macros here * polymorphic call helper for C (vcall.h) Interface system and module loader -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +++++++++++++++++++++++++++++++++++ -except for some hardcoded references to 'lumiera_org' and '.lum' plugin names +except for some hardcoded references to `lumiera_org' and `.lum' plugin names this is quite generic, possibly moving this over could be postponed, but might eventually be done. @@ -124,26 +118,26 @@ interfaceregistry.c interfaceregistry.h plugin.c plugin_dynlib.c plugin.h ------ -The 'config' system could become a candidate too if it ever gets finished and -proved useful, but for the time being its better kept in Lumiera. +The ``config system'' could become a candidate too if it ever gets finished and +proves itself useful, but for the time being it's better kept in Lumiera. Not Library -~~~~~~~~~~~ -Too specific to Lumiera: +^^^^^^^^^^^ +Tied specifically to Lumiera: ----- luid.c luid.h time.h ----- C++ Parts ---------- +~~~~~~~~~ -For most of the C++ parts I am not sure, ichthyo should decided upon these +For most of the C++ parts I am not sure, _ichthyo_ should decide upon these (please edit this here) Library -~~~~~~~ +^^^^^^^ These look 'generic' or wrap the C parts: ------ singleton-factory.hpp singleton.hpp singleton-policies.hpp @@ -154,7 +148,7 @@ util.hpp variant.hpp ------ Not Sure -~~~~~~~~ +^^^^^^^^ ------ access-casted.hpp advice advice.hpp allocation-cluster.cpp allocation-cluster.hpp bool-checkable.hpp cmdline.cpp cmdline.hpp del-stash.hpp @@ -175,12 +169,14 @@ option.hpp query subsys.cpp subsys.hpp subsystem-runner.hpp Not Library -~~~~~~~~~~~ +^^^^^^^^^^^ ------ logging.cpp nobug-init.cpp nobug-init.hpp streamtype.cpp streamtype.hpp test/* time/* time.cpp tree.hpp ----- + + Tasks ~~~~~ // List what needs to be done to implement this Proposal: @@ -213,17 +209,14 @@ Cons Alternatives ^^^^^^^^^^^^ //alternatives: explain alternatives and tell why they are not viable: +Do nothing and handle fixes on a case by case base. -Rationale ---------- -//rationale: Give a concise summary why it should be done *this* way: - //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -237,4 +230,4 @@ Comments //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/RenderOptimizer.txt b/doc/devel/rfc/RenderOptimizer.txt index d5b28319b..b2312b73e 100644 --- a/doc/devel/rfc/RenderOptimizer.txt +++ b/doc/devel/rfc/RenderOptimizer.txt @@ -1,14 +1,14 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2007-06-07_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2007-06-07_ +|*Proposed by* | ct +|==================================== Render Optimizer ---------------- -Render only parts of a frame which are necessary for the Output; Optimize -render pipeline for efficiency +Render only parts of a frame which are necessary for the Output; +optimize render pipeline for efficiency Description @@ -28,62 +28,30 @@ output as the original sequence of effects. -Tasks -^^^^^ - - - - -Discussion -~~~~~~~~~~ - -Pros -^^^^ - - - -Cons -^^^^ - - - -Alternatives -^^^^^^^^^^^^ - - - -Rationale -~~~~~~~~~ - - - - - - Comments -------- Possible classification for video filters: + 1. The filter only changes the color of each pixel in the same way 2. The filter deforms the image but leaves the color 3. The filter makes complex things. The only additional hint it can export is - the - number of referenced past frames, if such a limit exists (sometimes it + the number of referenced past frames, if such a limit exists (sometimes it doesn't). Filters of type 1 and type 2 never use any previous frames, and are strictly -one frame in - one frame out. Filters of type 1 can always be swapped with +one frame in -- one frame out. Filters of type 1 can always be swapped with filters of type 2, the output is the same. All other filters cannot be swapped in general. The good news is, that: 1. All commonly used filters are either type 1 or type 2 - (type 3 are more the fun effects) + (type 3 are more the fun effects) 2. Filters of type 2 are colormodel agnostic - 3. If a filter of type 1 makes only linear transformations of the color - vectors (new_color = matrix * old_color), - the matrix can be transformed from e.g. RGB to YUV, so these filters can + 3. If a filter of type 1 makes only linear transformations of the color vectors + + (i.e.: new_color ≔ matrix · old_color), + then the matrix can be transformed from e.g. RGB to YUV, so these filters can always work in both colorspaces directly @@ -91,10 +59,10 @@ Parked ~~~~~~ Generally this is accepted but needs some more polishing when we go over it. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/RepositorySetup.txt b/doc/devel/rfc/RepositorySetup.txt index e01bfed99..4b2dbb039 100644 --- a/doc/devel/rfc/RepositorySetup.txt +++ b/doc/devel/rfc/RepositorySetup.txt @@ -1,12 +1,12 @@ Design Process: Repository Setup ================================ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-09_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-09_ +|*Proposed by* | ct +|==================================== Repository Setup ---------------- @@ -31,18 +31,15 @@ far incomplete works for this) ------------------------------------------------------------ -The cinelerra2 sources are put into oldsrc on a per-case base. +The Cinelerra-2 sources are put into `oldsrc` on a per-case base. -We want to use the new GIT feature of "Superprojects and Submodules" when it is +We want to use the new GIT feature of ``Superprojects and Submodules'' when it is ready for general use. Then we will transform several subtrees into separate GIT repos which will be linked to from the main Project (then called the -"Superproject") as submodules. +_Superproject_) as _Submodules_. -Tasks -~~~~~ - Pros ^^^^ * Because its a text-like structure, it is partially self-documenting @@ -52,70 +49,79 @@ Pros Cons ^^^^ * Can get large and confusing - * has no real "portal" or entrance point for people wanting to join - -Alternatives -^^^^^^^^^^^^ - + * has no real ``portal'' or entrance point for people wanting to join Rationale ~~~~~~~~~ Every important document, draft, text and code (including) prototypes should be -checked into one SCM (or a set of related SCMs). This repo should be "almost -everything" you need for the project. Because we try to use a distributed -developement model, every dev can/should have his own copy and fed his changes +checked into one SCM (or a set of related SCMs). This Repo should be ``almost +everything'' you need for the project. Because we try to use a distributed +development model, every dev can/should have his own copy and fed his changes back. -This 'Repository aproach' avoids the problems of a central infrastructure and +This ``Repository approach'' avoids the problems of a central infrastructure and helps cut down project management time. Basically, every dev is responsible -himself for getting every important piece of information added into "the -general view of matters" in a consitent way. +himself for getting every important piece of information added into ``the +general view of matters'' in a consistent way. Comments -------- - Basically the structure is just fine. -- Maybe add a "pastebin" somewhere in the dev-documentation area? +- Maybe add a ``pastebin'' somewhere in the dev-documentation area? - I would add the source tree roots at level 2, so we can have several submodules here: - * oldsrc - * cin3 - * prototype - link:Ichthyostega[] -- Draft now. -- Yes I left source dirs out but this sounds fine, note that with git, there is - no problem to reorganize the repo (in contrast to CVS) later. We can fix - things afterward when we find better ways. -- link:ct[] - [[DateTime(2007-06-17T17:36:46Z)]] -- Whats prototype for? won't that be better a branch? -- link:ct[] - [[DateTime(2007-06-17T22:04:39Z)]] -- I just wanted to show there could be additional things beside the main tree - (later to be separete submodules). The example was meant as a classical - throwaway prototype. But I agree, in our case we just start hacking at the - new tree and make feature/tryout/prototype branches... -- The point I wanted to make is: every directory 2 levels deep in the source - tree, e.g. /src/cinelerra3 or /src/oldsrource should be a completely - self-contained tree which can be built without needing anything of the rest - of the repo. Thats an prerequisite for moving to Submodules IMHO. But you - seem rather to put the sourcetree-roots 1 level deep. As we have just two - trees at the moment (and can easily reorganize), I have no objections against - this. The only point I really care is to try to keep the source tree - self-contained without any dependencies to the rest of the "design GIT" - (because of this Superprojects-Submodules thing...) -- link:Ichthyostega[] - [[DateTime(2007-06-17T23:45:06Z)]] -- We could make the trees deeper than one level, I didn't intended 1-level - depth. but also be careful with that not to make it too complex. While I am - not sure if we want a complete oldsrc, that just adds weight and confusion - for now (lets see). Neither I am fully decided about the hierachy in /src - (want /libs /plugins or /src/libs /src/plugins or /src/render/plugins? name - it rather 'effects' than 'plugins'?). While I am quite sure that I want to - separate /oldssrc and /src quite much (in /src should only be new stuff or - stuff which is carefully reviewed, with known license and author). -- - link:ct[] [[DateTime(2007-06-18T08:38:43Z)]] -- I made this proposal 'final' now further details are likely better worked out - in the git repository (and we already started to define things there) see - ./admin/treeinfo.sh -- link:ct[] [[DateTime(2007-06-27T16:01:52Z)]] + ** oldsrc + ** cin3 + ** prototype + +Ichthyostega:: 6/2007 -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Yes I left source dirs out but this sounds fine, note that with git, there is +no problem to reorganize the repo (in contrast to CVS) later. We can fix +things afterward when we find better ways. + +ct:: '2007-06-17T17:36:46Z' + +Whats prototype for? won't that be better a branch? + +ct:: '2007-06-17T22:04:39Z' + +I just wanted to show there could be additional things beside the main tree +(later to be separate submodules). The example was meant as a classical +throwaway prototype. But I agree, in our case we just start hacking at the +new tree and make feature/tryout/prototype branches... + +The point I wanted to make is: every directory 2 levels deep in the source +tree, e.g. /src/cinelerra3 or /src/oldsrource should be a completely +self-contained tree which can be built without needing anything of the rest +of the repo. Thats an prerequisite for moving to Submodules IMHO. But you +seem rather to put the sourcetree-roots 1 level deep. As we have just two +trees at the moment (and can easily reorganize), I have no objections against +this. The only point I really care is to try to keep the source tree +self-contained without any dependencies to the rest of the ``design GIT'' +(because of this Superprojects-Submodules thing...) + +Ichthyostega:: '2007-06-17T23:45:06Z' + +We could make the trees deeper than one level, I didn't intended 1-level +depth. but also be careful with that not to make it too complex. While I am +not sure if we want a complete oldsrc, that just adds weight and confusion +for now (lets see). Neither I am fully decided about the hierarchy in /src +(want /libs /plugins or /src/libs /src/plugins or /src/render/plugins? name +it rather 'effects' than 'plugins'?). While I am quite sure that I want to +separate /oldssrc and /src quite much (in /src should only be new stuff or +stuff which is carefully reviewed, with known license and author). + +ct:: '2007-06-18T08:38:43Z' + +I made this proposal 'final' now further details are likely better worked out +in the Git repository (and we already started to define things there) see +./admin/treeinfo.sh + +ct:: '2007-06-27T16:01:52Z' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ResourceManagementBudgeting.txt b/doc/devel/rfc/ResourceManagementBudgeting.txt index ffa488e5c..e4db5b5a4 100644 --- a/doc/devel/rfc/ResourceManagementBudgeting.txt +++ b/doc/devel/rfc/ResourceManagementBudgeting.txt @@ -3,19 +3,20 @@ Resource Management: Budgeting // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Fri Jul 23 20:33:32 2010_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Fri Jul 23 20:33:32 2010_ +|*Proposed by* | Christian Thaeter +|==================================== [abstract] ****************************************************************************** -The Profiler will give some Idea about how much Resources can me used to +The link:{rfc}/ResourceManagementProfiling.html[Profiler] +will give some Idea about how much Resources can be used to optimally utilize the system. Knowing this number leads to the next challenge, -distributing the resources to different subsystems, jobs and objects. I here -introduce a budgeting system which takes care for this. +distributing the resources to different subsystems, jobs and objects. Here, I +introduce a budgeting system which takes care of this. ****************************************************************************** @@ -33,6 +34,60 @@ available for anyone. +Tasks +~~~~~ +// List what would need to be done to implement this Proposal in a few words: + * define a sufficiently well defined goal first, to describe + what shall and can be achieved through budgeting ... + * then develop a plausible model of suitable control and regulation mechanisms + * very likely, practical tests will be required to show the feasibility of + effective automatic regulation over a significant span of different + use cases! + + + +Discussion +~~~~~~~~~~ + +Pros +^^^^ +// add just a fact list/enumeration which make this suitable: +// * foo +// * bar ... + + + +Cons +^^^^ +// fact list of the known/considered bad implications: + + + +Alternatives +^^^^^^^^^^^^ +//alternatives: if possible explain/link alternatives and tell why they are not viable: + + + +Rationale +--------- +//rationale: Describe why it should be done *this* way: + + + +//Conclusion +//---------- +//conclusion: When approved (this proposal becomes a Final) write some +// conclusions about its process: + + + + +Comments +-------- +//comments: append below + + [source,C] ------------------------------------------------------------------------------ typedef ssize_t budget_count; @@ -64,58 +119,36 @@ struct budget }; ------------------------------------------------------------------------------ +ct:: '2010-07-23 20:55:49 CEST' +.... +​ +​ +​ +.... +[[caveat]] +[underline]#Many years later,# I'd like to confirm that this RfC describes +a part of the *core vision*: + +the engine shall make best use of limited resources. -Tasks -~~~~~ -// List what would need to be done to implement this Proposal in a few words: -// * item ... +CAUTION: The same caveats as for the + link:{rfc}/ResourceManagementProfiling.html#caveat[Profiling] + do apply here as well... +I'd recommend to be extremely cautions to take any achievement for granted +for this topic, which is known to be notoriously difficult and insidious. +With _budgeting alone,_ we may be able to prevent overload of the system, +yet for anything beyond that, we need an actual optimisation strategy. +Ichthyostega:: '2025-09-17' -Discussion -~~~~~~~~~~ - -Pros -^^^^ -// add just a fact list/enumeration which make this suitable: -// * foo -// * bar ... - - - -Cons -^^^^ -// fact list of the known/considered bad implications: - - - -Alternatives -^^^^^^^^^^^^ -//alternatives: if possible explain/link alternatives and tell why they are not - viable: - - - -Rationale ---------- -//rationale: Describe why it should be done *this* way: - - - -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) write some - conclusions about its process: - - - - -Comments --------- -//comments: append below - //endof_comments: + + + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ResourceManagementProfiling.txt b/doc/devel/rfc/ResourceManagementProfiling.txt index bfd1b2731..a2c9c9e02 100644 --- a/doc/devel/rfc/ResourceManagementProfiling.txt +++ b/doc/devel/rfc/ResourceManagementProfiling.txt @@ -3,31 +3,34 @@ Resource Management: Profiling // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Fri Jul 23 19:34:29 2010_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Fri Jul 23 19:34:29 2010_ +|*Proposed by* | Christian Thaeter +|==================================== [abstract] ****************************************************************************** -From the beginning on we planned some kind of 'profiling' to adapt dynamically -to workload and machine capabilities. I describe here how statistic data can be -gathered in a generic way. This will later work together with other components +Right from the beginning of the project we planned some kind of _profiling_ +to adapt dynamically to current workload and machine capabilities. +I describe here how statistic data can be gathered in a generic way. +This will later work together with other components tuning the system automatically. ****************************************************************************** +-> link:{rfc}/ResourceManagementBudgeting.html[RfC: use gathered data for budgeting...] + Description ----------- //description: add a detailed description: I just introduce some ideas about the planned profiling framework here, nothing -is defined/matured yet this is certainly subject for futher discussion and +is defined/matured yet this is certainly subject for further discussion and refinement. -.Requirements/Evaluation generic:: + Requirements/Evaluation generic:: Profiling should be sufficiently abstracted to have a single set of datastructures and algorithms to work on a broad range of subjects being profiled. Moreover the profiling core just offers unitless @@ -49,7 +52,7 @@ refinement. such false alarms. Workload also changes over time we need to find some way to measure the current/recent workload an grand total over the whole application runtime is rather uninteresting. While it is also - important that we adapt slow enough not to get into some osccilating + important that we adapt slow enough not to get into some oscillating cycle. active or passive system:: @@ -59,10 +62,60 @@ refinement. +Tasks +~~~~~ +// List what would need to be done to implement this Proposal in a few words: + * develop a concept to outline what we actually want to observe ... + * refine this into a model to describe the observables + * derive an assessment of the specific requirements and challenges of this measurement + * use _this_ as the starting-point for an implementation draft ... +Discussion +~~~~~~~~~~ + +Pros +^^^^ +// add just a fact list/enumeration which make this suitable: +// * foo +// * bar ... + + + +Cons +^^^^ +// fact list of the known/considered bad implications: + + + +Alternatives +^^^^^^^^^^^^ +//alternatives: if possible explain/link alternatives and tell why they are not viable: + + + +Rationale +--------- +//rationale: Describe why it should be done *this* way: + + + +//Conclusion +//---------- +//conclusion: When approved (this proposal becomes a Final) +// write some conclusions about its process: + + + + +Comments +-------- +//comments: append below + + + .Brainstorming in Code [source,C] ------------------------------------------------------------------------------ @@ -127,56 +180,45 @@ struct profile }; ------------------------------------------------------------------------------ - -Tasks -~~~~~ -// List what would need to be done to implement this Proposal in a few words: -// * item ... +ct:: '2010-07-23 20:33:13 CEST' +.... +​ +​ +​ +.... +[[caveat]] +[underline]#Many years later,# I'd like to confirm that we need and want some +kind of profiling in the engine, for the purpose described in this RfC, which is +to fine-tune our operation parameters dynamically. +We should however be _careful_ not to settle down onto an implementation in our +mind _before_ having conducted a proper *requirement analysis*. Starting from +the valid idea what can be done with profiling and statistic, the first thing +to map out is what we actually want to achieve and to which degree this can +be reasonably achieved. From there we should head towards a model to +describe what we want to observe, and only from there we'll be able +to pick suitable measurement methods. -Discussion -~~~~~~~~~~ +^(I have just added these step to the ``Tasks'' section)^ -Pros -^^^^ -// add just a fact list/enumeration which make this suitable: -// * foo -// * bar ... +WARNING: we should drop the pre-established conception that what we capture + here is simple, and can be squeezed into a single data representation. +If it turns out that we're headed towards high-throughput processing, +we should keep possible solutions at the architecture level in mind, before +focusing on details of the implementation. Messaging systems and lock-free +data structures have made significant progress over the last decade. +-> see also my link:{rfc}/ResourceManagementBudgeting.html#caveat[remark to RfC:Budgeting] -Cons -^^^^ -// fact list of the known/considered bad implications: - - - -Alternatives -^^^^^^^^^^^^ -//alternatives: if possible explain/link alternatives and tell why they are not - viable: - - - -Rationale ---------- -//rationale: Describe why it should be done *this* way: - - - -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) write some - conclusions about its process: - - - - -Comments --------- -//comments: append below - +Ichthyostega:: '2025-09-17' //endof_comments: + + + + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/Roadmap-first.txt b/doc/devel/rfc/Roadmap-first.txt index 419d591a8..c2943b4e8 100644 --- a/doc/devel/rfc/Roadmap-first.txt +++ b/doc/devel/rfc/Roadmap-first.txt @@ -1,28 +1,30 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2009-01-30_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process : Roadmap +======================== + +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2009-01-30_ +|*Proposed by* | Ichthyostega +|==================================== -Roadmap up to Lumiera 1.0 -------------------------- +A Roadmap leading to Lumiera 1.0 +-------------------------------- As the very basic architecture questions seem to settle down now, it seems to be time to create a first Roadmap skeleton for the project. A specific approach is proposed: we should define criteria allowing us to judge when we've reached -a certain level plus we should define features to be ''excluded'' at a certain -level. We should -''not'' define ''Features'' to go into a certain level. +a certain level plus we should define features to be _excluded_ at a certain +level. We should _not_ define _Features_ to go into a certain level. -''the following text is copied from the Lumiera - https://issues.lumiera.org/roadmap[Trac]'' +TIP: the following text is copied from the Lumiera + https://issues.lumiera.org/roadmap[Trac] -Description: Milestones up to first Release -------------------------------------------- +Description: Milestones up to the first stable Release +------------------------------------------------------ Milestone integration: cooperating parts to render output @@ -30,16 +32,16 @@ Milestone integration: cooperating parts to render output For this milestone to be reached, the basic subsystems of Lumiera need to be designed, the most important interfaces between the parts of the application exist in a first usable version, and all the facilities on the rendering code -path are provided at least in a dummy version and are '''capable of cooperating -to create output'''. Based on Lumiera's design, this also means that the basic +path are provided at least in a dummy version and are *capable of cooperating +to create output*. Based on Lumiera's design, this also means that the basic frame cache in the vault layer is working. And it means that a media asset and a clip can be added to the internal session representation, which is then handed over to the builder. Probably it's a good idea to include basic playback/display of the rendered frames within the GUI while they are created. -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * no saving and loading of sessions * no manipulation of objects though the GUI (just display of the session) * no adding of arbitrary media or inclusion of arbitrary plugins @@ -50,18 +52,18 @@ Notable features ''not'' included Milestone alpha: operations accessible for users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For this milestone to be reached, the fundamental operations you'd expect from -a video editing software can be '''accessed by a user''' (not a developer!). -This means that the basic distribution/release model is set up, a ''user'' is +a video editing software can be *accessed by a user* (not a developer!). +This means that the basic distribution/release model is set up, a _user_ is able to compile Lumiera or install an existing package. Moreover a user should be able to create/open a session file (without any quirks), add some media (probably only a limited number of media types will be supported), and then perform the most basic operations like positioning, trimming, copying, playing -and finally rendering the timeline integration phase is closed and Lumiera has -reached alpha level. +and finally rendering the timeline. Once this level of functionality is +achieved, the _integration phase_ is closed and Lumiera has reached alpha level. -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * advanced configuration * complex/compound projects * meta-clips, multi-cam, advanced multi channel sound handling @@ -75,23 +77,23 @@ Notable features ''not'' included Milestone beta: usable for real work ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For this milestone to be reached, users should be able to '''get real work done -with Lumiera'''. Especially, a basic asset management should be in place, +For this milestone to be reached, users should be able to *get real work done* +with Lumiera. Especially, a basic asset management should be in place, Lumiera should be able to handle the most common media types, the user should -be able to do common editing tasks (adding, trimming, rolling, splicing -copying, moving) both by direct manipulation within the timeline, as by using +be able to perform common editing tasks (add, move, copy, splice, trim, roll, +slide, slip) both by direct manipulation within the timeline, as by using the conventional two-viewer setup with in/out points. Moreover, it should be possible to attach effects (probably still just some limited kinds of effects), apply simple transitions and control the layering and overlay mode on output. Similarily, the elementary routing capabilities and the handling of multiple sequences should be suported (probably still with limitations). The framework for automation handling should be in place, while there may be still -limitations on automation/keyframe editing. Having about this feature set -indicates, that Lumiera entered the beta phase. +limitations on automation/keyframe editing. Having implemented roughly +this feature set indicates that Lumiera can enter the beta phase. -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * configuration editing through the GUI * advanced routing, full support of virtual clips * arbitrary wiring, macro effects or similar @@ -99,25 +101,25 @@ Notable features ''not'' included * arbitrary nesting and navigation within projects * full multi-cam support, support for non-standard image/sound types * plugin libraries and packaging - * interfaces for plugin authors are not frozen! + * interfaces for plugin authors are _not yet_ frozen! * fully configurable GUI * full support for proxy editing everywhere - * extended workflow features (like "export to DVD") + * extended workflow features (like ``export to DVD'') Milestone release-1.0: usable for productions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For this milestone to be reached, Lumiera should be a '''reliable tool for -productions with a deadline'''. Lumiera 1.0 is not the ''dream machine,'' but -users should be able to do simple productions. We should be able to promote -Lumiera to professionals without remorse. The GUI should be mature, +For this milestone to be reached, Lumiera should be a *reliable tool for +productions with a deadline*. Lumiera 1.0 is not the ``dream machine'', but +users should be able to complete simple productions. We should be able to +promote Lumiera to professionals without remorse. The GUI should be mature, undo/recovery should work airtight, performance should be ok-ish and output quality without any glitches. Plugin authors can rely on stable interfaces and backwards compatibility from now on, up to release 2.0 -Notable features ''not'' included -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Notable features _not_ included +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * bangs and whistles * render farm, distributed execution, hardware acceleration * MIDI and adding of non-standard media kinds yet-to-appear @@ -126,17 +128,11 @@ Notable features ''not'' included * foreign session import/export * collaboration features * artificial intelligence + * saving the world -Tasks -+++++ -Please review and discuss this proposal, consider if it's of any use setting it -up this way... - - - Discussion ~~~~~~~~~~ @@ -151,7 +147,7 @@ Pros Cons ^^^^ The contents of the roadmap aren't very specific and thus aren't of much help -for determining ''what has to be done next.'' +for determining _what has to be done next._ @@ -165,18 +161,17 @@ Alternatives Rationale ~~~~~~~~~ -We deliberately don't set any date schedule. Releases happen ''when they are -ready.'' We may decide to do sprints on a short-term timeframe, but it doesn't -help promising things we can't calculate for sure. In an commercial setup, you -have to commit to features and dates, but you also control a certain budget, -which gives you the means to ''make things happen.'' In Open Source -development, we've to be patient and wait for the things to happen ;-) +We deliberately don't set any date schedule. Releases happen ``when they are +ready''. We may decide to do sprints on a short-term timeframe, but it doesn't +help promising things we can't plan and calculate reliably. In an commercial setup, +you have to commit to features and dates, but you also control a certain budget, +which gives you the means to _make things happen._ In Free Software development, +we have to be patient and wait for great things to happen 😇 -Thus the proposal is to set up just a very coarse and almost self-evident -roadmap skeleton, but to discuss and define criteria up-front, which allow us -to determine when we've actually reached a given level. Moreover, the proposal -is to add a list of features which can be savely ''excluded'' from the given -milestone +Thus the proposal aims to set up just a very coarse and almost self-evident +roadmap skeleton, but also to discuss and define criteria up-front, which allow us +to determine when we've actually reached a given level. Furthermore, the proposal +provides a list of features which can be savely _excluded_ from a given milestone. @@ -186,21 +181,34 @@ milestone Comments -------- -Looks ok to me, the dust is settling ad we can now think about such a roadmap. +Looks ok to me, the dust is settling and we can now think about such a roadmap. Some goals might be shifted between Milestones on collaborative decision, but so far I agree. Otherwise I'd like to keep the issue tracker focus on work to be done, it shall not become a wishlist tool for non developers, any such things are deliberately left out. - -- link:ct[] 2009-01-31 -In ticket #4 (debian packaging) i explained that packaging might be optional -for 'alpha' and should be moved to 'beta'. - -- link:ct[] 2009-02-01 +ct:: '2009-01-31' + +In https://issues.lumiera.org/ticket/4[#4 (debian packaging)] i explained that +packaging might be optional for ``alpha'' and should be moved to ``beta''. + +ct:: '2009-02-01' OK, we should make the packaging optional. I think, for alpha the criterion is -"accessability for users". If compiling remains so easy as it is now (compared +``accessability for users''. If compiling remains so easy as it is now (compared with other media related projects), than this shouldn't be a barrier. - -- link:Ichthyostega[] 2009-02-01 + +Ichthyostega:: '2009-02-01' + +[underline]#Many years later# I can confirm that this approach towards a roadmap +and release planning stood well the test of time and looks reasonable still. + +The joke with ``artificial intelligence'' got a nice ring meanwhile, +as many people seem to believe that we're close to the AI miracle. +And since Lumiera might indeed integrate some _tools_ based on +``machine learning'' eventually, it seems adequate to point out +that we can not _save the world_ already in Release 1.0 -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SchedulerRequirements.txt b/doc/devel/rfc/SchedulerRequirements.txt index dd729ff13..5266a44fd 100644 --- a/doc/devel/rfc/SchedulerRequirements.txt +++ b/doc/devel/rfc/SchedulerRequirements.txt @@ -3,12 +3,12 @@ SchedulerRequirements // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Mi 09 Jan 2013 12:04:03 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _Mi 09 Jan 2013 12:04:03 CET_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract @@ -170,7 +170,7 @@ scheduler and vault layer implementation. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -193,4 +193,4 @@ Ichthyostega:: 'Do 19 Sep 2013 21:31:07 CEST' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ScriptingLanguage.txt b/doc/devel/rfc/ScriptingLanguage.txt index f1a39c5ae..d7e09e178 100644 --- a/doc/devel/rfc/ScriptingLanguage.txt +++ b/doc/devel/rfc/ScriptingLanguage.txt @@ -1,13 +1,16 @@ -[grid="all"] -`------------`----------------------- -*State* _Pending_ -*Date* _2008-07-26_ -*Proposed by* link:ct[] -------------------------------------- +Design Process : Scripting Language +=================================== + +[options="autowidth"] +|==================================== +|*State* | _Pending_ +|*Date* | _2008-07-26_ +|*Proposed by* | ct +|==================================== -Scripting Language ------------------- +Required Scripting Language +--------------------------- Add support for the *Lua* scripting language in Lumiera. @@ -21,7 +24,7 @@ as »official« scripting language. Tasks ^^^^^ * Investigate Lua's C bindings and integrate it - * It will attach to the link:Plugin/Interface[] System cehteh is working on + * It will attach to the Plugin/Interface System cehteh is working on Pros @@ -50,7 +53,7 @@ Rationale Wee need scripting yet alone for driving the testsuite soon. Later on scripting might be used to customize workflows and other application internals. Further one might implement a high level / batch interface to lumiera to give it a -scripting interface similar to link:AviSynth[]. +scripting interface similar to the https://en.wikipedia.org/wiki/AviSynth[Frameserver »AviSynth«]. @@ -105,7 +108,7 @@ ct:: '2008-07-30T16:22:32Z' I have no problems using Lua. It is proven in the industry, well supported, -fast, efficient, high level and designed for this purpose. My only "complaint" +fast, efficient, high level and designed for this purpose. My only ``complaint'' is that Lua isn't my pet language (Scheme). And that really isn't a complaint at all. @@ -115,7 +118,7 @@ PercivalTiglao:: '2008-07-28T19:56:25Z' I think Python should be reconsidered: it's given that all languages in this class are powerful at what they do, however python has particularly well developed libraries and is used as the scripting language in the main raster -(GIMP), vector (Inkscape) and 3D (Blender, link:PythonOgre[], PyCrystal) Apps. +(GIMP), vector (Inkscape) and 3D (Blender, PythonOgre, PyCrystal) Apps. Combinations of these Apps are all going to be working in a stack in professional production, so the fact that all the others use python makes a more persuasive case for adoption than any micro-benefit in performance or @@ -126,8 +129,9 @@ get this into professional production houses, then I think having a single language from OS admin the whole way through the stack is a massive gain for the types of users who will be using it. I personally prefer Ruby. Naturally it's your decision to make, all the best, we are looking forward to alphas and -betas in the future + - -- *mytwocents* +betas in the future + +mytwocents:: 'Aug.2008' This proposal is about the _required_ scripting language, i.e. when @@ -201,5 +205,5 @@ Lua was _accepted_ as the required scripting language by October.2008 dev meeting. However, Ichthyo _questions and overrules_ this decision in Feb.2023 and moves this proposal back into the inception stage. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SemanticTags.txt b/doc/devel/rfc/SemanticTags.txt index 1816d7bed..bb40d5621 100644 --- a/doc/devel/rfc/SemanticTags.txt +++ b/doc/devel/rfc/SemanticTags.txt @@ -3,12 +3,12 @@ Semantic tags // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Do 30 Aug 2012 21:06:54 CEST_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Do 30 Aug 2012 21:06:54 CEST_ +|*Proposed by* | Christian Thaeter +|==================================== ******************************************************************************** .Abstract @@ -39,13 +39,13 @@ To give tags some sematics we introduce a simple ontology: - Tags can have namespaces, delimited by a dot 'foo.bar.baz'. Tags are looked up from right to left 'baz' would suffice as long it is unique. Non unique cases will be handled in context (sometimes non uniqunes is desired) -- We introduce simple "Is a" and "Has a" relationships. These are defined by the - casing of the tag: 'ALL_UPPERCASE' means "Is a" and anything else (including - mixed case) means "Has a". Note that for most cases the "Is a" relation will be - defined implicitly, ín normal cases one doesnt need to care. +- We introduce simple ``is-a'' and ``has-a'' relationships. These are defined by the + casing of the tag: `ALL_UPPERCASE' means ``is-a'' and anything else (including + mixed case) means ``has-a''. Note that for most cases the ``is-a'' relation will + be defined implicitly, in normal cases one does not need to care. - define some tag algebra for lookups (group tags by comma and semicolons, where comma means 'and' and semicolon means 'or'). Used to query the tag database. - regex/globbing might become handy too. + regex / globbing might become handy too. .Implicit Tags @@ -66,7 +66,7 @@ Tags are collected/discovered by some script which creates a tag-database (possibly plaintext asciidoc files) as big project index linking back to the content, details need to be worked out. -We create special asciidoc macros for crossreferencing tags for example: 'RFC:foobar' +We create special Asciidoc macros for cross-referencing tags for example: 'RFC:foobar' 'SOURCE:builder', details need to be worked out later. Note: this Proposal is about including tags in the first place, processing them is only @@ -108,7 +108,7 @@ Cons ^^^^ // fact list of the known/considered bad implications: - * adding tags and developing the tools manging them will take some time + * adding tags and developing the tools to manage them will take some time Alternatives @@ -129,7 +129,7 @@ It is very urgent and important that we make our content much easier accessible. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -196,4 +196,4 @@ Ichthyostega:: 'Mi 10 Okt 2012 05:36:35 CEST' ~~ //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SkillsCollection.txt b/doc/devel/rfc/SkillsCollection.txt index c2c4f3d68..978075c6a 100644 --- a/doc/devel/rfc/SkillsCollection.txt +++ b/doc/devel/rfc/SkillsCollection.txt @@ -1,9 +1,13 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2007-06-13_ -*Proposed by* link:ct[] ---------------------------------- +Offering Skills for Help +======================== + + +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2007-06-13_ +|*Proposed by* | ct +|==================================== Skills Collection @@ -18,7 +22,7 @@ Some Page should list different things needed for working on the project and users should attach themself when they offer support for it. This is meant that people who run into problems know who to ask. In contrast this is not meant like these Skill pages on Sourceforge or such. I don't like this rating and -posing system. We let people assing themself to skill and not skills to people +posing system. We let people assign themself to skill and not skills to people and there is no rating. Skills shall be anything which is needed like the tools we use, the code we @@ -39,12 +43,14 @@ Example .lumiera/renderpipe * ichthyo -... shall this contain emails? + +Question: __shall this contain emails?__ Tasks ^^^^^ - * just set this page up .. either on this wiki or in a tiddlywiki which + * just set this page up ... + + either on this wiki or in a TiddlyWiki which becomes checked into the repo @@ -55,13 +61,13 @@ Pros Cons ^^^^ - * privacy concerns, people might not publish what they know or better what - they ''not'' know + * privacy concerns, people might not publish what they know or, even more, + what they _do not_ know Alternatives ^^^^^^^^^^^^ -...urgs +...urgs 😶 Rationale @@ -76,5 +82,17 @@ community and is absolutely voluntary. Comments -------- +[underline]#Historical remark#: This RfC stems from the very first days of the »Cinelerra-3 movment«, +which turned into the Lumiera project over the course of the following months. The RfC was already +marked as __parked__ when first imported into the Lumiera Documentation in 2010. Early in 2008 however, +at the link:{ldoc}/devel/meeting_summary/2008-03-06.html#_draft_skills_collection[March developer meeting], +it was discussed shortly and deemed ``...only useful if there are more developers working on the project''. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Reading this RfC today gives me some kind of peculiar melancholic feeling -- it has the vibes of »zero hour«, +when all hands on deck are needed and everyone wants to help; people write their names on a blackboard +at the wayside, to get into contact, organise themselves or just to find their beloved ones... + +Ichthyostega:: '2025-09-11' + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/StreamTypeSystem.txt b/doc/devel/rfc/StreamTypeSystem.txt index 16347bcc0..7a2530244 100644 --- a/doc/devel/rfc/StreamTypeSystem.txt +++ b/doc/devel/rfc/StreamTypeSystem.txt @@ -3,12 +3,12 @@ Stream Type System // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _2008-10-05_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _2008-10-05_ +|*Proposed by* | Ichthyostega +|==================================== @@ -75,9 +75,9 @@ Levels of classification Image, Audio, MIDI, Text,..._ This is a simple Enum. * Below the level of distinct kinds of media streams, within every kind we have an open ended collection of *Prototypes*, which, within the high-level - model and for the purpose of wiring, act like the "overall type" of the - media stream. Everything belonging to a given Prototype is considered to be - roughly equivalent and can be linked together by automatic, lossless + model and for the purpose of wiring, act like the ``overall conceptual type'' + of the media stream. Everything belonging to a given Prototype is considered + to be roughly equivalent and can be linked together by automatic, lossless conversions. Examples for Prototypes are: stereoscopic (3D) video versus the common flat video lacking depth information, spatial audio systems (Ambisonics, Wave Field Synthesis), panorama simulating sound systems (5.1, @@ -96,7 +96,7 @@ Working with media stream implementations For dealing with media streams of various implementation type, we need _library_ routines, which also yield a _type classification system_ suitable for their intended use. Most notably, for raw sound and video data we use the -http://gmerlin.sourceforge.net/[GAVL] library, which defines a fairly complete +https://github.com/bplaum/gavl[GAVL] library, which defines a fairly complete classification system for buffers and streams. For the relevant operations in the Steam-Layer, we access each such library by means of a Façade; it may sound surprising, but actually we just need to access a very limited set of @@ -107,13 +107,13 @@ two streams and get an conversion plugin. Thus, to integrate an external library into Lumiera, we need explicitly to implement such a Lib Façade for this specific case, but the intention is to be able to add this Lib Façade implementation as a plugin (more precisely as a -"Feature Bundle", because it probably includes several plugins and some -additional rules) +link:{rfc}/FeatureBundle_PluggableModules.html[»Feature Bundle«], +because it probably includes several plugins and some additional rules) Link between implementation type and prototype ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -At this point the rules based configuration comes into play. Mostly, to start +At this point the _rules based configuration_ comes into play. Mostly, to start with, determining a suitable prototype for a given implementation type is sort of a tagging operation. But it can be supported by heuristic rules and an flexible configuration of defaults. For example, if confronted with a media @@ -155,10 +155,10 @@ Tasks // List what needs to be done to implement this Proposal: * draft the interfaces ([green]#✔ done#) * define a fall-back and some basic behaviour for the relation between - implementation type and prototypes [,yellow]#WIP# + implementation type and prototypes [orange]#(some draft)# * find out if it is necessary to refer to types in a symbolic manner, or if it is sufficient to have a ref to a descriptor record or Façade object. - * provide a Lib Façade for GAVL [,yellow]#WIP# + * provide a Lib Façade for GAVL * evaluate if it's a good idea to handle (still) images as a separate distinct kind of media @@ -210,7 +210,7 @@ Rationale //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -220,49 +220,74 @@ Comments -------- //comments: append below As usual, see the -http://www.lumiera.org/wiki/renderengine.html#StreamType[Development internal doc] +link:/wiki/renderengine.html#StreamType[Development internal doc] for more information and implementation details. Practical implementation related note: I found I was blocked by this one in further working out the details of the processing nodes wiring, and thus make any advance on the builder and thus to know more precisely how to organize the -objects in the link:EDL/Session[]. Because I need a way to define a viable +objects in the EDL rsp. Session. Because I need a way to define a viable abstraction for getting a buffer and working on frames. The reason is not immediately obvious (because initially you could just use an opaque type). The problem is related to the question what kind of structures I can assume for the -builder to work on for deciding on connections. Because at this point, the -high-level view (pipes) and the low level view (processing functions with a +builder to work on for deciding on routing and connectivity? Because at this point, +the high-level view (pipes) and the low level view (processing functions with a number of inputs and outputs) need in some way to be connected. The fact that we don't have a rule based system for deciding queries currently is not much of a problem. A table with some pre configured default answers for a small number of common query cases is enough to get the first clip rendered. -(Such a solution is already in place and working.) + - -- link:Ichthyostega[] 2008-10-05 +(Such a solution is already in place and working). -Woops fast note, I didn't read this proposal completely yet. Stream types could -or maybe should be coopertatively handled together with the backend. Basically -the backend offers one to access regions of a file in a continous block, this -regions are addressed as "frames" (this are not necessary video frames). The +Ichthyostega:: '2008-10-05' + +Woops fast note, I didn't read this proposal completely yet.... + +Stream types could or maybe should be cooperatively handled together with the backend. +Basically the backend offers one to access regions of a file in a continuous block, this +regions are addressed as ``frames'' (this are not necessary video frames). The backend will keep indices which associate this memory management with the frame -number, plus adding the capabilitiy of per frame metadata. This indices get -abstracted by "indexing engines" it will be possible to have different kinds of -indices over one file (for example, one enumerating single frames, one -enumerating keyframes or gops). Such a indexing engine would be also the place -to attach per media metadata. From the steam layer it can then look like `struct -frameinfo* get_frame(unsigned num)` where `struct frameinfo` (not yet defined) -is something like `{ void* data; size_t size; struct metadata* meta; ...}` + - -- link:ct[] 2008-10-06 +number, plus adding the capability of per frame metadata. This indices get +abstracted by ``indexing engines'' -- it will be possible to have different kinds +of indices over one file (for example, one enumerating single frames, one +enumerating keyframes or GOPs). Such a indexing engine would be also the place +to attach per media metadata. From the steam layer it can then look like + + struct frameinfo* get_frame(unsigned num) + +...where `struct frameinfo` (not yet defined) is something like + +[source, C] +---- + { + void* data; + size_t size; + struct metadata* meta; + ... + } +---- + +ct:: '2008-10-06' + Needs Work ~~~~~~~~~~ +Discussed in the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_stream_type_system[Apr.2011 developer meeting]. There are a lot details to be worked out for an actual implementation but we -agreed that we want this concept as proposed here. +agreed that we basically want some concept as proposed here. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' +I requested to keep it in `pending' state, in hope for more in-depth discussion + +Ichthyostega:: 'Apr 2011' + +[underline]#Many years later#, I still consider such a _type system_ for stream meta data +to be highly relevant and necessary as prerequisite for implementing the Builder. + +Ichthyostega:: '2025-09-18' //endof_comments: + '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SystematicMetadata.txt b/doc/devel/rfc/SystematicMetadata.txt index 1ca83713a..c0ca62548 100644 --- a/doc/devel/rfc/SystematicMetadata.txt +++ b/doc/devel/rfc/SystematicMetadata.txt @@ -3,16 +3,16 @@ SystematicMetadata // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Mo 08 Okt 2012 04:39:16 CEST_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Idea_ +|*Date* | _Mo 08 Okt 2012 04:39:16 CEST_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract -_give a short summary of this proposal_ +[red]#TODO# _give a short summary of this proposal_ ******************************************************************************** Lumiera is a metadata processing application: _Data_ is _media data_, and everything @@ -85,7 +85,8 @@ Tasks * define the interaction API [yellow-background]#WIP# * scrutinise this concept to find the pitfalls [yellow-background]#WIP# * build a demonstration prototype, where the receiver fabricates an object [red yellow-background]#TBD# - + ** the unit tests related to the _Diff System_ could be counted as such a demonstration + + Ichthyostega:: '2029-09-13' Discussion ~~~~~~~~~~ @@ -140,7 +141,7 @@ of defining a contract -- is turned into a local problem. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -150,8 +151,30 @@ Comments -------- //comments: append below +This RfC seems to be more like a vision statement; it contains some interesting +ideas, but not much of an actual proposal. At that time, presumably I had hoped +to spur further discussion or provoke some objection, in order to clarify what +we should be aiming at. + +_During the following years,_ many of the ideas spelled out first in this text +found their way into the *Diff System*, now used as a foundation for connecting the +GUI to the Session core in Steam Layer. Especially the discussion of ``Alternatives'' +seem to indicate that an essential motivation for this RfC was to find a viable +alternative to building the whole Application around a _central data model_ -- +which is in essence what I later transformed into a practical concept with the +aforementioned ``Diff System''. + +-> see the design page regarding link:{ldoc}/design/architecture/ETD.html[»External Tree Description«] + +[underline]#Bottom line#: not sure what to do with this RfC; concepts explained therein +seem still highly relevant and central to what Lumiera is intended to become; +but this text does not fit into the format of an RfC, nor is there a community +of developers to discuss such a design vision appropriately. + +Ichthyostega:: '2025-09-13' + //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/TagCloudsOnResources.txt b/doc/devel/rfc/TagCloudsOnResources.txt index e3589f15f..8bf5682aa 100644 --- a/doc/devel/rfc/TagCloudsOnResources.txt +++ b/doc/devel/rfc/TagCloudsOnResources.txt @@ -1,81 +1,61 @@ -Design Process : Tag Clouds for Resources -========================================= +Design Process : Tag Clouds +=========================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2008-07-15_ -*Proposed by* link:PercivalTiglao[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2008-07-15_ +|*Proposed by* | PercivalTiglao +|==================================== Tag Clouds for Resources ------------------------ -Perhaps a Cloud of tags is unnecessary, but tagging resources similar to +Perhaps a Cloud of Tags is unnecessary, but tagging resources similar to Youtube or like Tag Clouds allows for efficient searching and filtering. Anyone -who uses the web would know how to use them. If a "Cloud of Tags" approach is -used, then organizing the tags by some sort of frequency would be useful. IE: -the more a specific tag is used, the larger it gets, or perhaps the more often -that tag is searched on. - - -Description -~~~~~~~~~~~ +who uses the web would know how to use them. If a ``Cloud of Tags'' approach is +used, then organizing the tags by some sort of frequency would be useful: +the more often a given tag is used, the larger it gets (or perhaps the more often +that tag is searched and referred). -Tasks -~~~~~ - - -Pros -~~~~ - +.Pros * Simple GUI Concept * Eases management of resources with Search * Orthogonal to other resource management schemes like Folders -Cons -~~~~ - - -Alternatives -~~~~~~~~~~~~ - - - -Rationale -~~~~~~~~~ - - - - Comments -------- -* Note: I was inspired with this idea during an email conversation with - Rick777. -- link:PercivalTiglao[] [[DateTime(2008-07-17T14:29:57Z)]] +Note: I was inspired with this idea during an email conversation with _Rick777_. -* Agreed, this is usefull. Also, more advanced config rules can make use of - such tags and wiring can depend on them, for example to route your dialogue - audio to another global bus than the music or ambiance. - -- link:Ichthyostega[] [[DateTime(2008-07-27T22:23:38Z)]] +PercivalTiglao:: '2008-07-17T14:29:57Z' +Agreed, this is useful. Furthermore, advanced config rules can make use of +such tags and wiring can depend on them, for example to route your dialogue +audio to another global bus than the music or ambiance. + +Ichthyostega:: '2008-07-27T22:23:38Z' + +To confirm this point: tagged assets are considered important and kept on the main agenda + +Ichthyostega:: '2025-09-15' Conclusion ---------- -This Design Proposal is 'superseded' by a much more advanced proposal: -link:/rfc/DelectusShotEvaluator.html[Delectus] +This Design Proposal is _superseded_ by a much more advanced proposal: +link:/x/Delectus.html[Delectus] -(Dropping it doesn't mean disapproval) +^(Dropping it doesn't mean disapproval)^ '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt b/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt index 00100303a..3fdf41414 100644 --- a/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt +++ b/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt @@ -1,14 +1,17 @@ -Threads, Signals and important management tasks -=============================================== +Design Process: Signal Handlers +=============================== + +//MENU: label Threads, Signals and important management tasks + // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Sat Jul 24 21:59:02 2010_ -*Proposed by* Christian Thaeter -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Sat Jul 24 21:59:02 2010_ +|*Proposed by* | Christian Thaeter +|==================================== [abstract] ****************************************************************************** @@ -110,30 +113,9 @@ Tasks // * item ... We have appstate::maybeWait() which already does such a loop. It needs to be -extended by the proposed things above. +extended to install signal handlers and perform the actions proposed above. - - -Discussion -~~~~~~~~~~ - - -Pros -^^^^ -// add just a fact list/enumeration which make this suitable: -// * foo -// * bar ... - - -Cons -^^^^ -// fact list of the known/considered bad implications: - - - -Alternatives -^^^^^^^^^^^^ -//alternatives: if possible explain/link alternatives and tell why they are not +[red]#TODO# Do we have a ticket for this essential feature already? @@ -144,10 +126,11 @@ Rationale This is rather common practice. I describe this here for Documentation purposes and to point out which details are not yet covered. -//Conclusion -//---------- -//conclusion: When approbate (this proposal becomes a Final) write some +Conclusion +---------- +//conclusion: When approved (this proposal becomes a Final) write some +Without much ado: we need to care for this... @@ -158,7 +141,8 @@ Comments .State -> Final ichthyo wants this to be a dedicated thread (own subsystem) instead running in the initial thread. Fixed this in the proposal above, this makes this accepted. - Do 14 Apr 2011 03:40:41 CEST Christian Thaeter + +Christian Thaeter:: 'Thu 14 Apr 2011 03:40:41 CEST' ~~ //endof_comments: diff --git a/doc/devel/rfc/TimeHandling.txt b/doc/devel/rfc/TimeHandling.txt index 360f75c83..245f55447 100644 --- a/doc/devel/rfc/TimeHandling.txt +++ b/doc/devel/rfc/TimeHandling.txt @@ -1,17 +1,17 @@ Design Process : Time Handling ============================== -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2007-06-21_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2007-06-21_ +|*Proposed by* | Ichthyostega +|==================================== -Time handling -------------- -How to handle time values in the code and which policy to aply to the "current" -position +Handling of Time and Time Quantisation +-------------------------------------- +How to handle time values in the code and which policy to apply +to the ``current'' position Description @@ -24,23 +24,26 @@ Description * We use a set of library routines and convenience-methods to - Get time in different formats (fractional seconds, frame counts) - Calculate with time values (overloaded operators) - * Time measurement is zero based (of course :-? ) + * Time measurement is zero based (of course 😁 ) . *Quantizing to a frame index or similar* * Quantizing/rounding shall happen only once at a defined point in the calculation chain and, if in doubt, be done always as late as possible. * Values needing to be quantized to time (grid) positions are calculated by - half-way rounding, but the result should not depend on the actual - zero-point of the scale (i.e. `floor(0.5+val)`, thus quant(0.5) yields 1, - quant(0.49) yields 0, quant(-0.5) yields 0 ) + applying a suitable rounding scheme uniformly, e.g. half-way rounding, but + the result should not depend on the actual zero-point of the scale + ** `floor(0.5+val)` + ** `quant(0.5)` ⟼ 1 + ** `quant(0.49)` ⟼ 0 + ** `quant(-0.5)` ⟼ 0 . *Position of frames* - * Frame numbers are zero based and Frame 0 starts at time=0 (or whatever the + * Frame numbers are zero based and Frame 0 starts at time≡0 (or whatever the nominal start time is) * Each frame starts when the locator hits its lower border (inclusively) and ends when the locator is on its upper border (exclusively) image:{imgd}/Lumi.FramePositions1.png[] * When the locator snaps to frames this means it can be placed on the start positions of the frames solely - * When the locator is placed on such a start position, this means 'always' + * When the locator is placed on such a start position, this means _always_ displaying the frame starting at this position, irrespective of playback direction. . *Current position for keyframe nodes and automation* @@ -48,7 +51,7 @@ Description frame base (which normally is the case), for each frame there is a well defined 'point of evaluation' time position, irrespective of the playback direction - * There is no single best choice where to put this "POE", thus we provide a + * There is no single best choice where to put this ``POE'', thus we provide a switch image:{imgd}/Lumi.FramePositions2.png[] - 'Point of evaluation' of the automation is in the middle of the timespan @@ -62,17 +65,17 @@ image:{imgd}/Lumi.FramePositions2.png[] Tasks -~~~~~ -* Figure out what has to be done when switching the "current position" policy - on a existing project. +^^^^^ +* Figure out what has to be done when switching the ``current position'' + policy for an existing project. Alternatives -~~~~~~~~~~~~ -Leave everything as in Cinelerra2, i.e. show frames after the locator has +^^^^^^^^^^^^ +Leave everything as in Cinelerra-2, i.e. show frames after the locator has passed over them, behave different when playing backwards and set the keyframes on the position of the locator but use them on the frame actually to be shown -(which differs according to the playback direction but is always "one off"). +(which differs according to the playback direction but is always ``one off''). Why not? because it makes frame-precise working with keyframes a real pain and even creates contradictory situations when you switch back and forward while @@ -87,55 +90,64 @@ long as possible and only quantize for rendering a given frame. Rationale ~~~~~~~~~ The intention is to make time handling and calculations as uniform and -"rational" as possible. We try to stick to the precise mathematical values and -let the calculations just yield an result in an uniform manner, instead of -sticking to "simple" values like frame counts or even a session-wide frame rate +_deterministic_ as possible. We try to stick to the precise mathematical values +and let the calculations just yield an result in an uniform manner, instead of +relying on ``simple'' values like frame counts or even a session-wide frame rate -. Time and interval calculations are tricky. Solve this question once and be - done. -. Rounding is always dangerous, rounded values are not the more "clean" values. +. Time and interval calculations are tricky. Solve this question once and be done. +. Rounding is always dangerous, rounded values are by no means the ``cleaner'' values. The floor-rounding rule is chosen, because the length of an interval after quantisation should not depend on the position in relation to the zero point. - The usual mathematical rounding behaves "symmetrical" to the zero point, + The usual mathematical rounding behaves _symmetrical_ to the zero point, which could yield a different length after quantisation if an interval contains the zero point . This is based on the analogy with real film running through a film projector - (or the usual fencepost problem) -. While using the actual position of the locator as the "current" position for + (or the usual »fence post problem«) +. While using the actual position of the locator as ``the current'' position for keyframes seems more natural at first, it crates problems when mixing footage with different framerate or when using a low-framerate proxy footage. Comments ~~~~~~~~ -* This is the summary of a discussion cehteh, Plouj and ichthyo just had on - irc. - -- link:Ichthyostega[] [[DateTime(2007-06-21T05:12:03Z)]] +* This is the summary of a discussion _cehteh_, _Plouj_ and _ichthyo_ just had on IRC. -* We use GAVL now (needs to be included in the build system) - -- link:ct[] [[DateTime(2008-03-05T16:19:22Z)]] +Ichthyostega:: '2007-06-21T05:12:03Z' -* I've tidied up this old design proposal, we could make it final now. I've +* We use lib GAVL now (needs to be included in the build system) + +ct:: '2008-03-05T16:19:22Z' + +* I have tidied up this old design proposal, we could make it final now. I've changed the rounding rule, please check if it's OK. In the original proposal, we wanted to use the common mathematical rounding rule, i.e. round(-x) = - round(x) . I changed this, because of the danger of interval lengths or - alignment to "jump" dependant on the position in relation to the time zero + alignment to ``jump'' depending on the position in relation to the time zero point. - -- link:Ichthyostega[] [[DateTime(2008-10-04T22:47:54Z)]] -* Looks ok to me, maybe we should wrap up the gavl time handling in a very thin +Ichthyostega:: '2008-10-04T22:47:54Z' + +* Looks ok to me, maybe we should wrap up the Gavl time handling in a very thin layer to unify our time functions and then cast this again into a authoritative testsuite/specification. Anyways I think this can be finalized. - -- link:ct[] [[DateTime(2008-10-06T06:44:21Z)]] + +ct:: '2008-10-06T06:44:21Z' Conclusion ~~~~~~~~~~ -* The adapted form of this proposal was *accepted* by October.2008 developer - meeting. +* The adapted form of this proposal was __`accepted'__ by the + link:{ldoc}/devel/meeting_summary/2008-10-10.html#_time_handling[October.2008 developer meeting]. * The proposed thin library layer to centralize time calculations shall be added on demand. When doing so, we need to add thorough test coverage for time calculations too. -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +TIP: this library layer was first implemented as a collection of functions, + but has been transformed into a system of adaptor types meanwhile, + so that any conversion into a _Time Code_ also has to go through + a suitable _quantisation_ into a predefined _time grid_. + -> link:{ldoc}/design/architecture/time/index.html[read more here...] + +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/TimelineSequenceOutput.txt b/doc/devel/rfc/TimelineSequenceOutput.txt index 429c2f0f7..d71309a49 100644 --- a/doc/devel/rfc/TimelineSequenceOutput.txt +++ b/doc/devel/rfc/TimelineSequenceOutput.txt @@ -1,9 +1,14 @@ -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _2008-11-03_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process : Timelines +========================== + +//MENU: label Timelines and Sequences in the high-level-Model + +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _2008-11-03_ +|*Proposed by* | Ichthyostega +|==================================== .Summary @@ -18,8 +23,9 @@ Relation of Project, Timeline(s), Sequence(s) and Output generation ------------------------------------------------------------------- In the course of our discussions it meanwhile became clear, that Lumiera will -show multiple _timeline-like_ views within one project. Similarly it's clear -now that we will support link:EDLsAreMetaClips.html[nested Sequences as meta-clips]. +show multiple _timeline-like_ views within one project. Furthermore, support +for link:{rfc}/EDLsAreMetaClips.html[nested Sequences as meta-clips] is +considered an essential goal. The purpose of this entry is to try to settle on some definitions and clarify the relationships between these concepts. @@ -33,7 +39,7 @@ Project:: the top-level context in which all edit work is done over an Session:: the current in-memory representation of the Project when opened within an instance of Lumiera. This is an implementation-internal term. For - the GUI and the users POV we should always prefer the term "Project" for the + the GUI and the users POV we should always prefer the term »Project« for the general concept. Timeline:: the top level element within the Project. It is visible within a @@ -41,8 +47,9 @@ Timeline:: the top level element within the Project. It is visible within a arrangement of media objects, resolved to a finite time axis, to be rendered for output or viewed in a Monitor (viewer window). Timeline(s) are top-level and may not be further combined. A timeline is comprised of: - * a time axis in abolute time (WIP: not clear if this is an entity or just a - conceptual definition) + * a time axis in absolute time + + ^([purple]#WIP#: not clear if this is an entity or just a + conceptual definition)^ * a _PlayController_ * a list of global _Pipes_ representing the possible outputs (master busses) @@ -50,8 +57,8 @@ Timeline:: the top level element within the Project. It is visible within a nested Sequences Timeline View:: a view in the GUI featuring a given timeline. There might be - multiple views of the same timeline, all sharing the same !PlayController. A - proposed extension is the ability to _focus_ a timeline view to a + multiple views of the same timeline, all sharing the same `PlayController`. + A proposed extension is the ability to _focus_ a timeline view to a sub-Sequence contained within the top-level sequence of the underlying Timeline. (Intended for editing meta-clips) @@ -81,13 +88,13 @@ PlayController:: coordinating playback, cueing and rewinding of a media data needed for playback. Actually, the implementation of the PlayController(s) is assumed to live in the application core. -RenderTask:: basically a !PlayController, but collecting output - directly, without moving a !PlayheadCursor (maybe a progress indicator) and +RenderTask:: basically a `PlayController`, but collecting output + directly, without moving a `PlayheadCursor` (maybe a progress indicator) and not operating in a timed fashion, but freewheeling or in background mode Monitor/Viewer:: a viewer window to be attached to a timeline. When attached, a - monitor reflects the state of the timeline's PlayController, and it attaches - to the timeline's global pipes by stream-type match, showing video as monitor + monitor reflects the state of the timeline's `PlayController`, and it attaches + to the Timeline's global pipes by stream-type match, showing video as monitor image and sending audio to the system audio port (Alsa or Jack). Possible extensions are for a monitor to be able to attach to probe points within the render network, to show a second stream as (partial) overlay for comparison, @@ -108,36 +115,37 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline, same time we may have multiple views of the same timeline. * all playhead displays within different views linked to the _same_ underlying timeline are effectively linked together, as are all GUI widgets - representing the same !PlayController owned by a single timeline. + representing the same `PlayController` owned by a single timeline. * I am proposing to do it this way per default, because it seems to be a best match to the users expectation (it is well known that multiple playback cursors tend to confuse the user) -* the timeline view is modeled to be a sub-concept of "timeline" and thus can +* the timeline view is modelled to be a sub-concept of ``Timeline'' and thus can stand-in. Thus, to start with, for the GUI it doesn't make any difference if it talks to a timeline view or a timeline. * each timeline _refers_ to a (top-level) sequence. I.e. the sequences - themselves are owned by the project, and theoretically it's possible to refer + themselves are owned by the Project, and theoretically it's possible to refer to the same sequence from multiple timelines directly and indirectly. -* besides, it's also possible to create multiple independent timelines -— in +* besides, it's also possible to create multiple independent timelines -- in an extreme case even so when referring to the same top-level sequence. This configuration gives the ability to play the same arrangement in parallel with multiple independent play controllers (and thus independent playhead positions) -* to complement this possibilities, I'd propose to give the _timeline view_ - the possibility to be focussed (re-linked) to a sub-sequence. This way, it +* to complement this possibilities, I'd propose to give the _Timeline View_ + the possibility to be focused (re-linked) to a sub-sequence. This way, it would stay connected to the main play control, but at the same time show a sub-sequence _in the way it will be treated as embedded within the top-level sequence._ This would be the default operation mode when a meta-clip is opened (and showed in a separate tab with such a linked timeline view). The reason for this proposed handling is again to give the user the least - surprising behaviour. Because, when -— on the contrary -— the + surprising behaviour. Because, when -- on the contrary -- the sub-sequence would be opened as separate timeline, a different absolute time position and a different signal routing may result; doing such should be reserved for advanced use, e.g. when multiple editors cooperate on a single project and a sequence has to be prepared in isolation prior to being integrated in the global sequence (featuring the whole movie). -* one rather unconventional feature to be noted is that the _tracks_ (forks) are - within the _sequences_ and not on the level of the global busses as in most +* one rather unconventional feature to be noted is that the _Tracks_ + (actually a _»Fork«_ ≙ a tree of Tracks) are + within the _Sequences_ and not on the level of the global busses as in most other video and audio editors. The rationale is that this allows for fully exploiting the tree-structure, even when working with large and compound projects, it allows for sequences being local clusters of objects including @@ -149,12 +157,12 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline, Tasks ^^^^^ * Interfaces on the Stage and Steam level need to be fully specified. - Especially, "Timeline" is now promoted to be a new top-level entity within + Especially, »Timeline« is now promoted to be a new top-level entity within the Session * communication between the PlayController(s) and the GUI need to be worked out * the stream type system, which is needed to make this default connection - scheme work, currently is just planned and drafted. Doing a exemplaric + scheme work, currently is just planned and drafted. Doing a exemplarily implementation for GAVL based streams is on my immediate agenda and should help to unveil any lurking detail problems in this design. * with the proposed focusing of the timeline view to a sub-sequence, there are @@ -171,8 +179,7 @@ Pros ^^^^ * this design naturally scales down to behave like the expected simple default case: one timeline, one track, simple video/audio out. - * but at the same time it allows for bewildering complex setups for advanced - use + * but at the same time it allows for bewildering complex setups for advanced use * separating signal flow and making the fork (``track tree'') local to the sequence solves the problem how to combine independent sub-sequences into a compound session @@ -181,9 +188,8 @@ Pros Cons ^^^^ * it is complicated - * it is partially uncommon, but not fully revolutionary, and thus may be - misleading. - * the control handling in GUI can become difficult (focus? key shortcuts?) + * it is partially uncommon, but not fully revolutionary, and thus might be misleading. + * the control handling in the GUI can become difficult (focus? key shortcuts?) * the ability to have both separate timelines and timeline views can be very confusing. We really need to think about suitable UI design * because the signal flow is separated from the tracks, we need to re-design @@ -194,13 +200,13 @@ Cons Alternatives ^^^^^^^^^^^^ - * just one session, a list of tracks and don't cover the organisation of - larger projects at all. - * allow only linear sequences with one track, not cluster-like sequences - * make the tracks synonymous with the global busses as usual. Use an - allocation mechanism when "importing" separate sub-projects + * just one Session, a list of Tracks and do not attempt to cover the organisation + of larger projects at all. + * allow only linear Sequences with one Track, not cluster-like sequences + * make the Tracks synonymous with the global busses as usual. Use an + allocation mechanism when ``importing'' separate sub-projects * rather make compound projects a loosely coupled collection of stand-alone - projects, which are just "played" in sequence. Avoid nested referrals. + projects, which are just ``played'' in sequence. Avoid nested referrals. * don't build nested structures, rather build one large timeline and provide flexible means for hiding and collapsing parts of it. @@ -210,7 +216,7 @@ Rationale Obviously, the usual solution was found to be limiting and difficult to work with in larger projects. On the other hand, the goal is not to rely on external project organisation, rather to make Lumiera support more complicated -structures without complicated "import/export" rules or the need to create a +structures without complicated ``import/export'' rules or the need to create a specific master-document which is different from the standard timeline. The solution presented here seems to be more generic and to require fewer treating of special cases than the conventional approach would be. @@ -224,17 +230,17 @@ Comments -GUI handling could make use of expanded view features like ; +GUI handling could make use of expanded view features like... * drop down view of track, that just covers over what was shown below. This may be used for quick precise looks, or simple editions, or clicking on a subtrack to burrow further down. * show expanded trackview in new tab. This creates another tabbed view which - makes the full window are available for a "magnified" view. It is very easy + makes the full window are available for a ``magnified'' view. It is very easy to jump back to the main track view, or to other view tabs (edit points). -* The main track view could show highlights for "currently created" views/edit +* The main track view could show highlights for ``currently created'' views/edit points, and whether they are currently being used or not (active/inactive). * Each tab view could show a miniature view of the main track view (similar @@ -246,36 +252,38 @@ GUI handling could make use of expanded view features like ; positioned very close to the point on the track that was clicked on to trigger the drop down. This close proximity means that the mouse motion distance to commonly used (next) options, is very minimal. Icons for common - options might include ; remove drop down view, create new tab view (active - edit point), create edit point (but don't open a new tab - just create the - highlight zone on the track), temporarily "maximise" the drop down view to + options might include; remove drop down view, create new tab view (active + edit point), create edit point (but don't open a new tab -- just create the + highlight zone on the track), temporarily ``maximise'' the drop down view to the full window size (ie show the equivalent tab view in the current window). -* some of the "matrix" type view methods commonly used in spreadsheets, like - lock horizontal and vertical positions (above OR Below, left OR Right of - marker) for scrolling - this can also be used for determining limits of +* some of the ``matrix type'' view methods commonly used in spreadsheets, like + lock horizontal and vertical positions (above _or_ below, left _or_ right of + marker) for scrolling -- this can also be used for determining limits of scroll. * monitor view could include a toggle between show raw original track , show zoomed and other camera/projector render, or show full rendering including - effects - this ties in with the idea of being able to link a monitor with - viewing anywhere in the node system - but is able to be swiftly changed + effects -- this ties in with the idea of being able to link a monitor with + viewing anywhere in the node system -- but is able to be swiftly changed within the monitor view by icons mounted somewhere on each of the respective monitors' perimeter. * the trackview itself, could be considered as a subview of a - total-timeline-trackview, or some other method of "mapping out" the full + total-timeline-trackview, or some other method of ``mapping out'' the full project (more than one way of mapping it out may be made as optional/default views). -* this set of features are going to be very exciting and convenient to work - with - a sort of google earth feature for global sized projects. +This set of features is going to be very exciting and convenient to work +with -- a sort of google earth feature for global sized projects. + +Tree:: '2008-12-19 22:58:30' -Tree 2008-12-19 22:58:30 Final ~~~~~ - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/TodoLists.txt b/doc/devel/rfc/TodoLists.txt index 1d3b987ac..9bc303a12 100644 --- a/doc/devel/rfc/TodoLists.txt +++ b/doc/devel/rfc/TodoLists.txt @@ -1,9 +1,9 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-03-05_ -*Proposed by* link:ct[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-03-05_ +|*Proposed by* | ct +|==================================== Todo Lists ---------- @@ -44,6 +44,7 @@ Rationale Comments -------- We decided to use a Tiddlywiki for now until this is further worked out - -- link:ct[] [[DateTime(2008-03-08T03:38:50Z)]] -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +ct:: '2008-03-08T03:38:50Z' + +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/UnitTests_Python.txt b/doc/devel/rfc/UnitTests_Python.txt index 27b203893..0ab60931f 100644 --- a/doc/devel/rfc/UnitTests_Python.txt +++ b/doc/devel/rfc/UnitTests_Python.txt @@ -2,12 +2,12 @@ Design Process : Unit Tests Python ================================== -[grid="all"] -`------------`----------------------- -*State* _Dropped_ -*Date* _2007-06-17_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Dropped_ +|*Date* | _2007-06-17_ +|*Proposed by* | Ichthyostega +|==================================== UnitTests in Python @@ -20,7 +20,7 @@ Cinelerra Code via SWIG Description ~~~~~~~~~~~ -Define Test classes in Python, using e.g. the link:PyUnit[] framework of the +Define Test classes in Python, using e.g. the PyUnit framework of the Python Standard lib. The SWIG compiler can generate wrapper code automatically, so we can access the C++ Classes and Facilities of Cinelerra as Python Modules and Classes. The Classes to be tested in Cinelerra need to provide some @@ -29,8 +29,7 @@ the whole Test driven aproach). Tasks -~~~~~ - +^^^^^ * Find out how the SWIG generated wrappers play together with Python's List and Map types. Without the ability to use the latter in the tests, this whole proposal is rather pointless. @@ -39,9 +38,8 @@ Tasks Pros -~~~~ - -Programming Unit and Self tests in a Scripting language facillates this task. +^^^^ +Programming Unit and Self tests in a Scripting language facilitates this task. The X-Language bindings are quite usable today. As a side effect, it helps to get a clean program structure, because the tests need some Interface and/or some object factories to create the test candidates. Python is proposed, @@ -49,14 +47,11 @@ because it is fairly mainstream, has a flat learning curve and but is moderately modern and functional-style at the same time. Cons -~~~~ - +^^^^ * Adds to the complexity * Some old-style hackers have a quite distinct aversion against Python -Alternatives -~~~~~~~~~~~~ Rationale ~~~~~~~~~ @@ -64,19 +59,26 @@ Rationale Why am I proposing this? Out of lazyness. Python is there, many devs (on linux) have some Python skills, SWIG is not overly complicated to use. -And last but not least: just to get the discussion going... ;-) +And last but not least: just to get the discussion going... 😉 Comments -------- -* I'd rather consider to use some embedded language in cinelerra which we can - use to drive tests, should be something smaller and more sane than python. - Needs certainly more discussion. For simple unit tests some C/C++ harness and - bit shell scripting would suffice, I really want to integrate this with - https://nobug.pipapo.org/[NoBug]. - -- link:ct[] [[DateTime(2007-06-17T17:32:27Z)]] +I'd rather consider to use some embedded language in cinelerra which we can +use to drive tests, should be something smaller and more sane than python. +needs certainly more discussion. For simple unit tests some C/C++ harness and +bit shell scripting would suffice, I really want to integrate this with +https://nobug.pipapo.org/[NoBug]. +ct:: '2007-06-17T17:32:27Z' + +Since Lumiera is a separate project now, we do no longer need to ``hook'' +into existing code ``from the outside''. Rather, we have created our own +lightweight unit testing framework in C++. +This RfC was link:{ldoc}/devel/meeting_summary/2008-03-06.html#_idea_unit_tests_in_python[dropped 3/08] + +ichthyo:: '2008-03-06' '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/UseCases.txt b/doc/devel/rfc/UseCases.txt index d4580413b..7c05a7485 100644 --- a/doc/devel/rfc/UseCases.txt +++ b/doc/devel/rfc/UseCases.txt @@ -1,15 +1,18 @@ -[grid="all"] -`------------`----------------------- -*State* _Parked_ -*Date* _2008-10-31_ -*Proposed by* link:Ichthyostega[] -------------------------------------- +Design Process: Use Cases +========================= + +[options="autowidth"] +|==================================== +|*State* | _Parked_ +|*Date* | _2008-10-31_ +|*Proposed by* | Ichthyostega +|==================================== Use Case analysis ----------------- -The only way to defeat "featuritis" is to build upon a coherent design -- +The only way to defeat ``featuritis'' is to build upon a coherent design -- + which in turn relies upon a more or less explicit understanding what the application should be like, and the way the prospective user is thought to work @@ -287,24 +290,24 @@ Comments .Template e.g. for regular TV series Constraints to fit all contents within fixed timeline, cover topic, select collage of iconic scenes from archived and collected footage. Update intro and -credit roll for each episode. Add in stopmotion, and 3D model animations with -vocal commentaries. Gather together separate items from "outworkers". +credit roll for each episode. Add in stop motion, and 3D model animations with +vocal commentaries. Gather together separate items from ``outworkers''. Tree:: '2008-12-27 08:36:36' +.State -> Parked +Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_use_cases[April.2011 developer meeting]. +We have to revisit this, possibly someone (or a group) who wants to work on the workflow. + +For now it is __parked__ until revisited. + +Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' + + //endof_comments: -Parked -~~~~~~ -We have to revisit this, possibly someone (or a group) who wants to work on -the workflow. For now its parked until revisited. - Do 14 Apr 2011 03:06:42 CEST Christian Thaeter - - - - -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +'''' +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/VersionNumberScheme.txt b/doc/devel/rfc/VersionNumberScheme.txt index 228462b6b..ef6cb6914 100644 --- a/doc/devel/rfc/VersionNumberScheme.txt +++ b/doc/devel/rfc/VersionNumberScheme.txt @@ -3,12 +3,12 @@ VersionNumberScheme // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Final_ -*Date* _Mi 09 Mär 2011 02:00:41 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Final_ +|*Date* | _Mi 09 Mär 2011 02:00:41 CET_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ******************************************************************************** @@ -142,7 +142,7 @@ when to use what version number. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -155,11 +155,27 @@ Comments .State -> Final considered common practice - Do 14 Apr 2011 03:46:07 CEST Christian Thaeter +Christian Thaeter:: 'Thu 14 Apr 2011 03:46:07 CEST' ~~ + + +💡 + +[underline]#Please Note#: our Git branching model has been switched to +link:{ldoc}/technical/code/GitBranching.html[Git-flow] recently. On occasion +of that change, I wrote two helper scripts + +- 'admin/buildVersion.py' extracts version info from the latest preceding + Git tag, and additionally allows to _bump some component_ of the version-ID +- 'admin/setVersion' edits a hard-wired small selection of known documents + in the tree with `sed` to update a version-ID + +These are both related to version numbers, and also our conventions +for Git-flow refer directly to this RfC. + +Ichthyostega:: '2025-09-15' //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/WebsiteNavigation.txt b/doc/devel/rfc/WebsiteNavigation.txt index 144c41a79..a5e7385a7 100644 --- a/doc/devel/rfc/WebsiteNavigation.txt +++ b/doc/devel/rfc/WebsiteNavigation.txt @@ -3,12 +3,12 @@ WebsiteNavigation // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Draft_ -*Date* _Mi 08 Dez 2010 11:32:32 CET_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _Mi 08 Dez 2010 11:32:32 CET_ +|*Proposed by* | Ichthyostega +|==================================== [abstract] ******************************************************************************** @@ -131,7 +131,7 @@ these issues. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -150,4 +150,17 @@ This is covered by another RfC. Ichthyostega:: 'So 07 Okt 2012 07:30:17 CEST' ~~ +This RfC is in the same state as _many years ago_ -- and frankly, I do not know +what to do with it. One part (the Menu generator script) was implemented. +The other parts, which are tagging and cross-link resolution were proposed +and found general agreement at that time, but no-one did care for expanding +them into an implementation concept. + +Meanwhile, I am working alone and can thus afford to keep the infrastructure +at the bare minimum, just enough for me to cope. Similar as with the +link:{rfc}/WebsiteSupportMarkup.html#_comments[cross-links and support markup]. +However, I consider those topics still something for a group of people to decide. + +Ichthyostega:: '2025-09-18' + //endof_comments: diff --git a/doc/devel/rfc/WebsiteSupportMarkup.txt b/doc/devel/rfc/WebsiteSupportMarkup.txt index 04529a788..3ac9fbafd 100644 --- a/doc/devel/rfc/WebsiteSupportMarkup.txt +++ b/doc/devel/rfc/WebsiteSupportMarkup.txt @@ -3,12 +3,12 @@ WebsiteSupportMarkup // please don't remove the //word: comments -[grid="all"] -`------------`----------------------- -*State* _Idea_ -*Date* _Sa 06 Okt 2012 16:47:44 CEST_ -*Proposed by* Ichthyostega -------------------------------------- +[options="autowidth"] +|==================================== +|*State* | _Draft_ +|*Date* | _Sa 06 Okt 2012 16:47:44 CEST_ +|*Proposed by* | Ichthyostega +|==================================== ******************************************************************************** .Abstract @@ -221,7 +221,7 @@ can be considered a one-time investment. //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: @@ -246,7 +246,17 @@ those stuff which matters in practice. Ichthyostega:: 'So 07 Okt 2012 07:31:25 CEST' ~~ +.State -> Draft +Unfortunately, nothing has happened with this RfC ever since; the reason is +lack of developer capacity. Since this RfC is already fairly detailed, and +no significant objections were pointed out, I am promoting this RfC to +a __"Draft"__ now, yet leave it pending. Same as with the +link:WebsiteNavigation.html#_comments[RfC: Website Navigation]. + +Ichthyostega:: '2025-09-18' + + //endof_comments: '''' -Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt b/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt index 7e11a3596..f0a81802c 100644 --- a/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt +++ b/doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt @@ -17,12 +17,14 @@ _Summary written by XXXXX_ Recurring Topics ---------------- -Discussion of open link:{ldoc}/devel/rfc.html[design process] drafts. +Discussion of open link:/x/DesignProcess.html[design process] drafts. Prop1 ~~~~~ +//// link:{rfc}/SomeProposal[descriptive name] +//// Summary what issues are discussed ..Details.. diff --git a/doc/devel/template/new_rfc.sh b/doc/devel/template/new_rfc.sh index a78af057b..4ef34a4c7 100644 --- a/doc/devel/template/new_rfc.sh +++ b/doc/devel/template/new_rfc.sh @@ -62,7 +62,7 @@ Rationale //Conclusion //---------- -//conclusion: When approbate (this proposal becomes a Final) +//conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: diff --git a/doc/technical/code/index.txt b/doc/technical/code/index.txt index df26c567c..6e94c6321 100644 --- a/doc/technical/code/index.txt +++ b/doc/technical/code/index.txt @@ -46,7 +46,7 @@ Guidelines //// '''' - * also see the link:{ldoc}/devel/rfc/index.html[Design Process] for ongoing discussions + * also see the link:/x/DesignProcess.html[Design Process] for ongoing discussions * see the link:/devs-vault/[Developers Vault] for frequently used developer's resources diff --git a/doc/technical/infra/MenuGen.txt b/doc/technical/infra/MenuGen.txt index baa6b6f88..82523c07b 100644 --- a/doc/technical/infra/MenuGen.txt +++ b/doc/technical/infra/MenuGen.txt @@ -178,27 +178,27 @@ supported placement directives -[options="header", width="70%",cols="^m,) -- discover `id.txt` -- create new node or retrieve existing node - linkChild(id) basic function for attaching child node - linkParent(id) basic function to attach below parent - putChildLast(id) [attach] child move child to current end of list - appendChild(id) [append] child - putChildFirst(id) move child to current list start - prependChild(id) prepend [child] - putChildAfter(id,ref) [attach|put] child after move child after the given ref entry - link(url[,id][,label]) [child ] link ::[ + + + + + + + + + +

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

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

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

- - + @@ -163234,7 +163256,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -163244,6 +163266,16 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + @@ -163266,16 +163298,13 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

klar machen: Diskusssion ist abgeschlossen

- - + @@ -163293,32 +163322,34 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - - +

Name + Datum als Asciidoc-Delimited-Block

- - + - - - +

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

- - + + + + + + + + + @@ -163328,6 +163359,32 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + + + + + + + + + + + From 67695c97b837e3f803a17ecbcc2a27a4470d8d60 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 16 Sep 2025 23:50:55 +0200 Subject: [PATCH 25/51] clean-up: drop superseded or obsoleted RfCs See added comments for the reason --- doc/devel/rfc/AllPluginInterfacesAreC.txt | 10 +-- doc/devel/rfc/ApplicationStructure.txt | 2 +- doc/devel/rfc/CCodingStyleGuide.txt | 29 ++++++- doc/devel/rfc/GitCommitMessageFormat.txt | 51 +++++++++++- doc/devel/rfc/RefactorLiblumieraOut.txt | 19 ++++- doc/devel/rfc/SemanticTags.txt | 38 ++++++--- doc/devel/rfc/TodoLists.txt | 78 +++++++++++++------ .../CCodingStyleGuide.txt | 0 .../GitCommitMessageFormat.txt | 0 .../RefactorLiblumieraOut.txt | 0 .../SemanticTags.txt | 0 .../{rfc_parked => rfc_dropped}/TodoLists.txt | 0 12 files changed, 181 insertions(+), 46 deletions(-) rename doc/devel/{rfc_final => rfc_dropped}/CCodingStyleGuide.txt (100%) rename doc/devel/{rfc_final => rfc_dropped}/GitCommitMessageFormat.txt (100%) rename doc/devel/{rfc_pending => rfc_dropped}/RefactorLiblumieraOut.txt (100%) rename doc/devel/{rfc_pending => rfc_dropped}/SemanticTags.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/TodoLists.txt (100%) diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 33683523b..74c155b1c 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -173,8 +173,8 @@ documented in the repository (tiddlywiki/source) ct:: '2007-07-11 13:10:07' - -Development took another direction over course of the years; +.State -> Dropped +Development took another direction over the course of the years; Lumiera is not based on a _generic plug-in Architecture_ and the topic of interfaces for _dedicated plugins_ still needs to be worked out @@ -190,12 +190,12 @@ Architecture. Experience with high-profile projects based on such a concept seem to show both tremendous possibilities, especially regarding user involvement, but at the same time also indicate serious problems with long-term sustainability. -The practical development -- mostly driven ahead by _Ichthyo_ -- thus never really -embraced that idea; rather structuring by internal interfaces and contracts was +The practical development -- after some point mostly driven ahead by _Ichthyo_ -- never +really embraced that idea; rather structuring by internal interfaces and contracts was preferred. The basic system for loading of Plug-ins, as indicated by this proposal, is still used though to load some dedicated plug-ins, most notably the GUI. -To draw an conclusion: this proposal is now considered as *rejected*. +To draw a conclusion: this proposal is now considered as *rejected*. Instead, Ticket https://issues.lumiera.org/ticket/1212[#1212 »Extension Concept«] was added to the list of relevant https://issues.lumiera.org/report/17[»Focus Topics«] for further development. diff --git a/doc/devel/rfc/ApplicationStructure.txt b/doc/devel/rfc/ApplicationStructure.txt index f8a01bfdf..71f4a6d34 100644 --- a/doc/devel/rfc/ApplicationStructure.txt +++ b/doc/devel/rfc/ApplicationStructure.txt @@ -62,7 +62,7 @@ Then our application structure looks somewhat like (please refine): - ... Furthermore the interface and plugin system is flexible enough to provide things -independently of their origin (if it is build in or a plugin/dynamic library). +independently of their origin (if it is either built-in or a plugin/dynamic library). So deployment (where to link these things) is secondary. `"lumiera"` will then be the executable the user starts up, diff --git a/doc/devel/rfc/CCodingStyleGuide.txt b/doc/devel/rfc/CCodingStyleGuide.txt index 917ad31f4..55da055a7 100644 --- a/doc/devel/rfc/CCodingStyleGuide.txt +++ b/doc/devel/rfc/CCodingStyleGuide.txt @@ -3,7 +3,7 @@ Design Process : C Coding Style Guide [options="autowidth"] |==================================== -|*State* | _Final_ +|*State* | _Dropped_ |*Date* | _2007-07-03_ |*Proposed by* | ct |==================================== @@ -212,5 +212,32 @@ point'', i.e. every point in the system, that can be extended by plugins. Ichthyostega:: '2007-07-10T17:23:33Z' + +.State -> Dropped +During the last years, I have read this RfC several times, and I am still +not sure what this proposal wanted to achieve, and what was the intention of +proposing it this way. + +A ``C coding style'', a ``naming system'' meant to be very verbose, +but not intended to be about design, yet ``technically not needed when +using the plugin system'' -- which all together touches at +questions of design for sure. + +In the early stages of the project, there was a debate revolving around the +idea of bootstrapping the application from a tiny core, with pretty much +any functionality assembled from plugins, and internal functions being +callable directly from Lua code. Combined with a low-ceremony, distributed, +collaborative working style, such a setup was linked to the promise of +fluid evolution of ideas in order to try out unconventional solutions +and see what works best. + +Personally, this premise made me feel queasy, because I had a clear vision +in my head, which required to build some rather advanced and challenging +structures. Mastering complexity means to segregate and settle parts of a +problem in order to avoid excess interdependencies. I'd rather attempt +to deflect and redirect flexibility and differentiation towards the +periphery and establish stable yet generic structures in the core. + +Ichthyostega:: '2025-09-16' + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GitCommitMessageFormat.txt b/doc/devel/rfc/GitCommitMessageFormat.txt index 9da865ffd..ce27b6692 100644 --- a/doc/devel/rfc/GitCommitMessageFormat.txt +++ b/doc/devel/rfc/GitCommitMessageFormat.txt @@ -5,7 +5,7 @@ Git Commit Message Format [options="autowidth"] |==================================== -|*State* | _Final_ +|*State* | _Dropped_ |*Date* | _Fr 31 Aug 2012 03:54:14 CEST_ |*Proposed by* | Christian Thaeter |==================================== @@ -20,8 +20,8 @@ Description ----------- //description: add a detailed description: -Git commit messages are almost free form text, the only exception is that git -threats the first line in a commit message specially to form the header one +Git commit messages are almost free form text, the only exception is that Git +treats the first line in a commit message specially to form the header one sees in various outputs. Since we aim to automate some processing we refine the format for commit @@ -174,6 +174,51 @@ We decided on the sept. 2012 devel meeting to finlize this RFC. Christian Thaeter:: 'Do 13 Sep 2012 03:57:23 CEST' ~~ +NOTE: This RfC is now superseded by using the _Git-flow branching scheme._ + +.State -> Dropped + +With the recent move to link:{ldoc}/technical/code/GitBranching.html[Git-flow] +we acknowledge now -- by employing a branch model -- that the project history +is _built_ and _conducted_ consciously, _by us._ In the current stage, +it is not the goal of this project to churn out a stream of commits, +using an automated production line to push some metrics high. + +Since any automation comes at a cost and incurs burdens and limitations, +it should be employed to solve actual problems, but should not +be introduced prematurely: + +- we spend most of our time with finding suitable solutions, not with + coding them up. When a part is completed, some time can be spent + to document it and to consolidate the history. Thus, leaving + formalised WIP and STASH marks is besides the point. + +- releases and even bugfixes require forethought, analysis, verification + and reflection. The extra time required to set a git tag manually, or + even to perform a merge, is negligible in comparison, and does not + justify the weight of automation. + +- documentation is written in the context of solving actual problems; + it is pointless to spot ``documentation commits'' by some markers, + because their relevance is already obvious from a meaningful context. + +- Git bisect is an essential tool when working with a code base which you + do not understand. With a well-crafted yet ambitious system the situation + is quite distinct: in such a system, the change which caused the breakage + is obvious and easy to spot -- while the actual challenge is to + understand _why_ difficulties arose -- not to mention the amount + of work required to develop a path of escape from a real dilemma. + +This RfC highlights some general considerations however, which remain +valid anyway: to provide a short commit summary in the first line, +and then, after an empty line, to provide a description for +anything that is non-obvious, possibly with cross-references to +tickets, URLs pointing to external sources and anything that might +provide meaningful context for someone looking at this change +years later. And, commit messages should be line-wrapped. + +Ichthyostega:: '2025-09-16' + //endof_comments: '''' diff --git a/doc/devel/rfc/RefactorLiblumieraOut.txt b/doc/devel/rfc/RefactorLiblumieraOut.txt index 31ad2c586..3b4eea822 100644 --- a/doc/devel/rfc/RefactorLiblumieraOut.txt +++ b/doc/devel/rfc/RefactorLiblumieraOut.txt @@ -5,7 +5,7 @@ Refactor Liblumiera Out [options="autowidth"] |==================================== -|*State* | _Idea_ +|*State* | _Dropped_ |*Date* | _Fr 22 Apr 2011 10:46:50 CEST_ |*Proposed by* | Christian Thaeter |==================================== @@ -226,8 +226,25 @@ Comments -------- //comments: append below +.State -> Dropped +Ongoing development over the following years (after 2011) helped to clarify the situation +regarding the support library in Lumiera. The improved language standards, most notably C++14, +obsoleted most of the ad-hoc solutions in our library, since many aspects of system +integration are now handled by language and STL facilities in a satisfactory way. +On the other hand, by using the heightened capabilities of the language, some solution +patterns very specific to Lumiera could be established, gradually turning the support +library into some kind of an application framework. + +It is quite common in the field of software development to put great hopes into code +reuse -- yet it is this very tendency towards a framework which prevents that ideal +from playing out as anticipated, in practice. What seems to work best is to look +at some well-made piece of software, understand how it works, and then to copy +and extract parts in order to transform it into _your own solution._ + +Ichthyostega:: '2025-09-16' //endof_comments: + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SemanticTags.txt b/doc/devel/rfc/SemanticTags.txt index bb40d5621..875f1d66b 100644 --- a/doc/devel/rfc/SemanticTags.txt +++ b/doc/devel/rfc/SemanticTags.txt @@ -5,7 +5,7 @@ Semantic tags [options="autowidth"] |==================================== -|*State* | _Idea_ +|*State* | _Dropped_ |*Date* | _Do 30 Aug 2012 21:06:54 CEST_ |*Proposed by* | Christian Thaeter |==================================== @@ -13,7 +13,7 @@ Semantic tags ******************************************************************************** .Abstract We have a lot documentation which needs to be cross referenced. Adding well the -known 'tags' concept and extend it slightly with some semantics will aid future +known `tags' concept and extend it slightly with some semantics will aid future automatic processing. ******************************************************************************** @@ -21,15 +21,15 @@ Description ----------- //description: add a detailed description: -Every document (including sourcecode) could extended with some metadata, aka tags -which are then used to build automatic crossreferences. +Every document (including sourcecode) could be extended with some metadata, +aka. ``tags'', which are then used to build automatic crossreferences. -Commonly tags are just 'words' which are picked up and crossreferenceds. I propose +Commonly tags are _just words_ which are picked up and cross referenced. I propose to extend this scheme slightly. Overall this scheme must be very natual and easy to use. A user should not need to -know about the underlying machinery and a tag as in a single lowercase 'word' should -be sufficient in almost all cases. Moreover Tags should be optional. +know about the underlying machinery and a tag as in a single lowercase `"word"` +should be sufficient in almost all cases. Moreover Tags should be optional. .Ontology @@ -127,10 +127,13 @@ It is very urgent and important that we make our content much easier accessible. -//Conclusion -//---------- +Conclusion +---------- //conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: +⛔ This proposal was never expanded upon. +While containing some interesting ideas, in its current form +it is not deemed helpful for the project. @@ -141,7 +144,7 @@ Comments //edit comment You may recall this proposal created some heated debate at the last developer meeting. -After thinking it over some time, I can see now more clearly what irritated me. +After thinking it over some time, I can _see now more clearly what irritated me._ . for me, the proposal seems somewhat to lack focus. Right now we have some shortcomings at rather basic operations when *authoring content* at the website. This proposal tends to be more @@ -192,6 +195,21 @@ reader will somehow ``get it''. Ichthyostega:: 'Mi 10 Okt 2012 05:36:35 CEST' ~~ +.State -> Dropped +It is now _many years later,_ and no further discussion happened, nor did +anyone care to address the urgent practical needs related to stable cross-links +when authoring the website content. + +- -> link:{rfc}/WebsiteSupportMarkup.html[Cross-links and Website support markup] +- -> link:{rfc}/WebsiteNavigation.html[Website Navigation Menu] + +This proposal contains some intriguing ideas -- yet these ideas require more +dedicated work to transform them into a closed specification, which can be +judged for practicability. I would rather propose to start from the much +more concrete issue with the cross-links and develop a matching algorithm +which is sufficient to generate a ``linkfarm'' entry + +Ichthyostega:: '2025-09-17' //endof_comments: diff --git a/doc/devel/rfc/TodoLists.txt b/doc/devel/rfc/TodoLists.txt index 9bc303a12..e83eab89f 100644 --- a/doc/devel/rfc/TodoLists.txt +++ b/doc/devel/rfc/TodoLists.txt @@ -1,6 +1,9 @@ +How to organize work? +===================== + [options="autowidth"] |==================================== -|*State* | _Parked_ +|*State* | _Dropped_ |*Date* | _2008-03-05_ |*Proposed by* | ct |==================================== @@ -12,30 +15,12 @@ We need some way to organize tasks to be done (tiddlywiki, testsuite, ...?) Description ~~~~~~~~~~~ +Cehteh:: +``I want something which doesn’t need much human care and I want one big `milestones' thing +and a small `mini-task' thing'' - -Tasks -^^^^^ - - -Pros -^^^^ - - - -Cons -^^^^ - - - -Alternatives -^^^^^^^^^^^^ - - - -Rationale -^^^^^^^^^ - +Ichthyo:: +could be refined as as `Roadmap' and `Near time task list' @@ -43,8 +28,51 @@ Rationale Comments -------- -We decided to use a Tiddlywiki for now until this is further worked out +Discussed in the link:{ldoc}/devel/meeting_summary/2008-03-06.html#_idea_todo_lists[March.2008 developer meeting]. + +We decided to use a TiddlyWiki for now until this is further worked out ct:: '2008-03-08T03:38:50Z' +.... +​ +​ +​ +​ +​ +.... + +.looking back at another era... +What shall I say, just Whew! 😖 + +For context, I can recall that _Cehteh_ had a very pronounced aversion against bugtrackers +(and especially Bugzilla), because they are just plain confusing, filled with obsolete +information and last but not least, they create spurious work without being helpful +for the developer. Wouldn't it be much better to put everything into the code or +close to the code (as markup in comments)? Git would propagate this information +to the community of other contributors, which would decide about what is viable, +just simply by merging or not merging -- and some clever tool could watch the +resulting commit stream and extract the minimum necessary accounting to +supply the developers with that amount of information + they need to be actually productive.... + +.State -> Dropped +Lumiera is quite another kind of project today. There _is_ a https://issues.lumiera.org/[Bugtracker], +and I need all kinds of meta-tickets, tags, overview lists, the content in documentation pages plus +my own personal notes in several mindmaps just to cope with the sheer amount of information and not +to forget about matters already decided and settled. + +_All this meta-work takes a considerable amount of effort,_ for sure. + +Yet the question remains, how can I ``keep track'' without keeping track? +How can I judge and decide, without actually performing the judgement to arrive at a decision? +Would it make any difference to this dilemma, if ``someone else'' were to perform that work?? + +Can this kind of immaterial mental work be conditioned and commodified into an industrial process, +so that the individual person might side-step the effort, yet sill remain a sovereign? + +[purple]#I do not know the answer to this question.# + +Ichthyostega:: '2025-09-18' + + +'''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc_final/CCodingStyleGuide.txt b/doc/devel/rfc_dropped/CCodingStyleGuide.txt similarity index 100% rename from doc/devel/rfc_final/CCodingStyleGuide.txt rename to doc/devel/rfc_dropped/CCodingStyleGuide.txt diff --git a/doc/devel/rfc_final/GitCommitMessageFormat.txt b/doc/devel/rfc_dropped/GitCommitMessageFormat.txt similarity index 100% rename from doc/devel/rfc_final/GitCommitMessageFormat.txt rename to doc/devel/rfc_dropped/GitCommitMessageFormat.txt diff --git a/doc/devel/rfc_pending/RefactorLiblumieraOut.txt b/doc/devel/rfc_dropped/RefactorLiblumieraOut.txt similarity index 100% rename from doc/devel/rfc_pending/RefactorLiblumieraOut.txt rename to doc/devel/rfc_dropped/RefactorLiblumieraOut.txt diff --git a/doc/devel/rfc_pending/SemanticTags.txt b/doc/devel/rfc_dropped/SemanticTags.txt similarity index 100% rename from doc/devel/rfc_pending/SemanticTags.txt rename to doc/devel/rfc_dropped/SemanticTags.txt diff --git a/doc/devel/rfc_parked/TodoLists.txt b/doc/devel/rfc_dropped/TodoLists.txt similarity index 100% rename from doc/devel/rfc_parked/TodoLists.txt rename to doc/devel/rfc_dropped/TodoLists.txt From c7528bbe8add54150f6753c9136fc5b7f43b9ea6 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 18 Sep 2025 23:13:55 +0200 Subject: [PATCH 26/51] clean-up: some RfCs became effectively final The purpose of RfCs is to channel and document discussions among a group of developers regarding questions of design. While there is unfortunately no longer a group of developers discussing matters and working together on the code base, some questions can be considered more or less settled, by being implemented and validated. - the Scheduler - structure of the Developer Documentation - Application installation as relocatable bundle --- doc/devel/meeting_summary/2011-04-13.txt | 1 + doc/devel/rfc/ApplicationInstall.txt | 36 ++++++++----- .../rfc/DeveloperDocumentationStructure.txt | 30 ++++++++++- doc/devel/rfc/SchedulerRequirements.txt | 51 ++++++++++++++----- .../ApplicationInstall.txt | 0 .../DeveloperDocumentationStructure.txt | 0 .../SchedulerRequirements.txt | 0 7 files changed, 91 insertions(+), 27 deletions(-) rename doc/devel/{rfc_pending => rfc_final}/ApplicationInstall.txt (100%) rename doc/devel/{rfc_pending => rfc_final}/DeveloperDocumentationStructure.txt (100%) rename doc/devel/{rfc_pending => rfc_final}/SchedulerRequirements.txt (100%) diff --git a/doc/devel/meeting_summary/2011-04-13.txt b/doc/devel/meeting_summary/2011-04-13.txt index 8d388c9c3..21fd0d915 100644 --- a/doc/devel/meeting_summary/2011-04-13.txt +++ b/doc/devel/meeting_summary/2011-04-13.txt @@ -355,6 +355,7 @@ revisit the relevant design process entries in each developer meeting. -> link:{rfc}/ApplicationInstall.html[RfC: Application Install] +[[application_install_proposal]] .-- the Application Install proposal -- [caption="☉Transcript☉ "] ---------------------------- diff --git a/doc/devel/rfc/ApplicationInstall.txt b/doc/devel/rfc/ApplicationInstall.txt index 60fa8990d..70ea3460e 100644 --- a/doc/devel/rfc/ApplicationInstall.txt +++ b/doc/devel/rfc/ApplicationInstall.txt @@ -5,20 +5,20 @@ ApplicationInstall [options="autowidth"] |==================================== -|*State* | _Draft_ +|*State* | _Final_ |*Date* | _Di 11 Jan 2011 17:00:55 CET_ |*Proposed by* | Ichthyostega |==================================== [abstract] ********************************************************************************* -Lumiera should be a _freely relocatable_ application bundle. +Lumiera should be a _freely relocatable_ application bundle. + Relying only on the relative folder structure within this bundle, the application will be fully functional at any location, provided that the external library dependencies are resolvable using the standard mechanisms of the platform. -The setup mechanism must be obvious, self-explanatory and must not rely -on compiled in magic or buildsystem trickery. Yet packaging into a FSH conforming -installation location should be supported by the same mechanisms. +This setup mechanism should be obvious and self-explanatory and must not rely +on compiled-in hidden magic or buildsystem trickery. Yet packaging into a fully +FSH conforming installation location should be supported by the same mechanisms. ********************************************************************************* Description @@ -66,7 +66,7 @@ In former days, it was common habit to compile-in a hard wired absolute policy forbids doing so. This is the result from numerous maintainability problems in the past. On the other hand, the GNU linker and other modern linkers support a relative resolution of shared modules directly accompanying -an specific executable. The Debian policy allows this, if and only if these +a specific executable. The Debian policy allows this, if and only if these shared modules are installed with the same binary package and only used by this specific executable(s). Together, this is exactly what we need to solve our requirement. @@ -76,7 +76,7 @@ and sets the +DT_RUNPATH+ with an value relative to +$ORIGIN+, which resolves to the path of the currently executing binary. Moreover, it is _sufficient_ to set this on the initial executable _only,_ because this creates a common searchpath for all lib resolution events in the scope of that loaded executable. -Besides that, we need to care that our private libraries have a unique +SONAME+, +Besides that, we need to care that our private libraries have an unique +SONAME+, in this case all starting with the prefix +liblumiera*+. Note moreover that this new-style +DT_RUNPATH+ indeed _can_ be overridden by an +LD_LIBRARY_PATH+ in the environment, should there be the need for very special experiments. @@ -172,10 +172,10 @@ up some very specific problems and constraints, which can be a serious threat when discovered late in the development process. The second alternative isn't really applicable IMHO. The original UNIX philosophy -breeds on an academic setup and really excels with small nifty commandline utils +draws from an academic setup and really excels with small nifty commandline utils combined by pipes, each specialised to do a single thing very well. These utils are more like the objects within our implementation. The concept of large -application software bundles and desktop software was always a bit alien +application software bundles and desktop software was always slightly alien within the classic UNIX environment. @@ -191,17 +191,20 @@ trickery, inline code compiled on-the-fly, relying on very specific and un-obvious behaviour of some build script, configuration via environment variables and a lot of similar idioms. These practices might be adequate in a quickly moving Research & Development setup, but turned out to be -not so helpful when it comes to industrial strength development, +not so helpful when it used within large-scale development efforts, as they are known to lead to maintenance problems. -//Conclusion -//---------- +Conclusion +---------- //conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: - +All the indicated clean-up was done and the bootstrap sequence could be implemented. + +The link:{ldoc}/devel/meeting_summary/2011-04-13.html#application_install_proposal[Apr.2011 developer meeting] +shortly touched on this proposal without raising any objections. +``... for example this application install .. is boring .. we need it, you did it well'' (_Cehteh_) @@ -221,5 +224,12 @@ try to bring these points to discussion separately. Ichthyostega:: 'So 13 Feb 2011 20:04:00 CET' +.State -> Final +After being established in 2011, this structure was used ever since. There was once +a problem with a bug in `ld.so` related to the transitive use of the `$origin` token; +this bug had been resolved quickly. Other than that, packaging and application start +always worked as intended -- so I consider this topic as settled. + +Ichthyostega:: '2025-09-18' //endof_comments: diff --git a/doc/devel/rfc/DeveloperDocumentationStructure.txt b/doc/devel/rfc/DeveloperDocumentationStructure.txt index 57ab7cbf3..041873654 100644 --- a/doc/devel/rfc/DeveloperDocumentationStructure.txt +++ b/doc/devel/rfc/DeveloperDocumentationStructure.txt @@ -5,7 +5,7 @@ Developer Documentation Structure [options="autowidth"] |==================================== -|*State* | _Draft_ +|*State* | _Final_ |*Date* | _Mon Aug 2 18:03:25 2010_ |*Proposed by* | Cehteh + Ichthyo |==================================== @@ -125,7 +125,21 @@ developers. //---------- //conclusion: When approvedd (this proposal becomes a Final) // write some conclusions about its process: +This RfC had been started initially by _Cehteh_ to propose a _simple structure_ -- +the ensuing discussion however showed that our documentation is already structured +in a mostly consistent way, which just happens to be not that simple. Some confusing +redundancies could be removed, as result from that discussion. _Ichthyo_ then edited +and extended the original RfC to reflect the existing structure. +A serious problem is posed by the rather tedious procedure to define cross-links in the +Asciidoc based web content. link:WebsiteSupportMarkup.html[Another RfC] was created to +discuss these problems in detail, leading to a solution proposal, which unfortunately +was never implemented (due to lack of developer capacity). This _somehow transitory_ +situation had the (adverse) effect that most detailed technical content was authored +within the Development TiddlyWiki. + +These remaining problems do not seem to be related to the _structure_ of the documentation +however, which seems to fulfil its purpose. So this RfC now counts as de-facto standard. @@ -175,4 +189,18 @@ documentation in textual form, which is inherentely structured. Ichthyostega:: 'Mo 09 Sep 2013 01:01:25 CEST' ~~ +.State -> Final +I am using this structure now since several years, without encountering any +serious mismatch or incompatibility. The situation with the cross-linking +generator, which still remains to be implemented, is obviously some kind +of impediment, since it prevents me from migrating more mature content +from the TiddlyWiki into the documentation section of the website. + +Furthermore, I should notice, as a limitation, that I am the _only one_ to +use this structure actively -- so the fact that I feel comfortable with +the arrangement should be taken with a grain of salt. Yet, on the other +hand, we have meanwhile a massive body of information integrated +into this structure, so that it can be considered more than +just a ``proposal for discussion'' + //endof_comments: diff --git a/doc/devel/rfc/SchedulerRequirements.txt b/doc/devel/rfc/SchedulerRequirements.txt index 5266a44fd..e3a90503d 100644 --- a/doc/devel/rfc/SchedulerRequirements.txt +++ b/doc/devel/rfc/SchedulerRequirements.txt @@ -5,7 +5,7 @@ SchedulerRequirements [options="autowidth"] |==================================== -|*State* | _Draft_ +|*State* | _Final_ |*Date* | _Mi 09 Jan 2013 12:04:03 CET_ |*Proposed by* | Ichthyostega |==================================== @@ -15,7 +15,7 @@ SchedulerRequirements Define the expected core properties and requirements of the Scheduler service. ******************************************************************************** -The rendering and playback subsystem relies on a Scheduler component to invoke +The rendering and playback subsystem relies on a *Scheduler* component to invoke individual frame rendering and resource fetching jobs. This RfC summarises the general assumptions and requirements other parts of the application are relying on @@ -77,13 +77,14 @@ knowledge of some specific job's termination. More precisely, we need to find ou when a ``stream of calculations'' has left a well defined domain -- and this can be modelled by the activation of specific marker jobs. It is possible to obtain that knowledge with some timing leeway, but in the end, this information needs -to arrive with absolutely reliability (violations leading to segfault). +to arrive with absolutely reliability (memory management will rely on them, +and thus failure might lead to out-of.memory or segfault). job scheduling modes ~~~~~~~~~~~~~~~~~~~~ The scheduler offers various modes of treatment on a per job base. The default is to -handle jobs time based with a moderate latency. Alternatively jobs can be handled as +handle jobs as _time-bound_, with a moderate latency. Alternatively jobs can be handled as _background_ jobs, as _freewheeling_ jobs (maximum usage of performance and bandwidth), or as _low-latency timed_ jobs. @@ -115,9 +116,9 @@ Tasks // List what needs to be done to implement this Proposal: // * first step [yellow-background]#WIP# * define the job interface ([green]#✔ done#) - * define a protocol for job state handling [red yellow-background]#TBD# - * define the representation of dependencies and the notifications in practice [red yellow-background]#TBD# - * verify the proposed requirements by an scheduler implementation sketch [red yellow-background]#TBD# + * define a protocol for job state handling ([green]#✔ done#) + * define the representation of dependencies and the notifications in practice ([green]#✔#) + * verify the proposed requirements by an scheduler implementation sketch ([green]#✔#) @@ -138,7 +139,7 @@ Pros Cons ^^^^ // fact list of the known/considered bad implications: - * there is no ``for-loop'' to base any playback control structures on + * there is no ``while-loop'' to base any playback control structures on * compliance to externally imposed deadlines and memory management are challenging. Alternatives @@ -150,8 +151,8 @@ Alternatives We do not want (1), since it is tied to an obsolete hardware model and lacks the ability to be adapted to the new kinds of hardware available today or to be expected in near future. We do not -want (2) since it essentially doesn't solve any problem, but rather pushes complexity into the -higher layers (Session, Stage), which are lacking the information about individual jobs and timing. +want (2) since it essentially doesn't solve any problem, but rather pushes complexity into the higher +layers (Session, Stage), which however are lacking information about individual jobs and timing. @@ -161,17 +162,20 @@ Rationale We use a scheduler to gain flexibility in controlling various aspects of computation and I/O usage. Moreover, we turn the scheduler into an interface between the Vault and Steam-Layer; while the exact outfitting of the individual jobs highly depends on internals of the Session and Engine models, -the properties of _actual job execution_, closely related to system programming are akin +the properties of _actual job execution_, closely related to system programming, are linked to the Vault. The actual requirements outlined in this RfC are derived from the internals of the player implementation, while _the way_ these requirements are defined, and especially the aspects _omitted_ from specification are derived from knowledge regarding the possible scheduler and vault layer implementation. -//Conclusion -//---------- +Conclusion +---------- //conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: +A solution closely following this proposal was implemented and became a +centrepiece of the Lumiera Render Engine. There was no further formal +decision, since _Ichthyo_ worked alone during the past years. @@ -189,6 +193,27 @@ can be developed independently of the scheduler implementation Ichthyostega:: 'Do 19 Sep 2013 21:31:07 CEST' ~~ +.State -> Final +After an extended intermission, where development was focused at GUI topics, the integration +work since 2023 strives at achieving an initial integration of the Render Engine. As part of the +https://issues.lumiera.org/ticket/1221[#1221 »PlaybackVerticalSlice«], an implementation of the +Scheduler, as proposed by this RfC, was +link:/x/imp/Scheduler.html[built from scratch and tested extensively]. Practical experience +during this effort leads to the following refinements: + +- the Scheduler does not invoke Jobs, + + but processes _verbs_ from an _Activity Language_ rather. +- this language in turn embodies a primitive to check a dependency count +- an external event may re-trigger such a chain of Activities within the Scheduler +- an extent-based memory manager can be based on deadlines of these Activities. +- the Scheduler becomes a passive management task, pulled by a active Workers. +- Workers manage their capacity through a statistical distribution of _sleep times._ + +In this form, the proposal can be considered as implemented. + +^(see -> https://git.lumiera.org/?p=LUMIERA;a=commit;h=d71eb37[d71eb37] +and https://issues.lumiera.org/ticket/1344[#1344])^ + +Ichthyostega:: '2024-04-20 01:55 CEST' //endof_comments: diff --git a/doc/devel/rfc_pending/ApplicationInstall.txt b/doc/devel/rfc_final/ApplicationInstall.txt similarity index 100% rename from doc/devel/rfc_pending/ApplicationInstall.txt rename to doc/devel/rfc_final/ApplicationInstall.txt diff --git a/doc/devel/rfc_pending/DeveloperDocumentationStructure.txt b/doc/devel/rfc_final/DeveloperDocumentationStructure.txt similarity index 100% rename from doc/devel/rfc_pending/DeveloperDocumentationStructure.txt rename to doc/devel/rfc_final/DeveloperDocumentationStructure.txt diff --git a/doc/devel/rfc_pending/SchedulerRequirements.txt b/doc/devel/rfc_final/SchedulerRequirements.txt similarity index 100% rename from doc/devel/rfc_pending/SchedulerRequirements.txt rename to doc/devel/rfc_final/SchedulerRequirements.txt From 051cb31e283fa92c22c5e839e58839097727e740 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 5 Oct 2025 02:02:22 +0200 Subject: [PATCH 27/51] clean-up: re-classify essential RfCs The RfC documents were written to complement discussions of the Lumiera developers; yet since the time where ''Ichthyo'' is working basically alone on the project, this kind of discussions have ceased. During the following years, some ideas promoted by the existing RfC documents became rather detached from the actual state of development in the code base. Many of the existing RfC documents require some commentary to place them into context, and some of the decisions taken in the early stage of the project should be **re-assessed**. This includes the decision to reject some proposals, which initially might have seemed desirable, yet could not be reconciled with the understanding of the matter and topic in question, as was gained through the ongoing analysis and development. --- doc/design/architecture/ETD.txt | 12 +- doc/devel/meeting_summary/2008-02-01.txt | 2 +- doc/devel/meeting_summary/2008-04-03.txt | 3 +- doc/devel/meeting_summary/2008-06-06.txt | 2 +- doc/devel/rfc/AllPluginInterfacesAreC.txt | 2 +- doc/devel/rfc/ApplicationStructure.txt | 29 +- doc/devel/rfc/ConfigLoader.txt | 36 +- doc/devel/rfc/DataBackend.txt | 51 +- .../rfc/DeveloperDocumentationStructure.txt | 24 +- doc/devel/rfc/DevelopmentFramework.txt | 57 +- .../rfc/DistributedDevelopmentFramework.txt | 51 +- doc/devel/rfc/GitCommitMessageFormat.txt | 2 +- doc/devel/rfc/GitSubmoduleTransistion.txt | 32 +- doc/devel/rfc/GlobalInitialization.txt | 18 +- doc/devel/rfc/InterfaceNamespaces.txt | 15 + doc/devel/rfc/Manifest.txt | 4 +- doc/devel/rfc/MasterRepositorySetup.txt | 1 + doc/devel/rfc/RenderOptimizer.txt | 31 +- doc/devel/rfc/ScriptingLanguage.txt | 9 +- doc/devel/rfc/SkillsCollection.txt | 4 +- doc/devel/rfc/StreamTypeSystem.txt | 35 +- doc/devel/rfc/SystematicMetadata.txt | 58 +- doc/devel/rfc/WebsiteSupportMarkup.txt | 2 +- .../ConfigLoader.txt | 0 .../DataBackend.txt | 0 .../DistributedDevelopmentFramework.txt | 0 .../GitSubmoduleTransistion.txt | 0 .../ScriptingLanguage.txt | 0 .../SkillsCollection.txt | 0 doc/technical/library/DiffFramework.txt | 39 +- .../diff/tree-mutator-collection-binding.hpp | 4 +- wiki/thinkPad.ichthyo.mm | 874 +++++++++++++++++- 32 files changed, 1266 insertions(+), 131 deletions(-) rename doc/devel/{rfc_parked => rfc_dropped}/ConfigLoader.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/DataBackend.txt (100%) rename doc/devel/{rfc_final => rfc_dropped}/DistributedDevelopmentFramework.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/GitSubmoduleTransistion.txt (100%) rename doc/devel/{rfc_pending => rfc_dropped}/ScriptingLanguage.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/SkillsCollection.txt (100%) diff --git a/doc/design/architecture/ETD.txt b/doc/design/architecture/ETD.txt index b2a828f94..0adac6747 100644 --- a/doc/design/architecture/ETD.txt +++ b/doc/design/architecture/ETD.txt @@ -1,7 +1,7 @@ External Tree Description ========================= :Author: Ichthyostega -:Date: Fall 2015 +:Date: Autumn 2015 @@ -17,11 +17,11 @@ Any collaboration requires, as an underlying, some kind of common understanding. And any formalised, mechanical collaboration requires to represent that common point of attachment -- at least as _symbolic representation._ The »External Tree Description« is shaped to fulfil this need: _in theory,_ the whole field could be represented, symbolically, as a network of hierarchically -structured elements. Yet, _in practice,_ all we need is to conceive the presence of such a representation, +structured elements. Yet, _in practice,_ all we need is to presuppose the presence of such a representation, as a backdrop to work against. And we do so -- we work against that symbolic representation, -by describing *changes* made to the structure and its elements. Thus, the description of changes, -the link:{ldoc}/technical/library/DiffFramework.html[diff language], refers to and partially embodies -such symbolically represented elements and relations. +by describing *changes* made to the structure and its elements. And so the description of changes, +the link:{ldoc}/technical/library/DiffFramework.html[diff language], thus refers to and partially +embodies such symbolically represented elements and relations. Elements, Nodes and Records --------------------------- @@ -29,7 +29,7 @@ We have to deal with _entities and relationships._ Entities are considered the building blocks, the elements, which are related by directional links. Within the symbolic representation, elements are conceived as *generic nodes* (`GenNode`), while the directed relations are impersonated as being attached or rooted at the originating side, -so the target of a relation has no traces or knowledge of being part of that relation. Moreover, each +so that the target of a relation has no knowledge of being part of that relation. Moreover, each of our nodes bears a _relatively clear-cut identity._ That is to say, within the relevant scope in question, this identity is unique. Together, these are the building blocks to represent any *graph*. diff --git a/doc/devel/meeting_summary/2008-02-01.txt b/doc/devel/meeting_summary/2008-02-01.txt index 1f4767144..919f48c44 100644 --- a/doc/devel/meeting_summary/2008-02-01.txt +++ b/doc/devel/meeting_summary/2008-02-01.txt @@ -35,7 +35,7 @@ One point in the agenda of future meetings will be to work through proposals in The development model --------------------- -We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course)._ Cehteh_ is currently working on a Git web frontend which makes the codebase in the mob-repo web-editable like a wiki. +We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course). _Cehteh_ is currently working on a Git web frontend (``webgit'') which makes the codebase in the mob-repo web-editable like a wiki. Will we need a stable version or an official branch? not yet -- as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it. diff --git a/doc/devel/meeting_summary/2008-04-03.txt b/doc/devel/meeting_summary/2008-04-03.txt index 0cbeffcc6..05248b154 100644 --- a/doc/devel/meeting_summary/2008-04-03.txt +++ b/doc/devel/meeting_summary/2008-04-03.txt @@ -65,9 +65,8 @@ in registering to the project in planning/alpha stage to interest people such as It was noted that the https://web.archive.org/web/20090601174640/http://www.linux.com/archive/feature/126441[article on Linux.com] resulted in a lot of people contacting Ichthyo and Cehteh. -»I believe in Cinelerra« +https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-January/012806.html[»I believe in Cinelerra«] by Leo Germani also generated a lot of traffic by developers. -[purple]## Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on. Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful) diff --git a/doc/devel/meeting_summary/2008-06-06.txt b/doc/devel/meeting_summary/2008-06-06.txt index d6dda871a..9a9bdb468 100644 --- a/doc/devel/meeting_summary/2008-06-06.txt +++ b/doc/devel/meeting_summary/2008-06-06.txt @@ -32,7 +32,7 @@ Idea: Design the Render Nodes interface link:{rfc}/DesignRenderNodesInterface.html[RfC / Call for a Render Node interface] _Cehteh_ points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. -Later on, interface versions will be numbered. If needed, we could add a special ``draft'' or ``experimenta'' tag, +Later on, interface versions will be numbered. If needed, we could add a special ``draft'' or ``experimental'' tag, or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface. _Ichthyo_ agrees, but adds he also meant ``interface'' in this proposal in a wider sense, diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 74c155b1c..f79f4d1b5 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -175,7 +175,7 @@ ct:: '2007-07-11 13:10:07' .State -> Dropped Development took another direction over the course of the years; -Lumiera is not based on a _generic plug-in Architecture_ and the topic +Lumiera is _not_ based on a _generic plug-in Architecture_ and the topic of interfaces for _dedicated plugins_ still needs to be worked out Ichthyostega:: '2023-10-24 22:55:23' diff --git a/doc/devel/rfc/ApplicationStructure.txt b/doc/devel/rfc/ApplicationStructure.txt index 71f4a6d34..f08c94c3e 100644 --- a/doc/devel/rfc/ApplicationStructure.txt +++ b/doc/devel/rfc/ApplicationStructure.txt @@ -149,12 +149,15 @@ an architecture based on abstractions and exploiting the proven design patterns. Ichthyo:: '2008-11' - ++ +-- It has that flexibility, yes. But that means not that we have to abuse it in -any way. The main() there and thus the bootstrap of the application is under +any way. The `main()` there and thus the bootstrap of the application is under our tight control, if we want to reject scriptable/highly configurable bootstrapping there then we can just do so. Thats more a social than a -technical decision. I personally don't like if a design is ``nannying'' and puts +technical decision. + +I personally don't like if a design is ``nannying'' and puts too much constraints into unforeseen areas. If the computer can do some task better than we, it shall do it. This still means that I want to stay very much in control, it should only do some tedious, error-prone managing tasks for me. @@ -167,6 +170,7 @@ we have no control over. But I now realized that we can nicely use that for our own internal things too. IMO thats some very valuable service. ct:: '2008-11-08T06:26:18Z' +-- Some further minor details: We didn't finish the discussion about namespaces on the last meeting. (I know I still have to write up a proposal showing the two @@ -202,5 +206,24 @@ to document this here 😛 ct:: '2009-02-03T17:28:28Z' + +💡 + +[underline]#Historical remark#: this RfC is related to a series of discussions +and controversies during the early stages of the project -- which eventually +helped to establish a style of internal organisation within the application. + +After exploring various angles, Lumiera eventually became a *modularised Monolith* +-- using plug-ins for strictly optional parts of the system. Notably, the GUI +is loaded as a plug-in, and the integration with specific media-handling libraries +will rely on plug-in components as well. On the other hand, the core comprises +a small selection of built-in »Subsystems«, which are started with a formalised +lifecycle and dependency management. Flexibility is not attained by allowing +to totally reconfigure the application structure -- rather we allow for an +unusual degree of flexibility by combination and reconfiguration of +behaviour patterns within the application. + +Ichthyotega:: '2025-09-20' + + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/ConfigLoader.txt b/doc/devel/rfc/ConfigLoader.txt index 7e19d21ef..ca14143a8 100644 --- a/doc/devel/rfc/ConfigLoader.txt +++ b/doc/devel/rfc/ConfigLoader.txt @@ -6,7 +6,7 @@ Config Loader [options="autowidth"] |==================================== -|*State* | _Parked_ +|*State* | _Dropped_ |*Date* | _2008-08-07_ |*Proposed by* | **ct** |==================================== @@ -44,8 +44,8 @@ NOTE: (by _Ichthyostega,_ 2023) + -Parked -~~~~~~ + +.State -> Parked While the general idea seams adequate, the topic of Configuration requires a much more in-depth Requirement Analysis. Moreover, considering the state of tooling today (2023), I consider it questionable still to rely @@ -64,13 +64,35 @@ to be addressed _after achieving the first integration_ of the Engine. Ichthyostega:: '2023-10-24' ~~ +.State -> Dropped +Lumiera needs a system for configuration, but it will not work as proposed here. +The reasons for this decision can be traced back to questions of architecture +and the intended use of ``Configuration''. This became first clear in a +discussion between _Cehteh_ and _Ichthyo_, as they were walking together +through the forest north of the Karlsruhe castle in August 2011. -//Conclusion -//---------- -//conclusion: When approved (this proposal becomes a Final) -// write some conclusions about its process: +While _Cehteh_ aims at an unified set of configuration data, composed by +layering system-, user- and further local configuration files, to be combined +with textual expansion- and replacement mechanisms -- and the ability to +target a wide array of ``settings'' within the application, the intentions +of _Ichthyo_ go into an almost antithetical direction: He rather wants +to split off a very limited set of ``parametrisation'' and ``installation +configuration'', while handling most of the other possible choices by evaluation +of _configuration rules,_ which are tightly interwoven with the Session and +are actively resolved in the Builder, as opposed to being provided by a global +static _configuration service._ With this model, configuration can be injected +from various sources as a structured set of _facts._ Furthermore, _Ichthyo_ +wants to isolate the behaviour of the application from ad-hoc tweaks through +textual replacements and environment variables, rather looking for ways to +record any application of rules or facts in the global _Event Log._ +Ichthyostega:: '2025-09-20' +.... +​ +​ +.... +~What follows below is extended documentation for _Cehteh_'s Config System proposal...~ '''''''''''''''' diff --git a/doc/devel/rfc/DataBackend.txt b/doc/devel/rfc/DataBackend.txt index 380d37243..5210a2427 100644 --- a/doc/devel/rfc/DataBackend.txt +++ b/doc/devel/rfc/DataBackend.txt @@ -3,7 +3,7 @@ Design Process : Data Backend [options="autowidth"] |==================================== -|*State* | _Parked_ +|*State* | _Dropped_ |*Date* | _2007-06-04_ |*Proposed by* | ct |==================================== @@ -37,8 +37,8 @@ This just starts as braindump, I will refine it soon: link:http://localhost:8888/project/background/history/PossibilitiesAtHand.html[things possible in the middle layer]... -Parked -~~~~~~ +Conclusion: Dropped +------------------- The underlying principles remain valid, yet development took another direction during the last years. Special frameworks for high-performance asynchronous IO will be used for dedicated use cases. A garbage collector @@ -61,11 +61,56 @@ Developement takes place in the repo now ct:: '2007-06-27T16:14:56Z' +.State -> Parked Development took another direction over the last years; the former »Backend« layer is called »Vault« now and structured differently. Ichthyostega:: '2023-10-24T22:45:55Z' +.State -> Dropped +The approach to most of the topics listed in this RfC has shifted, and thus +it is time to draw the conclusion that overall Lumiera will not use a »Backend« +as an _adaptation layer,_ in the way envisioned here. Notably the idea of +centralising _any access to resources_ to apply some kind of instrumentation +and regulation is rejected. Rather, the »Vault« (as it is called now), +provides specialised low-level services with deep vertical integration; +this implies rather to establish dedicated control circuits for a small +number of special resources deemed performance critical. + +Most topics touched by this RfC however remain relevant, +yet will be approached differently... + +- while non-blocking, asynchronous I/O is still considered essential, + it is acknowledged that getting a grip at the resource usage of + external libraries and frameworks, integrated via plug-in, is a + non-trivial task, and must be approached at a case-by-case base. + +- the Scheduler provides a much more high-level and specialised + execution service then intended initially; the majority of + resource usage regulation will be achieved by adjusting the + job generation, which is connected to high-level structures, + while relying on generic resource observation facilities + in the Vault. + +- the Cache service will require a deep integration with the Builder + and the media / asset management; _cache invalidation_ will be + based on a _naming and identification scheme,_ which requires + explicit support by the high-level metadata management. + +- the Vault has no connection to media processing whatsoever, + it does not decode / encode data or mark and map parts of + media streams; this topic is coordinated at the level of + the builder and delegated to external facilities, while + the Vault provides some dedicated resource management + (notably handling GPU access and shader code) + +- file handles and generic file access are considered a non-issue, + as is the occasional usage of multithreading -- as long as any + substantial parallelism is organised through the scheduler. + +Ichthyostega:: '2025-09-20' + + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DeveloperDocumentationStructure.txt b/doc/devel/rfc/DeveloperDocumentationStructure.txt index 041873654..08270ad25 100644 --- a/doc/devel/rfc/DeveloperDocumentationStructure.txt +++ b/doc/devel/rfc/DeveloperDocumentationStructure.txt @@ -32,7 +32,7 @@ The Lumiera (developer) documentation shall be organised in the following way: link:{ldoc}/user/intro/intro.html[Lumiera from Outer Space], which outlines our vision and the fundamental concepts. . there is a section holding our link:{ldoc}/design/[design documents]. - Deliberately, these are written so to omit any technicalities, + Deliberately, these are written in a way omitting any technicalities, which keeps them valid as the technology evolves. . the entrance to the technical documentation is formed by link:{ldoc}/technical/overview.html[The inner Core] document. @@ -132,8 +132,8 @@ redundancies could be removed, as result from that discussion. _Ichthyo_ then ed and extended the original RfC to reflect the existing structure. A serious problem is posed by the rather tedious procedure to define cross-links in the -Asciidoc based web content. link:WebsiteSupportMarkup.html[Another RfC] was created to -discuss these problems in detail, leading to a solution proposal, which unfortunately +Asciidoc based web content. link:{rfc}/WebsiteSupportMarkup.html[Another RfC] was created +to discuss these problems in detail, leading to a solution proposal, which unfortunately was never implemented (due to lack of developer capacity). This _somehow transitory_ situation had the (adverse) effect that most detailed technical content was authored within the Development TiddlyWiki. @@ -153,12 +153,12 @@ Comments which includes the documentation. Why should we overthrow these results now and re-start the discussion? Lets just stick to this agreed on structure! * especially I don't like the way this proposal tries to squeeze everything into - an completely uniform structure. It is simply not true that the RFCs are just the + a completely uniform structure. It is simply not true that the RFCs are just the second level, and doxygen would cover the 3^rd^ level. Look at the existing documentation to see why. - - RFCs are a 'kind' of document, not a 'hierarchy level.' Indeed, our existing + - RFCs are a `kind' of document, not a `hierarchy level'. Indeed, our existing RFCs span all three hierarchy levels, and this is OK so and should remain this - way. (And yes, I like the RFCs much and want to retain them) + way. (And, in fact I consider the RFCs relevant and want to retain this formalism) - RFCs are well suited to topics requiring discussion and agreement by the whole core developer team. I see no point in 'pseudo-RFC-ing' the individual design decisions only relevant for an isolated part of the application and without @@ -170,11 +170,11 @@ Comments when asciidocing the content). * so my conclusion is rather having one overview text, and then the split into *conceptual* and *technical* documentation, each of which has a separate sub - structure not necessarily congruent to the structure on the other half. RFCs, + structure not necessarily congruent to the structure at the other half. RFCs, UML model and doxygen are just separate and consistent bodies of documentation and can be referred to from the main documentation. (I agree with the observation regarding permanent links into doxygen. But I can't imagine there isn't some - existing solution to this problem) + existing solution to this problem, waiting to be discovered) Ichthyostega:: '2010-10-15' ~~ @@ -190,7 +190,7 @@ Ichthyostega:: 'Mo 09 Sep 2013 01:01:25 CEST' ~~ .State -> Final -I am using this structure now since several years, without encountering any +I am using this structure since several years now, without encountering any serious mismatch or incompatibility. The situation with the cross-linking generator, which still remains to be implemented, is obviously some kind of impediment, since it prevents me from migrating more mature content @@ -199,8 +199,10 @@ from the TiddlyWiki into the documentation section of the website. Furthermore, I should notice, as a limitation, that I am the _only one_ to use this structure actively -- so the fact that I feel comfortable with the arrangement should be taken with a grain of salt. Yet, on the other -hand, we have meanwhile a massive body of information integrated -into this structure, so that it can be considered more than +hand, we have meanwhile a massive body of information structured +this way, so that it can be considered more than just a ``proposal for discussion'' +Ichthyostega:: '2025-09-20' + //endof_comments: diff --git a/doc/devel/rfc/DevelopmentFramework.txt b/doc/devel/rfc/DevelopmentFramework.txt index 34c53cf8f..0a430d65e 100644 --- a/doc/devel/rfc/DevelopmentFramework.txt +++ b/doc/devel/rfc/DevelopmentFramework.txt @@ -5,7 +5,7 @@ Design Process : Development Framework |==================================== |*State* | _Final_ |*Date* | _2007-06-08_ -|*Proposed by* | ct +|*Proposed by* | Cehteh |==================================== @@ -36,12 +36,12 @@ Description Tasks ^^^^^ -* cehteh will setup a initial repository +* _Cehteh_ will setup a initial repository (see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure]) * ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will add backport packages there if necessary so the debian-people can stay near Etch/stable in the next time -* ichthyo volunteers to get the new source into a debian package structure from +* _Ichthyo_ volunteers to get the new source into a debian package structure from start (same as the current cinelerra is) .And for later: @@ -133,5 +133,56 @@ We have now a ``compatibility wiki'', finalized this proposal ct:: '2008-03-26T13:43:26Z' +'''' +.... +​ +​ +​ +.... + +Assessment 2025 +~~~~~~~~~~~~~~~ +[underline]#In hindsight,# this RfC captures the baseline of our project setup. + +We soon settled upon the following toolchain, which is used up to today: + +- One published Git repository per developer, with direct pull / merging; + + history is consolidated eventually into the + link:{rfc}/MasterRepositorySetup.html#historical_remark[»official Lumiera repository«], + which is made accessible at + https://git.lumiera.org/?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`] +- We never used link:{rfc}/GitSubmoduleTransistion.html#_comments[Git submodules]... +- https://www.scons.org/[SCons] became the primary buildsystem soon, + with Autotools discontinued in 2011 +- https://trac.edgewall.org/[Trac] is used as planning- and ticket system. +- API documentation is extracted with https://www.doxygen.nl/[Doxygen] +- Website and documentation pages are generated by + https://asciidoc-py.github.io/[Asciidoc], with source files for + documentation maintained + https://git.lumiera.org/?p=LUMIERA;a=blob;f=doc/index.txt;h=9bc0f11e6fb67588388e7616320b695841571278;hb=20f3252892d5b53a05ecd8aeb571122806baba17[in-tree], + published + https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[automatically on push]. +- A https://classic.tiddlywiki.com/[TiddlyWiki] is used for development notes +- for Unit-Tests, we use our own minimalist + https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/lib/test/run.hpp;h=035633af9bde7a8053bcd304baffc21693dcf031;hb=20f3252892d5b53a05ecd8aeb571122806baba17[Test-runner]. + and a + https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/test.sh;h=8c13810eb475bbacd97c528607e6750f47bb145e;hb=20f3252892d5b53a05ecd8aeb571122806baba17[shell script] + to support definition of test collections. +- A Debian package is maintained with + https://wiki.debian.org/PackagingWithGit[git-buildpackage] and published + in our own DEB depot generated by the + https://wiki.debian.org/DebianRepository/SetupWithReprepro[reprepro tooling]. +- UML plays only a marginal role today -- yet in fact we generated our initial class + hierarchy with https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml], + as proposed by _Cehteh_. Sometimes, UML design sketches are made with + https://uml.sourceforge.io/[Umbrello], while schematic drawings, + Icons and graphic elements for the GUI are maintained + with https://inkscape.org/[Inkscape] +- Test-visualisation relies heavily on + https://graphviz.org/[Graphviz] and + http://www.gnuplot.info/[Gnuplot] + +Ichthyostega:: '2025-09-20' + + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/DistributedDevelopmentFramework.txt b/doc/devel/rfc/DistributedDevelopmentFramework.txt index eabc5dee9..9f8e50592 100644 --- a/doc/devel/rfc/DistributedDevelopmentFramework.txt +++ b/doc/devel/rfc/DistributedDevelopmentFramework.txt @@ -3,7 +3,7 @@ Design Process : Distributed Development Framework [options="autowidth"] |==================================== -|*State* | _Final_ +|*State* | _Dropped_ |*Date* | _2007-06-07_ |*Proposed by* | ct |==================================== @@ -47,9 +47,18 @@ Made this `final', this proposal got accepted and is already in use without much discussion ct:: '2007-06-27T16:07:13Z' +.... +​ +​ +​ +.... +[large]#🌑 ​ 🌒 ​ 🌓 ​ 🌔 ​ 🌕 ​ 🌖 ​ 🌗 ​ 🌘 ​ 🌑# -[underline]#Historical remark#: Not sure what this RfC was meant to propose; + -During the next year, an ambitious side-project named »*uwiki*« was started, +[underline]#Historical remark#: This was ultimately the first +_conceptual_ (not process-related) RfC published in this Design-Process +(note the date!). Thus, _in hindsight,_ +the question arises what this RfC was meant to propose; + +During the following months, an ambitious side-project named »**uWiki**« was started, with the goal to provide a wiki-like web frontend based on completely self-contained storage in a Git repository, without requiring any kind of data base. This project, however -- in spite of some compelling prototype implementations -- was abandoned; @@ -58,12 +67,40 @@ minimalist setup and would require a significant amount of web development rather -- a task no one was willing to take on. Yet the Lumiera project succeeded in building a web presence based on -https://asciidoc-py.github.io/[Asciidoc] sources checked into Git, with a lightweight -commit-hook script to automatically publish any changes on git-push -- a scheme +https://asciidoc-py.github.io/[Asciidoc] sources +https://git.lumiera.org/?p=website;a=summary[checked into Git], +with a lightweight +https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[commit-hook script] +to automatically publish any changes on git-push -- a scheme which comes close to the gist of this RfC. -Ichthyo:: '2025-09-08' +Ichthyostega:: '2025-09-08' + + +.State -> Dropped +After reconsidering this RfC, _many years later,_ it seems prudent to mark it as __`Dropped'.__ +The reasons for this decision are manifold. For one, the project never fully embraced this +working style, it was a vision from the early days rather. _Parts_ of that vision became a +practical reality, like the use of a link:{rfc}/MasterRepositorySetup.html[shared master repository], +or the use of Git and Asciidoc to generate and publish our website directly from a hook-script. + +But we did not ``create our own toolset to track issues, tasks, bugs in a distributed manner''. +This idea might seem enticing for a new experimental project, and, when taken further, it leads to +a development style where most questions of coordination, and notably the preparation of releases +and the delivery and roll-out of published code are handled by an automated production line. +Developers can do what they like most: ``code cool things'' -- while all that +``nasty other stuff'' is dealt with by an »Invisible Hand«. + +I do not consider such a setup healthy on the long run, nor can I see how it would be +adequate for a project with liabilities to care for: we should not consider the coordination +of a release cycle as something extraneous, to be ``automated away'' -- it requires the +full attention of the developers rather, to provide a longtime stable version and not to +interfere with the work of creative people, using the software in novel ways, +not foreseeable by the developers. +For this reason, I moved into the opposite direction and have now switched to the +link:/project/background/GitFlow.html[Git-flow branching model]. + +Ichthyostega:: '2025-09-20' '''' - Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GitCommitMessageFormat.txt b/doc/devel/rfc/GitCommitMessageFormat.txt index ce27b6692..0c65edcc1 100644 --- a/doc/devel/rfc/GitCommitMessageFormat.txt +++ b/doc/devel/rfc/GitCommitMessageFormat.txt @@ -204,7 +204,7 @@ be introduced prematurely: - Git bisect is an essential tool when working with a code base which you do not understand. With a well-crafted yet ambitious system the situation - is quite distinct: in such a system, the change which caused the breakage + is quite different: in such a system, the change which caused the breakage is obvious and easy to spot -- while the actual challenge is to understand _why_ difficulties arose -- not to mention the amount of work required to develop a path of escape from a real dilemma. diff --git a/doc/devel/rfc/GitSubmoduleTransistion.txt b/doc/devel/rfc/GitSubmoduleTransistion.txt index a2645b13c..1597105ed 100644 --- a/doc/devel/rfc/GitSubmoduleTransistion.txt +++ b/doc/devel/rfc/GitSubmoduleTransistion.txt @@ -1,6 +1,10 @@ +Design Process : Submodules +=========================== + + [options="autowidth"] |==================================== -|*State* | _Parked_ +|*State* | _Dropped_ |*Date* | _2008-04-09_ |*Proposed by* | ct |==================================== @@ -55,8 +59,8 @@ Pros Cons ^^^^ - * needs some more git-fu to be used by the developers - * we will host considerably more git repositories (bigger list in gitweb), + * needs some more Git-fu to be used by the developers + * we will host considerably more Git repositories (bigger list in gitweb), this is not a problem but might look more confusing @@ -75,16 +79,36 @@ When all people get used to it it allows a cleaner more sane work flow and well isolated, less conflicting commits. - +Conclusion: Dropped +------------------- +The extended usage of Git Submodules for parts of the code base is not desirable. Comments -------- +.State -> Parked We concluded that that submodules are not yet needed with exception for the ./doc folder. Parked for now. ct:: '2008-07-26 09:09:57' + +.State -> Dropped +Git Submodules were a highly anticipated feature at the time when the +Lumiera project started -- yet the actual implementation was generally +perceived as a disappointment, since the tooling failed to provide that +kind of seamless integration into everyday Git usage as was desirable. + +There remains one area however, where the Lumiera project might revisit +the idea of using Submodules: our _Website_ -- which might become a portal +to integrate several rather loosely coupled efforts eventually, notably +the public front-end, including some images, a user documentation section, +the technical documentation and possibly a knowledge base maintained +separately. + +Ichthyostega:: '2025-09-25' + + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GlobalInitialization.txt b/doc/devel/rfc/GlobalInitialization.txt index 24359c7c8..43a73c72b 100644 --- a/doc/devel/rfc/GlobalInitialization.txt +++ b/doc/devel/rfc/GlobalInitialization.txt @@ -132,7 +132,7 @@ there too, so it gets issued automatically. probably after parsing the commandline in main (and either this or the loading of a existing session will bring the proc layer up into fully operational state + - Ichthyo:: 'DateTime(2008-04-09T02:13:02Z' + Ichthyo:: '2008-04-09T02:13:02Z' * About NoBug initialization: I've seen that you made a `nobugcfg` where you centralized all nobug setup. Problem here is that a change in that file @@ -199,7 +199,7 @@ Some comments... - Regarding organisation of includes:... agreed - Initialisation of the very... - * I won't hesitate to add some C\++ functionality to give *NoBug* an + * I won't hesitate to add some C\++ functionality to give *NoBug* a singleton initialization in C++ - Then there is the initialisation of common services... _agreed_ @@ -266,7 +266,7 @@ outdated and ``misaligned'' IMHO. * Startup and Shutdown of an application like Lumiera requires way more than this. More specifically, we have to consider modularisation. * in hindsight, I was naiive to agree with this proposal. - It can not be that easy. + _It can not be that easy._ * my comments do indeed indicate the direction the further development did take: today, Lumiera does the _exact opposite_ of this proposal, there is *no central init call* -- we use *modularised hooks* instead @@ -280,6 +280,18 @@ we should preferably start a new RfC. Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~~ +💡 + +[underline]#Historical remark#: This RfC is closely related to discussions +regarding the link:{rfc}/ApplicationStructure.html[Application Structure] +and possibly using a link:{rfc}/AllPluginInterfacesAreC.html#_conclusion[Plug-in based Achitecture]. + +Investigating and debating these possibilities in a productive way was key +to gain an understanding what is required to build and maintain an Application +of this dimension and scope. + +Ichthyostega:: '2025-09-20' + + //endof_comments: '''' diff --git a/doc/devel/rfc/InterfaceNamespaces.txt b/doc/devel/rfc/InterfaceNamespaces.txt index 357bb75b7..6c0f192a4 100644 --- a/doc/devel/rfc/InterfaceNamespaces.txt +++ b/doc/devel/rfc/InterfaceNamespaces.txt @@ -143,5 +143,20 @@ this interfaces we will *break this plugin* intentionally! ct:: '2008-10-24T03:43:43Z' + +Clarification of relevance +~~~~~~~~~~~~~~~~~~~~~~~~~~ +As this RfC touches on the subject of Plug-ins, it should be stated very clearly +that Lumiera is **not based on a »Plugin Architecture«**. This Architecture Style +was indeed link:{rfc}/AllPluginInterfacesAreC.html[proposed and considered] during +the early stages of the project, but rejected later, based on the ensuing discussion +and experience with existing systems, as well as with our own implementation drafts +going into this direction. + +Lumiera will use Plug-ins however, to add _optional capabilities._ +And thus everything stated in this RfC regarding unique identifiers remains valid. + +Ichthyostega:: '2025-09-20' + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/Manifest.txt b/doc/devel/rfc/Manifest.txt index 0c2d5db73..c317694c6 100644 --- a/doc/devel/rfc/Manifest.txt +++ b/doc/devel/rfc/Manifest.txt @@ -111,10 +111,10 @@ project. Comments -------- -[underline]#This document is one of the **first RfC**s# published in *Summer 2007*, + +[underline]#This document is among the **earliest RfC**s# published in *Summer 2007*, + as a new community movement was about to form, with the goal to improve Cinelerra for real, in a new version Cinelerra-3. -Early in 2008, this initiative had turned into a new project, with the +At the beginning of 2008, this initiative had turned into a new project, with the https://web.archive.org/web/20231026200633/https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-March/013474.html[community chosen] name »*Lumiera*« -- years later, in 2010, documentation and existing RfC entries were migrated from _Cehteh_'s `pipapo.org` Wiki to the diff --git a/doc/devel/rfc/MasterRepositorySetup.txt b/doc/devel/rfc/MasterRepositorySetup.txt index f0845a112..81d092acc 100644 --- a/doc/devel/rfc/MasterRepositorySetup.txt +++ b/doc/devel/rfc/MasterRepositorySetup.txt @@ -51,6 +51,7 @@ ct:: '2008-04-08T21:48:51Z' '''' +[[historical_remark]] [underline]#Historical remark#: This RfC describes the setup we used up to ~2012. + After that point, I was working alone basically (not counting occasional small contributions), and consequently the current state could be found in the ``ichthyo'' Git repository diff --git a/doc/devel/rfc/RenderOptimizer.txt b/doc/devel/rfc/RenderOptimizer.txt index b2312b73e..11919b011 100644 --- a/doc/devel/rfc/RenderOptimizer.txt +++ b/doc/devel/rfc/RenderOptimizer.txt @@ -1,3 +1,7 @@ +Design Process : Optimiser +========================== + + [options="autowidth"] |==================================== |*State* | _Parked_ @@ -55,13 +59,36 @@ The good news is, that: always work in both colorspaces directly -Parked -~~~~~~ + +.State -> Parked Generally this is accepted but needs some more polishing when we go over it. Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST' +.Reassessment : remains valid +[underline]#Relevance confirmed 2025.# +This RfC is written narrow enough to just define the goal of an optimised +render pipeline -- which _was_ and _is_ a central goal of the Lumiera project. + +Approaching this topic however _requires much more work_ and notably a detailed +analysis of the possibilities, based on *facts and measurements*. There is the +real danger to get attached to some implementation idea deemed enticing, +leading to very specific tweaks which limit the ability to adapt to +other relevant requirements. + +Furthermore, since Lumiera aims at being library / framework agnostic, +a significant difficulty to overcome first is the build-up of an abstract +framework to describe and engage viable optimisations, which can then be +applied as transformations within the Builder -- quite similar to the +proceedings of an optimising compiler. The description of possible +optimisations likely involves elements of knowledge representation, +combined with heuristical aspects, possibly augmented by +machine learing. + +To summarise: this is a *long-term vision*. + +Ichthyostega:: '2025-09-20' '''' diff --git a/doc/devel/rfc/ScriptingLanguage.txt b/doc/devel/rfc/ScriptingLanguage.txt index d7e09e178..a33387892 100644 --- a/doc/devel/rfc/ScriptingLanguage.txt +++ b/doc/devel/rfc/ScriptingLanguage.txt @@ -3,7 +3,7 @@ Design Process : Scripting Language [options="autowidth"] |==================================== -|*State* | _Pending_ +|*State* | _Dropped_ |*Date* | _2008-07-26_ |*Proposed by* | ct |==================================== @@ -201,9 +201,10 @@ Ichthyostega:: '2023-02-04' ~~ Conclusion ---------- -Lua was _accepted_ as the required scripting language by October.2008 dev -meeting. However, Ichthyo _questions and overrules_ this decision in Feb.2023 -and moves this proposal back into the inception stage. +Lua was _accepted_ as the required scripting language by the +link:{ldoc}/devel/meeting_summary/2008-10-10.html#_lua_scripting_language[Oct.2008 dev meeting]. +However, Ichthyo __questions and overrules__ this decision in Feb.2023 +and moves this topic back into the inception stage. Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SkillsCollection.txt b/doc/devel/rfc/SkillsCollection.txt index 978075c6a..8a78788f5 100644 --- a/doc/devel/rfc/SkillsCollection.txt +++ b/doc/devel/rfc/SkillsCollection.txt @@ -4,7 +4,7 @@ Offering Skills for Help [options="autowidth"] |==================================== -|*State* | _Parked_ +|*State* | _Dropped_ |*Date* | _2007-06-13_ |*Proposed by* | ct |==================================== @@ -90,7 +90,7 @@ it was discussed shortly and deemed ``...only useful if there are more developer Reading this RfC today gives me some kind of peculiar melancholic feeling -- it has the vibes of »zero hour«, when all hands on deck are needed and everyone wants to help; people write their names on a blackboard -at the wayside, to get into contact, organise themselves or just to find their beloved ones... +at the wayside, to get into contact, organise themselves or maybe just to find their beloved ones... Ichthyostega:: '2025-09-11' diff --git a/doc/devel/rfc/StreamTypeSystem.txt b/doc/devel/rfc/StreamTypeSystem.txt index 7a2530244..4c4baa8b5 100644 --- a/doc/devel/rfc/StreamTypeSystem.txt +++ b/doc/devel/rfc/StreamTypeSystem.txt @@ -26,10 +26,17 @@ Description ----------- //description: add a detailed description: The general idea is that we need meta information, and -- more precisely -- -that _we_ need to control the structure of this metadata. Because it has -immediate consequences on the way the code can test and select the appropriate -path to deal with some data or a given case. This brings us in a difficult -situation: +that _we_ need to be in control with regards to the structure of this metadata. +Because this structure of metadata has immediate consequences with respect to the +code's ability to test and select an appropriate path to deal with some data or +a given clause in the high-level-Model.footnote:[To clarify the context of this +problem: the »Builder« works like a _compiler,_ while the high-level-Model is +similar to an attributed syntax tree. And the goal is to generate a low-level +processing description, which implements the given structure in the Session. +Drilling down some levels will yield a descriptor of a _medium_ (e.g. video) +-- and so the actual task becomes to define a formalised processing scheme +to work on something as unspecific as ``a medium''.] +This brings us in a difficult situation: * almost everything regarding media data and media handling is notoriously convoluted @@ -37,13 +44,13 @@ situation: solution * we want to build on existing libraries rather then re-inventing media processing. - * a library well suited for some processing task not necessarily has a type - classification system which fits our needs. + * a library well suited for some processing task does not necessarily have + a type classification scheme which fits our needs. -The proposed solution is to create an internal Stream Type System which acts as -a bridge to the detailed (implementation type) classification provided by the -library(s). Moreover, the approach was chosen especially in a way as to play -well with the rule based configuration, which is envisioned to play a central +The proposed solution is to create an internal *Stream Type System* which acts +as a bridge to the detailed (implementation type) classification provided by the +library(s). Furthermore, the approach was chosen especially in a way as to mesh +up well with the rule based configuration, which is envisioned to play a central role for some of the more advanced things possible within the session. @@ -52,18 +59,18 @@ Terminology * *Media* is comprised of a set of streams or channels * *Stream* denotes a homogeneous flow of media data of a single kind * *Channel* denotes an elementary stream, which -- _in the given context_ -- - can't be decomposed any further + can not be decomposed any further * all of these are delivered and processed in a smallest unit called *Frame*. Each frame corresponds to a time interval. * a *Buffer* is a data structure capable of holding one or multiple Frames of media data. - * the *Stream Type* describes the kind of media data contained in the stream + * the *Stream Type* describes the kind of media data contained in the stream. Concept of a Stream Type ~~~~~~~~~~~~~~~~~~~~~~~~ The Goal of our Stream Type system is to provide a framework for precisely -describing the ``kind'' of a media stream at hand. The central idea is to +describing the ``kind'' of a given media stream. The central idea is to structure the description/classification of streams into several levels. A complete stream type (implemented by a stream type descriptor) contains a tag or selection regarding each of these levels. @@ -95,7 +102,7 @@ Working with media stream implementations ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For dealing with media streams of various implementation type, we need _library_ routines, which also yield a _type classification system_ suitable -for their intended use. Most notably, for raw sound and video data we use the +for their intended use. Notably, for raw sound and video data we use the https://github.com/bplaum/gavl[GAVL] library, which defines a fairly complete classification system for buffers and streams. For the relevant operations in the Steam-Layer, we access each such library by means of a Façade; it may sound diff --git a/doc/devel/rfc/SystematicMetadata.txt b/doc/devel/rfc/SystematicMetadata.txt index c0ca62548..8e6a5b97a 100644 --- a/doc/devel/rfc/SystematicMetadata.txt +++ b/doc/devel/rfc/SystematicMetadata.txt @@ -15,9 +15,11 @@ SystematicMetadata [red]#TODO# _give a short summary of this proposal_ ******************************************************************************** -Lumiera is a metadata processing application: _Data_ is _media data_, and everything +Lumiera is a metadata processing application: the actual _Data_ processed +is the _media data_, used for rendering and playback, while everything else is _metadata_. Since our basic decision is to rely on existing libraries for -handling data, the ``metadata part'' is what _we are building anew._ +handling the data, the ``metadata part'' is what _actually happens_ within the +Lumiera application. This RfC describes a fundamental approach towards metadata handling. @@ -27,7 +29,7 @@ Description //description: add a detailed description: Metadata is conceived as a huge uniform tree. This tree is conceptual -- it is never represented as a whole. In the implemented system, we only ever see parts -of this virtual tree being cast into concrete data representations. These parts +of this virtual tree as being cast into concrete data representations. These parts are like islands of explicitly defined and typed structure, yet they never need to span the whole virtual model, and thus there never needs to be an universal model data structure definition. Data structure becomes implementation detail. @@ -35,11 +37,11 @@ model data structure definition. Data structure becomes implementation detail. Parts of the system talk to each other by _describing_ some subtree of metadata. This description is transferred _in the form of a tree diff:_ the receiver pulls a sequence of diff verbs from a diff iterator, and interpreting these verbs will -walk him down and expand the tree in question. Sub-scopes are ``opened'' and -populated, similar to populating a filesystem. It is up to the receiver to -assemble these information into a suitable representation. Some receiver -might invoke an object factory, while another serialises data into an -external textual or binary representation. +walk him down and expand or transform the tree in question. As part of this +description of model changes, sub-scopes are ``opened'' and populated, similar +to populating a filesystem. It is up to the receiver to assemble these information +into a suitable representation. Some receiver might invoke an object factory, +while another serialises data into an external textual or binary representation. Abstract Metadata Model @@ -86,18 +88,22 @@ Tasks * scrutinise this concept to find the pitfalls [yellow-background]#WIP# * build a demonstration prototype, where the receiver fabricates an object [red yellow-background]#TBD# ** the unit tests related to the _Diff System_ could be counted as such a demonstration + - Ichthyostega:: '2029-09-13' + Ichthyostega:: '2025-09-13' Discussion ~~~~~~~~~~ Pros ^^^^ -- the basic implementation is strikingly simple, much simpler than building - a huge data structure or any kind of serialisation/deserialisation scheme -- parts can be combined in an open fashion, we don't need a final concept up-front -- even complex routing and overlaying strategies become manageable, since they can be - treated in isolation, local for a given scope and apart from the storage representation +- the basic implementation of a meta data structure (a _property tree_) and the + representation of a ``Diff'' is comparatively simple -- much simpler than the + task to define and build a global data model, and get it properly connected + to the various implementation facilities to operate on this data. +- parts can be combined and can evolve in an open ended way, without requiring + a finalised concept up-front, +- even complex routing and overlaying strategies remain manageable, since routing + and data fusion can be treated in isolation, local for a given scope and apart + from the storage representation; - library implementations for textual representations can be integrated. @@ -133,10 +139,12 @@ Basically common (meta) data could take on a lot of shapes between two extremes: - the _precise typed structure_, which also is a contract - the _open dynamic structure_, which leaves the contract implicit -The concept detailed in this RfC tries to reconcile those extremes by avoiding -a global concrete representation; + -this way the actual interaction -- with the necessity -of defining a contract -- is turned into a local problem. +The concept explained in this RfC tries to reconcile those extremes by avoiding +a global concrete representation; instead, several interactions, each local in +scope, can coexist on top of the abstract structure as backdrop. Each of these +actual interactions can have its own specialised standard, which actually is +a collaboration protocol, and is based on a common understanding of the +_structure,_ instead of sharing actual data implementation. //Conclusion @@ -161,15 +169,17 @@ found their way into the *Diff System*, now used as a foundation for connecting GUI to the Session core in Steam Layer. Especially the discussion of ``Alternatives'' seem to indicate that an essential motivation for this RfC was to find a viable alternative to building the whole Application around a _central data model_ -- -which is in essence what I later transformed into a practical concept with the -aforementioned ``Diff System''. +which is the naive solution and tends to become a major impediment to +hinder the further evolution within larger software projects. --> see the design page regarding link:{ldoc}/design/architecture/ETD.html[»External Tree Description«] +- -> see the design page regarding link:{ldoc}/design/architecture/ETD.html[»External Tree Description«] +- -> and the corresponding technical description + regarding the link:{ldoc}/technical/library/DiffFramework.html[Diff Framework] [underline]#Bottom line#: not sure what to do with this RfC; concepts explained therein -seem still highly relevant and central to what Lumiera is intended to become; -but this text does not fit into the format of an RfC, nor is there a community -of developers to discuss such a design vision appropriately. +seem still highly relevant and central to what Lumiera is intended to become -- and they +have already been implemented; hoever, this text does not fit into the format of an RfC, +nor is there a community of developers to discuss such a design vision appropriately. Ichthyostega:: '2025-09-13' diff --git a/doc/devel/rfc/WebsiteSupportMarkup.txt b/doc/devel/rfc/WebsiteSupportMarkup.txt index 3ac9fbafd..6bff1347b 100644 --- a/doc/devel/rfc/WebsiteSupportMarkup.txt +++ b/doc/devel/rfc/WebsiteSupportMarkup.txt @@ -251,7 +251,7 @@ Unfortunately, nothing has happened with this RfC ever since; the reason is lack of developer capacity. Since this RfC is already fairly detailed, and no significant objections were pointed out, I am promoting this RfC to a __"Draft"__ now, yet leave it pending. Same as with the -link:WebsiteNavigation.html#_comments[RfC: Website Navigation]. +link:{rfc}/WebsiteNavigation.html#_comments[RfC: Website Navigation]. Ichthyostega:: '2025-09-18' diff --git a/doc/devel/rfc_parked/ConfigLoader.txt b/doc/devel/rfc_dropped/ConfigLoader.txt similarity index 100% rename from doc/devel/rfc_parked/ConfigLoader.txt rename to doc/devel/rfc_dropped/ConfigLoader.txt diff --git a/doc/devel/rfc_parked/DataBackend.txt b/doc/devel/rfc_dropped/DataBackend.txt similarity index 100% rename from doc/devel/rfc_parked/DataBackend.txt rename to doc/devel/rfc_dropped/DataBackend.txt diff --git a/doc/devel/rfc_final/DistributedDevelopmentFramework.txt b/doc/devel/rfc_dropped/DistributedDevelopmentFramework.txt similarity index 100% rename from doc/devel/rfc_final/DistributedDevelopmentFramework.txt rename to doc/devel/rfc_dropped/DistributedDevelopmentFramework.txt diff --git a/doc/devel/rfc_parked/GitSubmoduleTransistion.txt b/doc/devel/rfc_dropped/GitSubmoduleTransistion.txt similarity index 100% rename from doc/devel/rfc_parked/GitSubmoduleTransistion.txt rename to doc/devel/rfc_dropped/GitSubmoduleTransistion.txt diff --git a/doc/devel/rfc_pending/ScriptingLanguage.txt b/doc/devel/rfc_dropped/ScriptingLanguage.txt similarity index 100% rename from doc/devel/rfc_pending/ScriptingLanguage.txt rename to doc/devel/rfc_dropped/ScriptingLanguage.txt diff --git a/doc/devel/rfc_parked/SkillsCollection.txt b/doc/devel/rfc_dropped/SkillsCollection.txt similarity index 100% rename from doc/devel/rfc_parked/SkillsCollection.txt rename to doc/devel/rfc_dropped/SkillsCollection.txt diff --git a/doc/technical/library/DiffFramework.txt b/doc/technical/library/DiffFramework.txt index c8048f45d..6fca425a1 100644 --- a/doc/technical/library/DiffFramework.txt +++ b/doc/technical/library/DiffFramework.txt @@ -308,7 +308,7 @@ mutation. Some typical ``degenerated'' patterns of spelling out a diff are as fo Representation of objects ~~~~~~~~~~~~~~~~~~~~~~~~~ -While we are talking about _structured data,_ in fact the entities we are about to handle are *objects*, conceived in +While we are talking about _structured data,_ in fact the entities we are about to handle are *objects*, understood as in the standard flavour of object orientation, where an object is the instance of a type and offers a contract. Incidentally, this is not the original, ``pure'' meaning of object orientation, but the one that became prolific to bring our daily practice closer to the inherent structuring of modern human organisation. And in dealing with this kind of object, we @@ -320,12 +320,16 @@ Even when this bears the danger to raise failures rather late, when it comes to data structure. The intention behind this whole diff approach is to transform tight coupling with strict rules into a loose collaboration based on a common understanding. So generally we'll assume the diff is just right, and if not, we'll get what we deserve.footnote:[This gives rise to a tricky discussion about loss of strictness -and the costs incurred by that happening. We should not treat this topic in isolation; we should recall that -loose coupling was chosen to avoid far more serious problems caused by tight coupling, and especially the -deteriorating and poisoning effect on architecture and the further dire consequences of a global fixed common -data model -- which prevail when used in large, not heterogenous systems. +and the costs incurred by that choice: Assuming as starting point a fixed global data model, which is strict, +yet we choose to open the tight connection and rather prefer a collaboration based on a ``common understanding'' +-- which seems _fuzzy_ and might be seen as an unfortunate choice. We should not treat this topic in isolation however; +we should recall rather that loose coupling was chosen to avoid far more serious problems caused by tight coupling, +and especially the deteriorating and poisoning effect on architecture and the further dire consequences of a global +fixed common data model -- which prevail when used in large, and overall heterogeneous systems. And _when a system indeed is not homogeneous,_ we better try to make each part open-closed, open for change -but closed against extension. This is especially true in the case of the UI.] +but closed against extension. This is especially true in the case of the UI. And together this implies that +we have small cohesive units of functionality; a collaboration between such units is _not_ considered +dangerous, as long as it conforms to a well defined protocol and does not leave the local and cohesive scope.] object representation protocol @@ -335,14 +339,27 @@ A diff is created to tell some partner about our data, and the »protocol to des - the ID is the object's identity and is given once, right at start, and never changed - we spell out any metadata first (esp. type information), followed by all attributes, and then followed by contents of the object's scope (children). -- attributes are to be given such as not to counter the more stringent semantics - of an object field or property +- attributes must be spelled out in such a way as not to counteract the more stringent semantics + of an object field or property. More specifically... * never attempt to re-order or delete such attributes, since their presence is fixed in the class definition * when a field is mandatory _by its nature,_ it shall be required at construction, and the corresponding data - is to be given with the `ins` verb causing the constructor call + needs to be given immediately with the `ins` verb causing the constructor call * on the other hand, the data for an optional field, when present, shall be spelled out by `ins` verb after construction, with the first _population diff._ - * we do not support attribute map semantics (or extended ``object properties'' of any kind). + - If necessary, treat them as nested entity with map semantics + * the diff can address an attribute by its key; in the concrete binding to an object this will + cause a linear search through all attribute handlers to find the proper one, responsible for the + specific attribute given + * we do not support attribute map semantics (or extended ``object properties'' of any kind, as many + script languages do). If it is deemed necessary, in special cases, to have a _map_ of `(key ⟼ value)` + bindings, then do not represent them as object attributes, rather treat them as nested entity with map + semantics.footnote:[The `TreeMutator` provides a ready-made binding to STL containers, with a special + case to address a map. But this remains a borderline case and this usage to apply a diff to a map + can be tricky (due to the ordering constraints of a map).] +TIP: nothing has been said about _detecting_ differences in object or property trees; + it is assumed that solving this especially nasty problem can be avoided, since + the _emanation_ of a diff in Lumiera can always be assumed to have additional + knowledge regarding the location of the change, and thus does not need to + ``find'' the changed data. The reasoning behind this assumption is that + the diff messages are generated in response to an _Event._ diff --git a/src/lib/diff/tree-mutator-collection-binding.hpp b/src/lib/diff/tree-mutator-collection-binding.hpp index bdb24b15a..ef237a583 100644 --- a/src/lib/diff/tree-mutator-collection-binding.hpp +++ b/src/lib/diff/tree-mutator-collection-binding.hpp @@ -38,7 +38,7 @@ ** - at the bottom we use an adaptation layer in the form of a traits template, ** with two concrete specialisations of the ContainerTraits for vector-like ** and map-like collections - ** - on top of this the CollectionBinding is established to establish a kind of + ** - on top of this the CollectionBinding is established to provide a kind of ** generic access protocol for consuming a collection guided by diff instructions ** - the third level then holds the actual TreeMutator implementation, embodied into ** the ChildCollectionMutator template, which in fact translates and delegates @@ -48,7 +48,7 @@ ** provided by the client of this collection binding. The entrance point to this ** DSL layer is the _DefaultBinding, which is established by wrapping the actual ** collection into the concrete CollectionBinding at the point where the builder - ** is created. The further DSL verbs on the CollectionBindingBuilder just server + ** is created. The further DSL verbs on the CollectionBindingBuilder just serve ** to provide or overlay some lambdas to fill in the flexible parts of the binding. ** ** And these flexible parts are mostly concerned with the _actual contents_ of the diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index cc53d4d45..08699e5bf 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -161051,10 +161051,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + - + @@ -161164,8 +161165,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + @@ -161212,7 +161217,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161232,7 +161237,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161344,11 +161349,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + - + @@ -161368,6 +161373,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + @@ -161379,6 +161385,25 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + +

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

+ + + + + @@ -161487,14 +161512,29 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + - + + + + + + + + + - + + + @@ -161510,9 +161550,13 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + @@ -161539,6 +161583,28 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + +

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

+ + + + + + + + + @@ -161707,7 +161773,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161728,6 +161794,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + @@ -161861,8 +161928,9 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + @@ -162655,7 +162723,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -162664,7 +162732,18 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo

+ + + + + +

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

+ + + @@ -163269,6 +163348,260 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + +

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

+ + + + + + + + +

+ einige meiner Texte habe ich als HTML gespeichert +

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

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

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

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

+ + + + + + + +

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

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

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

+ + + + + + + + + + +

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

+

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

+ + + + + + + +

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

+ + + + + + + +

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

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

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

+ + + + + + + + + + +

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

+

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

+

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

+

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

+

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

+

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

+

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

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

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

+

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

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

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

+

+ +

+

+ commit c0d7ae1aa2073e4e5b29f864d32a639c2864e9a1 +

+

+ Merge: b5d2e9486 2e58b02b8 +

+

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

+

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

+

+ +

+

+     Merge added builder documentation +

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

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

+ + + + + + + + + + @@ -163311,10 +163644,421 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + +

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

+ + + + + + +

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

+ + + + + + + +

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

+ + + + + + + +

+ eine Menge RfCs waren politisch aufgeladen +

+ + + + + +

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

+ + + + + + + +

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

+ + + + + + + + + + +

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

+ + + + + + + +

+ habe ich schon vor einigen Jahren explizit verworfen +

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

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

+

+ +

+

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

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

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

+

+ +

+

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

+ + + + + + + + +

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

+

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

+

+ +

+

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

+

+ +

+

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

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

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

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

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

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

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

+ + + + + + + +

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

+ + + + + + + + +

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

+

+ +

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

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

+

+ +

+

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

+

+ Konsequenzen +

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

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

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

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

+ + + + + + + +

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

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

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

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

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

+

+ +

+

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

+ + + + + + + + - - + + + @@ -163348,6 +164092,99 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + +

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

+ + + + + + + + + +

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

+ + + + + + + + +

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

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

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

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

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

+

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

+

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

+

+ outweigh the drawbacks. +

+

+
+ +

+

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

+

+ +

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

+ und zwar für zwei Dinge +

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

+ nenne es »can be solved« +

+ + + + + + + + + +

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

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

+ dahinter steckt eine Form des Verfallens +

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

+ ⟹ auf Frederick Brooks zurückgreifen +

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

+ Recherche: das war ja noch alles viel dramatischer +

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

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

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

+ Das meine ich auf mehreren Ebenen +

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

+ Warnung: gefühlte Realität +

+ + + + + + + +

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

+ + + + + + + + + +

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

+ + + + + + + + + +

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

+ + + + + + + + + +

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

+ + + + + + + + + +

+ Auseinandersetzung mit der Historie  ⟹  habe Liberalismus  dahinter entdeckt +

+ + + + + + + +

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

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

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

+ + + + + + + + + +

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

+ + + + + + + + + +

+ Das ist ein strategischer Ansatz +

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

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

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

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

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

+ Erste Mail: Oktober 2006. +

+

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

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

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

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

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

+ + + + + + + + + +

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

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

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

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

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

+

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

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

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

+ + + + + + + + + + +

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

+ + + + + + + + + +

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

+

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

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

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

+ + + + + + + + + + +

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

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

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

+ + + + + + + + + + +

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

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

+ OpenStreetMap project. +

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

+ Hatte damals die Idee, +

+

+ die verschiedensten Video-Entwickler +

+

+ in einem Meta-Projekt »Open Video« +

+

+ zusammenzubringen +

+ + + + + + + +

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

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

+ Fazit: es hat sich erübrigt +

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

+ commit 13b963ba5bc39603c1d425752f07d8b3941f01ba +

+

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

+

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

+

+ +

+

+     initial commit, just tiddlywiki tests +

+ + + + + + + + + +

+ commit 0a9c2599dd49990b8ccf779a44abdaba626bdd86 +

+

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

+

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

+

+ +

+

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

+ + + + + + + + + +

+ commit 0a9c2599dd49990b8ccf779a44abdaba626bdd86 +

+

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

+

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

+

+ +

+

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

+ + + + + + + + + +

+ commit a313ea87a588241a1db72b6cac6e2aee2b512fc7 +

+

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

+

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

+

+ +

+

+     Work in progress, just for review +

+

+ src/lib/plugin.c +

+

+ src/lib/plugin.h +

+ + + + + + + + + +

+ commit 471148b7db2e41f2c081760cc367710ce6999da9 +

+

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

+

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

+

+ +

+

+     basic automake setup +

+ + + + + + + + + +

+ commit ebb4da6cc738392c015c7d66c54c6483331459f4 +

+

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

+

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

+

+ +

+

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

+ + + + + + + + + +

+ commit ed4decb5de9c6c22bb0f9173e3d239fefe9453e7 +

+

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

+

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

+

+ +

+

+     added notes from yesterday irc discussion +

+ + + + + + + + + + +

+ commit 45c21677009dfc733d0ecd6f26d783c99b2818d5 +

+

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

+

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

+

+ +

+

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

+ + + + + + + + + +

+ commit ce3eb42131b0f8f809b00ef9a7759eb885e684d3 +

+

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

+

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

+

+ +

+

+     test suite works now basically +

+ + + + + + + + +

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

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

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

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

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

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

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

+

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

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

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


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

 These are interesting times ��

+
+ -- 
Herman Robak
+
+

+

+ +

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

+ +

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

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

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

+ Error, Locking, Plugin und eine Linked List +

+ + + + + + + + + +

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

+

+ +

+

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

+

+ +

+

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

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

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

+ + + + + + + + + +

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

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

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

+ + + + + + + + + +

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

+ + + + + + + + + +

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

+

+ +

+

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

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

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

+

+ +

+

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

+

+ +

+

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

+ + + + + + + + + +

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

+

+ +

+

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

+ + + + + + + + + + +

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

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

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

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

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

+ + + + + + + +

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

+ + + + + + + + + + +

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

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

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

+ + + + + + + + + +

+ Und das hat mehrere Quellen +

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

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

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

+ Deshalb ist die Beurteilung dieser Kontroverse so schwierig +

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

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

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

+ 8.7. +

+ + + + + + + + + +

+ 9.7. +

+ + + + + + + + + +

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

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

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

+ + + + + + + + + +

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

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

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

+

+ +

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

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

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

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

+ + + + + + + + + +

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

+

+ ich hatte es aber schnell wieder verdrängt +

+ + + + + + + +

+ Woher weiß ich das? +

+

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

+

+ +

+

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

+ + + + + + + + + + + 

+    

+      
Vorhin hab ich gesehen, daß Du auch grade die ersten Schritte
+in UML gemacht hast; bin schon gespannt...

+    

+    
bin am fluchen, verdammt lange her das ich UML das letzte mal angeschaut
+hab, das war 1.0 und da hat sich einiges getan, ausserdem fehlen mir
+oder bouml einfach ein paar sachen um bestimmte dinge zu modelliern.
+
+	Christian
+
+

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    
Ichthyostega wrote:

+    

+      
So, could you please have a look at this prototype buildsystem? I pushed out to cinelerra3/ichthyo
+ #scons     - just the buildsystem
+ #prototype - contains the same code plus the files of my experimental/prototype branch to compile

+    

+    
morning, trying it out now ��, next i'll write some DesignProcess
+proposals about C nameing rules, plugins and interfaces. (i am back ;))
+
+note about gnu style: (how I/emacs interpret it)

+    

+      ....
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      ganz klar eine Anspielung an "Terminator"
+    

+    

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

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

+      

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

+    

+    

+      

+        

+          ct
+        

+        

+          

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

+        

+      

+    

+  
+
+
+
+  
+    
+  
+  
+    

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

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+    

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

+    

+      
    
+        
  • 
+          
    
+            Just only use C++
+          
    
+        
    • 
+        
  • 
+          
    
+            Maybe SWIG?
+          
    
+        
    • 
+        
  • 
+          
    
+            Implement lumiera in C instead C++
+          
    
+        
    • 
+      

+    

+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+    

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

+    

+      
+    

+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+    

+      Ich lese das zwischen den Zeilen so
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+    

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

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

+      
Am Dienstag, den 03.07.2007, 20:51 +0200 schrieb Christian Thaeter:
+
+

+      

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

+      

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

+    

+    

+      
+    

+  
+
+
+
+  
+    
+  
+  
+    

+      effektiv ist das eine freundlich verpackte Ablehnung
+    

+  
+
+
+
+
+  
+    
+  
+  
+    

+      hier sage ich explizit, und mir Argument,
+    

+    

+      daß ich C als Einschränkung empfinde
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+  
+    
+  
+  
+    
Voßeler Hermann wrote:

+    

+      
Am Dienstag, den 03.07.2007, 20:51 +0200 schrieb Christian Thaeter:
+
+

+      

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

+      

+      
yes, I have seen it this morning. I have to look at it more carefull
+tonight, when at home. Basically, it looks OK for all external
+interfaces, i.e. interfaces other external apps or components will use
+to call to cinelerra or to embed within cinelerra. Good examples for 
+this type of things are LADSPA plugins or some video codec interface
+
+For use /within/ the application we should consider the following
+questions first:
+* how much "plugin architecture" do we want? Does a "micro
+  kernel/plugin" aproach help? how then do we handle extension points?

+    

+    
imo as much as possible, I stated that the cinelerra main app should be
+only a skeleton using plugins. (do we want to start more monolithic and
+then factor plugins out, or plugins from start on?)
+
+Extensions shall be considered when designing this interfaces. I also
+considered to make the plugin interface extensible without breaking
+compatibility (naturally it will turn out whats needed during
+development of new features)
+
+consider my favorite example
+ (based on cin2, cin3 might be little diffrent):
+Cinelerra has tracks on the timeline, these tracks shall be plugins (we
+provide plugins for audio and video tracks, but someone might provide
+tracks for midi, 3D animation or such)
+
+Tracks have some gui components
+ 1. patchbay
+ 2. timline drawing (thumbs for video, waveform for audio, notes for
+midi, ...)
+
+some internal components:
+ 1. list of clips on the track
+ 2. attached effects container
+
+(and some more)
+
+we now need to define/collect what interfaces are needed to implement
+tracks. There will be not a single interface but a group of related
+interfaces which in sum define the behaviour and gui rendering of a track.
+ * cinelerra_track_gui_patchbay_interface
+  defines the patchbay gui
+ * cinelerra_track_gui_timeline_interface
+  how timeline is rendered
+ * cinelerra_track_effects_container_interface
+  manage effects on the track
+ * cinelerra_track_clips_interface
+  manages clips (add/remove, order, ...)
+
+
+these 'tracks' use in turn other interfaces we define, effects, codecs, ...
+
+
+for effects plugins this is quite similar, we need at least a interface
+for the gui component and one for the internal workings.
+
+
+

+    

+      
* why should we constrain ourselfs to just C linkage? For example for
+  the effects plugins it's just natural to require each plugin to define
+  a GUI object as well and then proxy the communication (Cinelerra2
+  basically does the same, just does it create two instances of each
+  plugin class, one for the processing and one for the gui). Same for
+  exceptions: they wouldn't be used so commonly if they weren't 
+  helpfull ��. On the other hand: for a data storage plugin/interface
+  I don't see much use in using classes at all because this is
+  procedural by nature. (Thats the point where people start intventing
+  all those silly singleton classes...)

+    

+    
The Idea is here to make it possible to write plugins in any other
+language, C bindings are the best thing to make this possible. The
+downside is that glueing C++ is not effortless. I think it's still worth
+it, but this is just a proposal.
+
+

+    

+      
* the internal interfaces shouldn't be fixed this much, because this
+  hinders refacturing. Well, at least until we reach beta 0.98 ��

+    

+    
yes, my proposal only applies to 'external' interfaces. Unfortunally many
+interfaces are considered external by this plugin architecture (whatever
+we provide for us, we provide for people extenting it too)
+
+

+    

+      
+    

+  
+
+
+
+  
+    
+  
+  
+    

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

+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+    

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

+    

+      
+    

+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

+      Das macht diesen Vorschlag so »entwaffnend«:
+    

+    

+      
+    

+    

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

+    

+      
+    

+    

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

+    

+      
+    

+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

+    

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

+    

+      Im Rückblick deute ich das wie folgt
+    

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

+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+    

+      
+    

+    

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

+    

+      
+    

+    

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

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

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

+    

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

+    

+      
+    

+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+  
+    
+  
+  
+    

+      Sein Vorschlag
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+  
+    
+  
+  
+    

+      

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

+    

+    

+      

+        

+          ct
+        

+        

+          

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

+        

+      

+    

+  
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+    

+      
+    

+    

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

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

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

+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

+      ich kann mich jetzt wieder erinnern,
+    

+    

+      das als eine Niederlage empfunden zu haben.
+    

+    

+      Ich hab mich elend gefühlt.
+    

+  
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+    

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

+  
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+      ich kann jetzt den Zusammenhang gedanklich fassen
+    

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

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

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

+      allerdings nie irgend etwas zum DataBackend
+    

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

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

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

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

+    
    
+      
  • 
+        eine funktionale Skizze für eine Render-Engine zustande zu bekommen
+      
    • 
+      
  • 
+        beispielhaft einen neuen Coding- und Kollaborationsstil zu etablieren
+      
    • 
+      
  • 
+        dieses dann zu verwenden, um den Umbau von Cinelerra anzugehen
+      
    • 
+    

+  
+
+
+
+
+
+
+  
+    
+  
+  
+    
mark carter schrieb:

+    

+      
Maybe a lot of my problem is that I'm new to the code. Coming in from
+fresh on such a big project is bound to be daunting,....

+    

+    
well, but my personal experience was that, contrary to other projects,
+things get worse when you get accustomed. Trying to work with the
+current codebase is just plain frustrating, you find yourself
+fighting against windmills all the time.
+
+

+    

+      
Looking at the codebase, I realise that there's quite a lot of it, and
+think that a ground-up rewrite is likely to be doomed. I think that we
+must find a way of remoulding the existing code into a more stable form.

+    

+    
This indeed /is/ a big problem.
+At the moment I just choose to ignore it and picked me one region, namely
+the render engine / render pipeline and rewrite that one. Christian concentrates
+on some aspects of file handling media loading.

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+    

+      
+    

+    

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

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

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

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

+      Raffaella und Odin haben dieses Moment aufgegriffen —
+    

+    

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

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

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

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

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

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

+      ohne sie explizit breitzutreten!
+    

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

+  
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

+      man hat sich auf einen Weg gemacht,
+    

+    

+      auf den man sich vernünftigerweise
+    

+    

+      niemals gemacht hätte
+    

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

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

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

+      das Thema der Flexibilität
+    

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

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

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

+      Benny hatte schon vor Monaten gesagt,
+    

+    

+      ich möge ihn da einbeziehen
+    

+  
+
+
+  
+    
+  
+  
+    

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

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

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

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

+      danke Benny!
+    

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

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

+    
'spelling', ... but not 'format'. I'm not entirely sure; but it is not

+    
_generally_ used like this. But I am nearly certain you will find it

+    
as a special process in, for example, a group of Archeologists where

+    
transliterate has a special meaning only to this group.

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

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

+    
    ambiguous. Does 'properly' refer to the process of providing the

+    
    credit, i.e., it was only written on a piece of paper, .. i.e.,

+    
    'how' the credit was down; or is the creditation inappropriate?

+    
    

+    
    This kind of error is something similar to the many errors Trump

+    
    makes and upsets many jurnalists, as the ambiguity is often

+    
    critical and is much discussed on the BBC

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

+      also ist Benny's Vorschlag inhaltlich viel bessern
+    

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

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

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

+  
+
+
+  
+    
+  
+  
+    

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

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

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

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

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

+    

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

+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+  
+    
+  
+  
+    

+      ich kann nicht einschätzen,
+    

+    

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

+  
+
+
+  
+    
+  
+  
+    

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

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

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

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

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

+    
    

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

+    
    But please check

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

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

+      versuche die grammatikalische Verbesserung aufzunehmen,
+    

+    

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

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

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

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

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

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      und hat begonnen, dicke Bretter zu bohren:
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

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

+      die Darstellung könnte sich vor allem
+    

+    

+      auf die kollektiven Aspekte konzentrieren
+    

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

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

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      Lumiera ist entstanden durch meine Verstrickung in diesen Konflikt
+    

+  
+
+
+  
+    
+  
+  
+    

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

+  
+
+
+
+
+  
+    
+  
+  
+    

+      ich sehe jetzt in dieser Position eine Chance
+    

+  
+
+
+
+
+
+
 
 
 
@@ -161580,6 +165916,19 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
+
+
+  
+    
+  
+  
+    

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

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

+      das war nun eine
+    

+    

+      intensive Auseinandersetzung
+    

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

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

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

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

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

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

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

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

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

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

+    

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

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

+      war trotzdem ein Monster-Aufwand
+    

+  
+
+
+  
+    
+  
+  
+    

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

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

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

+  
+
+
+
+
+  
+    
+  
+  
+    

+      

+        

+          ⚠ Achtung: im Website-Repo
+        

+        

+          commit a32d3e0f7caf8d905e3203608c426953f85fd6e4
+        

+        

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

+        

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

+        

+          

+          
+        

+        

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

+        

+          
+        

+      

+    

+  
+
+
+
 
 
 

From 1c234d5a0beef10cf1f7558124a0f175c3a63f49 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Wed, 5 Nov 2025 02:55:45 +0100
Subject: [PATCH 29/51] 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.
+    
      
+  
+      
+      
+      
       
 
 

From 11efb6e9de183aba3c6a79e74b9601b12422f053 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Mon, 10 Nov 2025 02:55:02 +0100
Subject: [PATCH 30/51] Git-flow: Illustrations

Vectorgraphic drawings to show the Git-flow branching scheme
explained in the accompanying text
---
 doc/technical/code/GitBranching.txt |   5 +
 wiki/thinkPad.ichthyo.mm            | 252 +++++++++++++++++++++++++---
 2 files changed, 237 insertions(+), 20 deletions(-)

diff --git a/doc/technical/code/GitBranching.txt b/doc/technical/code/GitBranching.txt
index 731389679..9d565c33d 100644
--- a/doc/technical/code/GitBranching.txt
+++ b/doc/technical/code/GitBranching.txt
@@ -32,6 +32,11 @@ extended line into their _personal repository._ However, the _normative state_ o
 is represented by the link:https://git.lumiera.org/gitweb?p=LUMIERA[»Lumiera Repository«]
 `git://git.lumiera.org/LUMIERA`
 
+***************************************************
+image:{img}/pub/GitFlow-branches.svg[
+"Illustration Git-flow branching pattern"]
+***************************************************
+
 The Core Developer(s) can _push_ to this repository, thereby acting as _Gateway._ Automated builds
 will listen to this repository, and any further _downstream processes,_ like e.g. packaging,
 are always based on this state. What is described in the following sections however is a
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index aca8c2d90..7e35e2c21 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -165916,8 +165916,8 @@ that situation will improve in forseeable future.
 
 
 
-
-
+
+
 
 
 
@@ -165945,7 +165945,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -165962,7 +165962,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -165975,7 +165975,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -166158,8 +166158,60 @@ that situation will improve in forseeable future.
 
 
 
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Wobei allerdings (gemäß meinen Erfahrungen bei der Bank) die CI explizit so aufgesetzt werden muß, daß sie verschiedene »Linien« nicht vermischt. Es ist nicht möglich, die CI-Builds allein durch die Versionsnummer zu steuern. Vielmehr muß es eine dedizierte CI geben für
+    
      
+    
        
+      
      • 
+        Produktionsstand
+      
        • 
+      
      • 
+        Releases in Arbeit
+      
        • 
+      
      • 
+        Fixes in Arbeit
+      
        • 
+      
      • 
+        Integration
+      
        • 
+      
      • 
+        Feature-Development
+      
        • 
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      ...so daß die unqualifizierte Version auf dem Integration-Branch die geringste Prio hat (am ältesten sortiert), Features danach stehen, und mit Timestamp markierte explizite Snapshots die höchste Prio haben
+    
      
+  
+      
+
+
+
+
+
+
+
+
 
 
 
@@ -166181,6 +166233,7 @@ that situation will improve in forseeable future.
     
      
   
 
+
       
       
 
@@ -166205,8 +166258,8 @@ that situation will improve in forseeable future.
 
       
       
-
-
+
+
 
 
 
@@ -166711,15 +166764,108 @@ that situation will improve in forseeable future.
 
 
 
-
+
+
+
+
+  
+  
+    
      
+      Und zwar aus mehrerlei Gründen
+    
      
+    
        
+      
      • 
+        didaktisch: mein Text operiert auf einem abstrakteren Level als der Original-Text von Vincent Driessen; daher gehe ich auf viele Details nicht ein, arbeite aber die Grundstrukturen und Motivationen stärker heraus
+      
        • 
+      
      • 
+        Abweichungen in der Methode: ich setzte die Tags etwas woanders, und ich schlage vor, die back-Merges sets vom Tag aus zu machen
+      
        • 
+      
      • 
+        Darstellung: ich möchte den Zeitablauf von unten nach oben darstellen, so wie er auch in fast allen Git-UIs gezeigt wird
+      
        • 
+    
      
+  
+      
+
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      nach einigem Herumknobeln: es paßt neben den einleitenden Text, ab dem 2. Absatz ⟹ daraus ergibt sich eine Beschränkung der Zeichnungsgröße
+    
      
+  
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
-
+
 
   
   
@@ -166729,6 +166875,21 @@ that situation will improve in forseeable future.
   
 
 
+
+
+
+
+  
+  
+    
      
+      rein praktisch gesehen bringt das keinen Mehrwert;
+    
      
+    
      
+      wir hatten bisher nur »preview«-Releases, wlche nicht wirklich einen greifbaren Stand verkörpern. Zudem liegt das letzte solche Release jetzt (Räusper)  zehn Jahre zurück... wir würden also jetzt über 10 Jahre einen leeren Branch ziehen. Da erscheint es mir besser, das Schema jetzt neu aufzusetzen, mit Master von dem Punkt an dem Git-flow eingeführt wird
+    
      
+  
+      
+
       
       
 
@@ -166748,17 +166909,62 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
-
 
 
 
 
 
 
-
-
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
        
+      
      • 
+        project/news/DevReport-16-11.txt : by cutting a new ``preview release'' (Version `Lumiera-0.pre.03`), and, in the process, updating the packages...
+      
        • 
+      
      • 
+        project/news/old_news.txt : We published the next »preview release« `0.pre.03`
+      
        • 
+      
      • 
+        project/background/history/Resources.txt : Erwähnung in der Zeittafel
+      
        • 
+    
      
+  
+      
+
+      
+
+
+
+
+
+      
+
+
+
+
+
+
+  
+  
+    
      
+      Fazit: OK
+    
      
+  
+      
+      
+      
       
 
 
@@ -167064,12 +167270,18 @@ that situation will improve in forseeable future.
 
 
 
+
+
 
-
+
+
+
+
+
 
 
 
-
+
 
 
 
@@ -167129,7 +167341,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 

From 2ca07bfe6be0dc3f6dc88c51619f6bf6655a46ff Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sat, 8 Nov 2025 21:36:20 +0100
Subject: [PATCH 31/51] Bugfix-failed: attempt to fix XVideo widget drawing
 problems

Based on the additional insight gained through the FrOSCon talk,
an attempt was made to investigate and fix the garbled display of the
docking panel header directly above our VideoDisplayWidget.

However, that turned out to be a problem with insufficeint support
of the XVideo standard with my (very old, 2011) NVidia graphic card.
Indeed, the hardware+software stack needs to support this Auto-Keying
extension of XVideo, so that the video display can be integrated
seamlessly into the rest of the UI. In my case, the driver seemingly
just fills the complete XWindow with the key-marker and thus the
decorations of the docking panel, which happens to use the same XWindow,
will just not be flushed to the display.

This unsuccessful research indicates that upholding support for XVideo
could become problematic...
---
 src/stage/output/xv-displayer.cpp |  12 +
 wiki/thinkPad.ichthyo.mm          | 530 +++++++++++++++++++++++++++++-
 2 files changed, 528 insertions(+), 14 deletions(-)

diff --git a/src/stage/output/xv-displayer.cpp b/src/stage/output/xv-displayer.cpp
index 6d23bfaab..00e7a9b74 100644
--- a/src/stage/output/xv-displayer.cpp
+++ b/src/stage/output/xv-displayer.cpp
@@ -142,6 +142,18 @@ namespace output {
                         }
                     }
                 }
+               /* WARNING: some graphic cards (notably my very old NVidia card) do not properly support the XV-Keying feature.
+                *          The above loop is written in a »defensive« way, insofar it is not permitted to set/change X attributes
+                *          that are not provided and supported by your hardware and driver stack.
+                *          It may thus happen (and it happens on my System) that the X driver somehow applies a default keying
+                *          to the complete XWindow. However, if parts of that window are used by other UI elements (as is the case
+                *          with our docking-panels), then these other widgets become "garbled" and will not repaint properly.
+                *          It does not help to attempt to paint explicitly with low-level X functions into that problematic region,
+                *          and I could not figure out why such an attempted fix does not work, when we paint in the on_map()-Event.
+                *          We can paint just fine with the same low-level functions from within the put() call.
+                *
+                *          Anyhow, as such the XV display works correct even in such cases, but it looks "broken" :-(
+                */
             }
           
           if (gotPort)
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 7e35e2c21..e64b0ffe9 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -130337,10 +130337,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
-
+
 
 
-
+
 
 
 
@@ -130355,6 +130355,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
+
+
+
+
 
 
 
@@ -130390,7 +130394,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
-
+
 
 
 
@@ -130400,12 +130404,480 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      wenn man beispielsweise zwar einen XV_COLORKEY setzen kann, aber kein XV_AUTOPAINT_COLORKEY
+    
      
+  
+      
+      
+
+
+
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...dann kann ich das ganze Fenster füllen, durchaus auch mit beliebigen Farben (wobei hier eine Falle wartet, da die Farbtiefe unterschiedlich sein könnte).
+    
      
+  
+      
+
+
+  
+  
+    
      
+      dixplay_x11.c, line 623
+    
      
+    
      
+      
+    
      
+    
      
+      
      
+        
      
+          static inline void  xv_draw_colorkey(void) {
+        
      
+        
      
+          XSetForeground( xj_dpy, xj_gc,  0 );
+        
      
+        
      
+          if (xj_box[1] >  0 ) {
+        
      
+        
      
+          XFillRectangle( xj_dpy, xj_win,  xj_gc, 0, 0,  xj_box[2], xj_box[1]);
+        
      
+        
      
+          XFillRectangle( xj_dpy, xj_win,  xj_gc, 0, xj_box[1]+xj_box[3],  xj_box[2], xj_box[1]+xj_box[3]+xj_box[1]);
+        
      
+        
      
+          } /* else */
+        
      
+        
      
+          if (xj_box[0] >  0 ) {
+        
      
+        
      
+          XFillRectangle( xj_dpy, xj_win,  xj_gc, 0, 0,  xj_box[0], xj_box[3]);
+        
      
+        
      
+          XFillRectangle( xj_dpy, xj_win,  xj_gc, xj_box[0]+xj_box[2],  0, xj_box[0]+xj_box[2]+xj_box[0],  xj_box[3]);
+        
      
+        
      
+          }
+        
      
+        
      
+          }
+        
      
+        
      
+          
+        
      
+      
      
+    
      
+    
      
+      
+    
      
+    
      
+      ... verwende dann in XSetForeground ggfs eine andere Farbe, wie 0x00FF00 für Grün
+    
      
+  
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+          number of attributes: 7
+    
      
+    
      
+            "XV_SET_DEFAULTS" (range 0 to 0)
+    
      
+    
      
+                    client settable attribute
+    
      
+    
      
+            "XV_ITURBT_709" (range 0 to 1)
+    
      
+    
      
+                    client settable attribute
+    
      
+    
      
+                    client gettable attribute (current value is 0)
+    
      
+    
      
+            "XV_SYNC_TO_VBLANK" (range 0 to 1)
+    
      
+    
      
+                    client settable attribute
+    
      
+    
      
+                    client gettable attribute (current value is 1)
+    
      
+    
      
+            "XV_BRIGHTNESS" (range -1000 to 1000)
+    
      
+    
      
+                    client settable attribute
+    
      
+    
      
+                    client gettable attribute (current value is 0)
+    
      
+    
      
+            "XV_CONTRAST" (range -1000 to 1000)
+    
      
+    
      
+                    client settable attribute
+    
      
+    
      
+                    client gettable attribute (current value is 0)
+    
      
+    
      
+            "XV_SATURATION" (range -1000 to 1000)
+    
      
+    
      
+                    client settable attribute
+    
      
+    
      
+                    client gettable attribute (current value is 0)
+    
      
+    
      
+            "XV_HUE" (range -1000 to 1000)
+    
      
+    
      
+                    client settable attribute
+    
      
+    
      
+                    client gettable attribute (current value is 0)
+    
      
+    
      
+          maximum XvImage size: 16384 x 16384
+    
      
+    
      
+          Number of image formats: 4
+    
      
+    
      
+            id: 0x32595559 (YUY2)
+    
      
+    
      
+              guid: 59555932-0000-0010-8000-00aa00389b71
+    
      
+    
      
+              bits per pixel: 16
+    
      
+    
      
+              number of planes: 1
+    
      
+    
      
+              type: YUV (packed)
+    
      
+    
      
+            id: 0x32315659 (YV12)
+    
      
+    
      
+              guid: 59563132-0000-0010-8000-00aa00389b71
+    
      
+    
      
+              bits per pixel: 12
+    
      
+    
      
+              number of planes: 3
+    
      
+    
      
+              type: YUV (planar)
+    
      
+    
      
+            id: 0x59565955 (UYVY)
+    
      
+    
      
+              guid: 55595659-0000-0010-8000-00aa00389b71
+    
      
+    
      
+              bits per pixel: 16
+    
      
+    
      
+              number of planes: 1
+    
      
+    
      
+              type: YUV (packed)
+    
      
+    
      
+            id: 0x30323449 (I420)
+    
      
+    
      
+              guid: 49343230-0000-0010-8000-00aa00389b71
+    
      
+    
      
+              bits per pixel: 12
+    
      
+    
      
+              number of planes: 3
+    
      
+    
      
+              type: YUV (planar)
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      number of attributes: 5
+    
      
+    
      
+      "XV_COLORKEY" (range 0 to 16777215)
+    
      
+    
      
+      client settable attribute
+    
      
+    
      
+      client gettable attribute (current value is 2110)
+    
      
+    
      
+      "XV_BRIGHTNESS" (range -128 to 127)
+    
      
+    
      
+      client settable attribute
+    
      
+    
      
+      client gettable attribute (current value is 0)
+    
      
+    
      
+      "XV_CONTRAST" (range 0 to 255)
+    
      
+    
      
+      client settable attribute
+    
      
+    
      
+      client gettable attribute (current value is 128)
+    
      
+    
      
+      "XV_SATURATION" (range 0 to 255)
+    
      
+    
      
+      client settable attribute
+    
      
+    
      
+      client gettable attribute (current value is 128)
+    
      
+    
      
+      "XV_HUE" (range -180 to 180)
+    
      
+    
      
+      client settable attribute
+    
      
+    
      
+      client gettable attribute (current value is 0)
+    
      
+    
      
+      maximum XvImage size: 1024 x 1024
+    
      
+    
      
+      Number of image formats: 7
+    
      
+    
      
+      id: 0x32595559 (YUY2)
+    
      
+    
      
+      guid: 59555932-0000-0010-8000-00aa00389b71
+    
      
+    
      
+      bits per pixel: 16
+    
      
+    
      
+      number of planes: 1
+    
      
+    
      
+      type: YUV (packed)
+    
      
+    
      
+      id: 0x32315659 (YV12)
+    
      
+    
      
+      guid: 59563132-0000-0010-8000-00aa00389b71
+    
      
+    
      
+      bits per pixel: 12
+    
      
+    
      
+      number of planes: 3
+    
      
+    
      
+      type: YUV (planar)
+    
      
+    
      
+      id: 0x30323449 (I420)
+    
      
+    
      
+      guid: 49343230-0000-0010-8000-00aa00389b71
+    
      
+    
      
+      bits per pixel: 12
+    
      
+    
      
+      number of planes: 3
+    
      
+    
      
+      type: YUV (planar)
+    
      
+    
      
+      id: 0x36315652 (RV16)
+    
      
+    
      
+      guid: 52563135-0000-0000-0000-000000000000
+    
      
+    
      
+      bits per pixel: 16
+    
      
+    
      
+      number of planes: 1
+    
      
+    
      
+      type: RGB (packed)
+    
      
+    
      
+      depth: 0
+    
      
+    
      
+      red, green, blue masks: 0x1f, 0x3e0, 0x7c00
+    
      
+    
      
+      id: 0x35315652 (RV15)
+    
      
+    
      
+      guid: 52563136-0000-0000-0000-000000000000
+    
      
+    
      
+      bits per pixel: 16
+    
      
+    
      
+      number of planes: 1
+    
      
+    
      
+      type: RGB (packed)
+    
      
+    
      
+      depth: 0
+    
      
+    
      
+      red, green, blue masks: 0x1f, 0x7e0, 0xf800
+    
      
+    
      
+      id: 0x31313259 (Y211)
+    
      
+    
      
+      222
+    
      
+    
      
+      guid: 59323131-0000-0010-8000-00aa00389b71
+    
      
+    
      
+      bits per pixel: 6
+    
      
+    
      
+      number of planes: 3
+    
      
+    
      
+      type: YUV (packed)
+    
      
+    
      
+      id: 0x0
+    
      
+    
      
+      guid: 00000000-0000-0000-0000-000000000000
+    
      
+    
      
+      bits per pixel: 0
+    
      
+    
      
+      number of planes: 0
+    
      
+    
      
+      type: RGB (packed)
+    
      
+    
      
+      depth: 1
+    
      
+    
      
+      red, green, blue masks: 0x0, 0x0, 0x0
+    
      
+  
+      
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
 
 
 
-
+
+
+
 
 
+
+
+
+
+
+
 
 
 
@@ -130439,7 +130911,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
-
+
+
+
 
 
 
@@ -130451,7 +130925,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
-
+
 
 
 
@@ -130475,7 +130949,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
-
+
 
 
 
@@ -130653,8 +131127,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
-
-
+
+
 
 
 
@@ -130711,10 +131185,22 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
 
 
 
-
-
-
-
+
+
+
+
+
+
+  
+  
+    
      
+      Es ist ein sehr alter Standard, durchaus komplex und detailiertere Doku ist kaum noch zu finden (-> Einzelfragen auf Stackoverflow). Manpages sind, wie üblich, nur dann sinnvoll, wenn man schon weiß, worum es geht). Hinzu kommt, daß es wohl erhebliche Streubreite gibt bzgl. der Implementierung. »Beispielsweise« unterstützt meine uralt-Nvidia-Karte nicht das automatische Keying (Attribut XV_COLORKEY und XV_AUTOPAINT_COLORKEY sind nicht definiert, aber der X-Treiber macht ein Auto-Keying auf dem gesamten X-Window und das ist problematisch mit den Dockingpanels, die das gleiche XWindow verwenden)
+    
      
+  
+      
+
+
+      
       
       
       
@@ -161076,7 +161562,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -166915,6 +167401,22 @@ that situation will improve in forseeable future.
 
 
 
+
+
+  
+  
+    
      
+      Weil da nun die Kopfzeile (Docking-Panel) nicht richtig gezeichnet wird, bzw. pseudo-transparent wird.
+    
      
+    
      
+      Abbruch. Es zeigt sich, daß meine Grafikkarte das Auto-Keying von XV nicht unterstützt, d.h. die Attribute XV_AUTOPAINT_COLORKEY und XV_COLORKEY sind nicht definiert. Habe noch mind. 2 Stunden herumexperimentiert, bin aber auf keinen »grünen Zweig« gekommen. Diese Erfahrung läßt es für mich sehr fraglich erscheinen, ob wir XV unterstützen sollen....?
+    
      
+  
+      
+
+
+
+      
 
 
 

From a34b1f6ddd44c512ab647dd934c7e9959d95d358 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Thu, 13 Nov 2025 17:07:23 +0100
Subject: [PATCH 32/51] Bugfix: setVersion.py -- ability to handle suffixes

Turns out that in practice there will be (at least temporarily)
some version-tags including a suffix: the RC-versions!

Now there is the special twist, that Git does not allow '~' in Tag names,
and thus `git-buildpackage` introduced an additional layer of translation.
So we are forced to revert that translation, which is possible,
since the basic Debian version syntax disallows '_' in version numbers
(because '_' is used to separate the package name from the version number).

It seems prudent to implement that as an preprocessing step
and thus keep it out of the regular version number syntax.

Furthermore we need the ability to handle existing suffixes,
which (as we know now) can be picked up from the Git history.
 * my decision is to allow both pass-through and suppressing them
 * use `--suffix=False` to suppress / remove any existing suffix
 * the latter now allows us also to automate the setting of
   the final Release version
---
 admin/buildVersion.py    |  50 ++++++++++++++--
 wiki/thinkPad.ichthyo.mm | 121 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 162 insertions(+), 9 deletions(-)

diff --git a/admin/buildVersion.py b/admin/buildVersion.py
index cf1309cd5..690c289e3 100755
--- a/admin/buildVersion.py
+++ b/admin/buildVersion.py
@@ -47,7 +47,7 @@ def parseAndBuild():
                         ,choices=['maj','min','rev'], const='rev'
                         ,help='bump the version detected from Git (optionally bump a specific component)')
     parser.add_argument ('--suffix','-s'
-                        ,help='append (or replace) a suffix (by default attached with ~)')
+                        ,help='append (or replace) a suffix (attached with ~); False -> remove suffix')
     parser.add_argument ('--snapshot'
                         ,action='store_true'
                         ,help='mark as development snapshot by appending ~dev.YYYYMMDDhhmm, using UTC date from HEAD commit')
@@ -72,11 +72,30 @@ def getTimestampFromGit():
 
 
 
-def rebuild (version, bump=None, suffix=None, snapshot=False):
-    mat = re.fullmatch (VER_SYNTAX, version)
+def parseVerNr (verStr):
+    """ parse a version spec from a git tag,
+        possibly preprocess to translate _ -> ~
+    """
+    NOT_SFX = r'(?:[^_\W]|[\.\+])+'
+    DECODE  = r'('+NOT_SFX+')(?:_('+NOT_SFX+'))?'
+    #
+    mat = re.fullmatch (DECODE, verStr)
     if not mat:
-        __FAIL ('invalid version syntax in "'+version+'"')
+        __FAIL ('version string contains invalid characters: "'+verStr+'"')
+    verStr = mat.group(1)
+    if mat.group(2):
+        verStr += '~'+mat.group(2)
+    #
+    # check syntax of translated version spec
+    mat = re.fullmatch (VER_SYNTAX, verStr)
+    if not mat:
+        __FAIL ('invalid version syntax in "'+verStr+'"')
+    else:
+        return mat
     
+    
+def rebuild (version, bump=None, suffix=None, snapshot=False):
+    mat = parseVerNr (version)
     maj = mat.group(1)
     min = mat.group(2)
     rev = mat.group(3)
@@ -97,7 +116,10 @@ def rebuild (version, bump=None, suffix=None, snapshot=False):
     if snapshot:
         suf = 'dev.'+getTimestampFromGit()
     elif suffix:
-        suf = suffix
+        if not evalBool(suffix):
+            suf = None
+        else:
+            suf = suffix
     
     version = maj
     if min:
@@ -128,10 +150,26 @@ def runGit (argStr):
         proc = subprocess.run (argList, check=True, capture_output=True, encoding='utf-8', env={'LC_ALL':'C'})
         return proc.stdout.rstrip()                                                        # Note: sanitised env
     except:
-        __FAIL ('invoking git-describe')
+        __FAIL ('invoking git '+argStr)
 
 
 
+def evalBool (val) ->bool:
+    """ evaluate as bool value
+        @author: Tim Poulsen
+        @note: Adapted from the original, published 2023, CC-By-SA-4
+               https://www.timpoulsen.com/2023/python-bool-from-any.html
+    """
+    try:
+        return float(val) > 0
+    except:
+        if type(val) is str:
+            return val.lower() not in ['false', 'no', 'n', 'none', 'null']
+        else:
+            # rely on Python's type coercion rules
+            return bool(val)
+
+
 
 def __ERR (*args, **kwargs):
     print (*args, file=sys.stderr, **kwargs)
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index e64b0ffe9..b567c5944 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -166402,7 +166402,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -166697,7 +166697,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -166721,11 +166721,121 @@ that situation will improve in forseeable future.
 
 
 
+
+
+  
+  
+    
      
+      ...da in Git-Tags keine Tilde erlaubt ist, hat git-buildpackage hier eine Übersetzung in '_' eingeführt
+    
      
+  
+      
+
+
+
+
+
+
+  
+  
+    
      
+      ...denn dummerweise ist '_' ein word-constituent-char, d.h. die vorhergehenden Versions-Komponenten würden einen Trenner durch '_' einfach mit konsumieren
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Gemäß Debian-Policy ist das nämlich der Trenner zum Paketnamen, und darf daher in der nachfolgenden Versionsnummer nicht nochmal vorkommen (d.h. der letzte Underscore trennt den Namen von der versionsnr)
+    
      
+  
+      
+      
+      
+
+
+
+
+  
+  
+    
      
+      ist so möglich, da Underscore anderweitig nicht erlaubt ist (und Grenzfälle können hier unberücksichtigt bleiben, da letztlich in Lumiera nur sinnvolle und valide Versionsnummern vergeben werden dürfen; als zusätzilcher Filter dient das mandatory-prefix 'v*' im Tag
+    
      
+  
+      
+      
+
+
+
+
+
 
 
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Und zwar temporär, während man auf dem Release-Zweig ist, kann es ein RC-Tag geben. Wenngleich auch die (von mir intendierte) Git-flow policy verlangt, daß solche RC-Tags mit dem Release selber wieder gelöscht werden — man wird sie aber zulassen müssen, damit später mal eine CI korrekt mit Release-Candidates umgehen kann. Die Realität ist komplex. Seufz.
+    
      
+  
+      
+
+
+      
+
+
+  
+  
+    
      
+      Drei Varianten wären denkbar, diese hier erscheint mir am praktischten, und natürlichsten (und ist einfach umzusetzen, ohne den Parser komplexer zu machen
+    
      
+  
+      
+
+
+
+
+  
+  
+    
        
+      
      • 
+        man kann argparse.SUPPRESS verwenden
+      
        • 
+      
      • 
+        man nargs='?' setzen, und zudem einen Default angeben; damit ließe sich der Wert zur Option seinerseits optional machen...
+      
        • 
+    
      
+    
      
+      Dadruch würde aber der Aufruf komplexer, da nun der 'suffix' key möglicherweise nicht mehr im resultierenden dictionary nach Parser-Auswertung enthalten wäre.
+    
      
+  
+      
+      
+      
+      
+      
       
 
 
@@ -178045,7 +178155,12 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
+
+
+
+
 
 
 

From aac9ee2934046f3d7de90efab7897a469a0fb5e9 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sat, 15 Nov 2025 02:00:11 +0100
Subject: [PATCH 33/51] Bugfix: uninitialised stack-memory used in test
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

...this bug was spotted as the test failed reproducibly
when built with `-fstack-protector-strong` — which adds
additional "canary" markers to some kinds of problematic
stack storage; this seemed to have the effect that now
the second test uses exactly the same location as the
preceding test, and thus finds valid data in the newly
created work buffers.

There is no reason for using uninitialised storage in this
test (I can recall that I wanted to build a generic helper
and intended to use that as ''virtual overlay'' over existing
memory — but that usage never took place, and the `struct Buffer`
is not a general-purpose tool now, but only made for this
specific test. Thus memory can be easily zero-initialised.
---
 tests/core/steam/engine/node-devel-test.cpp |   4 +-
 wiki/thinkPad.ichthyo.mm                    | 258 +++++++++++++++++++-
 2 files changed, 251 insertions(+), 11 deletions(-)

diff --git a/tests/core/steam/engine/node-devel-test.cpp b/tests/core/steam/engine/node-devel-test.cpp
index a76752afb..3c20eeeac 100644
--- a/tests/core/steam/engine/node-devel-test.cpp
+++ b/tests/core/steam/engine/node-devel-test.cpp
@@ -26,9 +26,11 @@
 #include "lib/random.hpp"
 
 #include 
+#include 
 
 using lib::zip;
 using lib::izip;
+using std::array;
 using std::vector;
 using std::make_tuple;
 using lib::test::showType;
@@ -45,7 +47,7 @@ namespace test  {
       : util::NonCopyable
       {
         alignas(TestFrame)
-          std::byte storage[sizeof(TestFrame)];
+          array storage{}; //zero-init
         
         operator TestFrame*  () { return   std::launder (reinterpret_cast (&storage)); }
         TestFrame* operator->() { return   std::launder (reinterpret_cast (&storage)); }
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index b567c5944..771cdcc08 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -166384,8 +166384,12 @@ that situation will improve in forseeable future.
 
 
 
-
+
+
 
+
+
+
 
 
 
@@ -166447,6 +166451,19 @@ that situation will improve in forseeable future.
 
 
 
+
+
+  
+  
+    
      
+      DEB-Paket: direkt <v%(version)s>-Tag von master verwenden
+    
      
+  
+      
+
+
+
+      
       
 
 
@@ -169268,6 +169285,9 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
 
       
 
@@ -169792,6 +169812,7 @@ actively maintained upstream. Please remove gdl from Debian.
     
      
   
 
+
 
 
 
@@ -169951,7 +169972,7 @@ actively maintained upstream. Please remove gdl from Debian.
 
 
 
-
+
 
 
 
@@ -178388,6 +178409,10 @@ Since then others have made contributions, see the log for the history.      
       
       
+
+
+
+
       
 
 
@@ -178512,6 +178537,7 @@ Since then others have made contributions, see the log for the history.
 
 
+
 
 
 
@@ -178951,13 +178977,14 @@ Since then others have made contributions, see the log for the history.      
   
 
-
+
 
 
       
       
       
-
+
+
 
 
 
@@ -178965,7 +178992,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -179124,7 +179151,7 @@ Since then others have made contributions, see the log for the history.      
       
       
-
+
 
   
   
@@ -179494,7 +179521,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -179532,7 +179559,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -179728,6 +179755,7 @@ Since then others have made contributions, see the log for the history.
 
 
+
 
 
 
@@ -179933,6 +179961,7 @@ Since then others have made contributions, see the log for the history.
 
 
+
 
 
 
@@ -180049,7 +180078,7 @@ Since then others have made contributions, see the log for the history.
 
       
-
+
 
 
 
@@ -180162,6 +180191,7 @@ Since then others have made contributions, see the log for the history.      
 
 
+
 
 
 
@@ -180271,8 +180301,216 @@ Since then others have made contributions, see the log for the history.
       
       
-
+
+
 
+
+
+
+
+  
+  
+    
      
+      Zehn Jahre Reise ins Ungewisse....
+    
      
+    
        
+      
      • 
+        jetzt auf Debian/Trixie angekommen und C++23
+      
        • 
+      
      • 
+        mitten im »Playback Vertical Slice«
+      
        • 
+    
      
+  
+      
+
+      
+
+
+
+
+
+  
+  
+    
        
+      
      • 
+        master fungiert direkt als upstream-Branch
+      
        • 
+      
      • 
+        das Versionsschema angepaßt: upstream-tag = v%(version)s
+      
        • 
+    
      
+  
+      
+
+
+
+      
+
+
+
+
+
+
+
+
+
+
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
        
+      
      • 
+        git clone in ein Unterverzeichnis vom Paketverzeichnis
+      
        • 
+      
      • 
+        Paketverzeichnis in den Container gemounted
        
+
+        
        podman run -v /Werk/Gang/pack:/pack -it ichthyo/pack-debian-trixie-20250317
        
+      
        • 
+      
      • 
+        im Container....
+      
        • 
+      
          
+        
        • 
+          (ggfs dort equivs installieren)
+        
          • 
+        
        • 
+          cd /pack
+        
          • 
+        
        • 
+          mk-build-dep --install --remove
+        
          • 
+        
        • 
+          gbp buildpackage --git-tag
+        
          • 
+      
        
+    
      
+  
+      
+
+
+
+  
+  
+    
      
+      Vorbereitung:
+    
      
+    
      
+      ./build-pack-dock debian:trixie-2025####
+    
      
+  
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 

From 75ffb060c775ba953e8c1e1162e3ce6d3e3b1e81 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sun, 16 Nov 2025 01:55:28 +0100
Subject: [PATCH 34/51] Bugfix: Buildsystem --  no need to check for installdir

The option handling did check if the installdir exists;
this is problematic since it is often created later,
automatically from the installation...
---
 admin/scons/Options.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/admin/scons/Options.py b/admin/scons/Options.py
index 842fea5ba..5c28ca462 100644
--- a/admin/scons/Options.py
+++ b/admin/scons/Options.py
@@ -42,7 +42,7 @@ def defineCmdlineVariables(buildVars):
 #       ,EnumVariable('DIST_TARGET', 'Build target architecture', 'auto',
 #                   allowed_values=('auto', 'i386', 'i686', 'x86_64' ), ignorecase=2)
         ,PathVariable('PREFIX', 'Installation dir prefix', 'usr/local', PathVariable.PathAccept)
-        ,PathVariable('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathIsDir)
+        ,PathVariable('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathAccept)
         ,PathVariable('PKGLIBDIR', 'Installation dir for plugins, defaults to PREFIX/lib/lumiera/modules', '',PathVariable.PathAccept)
         ,PathVariable('PKGDATADIR', 'Installation dir for default config, usually PREFIX/share/lumiera', '',PathVariable.PathAccept)
      )

From 741b8fe5731a1b623d8eae26c7223345701d5dda Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sat, 15 Nov 2025 19:08:23 +0100
Subject: [PATCH 35/51] Build: document and disentangle dependencies
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A long-standing unnecessary mutual dependency caused rebuild
of most tests in the standard target, because the ''valgrind suppression''
executable was classified as »tool«, while also depending on the libraies
with the test code.
---
 admin/scons/Setup.py | 2 ++
 tests/SConscript     | 3 +--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py
index c2c19cca7..b7074f109 100644
--- a/admin/scons/Setup.py
+++ b/admin/scons/Setup.py
@@ -42,7 +42,9 @@ installUIRes = '#$DESTDIR/share/lumiera/'
 installConf  = '#$DESTDIR/lib/lumiera/config'
 
 #-------------------------------------------------------Configuration
+
 buildSetup = Record(locals())
+#  passed to LumieraEnvironment() -> env.path.xxxx
 
 
 
diff --git a/tests/SConscript b/tests/SConscript
index dcf294006..4fb38d9e7 100644
--- a/tests/SConscript
+++ b/tests/SConscript
@@ -97,7 +97,6 @@ Export('testsuite')
 
 # for creating a Valgrind-Suppression file
 vgsuppression = envSuite.Program('vgsuppression',['tool/vgsuppression.c']+list(testLibs)+list(core_lib))   ## for suppressing false valgrind alarms
-tools  += [vgsuppression]
 
 
 #
@@ -144,7 +143,7 @@ Depends(runTests,vgsuppression)
 #  - 'scons testcode' triggers building of the Testsuite
 #  - 'scons check' triggers building and running
 #
-env.Alias('testcode', testsuite )
+env.Alias('testcode', testsuite + vgsuppression)
 env.Alias('check',    runTests )
 
 # allow tempfiles of test.sh to be cleaned  

From c8196ce23411c369656a394e9d93a978cd5b9028 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sun, 16 Nov 2025 02:09:24 +0100
Subject: [PATCH 36/51] Build: configuring via environment is bad practice

Yes, I know...
Programmers absolutely LOVE to sneak-in various nifty toggles via environment.

Yet this is an anti-pattern!
And, by extension of that verdict, a "build interface" which relies
on the implicit convention that some magical variables are set,
is **not a proper interface** but a hack.

Thus we abandon that bad practice and handle the build in a clean and explicit way.

 * the DEB-Build in `debian/rules` now invokes SCons explicitly, passing arguments
 * the Lumiera Build-System is FSH aware and knows the proper installation locations
 * the setup of the application uses a setup configuration, shipped with the package
 * there is no need to ''compile-in any configuration''
   ** `LUMIERA_PLUGIN_PATH` is obsolete and unused since several years now
   ** `LUMIERA_CONFIG_PATH` was never used at all
   ** consequently, we also do not need `PKGLIBDIR` and `PKGDATADIR`
---
 admin/scons/Options.py   |    2 -
 admin/scons/Setup.py     |    6 +-
 wiki/thinkPad.ichthyo.mm | 1499 +++++++++++++++++++++++++++++++++++++-
 3 files changed, 1471 insertions(+), 36 deletions(-)

diff --git a/admin/scons/Options.py b/admin/scons/Options.py
index 5c28ca462..d79acf254 100644
--- a/admin/scons/Options.py
+++ b/admin/scons/Options.py
@@ -43,8 +43,6 @@ def defineCmdlineVariables(buildVars):
 #                   allowed_values=('auto', 'i386', 'i686', 'x86_64' ), ignorecase=2)
         ,PathVariable('PREFIX', 'Installation dir prefix', 'usr/local', PathVariable.PathAccept)
         ,PathVariable('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathAccept)
-        ,PathVariable('PKGLIBDIR', 'Installation dir for plugins, defaults to PREFIX/lib/lumiera/modules', '',PathVariable.PathAccept)
-        ,PathVariable('PKGDATADIR', 'Installation dir for default config, usually PREFIX/share/lumiera', '',PathVariable.PathAccept)
      )
 
 
diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py
index b7074f109..84ef3fd71 100644
--- a/admin/scons/Setup.py
+++ b/admin/scons/Setup.py
@@ -82,11 +82,7 @@ def defineBuildEnvironment():
     appendVal(env,'OPTIMIZE', 'CCFLAGS',   val=' -O3')
     appendVal(env,'DEBUG',    'CCFLAGS',   val=' -ggdb')
     
-    # setup search path for Lumiera plugins
-    appendCppDefine(env,'PKGLIBDIR','LUMIERA_PLUGIN_PATH=\\"$PKGLIBDIR/:ORIGIN/modules\\"'
-                                   ,'LUMIERA_PLUGIN_PATH=\\"ORIGIN/modules\\"')
-    appendCppDefine(env,'PKGDATADIR','LUMIERA_CONFIG_PATH=\\"$PKGLIBDIR/:.\\"'
-                                    ,'LUMIERA_CONFIG_PATH=\\"$DESTDIR/share/lumiera/:.\\"')
+    # NOTE: could define optional copile features here....
     
     Options.prepareOptionsHelp(buildVars,env)
     buildVars.Save(OPTCACHE, env)
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 771cdcc08..a63370e0a 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -152106,7 +152106,7 @@ std::cout << tmpl.render({"what", "World"}) << s
 
 
 
-
+
 
 
 
@@ -161311,7 +161311,35 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
+
+
+  
+  
+    
      
+      Das war eine Richtlinien-Entscheidung, nachdem wir den Vortrag »Video-Output« auf der FrOSCon gehalten haben.
+    
      
+    
      
+      Dazu gibt es mehrere Gründe
+    
      
+    
        
+      
      • 
+        wir sind massiv zurückgefallen und haben noch sehr viel zu tun für eine minimal funktionsfähige Applikation
+      
        • 
+      
      • 
+        das Thema »Shader-Programmierung« ist ein dicker Brocken, und erfordert zusätzliche Infrastruktur; ja das wird relevant
+      
        • 
+      
      • 
+        Wayland ist »um die Ecke« (und dann müssen wir sowiso nochmal 'ran)
+      
        • 
+    
      
+  
+      
+
+
+
+      
+      
 
 
       
@@ -161500,7 +161528,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
       
 
-
+
 
 
 
@@ -166365,6 +166393,135 @@ that situation will improve in forseeable future.
 
       
       
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...der Grund liegt in der Pflicht zur Bereitstellung der "Quellen". Das zwingt im Zusammenhang mit allgemeinen Inhalten wie Text, Bild und Video zur Auslegung, und dadurch wird die Situation rechtlich zweideutig. Theoretisch wäre das kein Problem, aber praktisch kann es ein Hindernis darstellen für jemanden, der lediglich gestalterischen Content  weiterverwenden und umgestalten möchte, also in unserem Fall Texte und Bilder. Daher bieten wir eine Wahlmögichkeite der Creatvice-Commons-By-SA, denn diese verpflichtet nicht zur Bereitstellung eines Quelltextes.
+    
      
+  
+      
+      
+
+
+
+
+  
+  
+    
      
+      Einschätzung: ja
+    
      
+  
+      
+
+
+      
+
+
+  
+  
+    
      
+      ABER: das verpflichtet UNS, die CC-By-SA einzuhalten
+    
      
+  
+      
+
+  
+  
+    
      
+      Und zwar deshalb, weil es nur einen kompatiblen Pfad gibt von CC-By-SA ⟶ GPL-3.
+    
      
+    
      
+      Deshalb müssen wir die Vereinigungsmenge der Forderungen beider Lizenzen erfüllen, was aber möglich ist....
+    
      
+  
+      
+
+
+  
+  
+    
      
+      ...hier müssen wir aufpassen. Da die CC-By-SA nicht auf Quellcode abstellt, muß die Attributierungs-Information jeweils auch textuell nahe bei dem jeweiligen Content aufgeführt sein.
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      ...das tun wir, unser Git-Repo ist öffentlich und die veröffentlichten Webseiten werden aus Asciidoc generiert. Für Bilder halten wir die bestmögliche Auflösung bereit, bzw. verwenden SVG, wo möglich
+    
      
+  
+      
+      
+      
+
+
+
+
+  
+  
+    
      
+      das heißt, mal eben den Spell-Checker laufen lassen, oder den Markup reparieren ist noch kein Beitrag, der eine Autorenschaft konstituiert.
+    
      
+  
+      
+      
+
+
+
+  
+  
+    
      
+      ABER: jeder relevante Autor eines Textes / Bildes muß im Text selber aufgeführt sein
+    
      
+  
+      
+
+      
+
+
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
       
       
       
@@ -168428,6 +168585,11 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
+
+
 
 
 
@@ -169289,6 +169451,50 @@ that situation will improve in forseeable future.
 
 
       
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Denn ich mußte mir das heute schon wieder zusammensuchen...
+    
      
+    
        
+      
      • 
+        die SCons-Kommando-Argumente werden im Konstruktor des Environment-Objekts geparst
+      
        • 
+      
      • 
+        die erwartete Argument-Definition kommt dorthin im Keyword-Argument 'variables'
+      
        • 
+      
      • 
+        wir definieren sie in unserem Options-Objekt
+      
        • 
+      
      • 
+        weitere key=value-Bindings können als zusätzliche KW-Args mitgegeben werden
+      
        • 
+      
      • 
+        im Besonderen diejenigen, die aus 'optcache' geladen wurden
+      
        • 
+      
      • 
+        alle diese Variablen (incl. der von der Kommandozeile) werden 'build variables'
+      
        • 
+      
      • 
+        diese können per env.subst(string) interpoliert werden
+      
        • 
+      
      • 
+        bei eingebauten Kommando-Aufrufen macht das SCons automatisch
+      
        • 
+    
      
+  
+      
+
+      
+      
       
 
 
@@ -170891,6 +171097,305 @@ Since then others have made contributions, see the log for the history.      
       
       
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Beschluß: wir gehen auf 3.10
+    
      
+  
+      
+
+
+      
+      
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Was war denn überhaupt der Sinn der vgsuppression? Welche Aufrufe sollten damit ausgenommen werden? warum brauchen die die Tests???
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Die »klassischen Hacker« waren seinerzeit unbedingt davon überzeugt, daß wir viel mit Valgrind arbeiten müssen, weil wir ja sonst Probleme mit Memory-Leaks „nie in den Griff bekommen“. Ich dagegen wollte immer ein deterministisches Memory-Management, und hab mich mit diesem Ansatz durchgeführt. Erste Versuche mit Valgrind waren nicht sonderlich hilfreich. Vor allem wegen Dingen wie dem "MPool", der nicht deterministisch ist. Ebenso hat Christian irgendwann einmal einen "Leak-Checker" geschrieben, und wollte den eingebunden haben. Dann kam heraus, daß sein C-Code leakt, aber der C++-Code nicht, weil die smart-Pointer per Konstruktion »wasserdicht« sind. Daraufhin hat Christian schlagartig das Interesse an dem Thema verloren. Und sich auch nie um eine brauchbare Konfiguration der vgsuppression gekümmert. Ich hatte darauf auch keinen Bock, denn das ist eine endlose Knobelei, und wozu? Ich weiß ja daß die smart-pointer nicht leaken.
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      searchpath.cpp :  replaceMagicLinkerTokens()
+    
      
+  
+      
+
+      
+
+
+  
+  
+    
      
+      SCons würde nämlich diese $ORIGIN ebenfalls versuchen, zu expandieren
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...dies dient dazu, Defaults aus dem 'optcache' zu laden
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...hab heute schon wieder ganzschön lang gebraucht, um mir das zusammenzupuzzeln (und ich kenne SCons und unser Buildsystem)
+    
      
+  
+      
+
+      
+      
+
+
+
+
+
+      
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Hauptsache, man hat irgendwas total trickreich eingefädelt, so daß man sich später von der linken Tasche in die rechte Tasche spielen kann
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      und exakt so machen wir es bereits
+    
      
+  
+      
+
+      
+
+
+
+  
+  
+    
      
+      das Config-System ist nur noch pro forma da
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      lumiera_get_plugin_path_default()
+    
      
+  
+      
+      
+      
+      
+      
+      
+
+
+
+
+      
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Nein! denn unser Buildsystem ist nicht Autotools oder CMake
+    
      
+  
+      
+
+      
+
+
+
+
+
+  
+  
+    
      
+      das beruht aber auf einer Mystifikation
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+      
+
+
+  
+  
+    
      
+      ...weil es dadurch zusätzliche Seiteneffekt-Abhängigeiten gibt, die man dem System nicht »ansieht«
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      ...das dann auch die üblichen Overlay-Ebenen hat (Paket, System, User)
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Für den normalen Build ist das irrelevant; erst wenn wir das Install-Target aufrufen, passiert da etwas. Und dann sollte das auf Betriebssystem-Ebene geregelt sein (und das erfordert i.d.R. auch Root-Rechte)
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Das ist so eine ganz typische Paketbau-Funktionalität: prüfen ob das Zielverzeichnis existiert, richtige Rechte hat und leer ist — oder eben einige dieser Kriterien grade nicht prüftn
+    
      
+  
+      
+      
+      
+
+
+
+
       
       
 
@@ -177084,47 +177589,49 @@ Since then others have made contributions, see the log for the history.
 
       
-
+
 
   
   
     
      
-      wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird.
+      wähle Kompatibiltät genau so, daß Ubuntu-Noble noch unterstützt wird, ansonsten den Level für »Trixie«
     
      
   
       
 
-
+
+
+
+
 
 
-
-
-
-
-
-
 
 
-
-
+
+
+
+
+
+
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...das war ein Beschluß auf dem Entwickler-Meeting im September: auch wenn wir (Benny+ich) jetzt viel Know-How aufgesammelt haben, verschieben wir das Thema »Shader-Programmierung« dann doch noch in die Zukunft, weil es nicht strikt notwendig ist, um die einfachste Form von Playback zu bekommen. Demnach könnten wir sogar mit dem bestehenden XVideo-Code weitermachen (oder eben Legacy GL nehmen, sofern noch Motivation dafür da ist)
+    
      
+  
+      
       
       
-
+
+
 
 
 
@@ -177255,6 +177762,74 @@ Since then others have made contributions, see the log for the history.      
       
       
+
+
+
+
+
+
+  
+  
+    
      
+      ...heißt nämlich, daß man Lumiera derzeit nicht nach /usr/local/ installieren könnte!
+    
      
+    
      
+      Das wenn ein »richtiger« Unix-Hacker mitbekommt, dann haben wir uns ziemlich lächerlich gemacht: „mit Autotools wär das nicht passiert...“
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Ich würde nie auf die Idee kommen, etwas anders ins System zu installieren, als via DEB-Paket. Und für das Debian-Paketieren brauchen wir ja einen Pfad relativ zum Build-Root (nämlich im debian/lumiera -  Unterverzeichnis, denn dort wird der Content für das neue DEB-Paket nach dem Build zusammengestellt....)
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+  
+  
+    
      
+      wie viele Build-Systeme beruht auch der SCons-Build darauf, rekursiv definierte Sub-Builds aus Unterverzeichnissen zu aggregieren. Das bedeutet, daß für den eigentlichen Bauvorgang jeweils in das Unterverzeichnis gewechselt wird. Das ist aber problematisch für Aktionen im Build-Tree, und deshalb bietet SCons diese spezielle Konvention mit dem '#'-Präfix, das den Pfad dann relativ zum Build-Root verankert
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Nov.2025 beim Erweitern/Debuggen entdeckt: da stößt das Setup mit der Hilfsfunktion getDirname() an ihre Grenzen. Gilt vermutlich auch für den ConfigData()-Builder. So belassen. Also: besser immer ein Präfix angeben, es ist ja auch kein optionales Argument
+    
      
+  
+      
+
+
+      
+      
       
 
 
@@ -179490,11 +180065,877 @@ Since then others have made contributions, see the log for the history.      
       
       
+
+
+
+  
+  
+    
        
+      
      • 
+        master fungiert direkt als upstream-Branch
+      
        • 
+      
      • 
+        das Versionsschema angepaßt: upstream-tag = v%(version)s
+      
        • 
+    
      
+  
+      
+
+
+
+      
+
+
+  
+  
+    
      
+      wird veröffentlicht in einem separaten Git-Repo debian/lumiera, ist aber auch in meinem 'ichthyo'-Repository
+    
      
+  
+      
+      
+
+
+
+
+
+  
+  
+    
      
+      die stammt eigentlich aus der Lumiera-Webiste und wurde umgeschrieben in ein eigenständiges HTML.... unbedingt per Diff/Merge  aktualisieren vom Website-Content!
+    
      
+  
+
+      
+
+
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Dort bin ich bereits vor ½ Jahr durch die ganze Serie von Neuerungen im Debian-Standard gegangen und habe viele Detail-Fragen geklärt
+    
      
+  
+      
+      
+
+
+
+
+  
+  
+    
      
+      Soll die Dokumentationsgenerierung überspringen, aber ein leeres Doumentations-Paket bauen
+    
      
+  
+      
+
+      
+      
+
+
+
+
+  
+  
+    
      
+      ...und wenn das problematisch wird, sollte das DEB-Packaging die DEB_BUILD_OPTIONS "terse" unterstützen
+    
      
+  
+      
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      war letztlich eine Sackgasse,
+    
      
+    
      
+      hat aber wichtige Umstände geklärt
+    
      
+  
+
+      
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Speziell GLib ist bekanntermaßen buggy, wenngliech auch sich das in den letzten Jahren verbessert hat. Aber die Leute ändern und modernisieren auch ständig ... also gibt es nicht wirklich einen »Kompatibilitäts-Level«
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      deshalb ist es ja »Referenz-Platform«, was auch bedeutet, wir orientieren uns nach Vorne, und die Referenz-Platform ist eigentlich der Mindest-Level (mit ein klein wenig Wasser unter dem Kiel, wegen Ubuntu)
+    
      
+  
+      
+
+
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...nur mit dem Unterschied, daß wir hier nun die Aufrufe direkt im debian/rules stehen haben; im Grunde hat uns die "magic" gar nicht viel gebracht, nachdem man sich erst mal damit beschäftigt hat.
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      override_dh_auto_clean: (hier zusätzlich optcache und configure-cache weglöschen)
+    
      
+    
      
+      override_dh_auto_build
+    
      
+    
      
+      override_dh_auto_test
+    
      
+    
      
+      override_dh_auto_install
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      DEB_SCONS_OPTIONS = \ 
+    
      
+    
      
+      BUILDLEVEL=ALPHA \ 
+    
      
+    
      
+      DEBUG=True       \ 
+    
      
+    
      
+      OPTIMIZE=False   \ 
+    
      
+    
      
+      VALGRIND=False   \ 
+    
      
+    
      
+      ARCHFLAGS=" -fstack-protector-strong"
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      SCons verwendet eine MD5-Summe über den Quellcode und außerdem  auch über alle Compiler-Schalter und Environment-Settings
+    
      
+  
+
+      
+
+      
+
+
+  
+  
+    
      
+      sollte daher alle drei Targets mit den gleichen Settings aufrufen
+    
      
+  
+      
+
+      
+
+
+  
+  
+    
      
+      Folgeproblem: *** Directory path for variable 'INSTALLDIR' does not exist: debian/lumiera
+    
      
+  
+
+      
+
+
+
+
+
+
+  
+  
+    
      
+      prüft und Syntax, aber nicht ob das Filesystem-Element existiert
+    
      
+  
+
+      
+
+
+      
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      NodeDevel_test : hier werden Checksummen über Datenblöcke gebildet und eine dafür präparierte Render-Pipeline geschickt.
+    
      
+    
      
+      Dieser Test enthält keine concurrency — also deutet ein (nicht reproduzierbarer) Fehler hier auf ein Hardware-Problem hin (den Verdacht hab ich schon länger)
+    
      
+  
+      
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Unterschied: -fstack-protector-strong
+    
      
+  
+      
+
+
+
+
+
+  
+  
+    
      
+      
      
+        
      
+          Buffer clone[50];
+        
      
+        
      
+          for (uint i=0;  i<channels; ++i)
+        
      
+        
      
+          CHECK (not clone[i]->isSane());
+        
      
+        
      
+          
+        
      
+      
      
+    
      
+  
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ist Sane() prüft nur header_.isPlausible() ⟹ das prüft ob ein das Marker-Wort im Header liegt — was durchaus der Fall sein kann, wenn exakt an der gleichen Stelle vorher schon mal ein Buffer-Header lag....
+    
      
+  
+      
+      
+
+
+
+  
+  
+    
      
+      ...vermutlich mit dem temporären TestFrame, der beim vorhergehenden Test während der Verifikation erzeugt wird. Dieser dürfte ja in den Bereich fallen, der in dieser Methode vom zweiten Array abgedeckt wird
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      alle Verwendungen (nur in diesem Test) brauchen einen sauberen Buffer
+    
      
+  
+      
+
+  
+  
+    
      
+      Dieses Konstrukt wird (augenscheinlich, habe dies stichprobenhaft geprüft) nur in diesem einen Test verwendet. Es werden jeweils ein/mehrere Buffer auf den Stack gelegt. In den meisten Fällen wir dann in diesen Buffer etwas generiert. In einigen Testfällen wird vorher geprüft, daß der Buffer keinen validen Testframe enthält, und nachher, daß dies der Fall ist. Die Prüfung vorher scheitert im vorliegenden Problemfall, vermutlich weil im Stack-Speicher exakt an der gleichen Stelle vorher das gleiche Verarbeitungsmuster stattfand
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      TestFrame selber generiert in seinem Konstruktor stets eine valide Buffer-Füllung und belegt alle Metadaten. Möglicherweise hatte ich die Idee, den »Buffer« über beliebige Storage legen zu können, um sie dann zu begutachten. Diese Verwendung fand dann aber nicht statt
+    
      
+  
+      
+      
+      
+
+
+
+
+
+  
+  
+    
      
+      das erspart mir das Gewürge, da std::byte kein numerischer Datentyp ist
+    
      
+  
+      
+      
+      
+      
+      
+
+
+
+
+
+  
+  
+    
      
+      hab gesehen daß der Speicher jetzt mit NULL gefüllt wird
+    
      
+  
+
+      
+      
+
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Seltsam....
+    
      
+    
      
+      Ich sehe keinerlei generische Platzhalter in meinem File...  Allerdings werde ich das demnächst ohnehin umstellen auf das maschinenlesbare Format
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+  
+  
+    
      
+      g++ -o target/modules/libtest-vault.so -Wl,--no-undefined -Wl,--as-needed -Wl,-soname=libtest-vault.so -Wl,-rpath=\$ORIGIN/../modules,--enable-new-dtags -shared tests/vault/mem/extent-family-test.os tests/vault/gear/activity-detector-test.os tests/vault/gear/scheduler-usage-test.os tests/vault/gear/test-chain-load-test.os tests/vault/gear/scheduler-commutator-test.os tests/vault/gear/scheduler-activity-test.os tests/vault/gear/scheduler-invocation-test.os tests/vault/gear/work-force-test.os tests/vault/gear/block-flow-test.os tests/vault/gear/scheduler-stress-test.os tests/vault/gear/scheduler-service-test.os tests/vault/gear/scheduler-load-control-test.os tests/vault/gear/special-job-fun-test.os -lm -ldl -lpthread -lrt -lnobugmt -lstdc++fs -lboost_program_options -lgavl target/modules/liblumieravault.so target/modules/liblumieracommon.so target/modules/liblumierasupport.so
+    
      
+  
+
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Da wir ja ein durchaus spezielles Versionsnummernschema haben. Die Fehlermeldung sieht so aus, als würde das als ein RC für eine Version v0 gedeutet
+    
      
+  
+      
+
+      
+
+
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Für die Installation per DEB-Paket brauchen wir kein allgemeines README, da vor allem die Bau- und Installations-Vorrausetzungen bereits erfüllt sind, und auch die Lizenz anderweitig deklariert wird. Daher sollte hier im README.debian alles für den reinen User Wissenswerte stehen
+    
      
+  
+      
+      
+
+
+  
+  
+    
        
+      
      • 
+        auf die NEWS
+      
        • 
+      
      • 
+        Auf die Website
+      
        • 
+      
      • 
+        (geplant: User-Manual)
+      
        • 
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      /documentation/user/manual.html
+    
      
+  
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      das war eine Scheiß-Arbeit...
+    
      
+    
        
+      
      • 
+        das Savepage-Plugin schreibt das DOM komplett neu
+      
        • 
+      
      • 
+        es fügt <tbody>-Elemente ein
+      
        • 
+      
      • 
+        es löst HTML-Entities auf (was ich definitiv nicht will, obschon es wegen UTF-8 eigentlich möglich wäre)
+      
        • 
+      
      • 
+        es fügt hinter jedem schließenden Tag noch whitespace ein (Windows???)
+      
        • 
+    
      
+  
+      
+
+      
+      
+
+
+  
+  
+    
      
+      und den Output in doc/devel/LumieraHelpLandingPage.html einchecken
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+  
+  
+    
      
+      Denn in Zukunft sollt das Buildsystem auch irgendwann mal ein User-Manual generieren und korrekt installieren; diese Platzhalter-Seite markiert mithin bereits den Ort dieser Installation und dient auch als Anker für diese zukünftige Funktionalität
+    
      
+  
+      
+
+
+      
+
+
+
+
+
+  
+  
+    
      
+      ....naja... das ist relativ; wie bei jeder DSL, wenn man mal das Schema verstanden hat, dann ist es konzis und deklarativ, und wenn man das Schema wieder vergessen hat, dann ist es »magisch«
+    
      
+  
+      
+
+      
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      (gemäß FHS) ⟹ <prefix>/share/doc/<paktename>/
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Das hier ist ein Buildsystem für ein Projekt von überschaubarem Umfang. Ganz ehrlich, ich erwarte nicht, daß irgendjemand außer mir  das SCons mag und pflegt. Also geht es höchstens darum, nach bestehendem Schema die eine oder andere Datei hinzuzufügen. Überdies frage ich mich, wie lange wir bei SCons bleiben können (hoffentlich noch lange, und hoffentlich darf dann nicht ich einen Ersatz programmieren, oder mich mit CMake herumärgern, das bei Weitem nicht so deklarativ ist
+    
      
+  
+
+      
+
+      
+      
+      
+
+
+
+
+
+  
+  
+    
      
+      dann wird subdir = <die letzte Pfadkomponente>, und das ist nicht, was man erwartet, sofern die Directories mehr als eine Ebene tief liegen. Kann ich jetzt nicht so ohne Weiteres ändern, ohne die Hilfsfunktion getDirname() (BuildHelper.py) umzuschreiben. Das ist es mir dann doch nicht wert!
+    
      
+  
+
+      
+
+
+
+      
+      
+      
+
+
+  
+  
+    
      
+      Installationsziel: <prefix>/share/doc/lumiera/manual-html/index.html
+    
      
+  
+
+      
+      
+
+
+
+
+      
+      
+      
+
+
+
+
+  
+  
+    
      
+      Was aber auch daran liegen könnte, daß XFCE nicht Gnome ist
+    
      
+  
+      
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    Some works meticulously keep track of what copyrights and licenses apply to each particular file when combining source from multiple origins. Some instead apply
+
+    
      
+      all licenses and all copyrights of component parts to the entire combined work. Both are generally accepted by the open source community, as long as it's clear that an effort is being made to identify and comply with the original licenses.
+    
      
+  
+      
+      
+
+
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Derzeit(2025) ist noch überhaupt nicht klar, in welcher Form wir Dokumentation ausliefern; naheliegend wäre es, unser (nicht vorhandenes) User-Manual aus den Asciidoc-Quellen zu bauen und damit als HTML lokal auszuliefern; das funktioniert aber nicht so ohne Weiteres, da die Seiten auf unsere Website abgestellt sind, und daher die volle Struktur vorraussetzen, und im Besonderen einen Webserver. Diesbezüglich fällt mir natürlich sofort das Stichwort »HTML-Help« ein — kann Asciidoc sowas generieren?
+    
      
+  
+      
+
+
+
+
+
+
+
+
+      
+      
+      
       
 
 
 
 
+
 
 
 

From 5c8e88e59e8e59371be9e00f3ca18e22b949940b Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Tue, 18 Nov 2025 16:09:54 +0100
Subject: [PATCH 37/51] Build: provide a placeholder page for the (planned)
 User-Manual
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Debian-Docbase allows to register some HTML documentation;
My old package definition added placeholder config, which renders
the documentation configuration invalid (as pointed out by Lintian).
However, I still think it is a good idea to have the anchor point
already defined, and thus I came up with the idea of in fact
providing some usable placeholder content...

As it turns out, we also have a placeholder page at the Lumiera website,
where the User Manual is assumed to be located later — so why not extend
this one and then provide the HTML-rendering for the DEB package?

To allow for this setup
 * I have now extended the placeholder page for the Website
   to include some generic description about Lumiera (from the 'about' page)
 * Furthermore, I added the screenshot (from the »Outer Space« page)
 * and I use this a an opportunity to document the various test / demo
   facilities currently available in the GUI, since these are rather obscure.
   While only intended for the developer, it seems still worthwhile
   to describe the possible effects — it may well be that we retain
   some of that test/demo functionality and in that case, we have
   now already some starting point for a documentation

 * Then, to include that page as stand-alone HTML, I used the 'Print Edit WE'-plugin
   from Firefox, to encode the images as inline-base64 URLs (which are restored
   by a tiny JavaScript embedded into that page)

 * and last but not least, our SCons buildsystem needs the ability
   to install such a documentation file, since it seems most adequate
   to handle this requirement as part of the generic installation (and
   not hidden in some Debian scripting)
---
 admin/scons/LumieraEnvironment.py       |  31 +-
 admin/scons/Setup.py                    |   1 +
 doc/SConscript                          |   5 +-
 doc/devel/LumieraHelpLandingPage.NOTICE |  16 +
 doc/devel/LumieraHelpLandingPage.html   | 699 ++++++++++++++++++++++++
 doc/user/manual.txt                     |  91 ++-
 6 files changed, 834 insertions(+), 9 deletions(-)
 create mode 100644 doc/devel/LumieraHelpLandingPage.NOTICE
 create mode 100644 doc/devel/LumieraHelpLandingPage.html

diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py
index d50b4db04..11dc15b5a 100644
--- a/admin/scons/LumieraEnvironment.py
+++ b/admin/scons/LumieraEnvironment.py
@@ -62,7 +62,7 @@ class LumieraEnvironment(Environment):
                 self.mergeConf(self.libInfo[other])
         else:
             self.Append (LIBS = other.get ('LIBS',[]))
-            self.Append (LIBPATH = other.get ('LIBPATH', []))
+            self.Append (LIBPATH = other.get('LIBPATH', []))
             self.Append (CPPPATH = other.get('CPPPATH', []))
             self.Append (LINKFLAGS = other.get('LINKFLAGS', []))
         
@@ -165,9 +165,11 @@ def register_LumieraResourceBuilder(env):
     
     def ConfigData(env, prefix, source, targetDir=None):
         """ install (copy) configuration- and metadata.
-            target dir is either the install location configured (in SConstruct),
-            or an explicitly given absolute or relative path segment, which might refer
-            to the location of the executable through the $ORIGIN token
+            @param targetDir: when None, then use he install location configured (in SConstruct),
+                otherwise an explicitly given absolute or relative path segment,
+                which might refer to the location of the executable through the $ORIGIN token
+            @param prefix: a prefix relative to the current path (location of SConscript),
+                i.e. typically a subdirectory where to find the source config file
         """
         source = path.join(prefix,str(source))
         subdir = getDirname(source, prefix)  # removes source location path prefix
@@ -188,6 +190,26 @@ def register_LumieraResourceBuilder(env):
         env.Install (toInstall, source)
         return env.Install(toBuild, source)
     
+    def DocFile(env, prefix, source, target=None):
+        """ install (copy) files for documentation.
+            Always places the documentation below the standard location 'installDoc' configured in Setup.py
+            @param prefix: relative to current path (SConscript), will be stripped at destination
+            @param target: when given, the target will be named explicitly, or (when only a directory)
+                placed into a specific subdir, otherwise (when None) the source spec will be placed
+                into the corresponding subdir after stripping the prefix
+        """
+        source = path.join(prefix,str(source))
+        subdir = getDirname(source, prefix)  # removes source location path prefix
+        if not target:
+            target = subdir+'/'
+        elif target.endswith('/'):
+            target = target+subdir+'/'
+        toInstall = path.join(env.path.installDoc, target)
+        if toInstall.endswith('/'):
+            return env.Install(toInstall, source)
+        else:
+            return env.InstallAs(toInstall, source) # this renames at target
+    
     
     buildIcon = env.Builder( action = Action(invokeRenderer, "rendering Icon: $SOURCE --> $TARGETS")
                            , single_source = True
@@ -197,6 +219,7 @@ def register_LumieraResourceBuilder(env):
     env.AddMethod(IconResource)
     env.AddMethod(GuiResource)
     env.AddMethod(ConfigData)
+    env.AddMethod(DocFile)
 
 
 
diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py
index 84ef3fd71..af2cfae53 100644
--- a/admin/scons/Setup.py
+++ b/admin/scons/Setup.py
@@ -40,6 +40,7 @@ installPlug  = '#$DESTDIR/lib/lumiera/modules'
 installIcon  = '#$DESTDIR/share/lumiera/icons'
 installUIRes = '#$DESTDIR/share/lumiera/'
 installConf  = '#$DESTDIR/lib/lumiera/config'
+installDoc   = '#$DESTDIR/share/doc/lumiera/'
 
 #-------------------------------------------------------Configuration
 
diff --git a/doc/SConscript b/doc/SConscript
index 537b9b137..e0abc0ebb 100644
--- a/doc/SConscript
+++ b/doc/SConscript
@@ -8,9 +8,10 @@ Import('env')
 
 
 doxydoc = env.Doxygen('devel/Doxyfile')
+env.Clean(doxydoc, doxydoc + ['devel/,doxylog','devel/doxygen-warnings.txt'])
 
-#  env.Install(dir = '$DESTDIR/share/doc/lumiera$VERSION/devel', source=documentation)
-env.Clean (doxydoc, doxydoc + ['devel/,doxylog','devel/doxygen-warnings.txt'])
+# HTML-documentation: this is a *placeholder* (eventually we'll build a user manual via Asciidoc)
+env.DocFile('devel', 'LumieraHelpLandingPage.html', 'manual-html/index.html')
 
 
 Export('doxydoc')
diff --git a/doc/devel/LumieraHelpLandingPage.NOTICE b/doc/devel/LumieraHelpLandingPage.NOTICE
new file mode 100644
index 000000000..6a4525d7b
--- /dev/null
+++ b/doc/devel/LumieraHelpLandingPage.NOTICE
@@ -0,0 +1,16 @@
+NOTE: this is a placeholder -- the intention is to build a user Manual via Asciidoc
+
+As of 2025, Lumiera is not usable, and thus only a placeholder HTML page is provided
+for the DEB-Package. The content on this page is identical to the "User-Manual" page:
+https://Lumiera.org/documentation/user/manual.html
+
+For the delivery
+- this page has been rendered with Asciidoc
+- the resulting HTML has been processed with the "Print Edit WE" plugin of Firefox,
+  which inlines any resources (CSS, images)
+
+This page will be installed by the Lumiera SCons build into $prefix/share/doc/lumiera
+(see doc/SConsscript)
+
+Hint: for updates, re-render the Asciidoc and then use git/diff to combine the
+      new or changed content with the embedded inline images (base64 data)
diff --git a/doc/devel/LumieraHelpLandingPage.html b/doc/devel/LumieraHelpLandingPage.html
new file mode 100644
index 000000000..fa19103df
--- /dev/null
+++ b/doc/devel/LumieraHelpLandingPage.html
@@ -0,0 +1,699 @@
+
+
+
+
+
+
+ 
+ 
+ 
+
+
+
+
+Lumiera User Manual
+
+
+
      
+  
      Lumiera
      
+  
      The new emerging NLE for GNU/Linux
      
+
      
+
      
+ 
      
+
+
      
+
+
+
+
      
+
      
+
      
+
      There is no »User Manual« — yet
      The plan is to create the manual and tutorials later in a collaborative way.
      
+This work is postponed until the software is actually usable.
      
+
      What is »Lumiera«?
      Lumiera is a Free/Open Source project to build a Non-Linear Video Editing (NLE)
+and compositing application for GNU/Linux.
+Its primary focus is professional editing, quality, usability and flexibility.
+On the one hand, it must meet the rigours of a professional
+film and video production environment; on the other hand, it must
+be flexible enough to satisfy the needs of more modest single-user
+equipment.
      
+
      These ambitious goals have led us to a complex and flexible internal structure,
+over the course of the last years. Many elements still need to be connected and
+integrated, so that the functionality becomes visible and can be explored by users.
+And we are a small team. Nevertheless, please be assured that work on the project is ongoing.
      
+
      
+
      
+
      
+
      
+
      UI Experiments
      
+
      
+
      While most of the work is focused at the inner workings of the Render Engine
+(as of Nov.2025), the User Interface has been upgraded to GTK-3 and outfitted with
+some experimental connection channels, to test interplay with the application core.
      
+
      After launching the lumiera application, a main window will be displayed.
      
+
      
+
+
+
+
      
+
      
+
      Video Output
      
+
      The ▶play / ⏸pause / ⏹stop buttons will activate some video output demo code,
+which is actually quite old — it was extracted 2009 from the Kino
+video editing software and used for various experiments since then. In its current shape,
+this dummy playback ensures that Lumiera is properly built and linked to use the
+XVideo standard with the help of the X11 XServer.
+This archaic standard from 1991 presumably was the first widely available and vendor-neutral interface
+for passing raw video frames to the GPU, which then scales and integrates them into the desktop display.
      
+
      The video frames for this demo are not generated by the Lumiera Render Engine — and
+thus this code is largely obsolete; maybe it will continue to live somewhere as a fallback
+for systems without proper support of OpenGL?
      
+
      
+
      
+
      The UI-Bus
      
+
      Instead of accessing a shared data model, the Lumiera UI is connected to the core
+through an asynchronous messaging channel, to dispatch command instructions into the
+session and to push responses up into the UI. There is a demo to verify this setup
+by pushing info and error messages into the »Info Box«
      
+
        
+
      • 
+
        
+In the “Help” menu, there is the entry ‘Help > Self Tests’
+
        
+
        • 
+
      • 
+
        
+The tab #1099 in this non-modal dialog box
+  allows to push notification messages into the UI-Bus…
+
        
+
          
+
        • 
+
          
+enter some text into the input widget at the top
+
          
+
          • 
+
        • 
+
          
+send a display message with this text at Info / Warn / or Error level
+
          
+
          • 
+
        • 
+
          
+or push the “mark” button to send a mark message, selected from the
+    drop-down
+
          
+
          • 
+
        
+
        • 
+
      
+
      
+
      
+
      Timeline Display
      
+
      The second tab in this “Test and Diagnostics” dialog box (‘Help > Self Tests’)
+allows to Populate the Timeline Display with a structure corresponding to session content.
+This structure is sent over the UI-Bus as a “Diff Message” — basically the core can notify
+the UI about changes in structured content elements, which both sides know, without ever sharing
+a common data representation.
      
+
      This demo engages this mechanism to populate an previously empty Timeline with structured content;
+the actual content is hard-wired for this test, offering two flavours (“Sequence 1” and “Sequence 2”).
      
+
      
+
      
+Sequence 1
+
      
+
      
+
      
+  A single Track, with two Clips, which can be clicked and dragged; they have a fixed given length,
+  but no further content.
+
      
+
      
+
      
+Sequence 2
+
      
+
      
+
      
+  A complex arrangement of nested tracks, some of which are expanded, and some have overview rulers.
+  Note that it is possible to scroll vertically, while the top-level overview rulers remain always
+  visible and pinned on top. Note furthermore that the Track-Head display in the left pane scrolles
+  alongside, and remains in sync with the main content pane. Tracks can not yet be expanded / collapsed
+
      
+
      
+
      
+
      The Button “move elements” is part of an ongoing experiment and currently disabled.
      
+
      
+
+
+
+
      
+Note
+the panes can be undocked and re-arranged, but retain their identity, so that
+      they can be addressed via UI-Bus without knowing where they are actually located
+      in the UI. And there are various known problems related to those docks…
      
+
      
+
      
+
      
+
      
+
      
+
      
+
      
+
      
+
+
+
diff --git a/doc/user/manual.txt b/doc/user/manual.txt
index d5952352a..ef02b532f 100644
--- a/doc/user/manual.txt
+++ b/doc/user/manual.txt
@@ -1,8 +1,93 @@
 Lumiera User Manual
 ===================
 
-The plan is to create the users manual later in a collaborative
-fashion, which was effective for Cinelerra.
+.There is no »User Manual« -- yet
+The plan is to create the manual and tutorials later in a collaborative way. +
+This work is postponed until the software is actually usable.
 
-This work is postponed until the software is actually working.
+.What is »Lumiera«?
+Lumiera is a Free/Open Source project to build a Non-Linear Video Editing (NLE)
+and compositing application for GNU/Linux.
+Its primary focus is professional editing, quality, usability and flexibility.
+On the one hand, it must meet the rigours of a professional
+film and video production environment; on the other hand, it must
+be flexible enough to satisfy the needs of more modest single-user
+equipment.
 
+These ambitious goals have led us to a complex and flexible internal structure,
+over the course of the last years. Many elements still need to be connected and
+integrated, so that the functionality becomes visible and can be explored by users.
+And we are a small team. Nevertheless, please be assured that work on the project is ongoing.
+
+- Look at the https://git.lumiera.org/[Git repositories] to see current activity
+- Visit the http://Lumiera.org/documentation/user/intro/intro.html[»Lumiera from Outer Space«]
+  page at the https://Lumiera.org[Lumiera.org] website to read more about the Design and Vision.
+
+
+UI Experiments
+--------------
+While most of the work is focused at the inner workings of the Render Engine
+(as of Nov.2025), the User Interface has been upgraded to GTK-3 and outfitted with
+some experimental connection channels, to test interplay with the application core.
+
+After launching the `lumiera` application, a main window will be displayed.
+
+image:{imgg}/lumiera20250823.png["Lumiera GTK UI / Screenshot 2025-08",width=650, link="{imgg}/lumiera20250823.png"]
+
+
+Video Output
+~~~~~~~~~~~~
+The [green]#▶#_play_ / [blue]#⏸#_pause_ / [red]#⏹#_stop_ buttons will activate some video output demo code,
+which is actually quite old -- it was extracted 2009 from the https://en.wikipedia.org/wiki/Kino_(software)[Kino]
+video editing software and used for various experiments since then. In its current shape,
+this dummy playback ensures that Lumiera is properly built and linked to use the
+https://en.wikipedia.org/wiki/X_video_extension[XVideo] standard with the help of the X11 XServer.
+This _archaic_ standard from 1991 presumably was the first widely available and vendor-neutral interface
+for passing raw video frames to the GPU, which then scales and integrates them into the desktop display.
+
+The video frames for this demo _are not generated by the Lumiera Render Engine_ -- and
+thus this code is largely obsolete; maybe it will continue to live somewhere as a fallback
+for systems without proper support of OpenGL?
+
+The UI-Bus
+~~~~~~~~~~
+Instead of accessing a shared data model, the Lumiera UI is connected to the core
+through an _asynchronous messaging channel,_ to dispatch command instructions into the
+session and to push responses up into the UI. There is a demo to verify this setup
+by pushing info and error messages into the »Info Box«
+
+- In the ``Help'' menu, there is the entry `Help > Self Tests'
+- The tab https://issues.lumiera.org/ticket/1099[#1099] in this non-modal dialog box
+  allows to push notification messages into the UI-Bus...
+   
+  * enter some text into the input widget at the top
+  * send a display message with this text at Info / Warn / or Error level
+  * or push the ``mark'' button to send a `mark` message, selected from the
+    drop-down
+
+Timeline Display
+~~~~~~~~~~~~~~~~
+The second tab in this ``Test and Diagnostics'' dialog box (`Help > Self Tests')
+allows to _Populate the Timeline Display_ with a structure corresponding to session content.
+This structure is sent over the UI-Bus as a ``Diff Message'' -- basically the core can notify
+the UI about changes in structured content elements, which both sides know, without ever sharing
+a common data representation.
+
+This demo engages this mechanism to _populate_ an previously empty Timeline with structured content;
+the actual content is hard-wired for this test, offering two flavours (``Sequence 1'' and ``Sequence 2'').
+
+Sequence 1::
+  A single Track, with two Clips, which can be clicked and dragged; they have a fixed given length,
+  but no further content.
+
+Sequence 2::
+  A complex arrangement of nested tracks, some of which are expanded, and some have overview rulers.
+  Note that it is possible to scroll vertically, while the top-level overview rulers remain always
+  visible and pinned on top. Note furthermore that the _Track-Head display_ in the left pane scrolles
+  alongside, and remains in sync with the main content pane. Tracks can not yet be expanded / collapsed
+
+The Button ``move elements'' is part of an ongoing experiment and currently disabled.
+
+NOTE: the panes can be undocked and re-arranged, but retain their identity, so that
+      they can be addressed via UI-Bus without knowing where they are actually located
+      in the UI. [red]#And there are various known problems related to those docks...#

From 5a5168b145284d0871b3ee61c8b50bfb68354135 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Wed, 19 Nov 2025 22:40:08 +0100
Subject: [PATCH 38/51] Build: fix problem that prevented installation into
 absolute path

...funny enough I never noticed this obvious mistake,
since I never install software directly into my system,
while the DEB-build does not use absolute paths...

Solution:
 * SCons has this speical convention that a path prefixed with '#'
   is resolved relative to the root of the build (where the SConstruct resides)
 * now we apply this automatically to the two relevant settings
   ** INSTALLDIR
   ** TARGDIR
 * but only (conditionally) if the configured path is relative, not absolute

As a consequence, most other hard-coded usages of the '#'-prefix can then be dropped
---
 admin/scons/LumieraEnvironment.py |  36 ++++++---
 admin/scons/Setup.py              |  26 +++----
 src/SConscript                    |   2 +-
 tests/SConscript                  |   4 +-
 wiki/thinkPad.ichthyo.mm          | 117 +++++++++++++++++++-----------
 5 files changed, 117 insertions(+), 68 deletions(-)

diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py
index 11dc15b5a..e85dbee62 100644
--- a/admin/scons/LumieraEnvironment.py
+++ b/admin/scons/LumieraEnvironment.py
@@ -29,14 +29,17 @@ class LumieraEnvironment(Environment):
         using global vars. Idea inspired by Ardour.
     """
     def __init__(self, buildSetup, buildVars, **kw):
-        kw.update(VERSION = buildSetup.VERSION
-                 ,TARGDIR = buildSetup.TARGDIR
-                 ,DESTDIR = '$INSTALLDIR/$PREFIX'
-                 ,toolpath = [buildSetup.TOOLDIR ]
-                 ,variables = buildVars
-                 )
-        Environment.__init__ (self, **kw)
-        self.path = Record (extract_localPathDefs(buildSetup))    # e.g. buildExe -> env.path.buildExe
+        Environment.__init__ (self, toolpath = [buildSetup.TOOLDIR ]
+                                  , variables = buildVars          # ◁───── reads settings from the commandline (see Options.py)
+                                  , **kw)
+        #
+        self['TARGDIR'] = buildSetup.TARGDIR
+        self['VERSION'] = buildSetup.VERSION
+        self['DESTDIR'] = '$INSTALLDIR/$PREFIX'
+        self._anchor_relative('INSTALLDIR')
+        self._anchor_relative('TARGDIR')
+        #
+        self.path = Record (extract_localPathDefs(buildSetup))     # ◁───── e.g. buildExe -> env.path.buildExe
         self.libInfo = {}
         self.Tool("BuilderDoxygen")
         self.Tool("ToolDistCC")
@@ -44,6 +47,16 @@ class LumieraEnvironment(Environment):
         register_LumieraResourceBuilder(self)
         register_LumieraCustomBuilders(self)
     
+    def _anchor_relative(self, key):
+        """ ensure that a relative path spec becomes anchored at build-root
+            @note: a special convention within scons: '#' implies directory of SConstruct
+        """
+        spec = self[key].strip()
+        if not (spec.startswith('/') or spec.startswith('#')):
+            spec = '#'+spec
+        self[key] = spec
+    
+    
     
     def Configure (self, *args, **kw):
         kw['env'] = self
@@ -120,12 +133,13 @@ def register_LumieraResourceBuilder(env):
     """
     
     import IconSvgRenderer as renderer  # load Joel's python script for invoking the rsvg-convert (SVG render)
-    renderer.rsvgPath = env.subst("$TARGDIR/rsvg-convert")
+    renderer.rsvgPath = env.subst("$TARGDIR/rsvg-convert").removeprefix('#')
+    #                                                    # the prefix '#' is a SCons specific convention,
+    #                                                    # which the external tool can not handle
     
     def invokeRenderer(target, source, env):
         source = str(source[0])
-        targetdir = env.subst(env.path.buildIcon)
-        if targetdir.startswith('#'): targetdir = targetdir[1:]
+        targetdir = env.subst(env.path.buildIcon).removeprefix('#')
         renderer.main([source,targetdir])
         return 0
         
diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py
index af2cfae53..ba15e32d7 100644
--- a/admin/scons/Setup.py
+++ b/admin/scons/Setup.py
@@ -28,19 +28,19 @@ OPTCACHE     = 'optcache'
 CUSTOPTFILE  = 'custom-options'
 
 # these are accessible via env.path.xxxx
-buildExe     = '#$TARGDIR'
-buildLib     = '#$TARGDIR/modules'
-buildPlug    = '#$TARGDIR/modules'
-buildIcon    = '#$TARGDIR/gui/icons'           # for IconResource() and IconRender()
-buildUIRes   = '#$TARGDIR/gui/'                # for GuiResource()
-buildConf    = '#$TARGDIR/config'              # for ConfigData()
-installExe   = '#$DESTDIR/lib/lumiera'
-installLib   = '#$DESTDIR/lib/lumiera/modules'
-installPlug  = '#$DESTDIR/lib/lumiera/modules'
-installIcon  = '#$DESTDIR/share/lumiera/icons'
-installUIRes = '#$DESTDIR/share/lumiera/'
-installConf  = '#$DESTDIR/lib/lumiera/config'
-installDoc   = '#$DESTDIR/share/doc/lumiera/'
+buildExe     = '$TARGDIR'
+buildLib     = '$TARGDIR/modules'
+buildPlug    = '$TARGDIR/modules'
+buildIcon    = '$TARGDIR/gui/icons'           # for IconResource() and IconRender()
+buildUIRes   = '$TARGDIR/gui/'                # for GuiResource()
+buildConf    = '$TARGDIR/config'              # for ConfigData()
+installExe   = '$DESTDIR/lib/lumiera'
+installLib   = '$DESTDIR/lib/lumiera/modules'
+installPlug  = '$DESTDIR/lib/lumiera/modules'
+installIcon  = '$DESTDIR/share/lumiera/icons'
+installUIRes = '$DESTDIR/share/lumiera/'
+installConf  = '$DESTDIR/lib/lumiera/config'
+installDoc   = '$DESTDIR/share/doc/lumiera/'
 
 #-------------------------------------------------------Configuration
 
diff --git a/src/SConscript b/src/SConscript
index 284569b7b..018937615 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -29,7 +29,7 @@ lumiera = ( env.Program('lumiera', ['lumiera/main.cpp'] + core, install=True)
 
 # Install the lumiera application:
 # symlink the executable into the bin dir
-env.SymLink('#$DESTDIR/bin/lumiera',env.path.installExe+'lumiera','../lib/lumiera/lumiera')
+env.SymLink('$DESTDIR/bin/lumiera',env.path.installExe+'lumiera','../lib/lumiera/lumiera')
 
 
 # building Lumiera Plugins
diff --git a/tests/SConscript b/tests/SConscript
index 4fb38d9e7..c233bf178 100644
--- a/tests/SConscript
+++ b/tests/SConscript
@@ -130,10 +130,10 @@ propagateSetting(testEnv, 'TESTMODE')
 propagateSetting(testEnv, 'LUMIERA_PLUGIN_PATH')
 propagateSetting(testEnv, 'HOME')
 
-testDir = env.Dir('#$TARGDIR')
+testDir = env.Dir('$TARGDIR')
 runTest = env.File("test.sh").abspath
 
-runTests = testEnv.Command('#$TARGDIR/,testlog', testsuite, runTest,  chdir=testDir)
+runTests = testEnv.Command('$TARGDIR/,testlog', testsuite, runTest,  chdir=testDir)
 Depends(runTests,vgsuppression)
 
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index a63370e0a..7abeb096c 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -171393,7 +171393,7 @@ Since then others have made contributions, see the log for the history.      
       
 
-
+
 
 
       
@@ -177762,9 +177762,9 @@ Since then others have made contributions, see the log for the history.
       
       
-
-
-
+
+
+
 
 
 
@@ -177789,11 +177789,14 @@ Since then others have made contributions, see the log for the history.
 
       
-
+
+
 
 
 
-
+
+
+
 
 
   
@@ -177807,12 +177810,52 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Effektiv ist das '#'-Präfix jetzt in $INSTALLDIR und $TARGDIR hineingewandert. Das ist aber eine SCons-spezifische Konvention, mit der der Icon-Renderer natürlich nix anfangen kann
+    
      
+  
+      
 
       
       
 
 
+
+
+
       
 
 
@@ -180105,8 +180148,7 @@ Since then others have made contributions, see the log for the history.      unbedingt per Diff/Merge        aktualisieren vom Website-Content!
     
      
   
-
-
+
 
 
 
@@ -180172,8 +180214,7 @@ Since then others have made contributions, see the log for the history.      
   
-
-
+
 
 
 
@@ -180325,8 +180366,7 @@ Since then others have made contributions, see the log for the history.und außerdem  auch über alle Compiler-Schalter und Environment-Settings
     
      
   
-
-
+
 
 
 
@@ -180348,8 +180388,7 @@ Since then others have made contributions, see the log for the history.             *** Directory path for variable 'INSTALLDIR' does not exist: debian/lumiera
     
      
   
-
-
+
 
 
 
@@ -180362,8 +180401,7 @@ Since then others have made contributions, see the log for the history.      
   
-
-
+
 
 
 
@@ -180529,8 +180567,7 @@ Since then others have made contributions, see the log for the history.      
   
-
-
+
 
 
 
@@ -180545,8 +180582,8 @@ Since then others have made contributions, see the log for the history.      
 
 
-
-
+
+
 
 
 
@@ -180583,8 +180620,7 @@ Since then others have made contributions, see the log for the history.      
   
-
-
+
 
 
 
@@ -180619,9 +180655,9 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
-
+
 
 
 
@@ -180664,14 +180700,14 @@ Since then others have made contributions, see the log for the history.      
 
 
-
-
-
+
+
+
 
 
-
+
 
-
+
 
 
 
@@ -180691,7 +180727,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
 
@@ -180719,7 +180756,7 @@ Since then others have made contributions, see the log for the history.      
 
 
-
+
 
   
   
@@ -180728,8 +180765,9 @@ Since then others have made contributions, see the log for the history.
   
 
+
 
-
+
 
 
 
@@ -180801,8 +180839,7 @@ Since then others have made contributions, see the log for the history.      außer mir  das SCons mag und pflegt. Also geht es höchstens darum, nach bestehendem Schema die eine oder andere Datei hinzuzufügen. Überdies frage ich mich, wie lange wir bei SCons bleiben können (hoffentlich noch lange, und hoffentlich darf dann nicht ich einen Ersatz programmieren, oder mich mit CMake herumärgern, das bei Weitem nicht so deklarativ ist
     
      
   
-
-
+
 
 
 
@@ -180818,8 +180855,7 @@ Since then others have made contributions, see the log for the history.Das ist es mir dann doch nicht wert!
     
      
   
-
-
+
 
 
 
@@ -180834,11 +180870,10 @@ Since then others have made contributions, see the log for the history.      Installationsziel: <prefix>/share/doc/lumiera/manual-html/index.html
     
      
   
-
-
+
 
-
-
+
+
 
 
 

From b3d8abcb2cea3787386cd1e403ee0b36012d0f5c Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Thu, 20 Nov 2025 22:55:38 +0100
Subject: [PATCH 39/51] Build: provide and install a lumiera.desktop file

The XDG Desktop spec is accepted universally, and thus
the old Debian-specific 'menu' system is deprecated and
no longer engaged automatically.

See: https://lists.debian.org/debian-devel-announce/2015/09/msg00000.html

Thus we'll now provide a Desktop file and install that already from out
SCons build system, together with a suitable variation of the Lumiera icon.

TODO: not sure if everything was done the correct way
 * do we need to ''register'' the new file in some way (preinst script?)
 * the menu entry shows up, but not the icon
 * but if we put an absolute path for the lumiera.svg into the desktop file, it shows up

Remark: in later experiments with package building,
the menu entry and the icon showed up in the menu.
Not sure if this requires a reboot or some similar
trigger (like restart of the destkop)
---
 admin/scons/LumieraEnvironment.py |   5 +-
 data/SConscript                   |   4 +
 data/desktop/lumiera.desktop      |  13 +++
 data/desktop/lumiera.svg          | 146 +++++++++++++++++++++++++++++
 wiki/thinkPad.ichthyo.mm          | 150 +++++++++++++++++++++++++++++-
 5 files changed, 311 insertions(+), 7 deletions(-)
 create mode 100644 data/desktop/lumiera.desktop
 create mode 100644 data/desktop/lumiera.svg

diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py
index e85dbee62..99a10199f 100644
--- a/admin/scons/LumieraEnvironment.py
+++ b/admin/scons/LumieraEnvironment.py
@@ -36,6 +36,7 @@ class LumieraEnvironment(Environment):
         self['TARGDIR'] = buildSetup.TARGDIR
         self['VERSION'] = buildSetup.VERSION
         self['DESTDIR'] = '$INSTALLDIR/$PREFIX'
+        self['SHARE'  ] = '$DESTDIR/share'
         self._anchor_relative('INSTALLDIR')
         self._anchor_relative('TARGDIR')
         #
@@ -169,7 +170,7 @@ def register_LumieraResourceBuilder(env):
         return env.Install(toBuild, source)
     
     def GuiResource(env, source):
-        """ pick up giben source resource and install
+        """ pick up given source resource and install
             them (flat) into the configured target
         """
         toBuild = env.path.buildUIRes
@@ -179,7 +180,7 @@ def register_LumieraResourceBuilder(env):
     
     def ConfigData(env, prefix, source, targetDir=None):
         """ install (copy) configuration- and metadata.
-            @param targetDir: when None, then use he install location configured (in SConstruct),
+            @param targetDir: when None, then use he install location configured (in Setup.py),
                 otherwise an explicitly given absolute or relative path segment,
                 which might refer to the location of the executable through the $ORIGIN token
             @param prefix: a prefix relative to the current path (location of SConscript),
diff --git a/data/SConscript b/data/SConscript
index d2407b502..e04d5f2fa 100644
--- a/data/SConscript
+++ b/data/SConscript
@@ -21,5 +21,9 @@ config  = ( env.ConfigData('config','setup.ini', targetDir='$ORIGIN')
           + env.ConfigData('config','dummy_lumiera.ini')
           )
 
+#further resources...
+env.Install('$SHARE/applications/'               , 'desktop/lumiera.desktop')
+env.Install('$SHARE/icons/hicolor/scalable/apps/', 'desktop/lumiera.svg')
+
 
 Export('icons config')
diff --git a/data/desktop/lumiera.desktop b/data/desktop/lumiera.desktop
new file mode 100644
index 000000000..771d6d0a5
--- /dev/null
+++ b/data/desktop/lumiera.desktop
@@ -0,0 +1,13 @@
+[Desktop Entry]
+Type=Application
+Version=1.5
+Name=Lumiera
+Comment=Video editing and compositing (unfinished; development preview)
+GenericName=VideoEditor
+Exec=lumiera
+TryExec=lumiera
+Icon=lumiera
+Terminal=false
+Categories=AudioVideo;Video;AudioVideoEditing;
+Keywords=media;film;editing;compositing;fx;
+
diff --git a/data/desktop/lumiera.svg b/data/desktop/lumiera.svg
new file mode 100644
index 000000000..bcf70b504
--- /dev/null
+++ b/data/desktop/lumiera.svg
@@ -0,0 +1,146 @@
+
+
+
+
+  Lumiera Icon
+  
+    
+      
+        image/svg+xml
+        
+        
+        Lumiera Icon
+        August 2009
+        
+          
+            Thorsten Wilms
+          
+        
+        
+          
+            CC By SA
+          
+        
+        
+          
+            Lumiera project
+          
+        
+        Lumiera Logo
+        After the Lumiera Logo contest, several flavours were created for use on posters, T-shirts and desktop icons
+        
+          
+            Raffaella Traniello, Thorsten Wilms, Odin Hørthe Omdal, Ichthyoste
+          
+        
+      
+      
+        
+        
+        
+        
+        
+        
+      
+    
+  
+  
+  
+    
+  
+  
+    
+  
+
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 7abeb096c..adc960272 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -177763,8 +177763,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
 
+
 
 
 
@@ -180626,15 +180626,15 @@ Since then others have made contributions, see the log for the history.      
 
 
-
+
 
 
-
+
 
 
 
 
-
+
 
 
 
@@ -180647,8 +180647,17 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
+
+
+
+
+
+
+
+
+
 
 
 
@@ -180892,6 +180901,137 @@ Since then others have made contributions, see the log for the history.
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      Bei den GUI-Icons gibt es ein app-icon.svg — aber das sieht unfertig/kaputt aus; vermutlich hat sich da Joel damals daran versucht, aber er ist daran gescheitert, daß das Lumiera-Logo sich nicht ohne Weiteres in ein Icon übersetzen läßt. Außerdem folgen diese SVGs ja einem ganz bestimmten Schema, und enthalten daher mehrere Varianten auf einem gemeinsamen »Canvas«
+    
      
+  
+      
+      
+
+
+  
+    
+  
+  
+    
      
+      Tja... damals hat man zwar ein Lumiera-Logo designt — aber dann würde noch die Arbeit ausstehen, daraus eine Design-Linie zu entwickeln, die in verschiedensten Größen und in verschiedenem Umfeld konsistent funktioniert. Und ersatzweise hat dann jeder für jeden Einzelfall seine Variante gebastelt (und ich mach ja auch nix Anderes)
+    
      
+  
+      
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      Deklarativität setzt etablierte Kategorien vorraus
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 

From 4d373c929e27c65528cfddc7b830b8b54932c66d Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Tue, 11 Nov 2025 23:28:55 +0100
Subject: [PATCH 40/51] Release: check legal statements / Authors

See corresponding commit in the website repository.
- Verified all authors via Git
- simplify the list and group by core/contributors
- list only significant contributors here

__Note__: the page "project/contributors" on the website
contains a much more extensive list with all helpers,
casual contributors and concept discussion participants
---
 AUTHORS                  |  54 ++--
 wiki/thinkPad.ichthyo.mm | 569 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 586 insertions(+), 37 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index 68cadbab9..bf58ea89f 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -1,59 +1,44 @@
 Lumiera Authors and Credits
 ===========================
-Version: 0.pre.03
-:Date: 11/2015
+:Date: 11/2025
 
 
 |==========================================
-|*Architecture and Design*|
-|graphical
-    user interface | JOEL HOLDSWORTH
+|*Architecture*    |
 |                  | HERMANN VOSSELER
-|                  | BRIAN RYTEL
-|processing layer  | HERMANN VOSSELER
-|backend           | CHRISTIAN THÄTER
+|                  | CHRISTIAN THÄTER
+|                  | JOEL HOLDSWORTH
 
-|                  |
-|                  |
-|*Workflow design* |
-|concept           | BRIAN RYTEL
-|                  | MIKE PROVOST
-|                  | NIKOLA DUPER
+|*Workflow Concept*|
+|                  | HERMANN VOSSELER
+|                  | WOUTER VERWIJLEN
 |                  | CHRISTOPH VARGA
+|                  | BRIAN RYTEL
+|                  | CLAY BARNES
+
 
 |                  |
 |                  |
-|*Programming*|
-|session and engine| HERMANN VOSSELER
-|backend           | CHRISTIAN THÄTER
+|*Core Developers* |
+|                  | HERMANN VOSSELER
+|                  | JOEL HOLDSWORTH
+|                  | CHRISTIAN THÄTER
+|*Programming*     |
 |                  | MICHAEL PLOUJNIKOV
-|graphical
-     user interface| JOEL HOLDSWORTH
 |                  | STEFAN KANGAS
 |                  | MICHAEL FISHER
-|library           | HERMANN VOSSELER
-|                  | CHRISTIAN THÄTER
-|                  | ANTON YAKOVLEV
-|                  | STEFAN KANGAS
-|testsuite         | CHRISTIAN THÄTER
-|                  | NICHOLAS SINNOTT-ARMSTRONG
-|                  | HERMANN VOSSELER
+|                  | SIMEON VÖLKEL
 
 |                  |
 |                  |
-|*Programming Documentation*|
-|                  | CHRISTIAN THÄTER
+|*Documentation*   |
 |                  | HERMANN VOSSELER
-|                  | MICHAEL PLOUJNIKOV
+|                  | CHRISTIAN THÄTER
 |                  | ODIN HØRTHE OMDAL
 |                  | SIMEON VÖLKEL
 |                  | MANO STIENEN
 |                  | HENDRIK BOOM
 |                  | BENNY LYONS
-|                  |
-|                  |
-|*Server Administration*|
-|                  | CHRISTIAN THÄTER
 |==========================================
 
 
@@ -78,6 +63,9 @@ Further Credits
 ---------------
 - inspirations and some UI components were taken from http://Ardour.org[Ardour]
 
+- https://github.com/x42/xjadeo[xjadeo] by Robin Gareus was very helpful
+  for learning how to output raw video from a desktop application
+
 - Parts of the Implementation are heavily inspired by +
   *The Loki Library*  (c) 2001 by *Andrei Alexandrescu*
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index adc960272..f7fc71fb5 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -166054,6 +166054,42 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
+
+
+
+  
+  
+    
      
+      ...der findet sich in der Seite project/credits.html und besteht aus einem speziellen CSS + ein JavaScript, das die Seite langsam scrollt.
+    
      
+    
      
+      
+    
      
+    
      
+      Relevant ist hier vor allem der Content, denn das war der erste Versuch, Attribution zu geben (und bisher auch die Basis des AUTHORS file)
+    
      
+  
+      
+      
+
+
+
+  
+  
+    
      
+      ....anhand der Git-Logs nach Auslassungen suchen; dann aber auch die Darstellung etwas rebalancieren, denn die entspricht mehr dem Eindruck aus der Anfangszeit, als jeder kleine Beitrag bejubelt wurde — aus heutiger Sicht haben wir einige substantielle Beiträge, die in dieser ganzen Masse an Credits untergehen, während Sachen hervorgehoben werden, die letztlich nie zustandegekommen sind (uWiki, Builddrone, neues Website-Layout, Christian's DataBackend)
+    
      
+  
+      
+
+      
+      
+      
+      
+      
       
 
 
@@ -167021,6 +167057,7 @@ that situation will improve in forseeable future.
 
 
 
+
 
 
 
@@ -168578,21 +168615,469 @@ that situation will improve in forseeable future.
 
 
       
-
+
+
 
 
 
 
 
+
+
+
+
+  
+  
+    
      
+      diese greift, wenn die mtime neuer wäre als die angegebene Unix-Epoch. Damit kann man einen Build reproducible machen
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
 
 
 
+
+
+
+
+  
+  
+    
        
+      
      • 
+        <link rel="license" href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.html" />
+      
        • 
+      
      • 
+        <link rel="license" href="https://www.gnu.org/licenses/gpl-3.0" />
+      
        • 
+      
      • 
+        <link rel="license" href="https://creativecommons.org/licenses/by-sa/4.0/" />
+      
        • 
+    
      
+  
+      
+
+      
+      
+      
+
+
+
+
+
+
+  
+  
+    
      
+      Grundsätzlich kann ich Content von anderen Leuten nicht ohne Weiteres aktualisieren. Aber Seiten, zu denen ich später Ergänzungen beigetragen habe, stellen ein abgeleitetes Werk dar, und in dem Zuge kann ich von dem Upgrade-Recht (das CC-Lizenzen stets beinhalten) Gebrauch machen. Das geht aber nur mit einem explizit genannten Stichdatum (oder wenn man sicherstellt, daß jede Seite tatsächlich bearbeitet wurde (Git-Commit) und einen entsprechenden Vermerk trägt
+    
      
+  
+      
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Vor allem relevant in der EU: die Datenbank als Ganzes (oder in großen Teilen) bleibt geschützt, da sie ein erhebliches Investment darstellt. CC-Lizenzen gelten nur für den Abruf und Gebrauch von Einzeldaten
+    
      
+  
+      
+      
+
+
+
+
+  
+  
+    
      
+      Das beseitigt eine gefährliche Falle. Manche Länder (z.B. England, Frankreich, Japan) haben ein striktes moral rights regime, das ohne ensprechende Klarstellung dafür sorgen könnte, daß die per CC gegebenen Rechte durch einen Beitrag abgeschwächt werden könnten. Die neue Lizenz hat eine spezielle »Tunell-Klausel«, der zufolge per übersteuerndem Recht eingeschränkte Rechte wieder aufleben, sofern die Bearbeitung in einen anderen Rechtsraum gelangt. Zu den moral rights gehört das Recht eines Authors, über die Art der Repräsentation seines Werkes vollumfänglich zu bestimmen. Das bedeutet, daß ein Author das Recht hat, einem abgeleiteten Werk oder einer Übersetzung nicht zuzustimmen  und verlangen kann, daß entsprechende Werke effektiv aus dem Verkehr gezogen werden. Das würde auch greifen, wenn ein bisher substantieller Anteil marginalisiert wird, oder die Art und der Stil der Darstellung sich ändert.
+    
      
+  
+      
+
+
+
+
+
+
+  
+  
+    
      
+      Es gibt jetzt einen Pfad CC By SA 4 ⟶ GPL 3+ (aber nicht umgekehrt!)
+    
      
+  
+      
+      
+      
+
+
+
+
+  
+  
+    
      
+      Adapted Material: means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor.
+    
      
+  
+      
+
+
+
+
+
+
+
+  
+  
+    
      
+      Es geht nach meiner Einschätzung vor allem um die Protokolle, die andere Leute geschrieben haben, die RfCs und die Workflow/GUI-Proposals. Alle diese werden mit klarer Author-Angabe reproduziert
+    
      
+  
+      
+      
+      
+
+
+  
+  
+    
      
+      und die neue Version schränkt nach meiner Einschätzung keine Rechte ein, sondern stellt nur Rechte klar. Der größte Knackpunkt könnten moral rights sein, aber da stelle ich mich auf den Standpunkt, daß ich eine Adaption/Collection mache, und daher gar nicht über die moral rights von Dritten verfügen kann. Insofern bestehen diese weiter
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      bisweilen mit Benny als Co-Author
+    
      
+  
+      
+      
+      
+
+
+
+      
+
+
+
+
+
+
+
+  
+  
+    
      
+      Wobei in diesem Kontext zweifelhaft ist, was ein maschinenlesbarer Code auf einer allgemeinen Lizenz-Seite bringen soll. Das würde eigentlich nur Sinn machen, wenn der Button auf jeder Seite wäre
+    
      
+  
+
+      
+
+
+
+
+  
+  
+    
      
+      So stellt es zumindest ChatGPT dar. Demnach habe man die Empfehlungen bei CC vereinfacht, und biete nun einfach Grafiken an, die die User in ihre Website packen können.
+    
      
+  
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      CSS, falscher Link
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ....und jeweils sehen ob sich das bewährt und entsprechend klar ist
+    
      
+  
+
+      
+      
+
+
+  
+  
+    
      
+      Denn damit kann man vermeiden, Attribution für Dinge zu geben, die nicht vorwärts gekommen sind
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...die wollten mal was beitragen, haben sich auch in der Diskussion engagiert, aber nie etwas geliefert
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
        
+      
      • 
+        ich hatte vor vielen Jahren in Asciidoc-Markup umgewandelt, was hier mit minimalem Aufwand möglich ist (einziges Problem: ich bekomme Ziffern  in der Aufzählung, statt Buchstaben wie im Original)
+      
        • 
+      
      • 
+        der eigentliche Text ist komplett identisch geblieben
+      
        • 
+      
      • 
+        geändert hat sich, daß jetzt auf die FSF-Website verlinkt wird, und daß ein Beispieltext angepaßt wurde
+      
        • 
+    
      
+  
+      
+
+      
+
+
+  
+  
+    
      
+      analog
+    
      
+  
+      
+
+      
+
+
+  
+  
+    
      
+      Die LGPL hatte ich ohnehin nur der Vollständigkeit halber mit eingeschlossen; sie spielt für Lumiera derzeit keine Rolle. Daher kann ich auch gleich die aktuellste Version LGPL-3 nehmen. Auch diese transcodiere ich ganz oberflächlich nach Asciidoc
+    
      
+  
+      
+      
+      
+
+
+
+
 
-
-
 
 
 
@@ -182918,11 +183403,87 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
+
+
 
 
 
 
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Es ist also im Besonderen nicht notwendig, daß irgend ein gewerblicher »Dienst« angeboten wird, da auch alle Arten von Publikationen mit erfaßt werden sollen.
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Auf eine Telefonnummer kann man verzichten. Aber die eMail muß regelmäßig gelesen werden (Reaktionszeit: Stunden). Und für die Adresse gilt: man muß dort persönlich einen Verantwortlichen antreffen können. Beispielsweise für eine gerichtliche  Ladung oder einen Durchsuchungsbeschluß. Es ist also eine Postbox explizit nicht ausreichend.
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Umsatzsteuernummer, Name der Zulassungsbehörde, bei Freiberuflern der Name der Stelle die den Titel oder das Diplom ausgestellt hat. Bei Unternehmen die Rechtsform. Bei journalistischen Publikationen, die regelmäßige Aktualisierungen beinhalten und regelmäßig publizierte Druckerzeugnisse wiedergeben (d.h. Zeitungen, Nachrichtendienste) muß ein Verantwortlicher benannt werden, der sofort reaktionsfähig ist (es genügt nicht die Angabe eines Firmensitzes)
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Konkret heißt das: es muß ein Link in den Footer, der »Impressum« heißt und mit höchstens einem Klick zum Ziel führt. Verlinken auf eine Hompage genügt nicht
+    
      
+  
+      
+
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 

From 6c3f0edf10f9a73ec53f4430b4539c1246e0cba7 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Fri, 21 Nov 2025 23:38:20 +0100
Subject: [PATCH 41/51] Release: update README

...and split-out the description of preview-releases,
since that rather belongs into some kind of changelog (NEWS).

Furthermore, check the links to the build dependencies
---
 INSTALL                               |   1 -
 NEWS                                  |  62 +++++++++
 README                                |  96 +++++--------
 doc/design/governance/integration.txt |  12 +-
 doc/user/tutorials/building.txt       |  30 ++--
 wiki/thinkPad.ichthyo.mm              | 191 ++++++++++++++++++--------
 6 files changed, 259 insertions(+), 133 deletions(-)
 delete mode 120000 INSTALL
 create mode 100644 NEWS

diff --git a/INSTALL b/INSTALL
deleted file mode 120000
index c3b5125d9..000000000
--- a/INSTALL
+++ /dev/null
@@ -1 +0,0 @@
-doc/user/tutorials/building.txt
\ No newline at end of file
diff --git a/NEWS b/NEWS
new file mode 100644
index 000000000..85053d59b
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,62 @@
+Lumiera -- Significant Changes
+==============================
+:Date: 11/2015
+
+*************************************************************
+Lumiera is a non-linear video editing and compositing tool.
+
+NOTE: as of 11/2025, Lumiera is in early development stage;
+it is not usable yet. This is a preview Release of a
+current development snapshot in pre-alpha stage.
+
+Visit http://Lumiera.org and join the mailing list
+when interested in Lumiera planning and development.
+****************************************************************
+
+
+Lumiera pre-Alpha Versions
+--------------------------
+
+**This source tree doesn't yet contain a working video editing application** +
+Rather, it contains the framework and technology core
+of the envisioned Application ``Lumiera''.
+
+See http://issues.lumiera.org/roadmap[Project roadmap]
+
+As of _11/2015_ (0.pre.03)::
+a lot of long standing maintennance work has been done. The Project switched
+to C++11 and in the end even to C++14 and Debian/Jessie as reference platform,
+followed by clean-up of now obsolete workarounds. On the GUI side, we largely
+made the transition to GTK-3, which lead to rework of our timeline widget, not
+finished yet. This work also spured an effort the connection and communication
+between Proc and the UI, which is expected to be asynchroneous. Due to the
+limited developer resources, work on the Engine and Player part is stalled.
+
+As of _10/2013_ (0.pre.02)::
+the data models have been elaborated and some significant parts of the session
+are finished. Work has continued with time handling, a draft of the output
+connection framework, a draft of the player subsystem and interfaces to the
+engine and processing network. Unfortunately there was a considerable slowdown
+and decrease in team size, yet still the code base is growing towards 90k LOC.
+No tangible progress regarding the GUI and the backend.
+
+As of _1/2011_ (0.pre.01)::
+the project has created and documented a fairly consistent design,
+partially coded up -- starting from the technical foundations and working up.
+The code base is approaching 65k LOC. Roughly half of this is test code.
+The Application can be installed and started to bring up a GTK GUI framework,
+but the GUI is very preliminary and not connected to core functionality.
+The video processing pipeline exists only in the blueprints.
+
+As of _2/2008_::
+the project has been separated completely from ``Cinelerra'', the parent project.
+The Community, which at that time was largely identical to the Cinelerra-CV community,
+choose the new project name ``Lumiera'' through a collaborative selection and vote.
+The basic project infrastructure is up and running, and work on the new codebase
+has started. We can show nothing beyond a test suite for some time to come.
+
+As of _7/2007_::
+we started with the backend and render engine draft, some example code
+complemented by several unit tests. There is a TiddlyWiki with detailed
+design considerations and developer documentation and a UML model
+
diff --git a/README b/README
index 08f1a3e21..f26f808fb 100644
--- a/README
+++ b/README
@@ -1,16 +1,14 @@
 Lumiera -- the video NLE for Linux
-====================================
+==================================
 Version: 0.pre.04~rc.1
-:Date: 11/2015
+:Date: 11/2025
 
 *************************************************************
 Lumiera is a non-linear video editing and compositing tool.
+The Application will allow to edit footage using common
+multimedia formats and audio/video stream codecs.
 
-The Application will allow to edit footage in the common
-multimedia formats (quicktime, ogg, mkv, avi) and audio/video
-stream codecs (dv, mpeg1/2/4, h264 ...)
-
-Lumiera features non-destructive editing, compositing tools,
+Lumiera features nondestructive editing, compositing tools,
 a selection of effects plugins, processing in RGB, YUV and
 RGB-float colour models and the ability to mix media with
 differing sizes and framerates. Lumiera is especially well
@@ -19,12 +17,11 @@ with lots of material, several scenes, nested sequences,
 colour grading, 3D support, full fledged sound montage
 and multiple edit versions prepared in parallel.
 
-NOTE: as of 11/2015, Lumiera is in early development stage;
+NOTE: as of 11/2025, Lumiera is in early development stage;
 it is not usable yet. The above describes the Lumiera project
-vision, which will need years to implement. This preview Release
-installs a current development snapshot in pre-alpha stage.
+vision, the implementation of which will require many more years.
 
-Visit http://Lumiera.org and join the mailing list
+Visit https://Lumiera.org and join the mailing list
 when interested in Lumiera planning and development.
 ****************************************************************
 
@@ -32,48 +29,20 @@ when interested in Lumiera planning and development.
 Lumiera pre-Alpha Versions
 --------------------------
 
-**This source tree doesn't yet contain a working video editing application** +
-Rather, it contains the framework and technology core
-of the envisioned Application ``Lumiera''.
+.This source tree doesn't contain a working video editing application yet.
+Rather, it contains the framework and technology core of the envisioned
+Application »Lumiera«. What we attempt to build here is innovative,
+and we must engage in a series of integration steps to search for
+suitable pathways towards our envisaged architecture.
 
-See http://issues.lumiera.org/roadmap[Project roadmap]
+Since 2024, the integration of the Render Engine takes centre stage,
+in an effort to establish a steady state realtime processing and
+display pipeline, still relying on generated video data rather
+than using a library to read and playback a video file.
 
-As of _11/2015_ (0.pre.03)::
-a lot of long standing maintennance work has been done. The Project switched
-to C++11 and in the end even to C++14 and Debian/Jessie as reference platform,
-followed by clean-up of now obsolete workarounds. On the GUI side, we largely
-made the transition to GTK-3, which lead to rework of our timeline widget, not
-finished yet. This work also spured an effort the connection and communication
-between Proc and the UI, which is expected to be asynchroneous. Due to the
-limited developer resources, work on the Engine and Player part is stalled.
+- https://Lumiera.org/documentation/design/governance/integration.html[Integration steps]
+- See also https://issues.lumiera.org/roadmap[Project roadmap]
 
-As of _10/2013_ (0.pre.02)::
-the data models have been elaborated and some significant parts of the session
-are finished. Work has continued with time handling, a draft of the output
-connection framework, a draft of the player subsystem and interfaces to the
-engine and processing network. Unfortunately there was a considerable slowdown
-and decrease in team size, yet still the code base is growing towards 90k LOC.
-No tangible progress regarding the GUI and the backend.
-
-As of _1/2011_ (0.pre.01)::
-the project has created and documented a fairly consistent design,
-partially coded up -- starting from the technical foundations and working up.
-The code base is approaching 65k LOC. Roughly half of this is test code.
-The Application can be installed and started to bring up a GTK GUI framework,
-but the GUI is very preliminary and not connected to core functionality.
-The video processing pipeline exists only in the blueprints.
-
-As of _2/2008_::
-the project has been separated completely from ``Cinelerra'', the parent project.
-The Community, which at that time was largely identical to the Cinelerra-CV community,
-choose the new project name ``Lumiera'' through a collaborative selection and vote.
-The basic project infrastructure is up and running, and work on the new codebase
-has started. We can show nothing beyond a test suite for some time to come.
-
-As of _7/2007_::
-we started with the backend and render engine draft, some example code
-complemented by several unit tests. There is a TiddlyWiki with detailed
-design considerations and developer documentation and a UML model
 
 
 
@@ -82,19 +51,24 @@ Build Requirements
 
 For building Lumiera, you'll need:
 
- * C99 / C++14 compiler GCC `>=4.9` or Clang `>=3.5`
+ * C++23 compiler GCC >=14 (Clang fails atm)
  * Git Version management system
- * http://www.scons.org/[SCons build system]
- * http://www.boost.org/[Boost libraries]
- * http://gmerlin.sourceforge.net/[GAVL library]
- * http://nobug.pipapo.org/[NoBug library]
- * http://www.gtkmm.org/en/[GTKmm]
- * http://alsa-project.org[ALSA libasound2-dev]
- * http://cgit.freedesktop.org/xorg/lib/libXv[libXv]
- * https://wiki.gnome.org/LibRsvg[lib rSVG]
- * https://git.gnome.org/browse/gdl[lib GDL]
+ * https://www.scons.org/[SCons build system]
+ * https://www.boost.org/[Boost libraries]
+ * https://github.com/bplaum/gavl[GAVL library]
+ * https://www.alsa-project.org/[ALSA (libasound2-dev)]
+ * https://nobug.pipapo.org/[NoBug library]
+ * https://gtkmm.gnome.org/en/[gtkmm]
+ * https://cgit.freedesktop.org/xorg/lib/libXv[libXv]
+ * https://wiki.gnome.org/Projects/LibRsvg[lib rSVG]
+ * https://git.lumiera.org/?p=debian/gdl;a=summary[lib GDL]
+ * https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL-mm bindings]
 
-See the online documentation at http://Lumiera.org/download.html
+Further information:
+
+ * Online documentation at https://Lumiera.org/download.html[Build and install].
+ * Documentation is also available in-tree in 'doc/user/tutorials/building.txt'
+ * Source code can be retrieved with `git clone git://git.lumiera.org/LUMIERA`
 
 
 
diff --git a/doc/design/governance/integration.txt b/doc/design/governance/integration.txt
index 605becf1e..6a1085fe8 100644
--- a/doc/design/governance/integration.txt
+++ b/doc/design/governance/integration.txt
@@ -6,12 +6,12 @@ Towards Integration
 //Menu: label Integration
 
 The Lumiera project creates innovative software, geared towards professional, high-quality work;
-it aims at high flexibility, offering user-control over a broad spectrum of configurable parameters,
-and with smooth workflows that scale well to larger and more intricate projects. Building such
-software involves some degree of exploration and search for adequate methods to reconcile
-conflicting goals. There is no ready-made blueprint that just needs implementation -- rather,
-we have to resort to a sequence of integration efforts, aimed at establishing core tenets
-of the envisioned architecture.
+it is characterised by comprehensive flexibility, allowing precise control of a wide range of
+parameters, as well as seamless workflows capable of handling even large and complex projects.
+Building such software involves some degree of exploration and the search for suitable ways to
+reconcile sometimes conflicting goals. There is no ready-made blueprint that simply needs to be
+implemented -- rather, we have to resort to a sequence of integration efforts, to establish the
+core tenets of our envisioned architecture.
 
 
 Vertical Slices
diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt
index becc7813f..a5c390c0d 100644
--- a/doc/user/tutorials/building.txt
+++ b/doc/user/tutorials/building.txt
@@ -132,13 +132,14 @@ sudo make install
 GDL-mm: building and installing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The *GNOME Docking library* is available through your your package manager,
-but we additionally need the C++ bindings. Since these haven't made it into the
-standard repositories yet, we provide a suitable custom package here;
-the following shows how to build the latter
-
-Version limitation::
-  we rely on GTK-3 and thus need a compatible GDL-3.
+The *GNOME Docking library* was maintained, outside of the Gnome project,
+until 2021, mostly by the Anjuta people. It has dropped out of most distributions
+meanwhile, but is compatible with GTK-3 and can be built for the time being.
+We retain a copy of the repository and maintain a Debian package at Lumiera.org.
+Additionally we need the C++ bindings, which were created by _Fabien Parent_ and
+maintained 2009-2013; we likewise provide a repository and Debian package for
+these at Lumiera.org. These prerequisite libraries can be rebuilt with
+the steps described below.
 
 There is a dependency on `xmlto`, which is an xml converter. To install on Debian:
 
@@ -146,11 +147,22 @@ There is a dependency on `xmlto`, which is an xml converter. To install on Debia
 apt-get install xmlto
 ------------------------------------------------------------
 
+.building GDL
+------------------------------------------------------------
+git clone git://git.lumiera.org/debian/gdl
+cd gdl
+git checkout master
+./autogen.sh
+make
+sudo make install
+------------------------------------------------------------
+
+.building GDL-mm
 ------------------------------------------------------------
 git clone git://git.lumiera.org/debian/gdlmm
 cd gdlmm
-git checkout debian
-./configure
+git checkout master
+./autogen.sh
 make
 sudo make install
 ------------------------------------------------------------
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index f7fc71fb5..2e8851945 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -166597,7 +166597,8 @@ that situation will improve in forseeable future.
 
 
 
-
+
+
 
 
 
@@ -168824,8 +168825,9 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
+
 
 
 
@@ -169930,6 +169932,63 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
+
+
+
+
+  
+  
+    
      
+      Das ist im Grunde die Formulierung aus der DEB-Paketbeschreibung, also eine knappe Charakterisierung was Lumiera ist, aus Sicht eines prospektiven Benutzers.... Aber der erste Satz wirkt aufgebläht und auch der Hinweis auf auf den Status eines Development-Snapshot erscheint aufgebläht und etwas redundant.
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...denn das erscheint mir immer noch ziemlich aus der Zeit gefallen; mit gegenwärtiger Software kann man nichts sinnvolles anfangen ohne Internet-Connection; daher ist eine ausführliche Bauanleitung viel angebrachter auf der Website. Das README gibt nur eine Zusammenfassung...
+    
      
+    
        
+      
      • 
+        mit was man es zu tun hat
+      
        • 
+      
      • 
+        was man weiter noch braucht um den Code zu bauen
+      
        • 
+      
      • 
+        wo man mehr Informationen und Anleitungen findet
+      
        • 
+    
      
+  
+      
+
+      
+      
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -170304,7 +170363,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -171256,7 +171315,7 @@ actively maintained upstream. Please remove gdl from Debian.
 
 
 
-
+
 
 
 
@@ -171566,8 +171625,8 @@ Since then others have made contributions, see the log for the history.      
       
       
-
-
+
+
 
 
 
@@ -171603,11 +171662,12 @@ Since then others have made contributions, see the log for the history.      
       
       
-
+
 
-
+
 
-
+
+
 
 
 
@@ -171631,7 +171691,7 @@ Since then others have made contributions, see the log for the history.
       
       
-
+
 
 
 
@@ -171642,7 +171702,7 @@ Since then others have made contributions, see the log for the history.      
 
 
-
+
 
 
 
@@ -171718,15 +171778,17 @@ Since then others have made contributions, see the log for the history.      
       
       
-
+
 
+
 
 
 
 
 
-
+
 
+
 
 
   
@@ -171785,10 +171847,10 @@ Since then others have made contributions, see the log for the history.      
 
 
-
+
 
-
-
+
+
 
 
 
@@ -171877,9 +171939,12 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
+
+
+
 
 
 
@@ -171895,7 +171960,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -175140,7 +175205,7 @@ Since then others have made contributions, see the log for the history.      
 
 
-
+
 
 
 
@@ -177653,15 +177718,15 @@ Since then others have made contributions, see the log for the history.
 
 
-
-
+
+
 
 
 
 
 
-
-
+
+
 
 
 
@@ -179618,8 +179683,9 @@ Since then others have made contributions, see the log for the history.      
 
 
-
-
+
+
+
 
 
 
@@ -180646,7 +180712,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
   
@@ -180837,10 +180904,10 @@ Since then others have made contributions, see the log for the history.      
 
 
-
-
+
+
 
-
+
 
 
 
@@ -180896,7 +180963,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
   
   
@@ -181155,13 +181222,15 @@ Since then others have made contributions, see the log for the history.      
 
 
-
-
+
+
 
 
 
-
+
+
 
+
 
 
 
@@ -181373,8 +181442,9 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
+
 
 
   
@@ -181386,9 +181456,10 @@ Since then others have made contributions, see the log for the history.      
 
 
-
+
+
 
-
+
 
 
 
@@ -181404,7 +181475,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
 
@@ -181412,22 +181484,30 @@ Since then others have made contributions, see the log for the history.
 
 
-
-
+
+
+
+
+
 
 
 
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
 
 
 
 
-  
-    
-  
+  
   
     
      
       Bei den GUI-Icons gibt es ein app-icon.svg — aber das sieht unfertig/kaputt aus; vermutlich hat sich da Joel damals daran versucht, aber er ist daran gescheitert, daß das Lumiera-Logo sich nicht ohne Weiteres in ein Icon übersetzen läßt. Außerdem folgen diese SVGs ja einem ganz bestimmten Schema, und enthalten daher mehrere Varianten auf einem gemeinsamen »Canvas«
@@ -181437,9 +181517,7 @@ Since then others have made contributions, see the log for the history.
 
 
-  
-    
-  
+  
   
     
      
       Tja... damals hat man zwar ein Lumiera-Logo designt — aber dann würde noch die Arbeit ausstehen, daraus eine Design-Linie zu entwickeln, die in verschiedensten Größen und in verschiedenem Umfeld konsistent funktioniert. Und ersatzweise hat dann jeder für jeden Einzelfall seine Variante gebastelt (und ich mach ja auch nix Anderes)
@@ -181454,9 +181532,7 @@ Since then others have made contributions, see the log for the history.
 
 
-  
-    
-  
+  
   
     
      
       Deklarativität setzt etablierte Kategorien vorraus
@@ -181475,7 +181551,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -181515,7 +181591,9 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
+
 
 
 
@@ -181531,8 +181609,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
-
+
+
 
 
 
@@ -181556,6 +181634,7 @@ Since then others have made contributions, see the log for the history.
 
 
+
 
 
 

From 8601202be500ea9b81d2cde4646858fc7a5fb6a2 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sat, 22 Nov 2025 23:51:21 +0100
Subject: [PATCH 42/51] Release: rework and update the changelog

A handwritten changelog is considered important and
helps to single out the overall relevant achievements.
Following a proposal from the Debian policy, this summary
of development steps will now be maintained in the NEWS file.

It will be marked with the version number of Lumiera.
---
 NEWS                     | 66 ++++++++++++++++++++++++----------------
 admin/setVersion         |  1 +
 wiki/thinkPad.ichthyo.mm | 42 ++++++++++++++++++++++++-
 3 files changed, 82 insertions(+), 27 deletions(-)

diff --git a/NEWS b/NEWS
index 85053d59b..b083567c4 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,7 @@
 Lumiera -- Significant Changes
 ==============================
-:Date: 11/2015
+Version: 0.pre.04~rc.1
+:Date: 11/2025
 
 *************************************************************
 Lumiera is a non-linear video editing and compositing tool.
@@ -8,32 +9,39 @@ Lumiera is a non-linear video editing and compositing tool.
 NOTE: as of 11/2025, Lumiera is in early development stage;
 it is not usable yet. This is a preview Release of a
 current development snapshot in pre-alpha stage.
+*************************************************************
 
-Visit http://Lumiera.org and join the mailing list
-when interested in Lumiera planning and development.
-****************************************************************
+
+In the current stage of development, the focus is primarily on the
+overall integration of fundamental functionality at all levels of
+the code base.
 
 
 Lumiera pre-Alpha Versions
 --------------------------
 
-**This source tree doesn't yet contain a working video editing application** +
-Rather, it contains the framework and technology core
-of the envisioned Application ``Lumiera''.
-
-See http://issues.lumiera.org/roadmap[Project roadmap]
+As of _11/2025_ (0.pre.04)::
+This version is again motivated by a series of major upgrades and clean-up.
+Compilation now requires C++23 and Debian/Trixie is considered the reference
+platform. The GUI is connected to the core over an asynchronous messaging
+bus and the timeline display has been reshaped to accommodate flexibly
+nested structures of media content, instructed by the session through
+a series of _diff messages_. A scheduler has been implemented to drive
+the Render Engine, but the connection to the player and UI for output
+is yet unfinished.
 
 As of _11/2015_ (0.pre.03)::
-a lot of long standing maintennance work has been done. The Project switched
+A lot of long standing maintenance work has been done. The Project upgraded
 to C++11 and in the end even to C++14 and Debian/Jessie as reference platform,
-followed by clean-up of now obsolete workarounds. On the GUI side, we largely
-made the transition to GTK-3, which lead to rework of our timeline widget, not
-finished yet. This work also spured an effort the connection and communication
-between Proc and the UI, which is expected to be asynchroneous. Due to the
-limited developer resources, work on the Engine and Player part is stalled.
+followed by clean-up of workarounds now obsoleted. On the GUI side, we largely
+made the transition to GTK-3, which leads to a rework of our timeline widget,
+which is in progress but not finished yet. This work also spurred an effort
+to reorder the connection and communication between core and the UI, which
+is expected to be asynchronous. Due to the limited developer resources,
+work on the Engine and Player part is stalled.
 
 As of _10/2013_ (0.pre.02)::
-the data models have been elaborated and some significant parts of the session
+The data models have been elaborated and some significant parts of the session
 are finished. Work has continued with time handling, a draft of the output
 connection framework, a draft of the player subsystem and interfaces to the
 engine and processing network. Unfortunately there was a considerable slowdown
@@ -41,22 +49,28 @@ and decrease in team size, yet still the code base is growing towards 90k LOC.
 No tangible progress regarding the GUI and the backend.
 
 As of _1/2011_ (0.pre.01)::
-the project has created and documented a fairly consistent design,
-partially coded up -- starting from the technical foundations and working up.
+The project has created and documented a fairly consistent design,
+and some parts implemented -- progressing from the technical foundations.
 The code base is approaching 65k LOC. Roughly half of this is test code.
 The Application can be installed and started to bring up a GTK GUI framework,
-but the GUI is very preliminary and not connected to core functionality.
+but the GUI is rather preliminary and not connected to core functionality.
 The video processing pipeline exists only in the blueprints.
 
 As of _2/2008_::
-the project has been separated completely from ``Cinelerra'', the parent project.
+The project has been separated completely from Cinelerra, the parent project.
 The Community, which at that time was largely identical to the Cinelerra-CV community,
-choose the new project name ``Lumiera'' through a collaborative selection and vote.
-The basic project infrastructure is up and running, and work on the new codebase
-has started. We can show nothing beyond a test suite for some time to come.
+choose the new project name **Lumiera** through a collaborative selection and vote.
+The basic project infrastructure was established, and work on the new codebase
+was underway. It is clear that no results other than a test suite can be shown
+in the foreseeable future.
 
 As of _7/2007_::
-we started with the backend and render engine draft, some example code
-complemented by several unit tests. There is a TiddlyWiki with detailed
-design considerations and developer documentation and a UML model
+A group of volunteers has formed to address some longstanding issues and limitations
+of **Cinelerra**, which we all used for video editing tasks requiring professional quality.
+The plan was to restructure some central parts of the render engine: introduce a Builder
+for render pipelines and use Placements to control arrangement of clips and a unified
+Data-Backend to coordinate usage of system resources. These innovations would serve
+as anchor, with the intention to propose the reworked codebase as a new version
+of Cinelerra, in the hope of turning Cinelerra development into a more
+participatory process going forward.
 
diff --git a/admin/setVersion b/admin/setVersion
index ea95fe63b..1a60b7c55 100755
--- a/admin/setVersion
+++ b/admin/setVersion
@@ -40,5 +40,6 @@ rewrite doc/devel/Doxyfile        'PROJECT_NUMBER\s*=' "$VER"
 rewrite doc/devel/Doxyfile.browse 'PROJECT_NUMBER\s*=' "$VER"
 rewrite admin/scons/Setup.py      'VERSION\s*='        "\'$VER\'"
 rewrite README                    'Version:'           "$VER"
+rewrite NEWS                      'Version:'           "$VER"
 
 echo -e "\nSUCCESSFULLY rewritten version $VER\ncheck git diff\n\n"
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 2e8851945..ac0620652 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -169979,8 +169979,48 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
+
+
+  
+  
+    
      
+      ...ein Commit-Log einer größeren Applikation ist für sich allein nicht aussagekräftig; es muß in den Kontext gestellt werden durch ein offiziell verbindlich vorgegebenes Urteil wo das Projekt steht und wohin es sich bewegt.
+    
      
+  
+
+
+
+      
+
+
+
+
+
+
+  
+  
+    
      
+      alle diese Preview-Releases wurden bisher bedingt durch Änderungen im Kontext, wie z.B. der Umstand, daß ich allein die Zügel tatsächlich übernommen habe, oder der Upgrade auf eine neue Refernz-Plattform und höhere Sprachstandards. Zwar wollte ich das immer, aber es ist mir nie gelungen, diese Releases auch mit Erreichen eines Meilensteins zu koppeln. Zudem haben wir noch keinen der großen Meilensteine erreicht.
+    
      
+  
+      
+      
+
+
+
+  
+  
+    
      
+      NEWS sollte neben einem Datum auch die Versionsnummer tragen
+    
      
+  
+      
+
+
+
+
 
 
 

From 524dc61771181ed51c2df9fc576ed6077de1f372 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sun, 23 Nov 2025 02:23:30 +0100
Subject: [PATCH 43/51] Release: check and update licensing information

- use a current copy of the GPL2 text, downloaded from fsf.org
- reformat the AUTHORS and get rid of the table formatting
- Stackoverflow has upgraded its Subscriber Content license to CC-By-SA 4.0
---
 AUTHORS                  | 62 ++++++++++++++++++----------------------
 COPYING                  | 47 +++++++++++++++---------------
 LICENSE                  | 26 ++++++++++-------
 NEWS                     |  4 +--
 wiki/thinkPad.ichthyo.mm | 39 ++++++++++++++++++-------
 5 files changed, 98 insertions(+), 80 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index bf58ea89f..39bcf9045 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -3,43 +3,37 @@ Lumiera Authors and Credits
 :Date: 11/2025
 
 
-|==========================================
-|*Architecture*    |
-|                  | HERMANN VOSSELER
-|                  | CHRISTIAN THÄTER
-|                  | JOEL HOLDSWORTH
+Architecture::
+- Hermann Voßeler
+- Christian Thäter
+- Joel Holdsworth
 
-|*Workflow Concept*|
-|                  | HERMANN VOSSELER
-|                  | WOUTER VERWIJLEN
-|                  | CHRISTOPH VARGA
-|                  | BRIAN RYTEL
-|                  | CLAY BARNES
+Workflow Concept::
+- Hermann Voßeler
+- Wouter Verwijlen
+- Christoph Varga
+- Brian Rytel
+- Clay Barnes
 
 
-|                  |
-|                  |
-|*Core Developers* |
-|                  | HERMANN VOSSELER
-|                  | JOEL HOLDSWORTH
-|                  | CHRISTIAN THÄTER
-|*Programming*     |
-|                  | MICHAEL PLOUJNIKOV
-|                  | STEFAN KANGAS
-|                  | MICHAEL FISHER
-|                  | SIMEON VÖLKEL
+Core Developers::
+- Hermann Voßeler
+- Joel Holdsworth
+- Christian Thäter
+Programming::
+- Michael Ploujnikov
+- Stefan Kangas
+- Michael Fisher
+- Simeon Völkel
 
-|                  |
-|                  |
-|*Documentation*   |
-|                  | HERMANN VOSSELER
-|                  | CHRISTIAN THÄTER
-|                  | ODIN HØRTHE OMDAL
-|                  | SIMEON VÖLKEL
-|                  | MANO STIENEN
-|                  | HENDRIK BOOM
-|                  | BENNY LYONS
-|==========================================
+Documentation::
+- Hermann Vosseler
+- Christian Thäter
+- Odin Hørthe Omdal
+- Simeon Völkel
+- Mano Stienen
+- Hendrik Boom
+- Benny Lyons
 
 
 
@@ -61,7 +55,7 @@ The Lumiera project feels especially obliged to::
 
 Further Credits
 ---------------
-- inspirations and some UI components were taken from http://Ardour.org[Ardour]
+- inspirations and some UI components were taken from https://ardour.org/[Ardour]
 
 - https://github.com/x42/xjadeo[xjadeo] by Robin Gareus was very helpful
   for learning how to output raw video from a desktop application
diff --git a/COPYING b/COPYING
index eeb586b39..227b449d5 100644
--- a/COPYING
+++ b/COPYING
@@ -1,12 +1,12 @@
-		    GNU GENERAL PUBLIC LICENSE
-		       Version 2, June 1991
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 2, June 1991
 
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
+ 
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 
-			    Preamble
+                            Preamble
 
   The licenses for most software are designed to take away your
 freedom to share and change it.  By contrast, the GNU General Public
@@ -15,7 +15,7 @@ software--to make sure the software is free for all its users.  This
 General Public License applies to most of the Free Software
 Foundation's software and to any other program whose authors commit to
 using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
+the GNU Lesser General Public License instead.)  You can apply it to
 your programs, too.
 
   When we speak of free software, we are referring to freedom, not
@@ -55,8 +55,8 @@ patent must be licensed for everyone's free use or not licensed at all.
 
   The precise terms and conditions for copying, distribution and
 modification follow.
-
-		    GNU GENERAL PUBLIC LICENSE
+
+                    GNU GENERAL PUBLIC LICENSE
    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
 
   0. This License applies to any program or other work which contains
@@ -110,7 +110,7 @@ above, provided that you also meet all of these conditions:
     License.  (Exception: if the Program itself is interactive but
     does not normally print such an announcement, your work based on
     the Program is not required to print an announcement.)
-
+
 These requirements apply to the modified work as a whole.  If
 identifiable sections of that work are not derived from the Program,
 and can be reasonably considered independent and separate works in
@@ -168,7 +168,7 @@ access to copy from a designated place, then offering equivalent
 access to copy the source code from the same place counts as
 distribution of the source code, even though third parties are not
 compelled to copy the source along with the object code.
-
+
   4. You may not copy, modify, sublicense, or distribute the Program
 except as expressly provided under this License.  Any attempt
 otherwise to copy, modify, sublicense or distribute the Program is
@@ -225,7 +225,7 @@ impose that choice.
 
 This section is intended to make thoroughly clear what is believed to
 be a consequence of the rest of this License.
-
+
   8. If the distribution and/or use of the Program is restricted in
 certain countries either by patents or by copyrighted interfaces, the
 original copyright holder who places the Program under this License
@@ -255,7 +255,7 @@ make exceptions for this.  Our decision will be guided by the two goals
 of preserving the free status of all derivatives of our free software and
 of promoting the sharing and reuse of software generally.
 
-			    NO WARRANTY
+                            NO WARRANTY
 
   11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
@@ -277,9 +277,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
 POSSIBILITY OF SUCH DAMAGES.
 
-		     END OF TERMS AND CONDITIONS
-
-	    How to Apply These Terms to Your New Programs
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
 
   If you develop a new program, and you want it to be of the greatest
 possible use to the public, the best way to achieve this is to make it
@@ -291,7 +291,7 @@ convey the exclusion of warranty; and each file should have at least
 the "copyright" line and a pointer to where the full notice is found.
 
     
-    Copyright (C) 19yy  
+    Copyright (C)   
 
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
@@ -303,17 +303,15 @@ the "copyright" line and a pointer to where the full notice is found.
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     GNU General Public License for more details.
 
-    You should have received a copy of the GNU General Public License
-    along with this program; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-
+    You should have received a copy of the GNU General Public License along
+    with this program; if not, see .
 
 Also add information on how to contact you by electronic and paper mail.
 
 If the program is interactive, make it output a short notice like this
 when it starts in an interactive mode:
 
-    Gnomovision version 69, Copyright (C) 19yy name of author
+    Gnomovision version 69, Copyright (C) year name of author
     Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
     This is free software, and you are welcome to redistribute it
     under certain conditions; type `show c' for details.
@@ -330,11 +328,12 @@ necessary.  Here is a sample; alter the names:
   Yoyodyne, Inc., hereby disclaims all copyright interest in the program
   `Gnomovision' (which makes passes at compilers) written by James Hacker.
 
-  , 1 April 1989
-  Ty Coon, President of Vice
+  , 1 April 1989
+  Moe Ghoul, President of Vice
 
 This General Public License does not permit incorporating your program into
 proprietary programs.  If your program is a subroutine library, you may
 consider it more useful to permit linking proprietary applications with the
-library.  If this is what you want to do, use the GNU Library General
+library.  If this is what you want to do, use the GNU Lesser General
 Public License instead of this License.
+
diff --git a/LICENSE b/LICENSE
index aa23fae45..6c52ed1b9 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,9 +1,15 @@
 - the *Lumiera* source code is (C) by the original authors (see `AUTHORS`)
 +
 -----------------------------------------------------------------------------
-Lumiera is free software -- you may use and redistribute it under the
-Terms and conditions of the GNU GENERAL PUBLIC LICENSE (GPL); 
-either version 2 of the License, or (at your option) any later version.
+Lumiera is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License,
+or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+See the GNU General Public License for more details.
 
 For a copy of the GPL Version 2 see the file COPYING
 -----------------------------------------------------------------------------
@@ -11,14 +17,14 @@ For a copy of the GPL Version 2 see the file COPYING
 
 
 - Website, design documents and accompanying materials are covered by
-  the same license as the source code, +
-  in addition they are also dual-licensed under *CC-By-SA 3*
+  the same license as the source code (GPL2+), +
+  in addition they are also dual-licensed under *CC-By-SA 4*
 
 
-- at various places, the implementation draws on solutions
-  and comments published at http://Stackoverflow.com[Stackoverflow] --
-  according to the http://stackexchange.com/legal[License Agreement] page,
-  any ``subscriber content'' on that site is provided under *CC-By-SA 3*..
+- at various places, the implementation draws on solutions and comments
+  published at http://Stackoverflow.com[Stackoverflow] -- according to the
+  https://stackoverflow.com/legal/terms-of-service/public#licensing[License Agreement],
+  any ``subscriber content'' on that site is provided under *CC-By-SA 4*.
   We attribute significant usages of solutions published this way
   in the doxygen comments of the relevant source code entities.
 
@@ -27,7 +33,7 @@ For a copy of the GPL Version 2 see the file COPYING
   *The Loki Library*  (C) 2001 by *Andrei Alexandrescu*
 +
 -----------------------------------------------------------------------------
-Loki is governed by a MIT-License. See: http://loki-lib.sourceforge.net
+Loki is governed by a MIT-License. See: https://sourceforge.net/projects/loki-lib/
 Permission to use, copy, modify, distribute and sell this software for any
 purpose is hereby granted without fee, provided that the above copyright
 notice appear in all copies and that both that copyright notice and this
diff --git a/NEWS b/NEWS
index b083567c4..c987e0570 100644
--- a/NEWS
+++ b/NEWS
@@ -31,8 +31,8 @@ the Render Engine, but the connection to the player and UI for output
 is yet unfinished.
 
 As of _11/2015_ (0.pre.03)::
-A lot of long standing maintenance work has been done. The Project upgraded
-to C++11 and in the end even to C++14 and Debian/Jessie as reference platform,
+A lot of long standing maintenance work has been done.
+The Project upgraded to C++14 and Debian/Jessie as reference platform,
 followed by clean-up of workarounds now obsoleted. On the GUI side, we largely
 made the transition to GTK-3, which leads to a rework of our timeline widget,
 which is in progress but not finished yet. This work also spurred an effort
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index ac0620652..dc16e97f3 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -169932,9 +169932,9 @@ that situation will improve in forseeable future.
 
 
 
-
-
-
+
+
+
 
 
 
@@ -170022,11 +170022,30 @@ that situation will improve in forseeable future.
 
 
 
-
-
+
+
 
-
-
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      Das hab ich neulich schon im Rahmen der Website überlegt und so beschlossen; ich kann das Aggregat re-lizensieren unter einer kompatiblen Lizenz (eigentlich könnte man das auch für GPL2+ ⟶ GPL3+ so machen). Auch Stackoverfow hat seine Lizenz für »Subscriber Content« auf CC-By-SA 4.0 gehoben
+    
      
+  
+      
+      
       
       
 
@@ -181267,8 +181286,8 @@ Since then others have made contributions, see the log for the history.
       
 
-
-
+
+
 
 
 
@@ -181674,7 +181693,7 @@ Since then others have made contributions, see the log for the history.
       
 
-
+
 
 
 

From ceceaf4ece70d5873fd6952a8bd6971c4c0e93ac Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Sun, 23 Nov 2025 23:47:24 +0100
Subject: [PATCH 44/51] Release: compile authorship information

Some recherche regarding the requirements and conditions of the GPL
made it clear that we are obliged to have at least an summary statement
of all authors and the years of their contributions embedded somewhere
in the source itself. The Git history alone is not sufficient to fulfil
this requirement, since a code base could be packaged as Tarball
and passed-on outside of any Git repository.

Thus I propose the following policy
- add yourself to the copyright header whenever you made
  some ''significant'' contribution to a code file
- maintain a list of relevant authors at top-level,
  indicating a time range of their contribution
- use the same information also in the debian/copyright (DEB package)
- clarify in the LICENSE that authorship can be extracted from Git

__Remark__: Anton Yakovlev made a single code contribution in 2009 (87e528bd),
which was never used anywhere and removed as part of a general clean-up in 2023.
Thus I do not list him as a code author, but he is mentioned in credits.txt
---
 AUTHORS                                 |  14 +-
 LICENSE                                 |  36 ++-
 NEWS                                    |   4 +
 doc/devel/rfc/RefactorLiblumieraOut.txt |  16 +-
 src/lib/lifecycle.cpp                   |   2 +-
 src/lib/lifecycleregistry.hpp           |   2 +-
 src/stage/widget/button-bar.cpp         |   1 +
 src/stage/widget/button-bar.hpp         |   1 +
 src/stage/widget/menu-button.cpp        |   1 +
 src/stage/widget/menu-button.hpp        |   1 +
 src/stage/widget/panel-bar.cpp          |   1 +
 src/stage/widget/panel-bar.hpp          |   1 +
 src/steam/common.hpp                    |   2 +-
 wiki/thinkPad.ichthyo.mm                | 372 ++++++++++++++++++++++--
 14 files changed, 408 insertions(+), 46 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index 39bcf9045..47be52115 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -17,14 +17,14 @@ Workflow Concept::
 
 
 Core Developers::
-- Hermann Voßeler
-- Joel Holdsworth
-- Christian Thäter
+- 2007-2025 Hermann Voßeler
+- 2008-2009 Joel Holdsworth
+- 2007-2011 Christian Thäter
 Programming::
-- Michael Ploujnikov
-- Stefan Kangas
-- Michael Fisher
-- Simeon Völkel
+- 2007-2010 Michael Ploujnikov
+- 2010-2011 Stefan Kangas
+- 2010-2012 Michael Fisher
+- 2007-2008 Simeon Völkel
 
 Documentation::
 - Hermann Vosseler
diff --git a/LICENSE b/LICENSE
index 6c52ed1b9..29de74adb 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,4 +1,18 @@
-- the *Lumiera* source code is (C) by the original authors (see `AUTHORS`)
+Lumiera is Free Software
+========================
+:Date: 11/2025
+
+This source tree or package is based on various contributions
+and its use is permitted under the conditions of the *GNU General Public License*
+
+
+- the *Lumiera* source code is copyrighted and licensed by the original authors
++
+--
+  * (c) 2007-2025 Hermann Voßeler
+  * (c) 2007-2011 Christian Thäter
+  * (c) 2008-2009 Joel Holdsworth
+--
 +
 -----------------------------------------------------------------------------
 Lumiera is free software; you can redistribute it and/or modify it
@@ -16,8 +30,24 @@ For a copy of the GPL Version 2 see the file COPYING
 
 
 
-- Website, design documents and accompanying materials are covered by
-  the same license as the source code (GPL2+), +
+- The full source code can always be retrieved from
+  https://git.lumiera.org/?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`]
+
+  * there are a lot of additional authors, which all hold copyright
+    on their respective contributions made under this license;
+    see the copyright statements of individual files
+
+  * furthermore, a full list of contributors can be retrieved
+    from the Git repository:
+
+      git log --format="\"%an <%ae>\",%ad" --date=short HEAD
+
+  * see also the file `AUTHORS`
+
+
+
+- Website, design documents and accompanying materials are covered
+  by the same license as the source code (GPL2+),  +
   in addition they are also dual-licensed under *CC-By-SA 4*
 
 
diff --git a/NEWS b/NEWS
index c987e0570..d7b6a1e1c 100644
--- a/NEWS
+++ b/NEWS
@@ -9,9 +9,13 @@ Lumiera is a non-linear video editing and compositing tool.
 NOTE: as of 11/2025, Lumiera is in early development stage;
 it is not usable yet. This is a preview Release of a
 current development snapshot in pre-alpha stage.
+
+Source code and a list of all contributors can be retrieved
+from `git://git.lumiera.org/LUMIERA`
 *************************************************************
 
 
+
 In the current stage of development, the focus is primarily on the
 overall integration of fundamental functionality at all levels of
 the code base.
diff --git a/doc/devel/rfc/RefactorLiblumieraOut.txt b/doc/devel/rfc/RefactorLiblumieraOut.txt
index 3b4eea822..6a5d07cea 100644
--- a/doc/devel/rfc/RefactorLiblumieraOut.txt
+++ b/doc/devel/rfc/RefactorLiblumieraOut.txt
@@ -19,9 +19,9 @@ which is already in use by other projects
 Description
 -----------
 //description: add a detailed description:
-Over the time we've put some efforts into the liblumiera. I have added
+Over the time we've put some efforts into the 'liblumiera'. I have added
 some from my code which predates the Lumiera project and which I am using
-on many other projects. This means that I would have to maintain thsese
+on many other projects. This means that I would have to maintain these
 sources in different unrelated projects and have to cross merge and update
 several copies of the same code when I do updates and fixes somewhere.
 I think its time to factor the re-useable parts out into a independent
@@ -48,13 +48,13 @@ For myself I need the C parts, while there is C\++ code which interfaces to the
 C implementations and also a lot code which does nice C\++ things on its own.
 This possibly means that we should in fact make 2 packages out of this, one C
 and one C\++ library (where the C++ part is more than just the wrappers, but
-also the tools and tricks which are currently in 'src/lib/' and reuseable).
+also the tools and tricks which are currently in 'src/lib/' and reusable).
 
 .Who maintains it
 Despite of being a spin-off I think we don't want to change anything from our
 current practice and maintain it by the Lumiera developers. In part I feel
 responsible for it, while it is really a part of the Lumiera codebase,
-despite of being independently useable.
+despite of being independently usable.
 
 .How to maintain it
 We need to decide about build system and documentation system. As build system
@@ -79,7 +79,7 @@ What belongs to the library
 Containers
 ++++++++++
  * cuckoo hashing (cuckoo.c|h)
- * linked lists (llist.h slist.h)
+ * linked lists (llist.h)
  * cache lists (mrucache.c|h)
  * splay trees (psplay.c|h)
  * priority queues (not done yet)
@@ -87,7 +87,7 @@ Containers
 Runtime tools
 +++++++++++++
  * error handling (error.h error.c) used by the other facilities too
- * clib convinience wrapers (safeclib.c|h) needs better name, maybe refactor
+ * clib convenience wrappers (safeclib.c|h) needs better name, maybe refactor
    into new facilities
 
 Multithreading
@@ -101,7 +101,7 @@ Memory management
 
 Metaprogramming
 +++++++++++++++
-  * preprecessor tools (ppmpl.h) move common preprocessor macros here
+  * preprocessor tools (ppmpl.h) move common preprocessor macros here
   * polymorphic call helper for C (vcall.h)
 
 Interface system and module loader
@@ -183,7 +183,7 @@ Tasks
 // * first step ([green]#✔ done#)
 
  * decide on name, namespaces [,yellow]#WIP#
- * create git repository, setup boilerplace (build system, legalese)
+ * create git repository, setup boilerplate (build system, legalise)
    [,yellow]#WIP#
  * move all code over into the git repos, refactor (namespace renames) ()
    [,yellow]#WIP#
diff --git a/src/lib/lifecycle.cpp b/src/lib/lifecycle.cpp
index f7c92513f..5d38e7090 100644
--- a/src/lib/lifecycle.cpp
+++ b/src/lib/lifecycle.cpp
@@ -2,7 +2,7 @@
   Lifecycle  -  registering and triggering lifecycle callbacks
 
    Copyright (C)
-     2008,            Hermann Vosseler 
+     2008,2017        Hermann Vosseler 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/lib/lifecycleregistry.hpp b/src/lib/lifecycleregistry.hpp
index 2fedc89fc..912aec541 100644
--- a/src/lib/lifecycleregistry.hpp
+++ b/src/lib/lifecycleregistry.hpp
@@ -3,7 +3,7 @@
 
    Copyright (C)
      2008,            Christian Thaeter 
-                        Hermann Vosseler 
+     2008,            Hermann Vosseler 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/stage/widget/button-bar.cpp b/src/stage/widget/button-bar.cpp
index 3ededa5f5..e223b61c6 100644
--- a/src/stage/widget/button-bar.cpp
+++ b/src/stage/widget/button-bar.cpp
@@ -3,6 +3,7 @@
 
    Copyright (C)
      2009,            Joel Holdsworth 
+     2012,            Michael R. Fisher 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/stage/widget/button-bar.hpp b/src/stage/widget/button-bar.hpp
index 8ba260563..306333e98 100644
--- a/src/stage/widget/button-bar.hpp
+++ b/src/stage/widget/button-bar.hpp
@@ -3,6 +3,7 @@
 
    Copyright (C)
      2009,            Joel Holdsworth 
+     2012,            Michael R. Fisher 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/stage/widget/menu-button.cpp b/src/stage/widget/menu-button.cpp
index 4a108431d..6d5c7a785 100644
--- a/src/stage/widget/menu-button.cpp
+++ b/src/stage/widget/menu-button.cpp
@@ -3,6 +3,7 @@
 
    Copyright (C)
      2008,            Joel Holdsworth 
+     2012,            Michael R. Fisher 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/stage/widget/menu-button.hpp b/src/stage/widget/menu-button.hpp
index 39c19e9ef..6e668b279 100644
--- a/src/stage/widget/menu-button.hpp
+++ b/src/stage/widget/menu-button.hpp
@@ -3,6 +3,7 @@
 
    Copyright (C)
      2008,            Joel Holdsworth 
+     2012,            Michael R. Fisher 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/stage/widget/panel-bar.cpp b/src/stage/widget/panel-bar.cpp
index f825dedf1..5d4576cd3 100644
--- a/src/stage/widget/panel-bar.cpp
+++ b/src/stage/widget/panel-bar.cpp
@@ -3,6 +3,7 @@
 
    Copyright (C)
      2009,            Joel Holdsworth 
+     2012,            Michael R. Fisher 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/stage/widget/panel-bar.hpp b/src/stage/widget/panel-bar.hpp
index 57da211e6..b9b0a6330 100644
--- a/src/stage/widget/panel-bar.hpp
+++ b/src/stage/widget/panel-bar.hpp
@@ -3,6 +3,7 @@
 
    Copyright (C)
      2009,            Joel Holdsworth 
+     2012,            Michael R. Fisher 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/src/steam/common.hpp b/src/steam/common.hpp
index 7ff496872..acb66319d 100644
--- a/src/steam/common.hpp
+++ b/src/steam/common.hpp
@@ -4,7 +4,7 @@
 
    Copyright (C)
      2008,            Christian Thaeter 
-                        Hermann Vosseler 
+     2008,            Hermann Vosseler 
 
   **Lumiera** is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index dc16e97f3..2cfafb541 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -160419,6 +160419,186 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Das ist der virale Mechanismus.
+    
      
+    
      
+      Er gilt nicht für die Hinzufügungen allein, denn diese können auch sonstwie unter beliebigen Bedingungen lizenziert werden (das heißt, man verliert nicht sein Copyright an seinem eigenen Werk, aber man erwirbt auch keine Rechte an den Werken andere Leute, jenseits dieser LIzenz)
+    
      
+  
+      
+
+      
+
+
+
+
+  
+  
+    
      
+      ...schließt den Fall ein daß man lediglich ein Compilat bereitstellt (auch das gilt als abgeleitetes Werk)
+    
      
+  
+      
+
+
+  
+  
+    
      
+      im Besonderen: klarstellen daß das Werk unter diese Lizenz fällt
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Hier gibt es diverse Varianten in der Lizenz, denn die Software kann auch Teil eines Produktes sein, sogar Teil einer Hardware. In diesem Fall muß ein Service für mindestens 3 Jahre geboten werden (oder so lange wie man Wartung und Reparatur bietet), über den man erfahren kann, wie man an den Quellcode kommt. Der Quellcode kann auch duch jemand Anderes bereitgestellt werden, aber man selber hat sicherzustellen, daß dies der Fall ist, solange man das Produkt anbietet oder wartet
+    
      
+  
+      
+      
+      
+      
+      
+
+
+
+
+  
+  
+    
      
+      Aber die Einzel-Statements sind wichtig für den Fall, daß jemand einzelne Files aus der Distribution herausnimmt und separat weiterverbreitet. Solange die Files in der Gesamtdistribution bleiben, genügt ein einziges zentrales Lizenz-Statement, das jedoch mit allen Einzel-Lizenzen kompatibel sein muß.
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      Der Copyright-Claim weist auf das Urheberrecht hin, das man gemäß Konvention von Bern automatisch erlangt, für typischerweise 70Jahre nach dem Tod. Dieses Recht bildet das Fundament, warum der Code überhaupt unter eine Lizenz fallen kann. Deshalb muß mindestens ein tragfähriger Copyritght-Claim gegeben sein
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+  
+  
+    
      
+      Diese Regelung zielt erkenntlich auf die »industriselle Praxis«: dort ist den Leuten alles egal,  wofür sie nicht bezahlt und wozu sie nicht geprügelt wurden. Da bekommt man dann (ist mir selbst oft genug passiert) irdend ein Zip-File hingerotzt, und weiß nicht einmal, ob das Executable, das auf dem Server installiert wurde, wirklich aus diesem Quellcode stammt. Die GPL bietet in diesem Fall einen zusätzlichen Hebel, nicht zuletzt auch um die Reputation einer Quelle aus FreeSoftware zu schützen.
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      Man muß jederzeit erkennen können...
+    
      
+    
        
+      
      • 
+        auf welchem Ursprungsrecht (Copyright-Claim) die Lizenz fußt
+      
        • 
+      
      • 
+        welche Lizenz nun effektiv gültig ist
+      
        • 
+      
      • 
+        wer sonst noch Änderungen vorgenommen hat und damit Copyright haben könnte
+      
        • 
+      
      • 
+        Datum der Änderungen summarisch (⟹ verlängert Gültigkeit der LIzenz 70Jahre nach dem Tod)
+      
        • 
+    
      
+  
+      
+      
+      
+      
+
+
+
+
+  
+  
+    
      
+      Jede Verletzung einer Pflicht terminiert die Lizenz, zunächst vorläufig. Allerdings handelt es sich um Vertragsrecht, und desshalb müßte die Aktion von einem Upstream-Rechteinhaber ausgehen...
+    
      
+  
+      
+
+
+
+  
+  
+    
      
+      Vorrausseztung ist, daß man schnellstmöglich die Versäumnisse nachholt (in weniger als 30 Tagen nach Bekanntwerden des Mißstandes). Dennoch können binnen 60 Tagen nach dem Start des Heilversuchs beliebige Upstream-Copyright-Holder ihre Lizenz terminieren und haben dann allerdings nur ihren eigenen Anteil am Werk als Hebel zur Verfügung. Sofern sie dies nicht (binnen 60 Tagen) von sich aus tun, wird die Lizenz durch den Heilungsversuch automatisch wiederhergestellt
+    
      
+  
+      
+      
+
+
+  
+  
+    
      
+      selbst wenn ich Fehler mache, und dadurch meine Lizenz verliere, können die Copyright-Holder sich nur bei mir bedienen, aber nicht weitere User in die Pflicht nehmen, die ihre Lizenz durch mich erlangt haben, solange sie im Glauben waren, diese Lizenz sei gültig.
+    
      
+  
+      
+      
+      
+
+
+
+  
+  
+    
      
+      Das gilt nur für die GPL-3 und auch nur für Patent-Claims, die ein Nutzer oder Contributor geltend machen könnte; die Lizenz schützt im Besonderen nicht vor Patent-Claims Dritter
+    
      
+  
+      
+      
+      
+      
       
       
 
@@ -169932,7 +170112,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -170036,9 +170216,7 @@ that situation will improve in forseeable future.
 
 
 
-  
-    
-  
+  
   
     
      
       Das hab ich neulich schon im Rahmen der Website überlegt und so beschlossen; ich kann das Aggregat re-lizensieren unter einer kompatiblen Lizenz (eigentlich könnte man das auch für GPL2+ ⟶ GPL3+ so machen). Auch Stackoverfow hat seine Lizenz für »Subscriber Content« auf CC-By-SA 4.0 gehoben
@@ -171700,7 +171878,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
 
@@ -178239,6 +178418,10 @@ Since then others have made contributions, see the log for the history.
 
 
+
+
+
+
 
 
 
@@ -179902,12 +180085,36 @@ Since then others have made contributions, see the log for the history.
 
 
-
-
-
+
+
+
+
+
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -181276,20 +181483,20 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
 
-
+
 
-
+
 
 
-
+
 
-
-
+
+
 
 
 
@@ -181655,7 +181862,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
 
@@ -181665,7 +181873,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -181673,7 +181881,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
 
@@ -181691,15 +181900,116 @@ Since then others have made contributions, see the log for the history.
 
 
+
+
+  
+  
+    
      
+      Das ist expizit erlaubt und stellt ein Statement für die Codebasis als Sammel-Veröffentlichung dar; diese Angabe ersetzt nicht die Angaben für die Files, aber stellt eine (damit zwingend kompatible) Veröffentlichung eines Sammelwerks dar, welches damit ein vereinfachtes Handle bietet für die Weiterverbreitung (und insofern dann zumindest die Einzel-Lizenzen überlagert). Bezüglich der Attributierung ist die GPL ja nicht so streng wie die CC oder Apache
+    
      
+  
+
       
-
+
+
 
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      ...ist mir aber schon neulich aufgefallen, beim Aufbereiten der Daten für die Historien-Seite. Joel war also noch gut 1 1/2 Jahre formal im Projekt mit dabei, und hat an Meetings teilgenommen, bis er sich offiziell verabschiedet hat
+    
      
+  
+      
+      
+      
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      das Alsa-Experiment, was unfertig ist und nur funktioniert wenn die Soundkarte zwei Kanäle hat und 16 Bit erwartet (also bei mir funktioniert es schon mal nicht deshalb). Allerdings ist das Experiment bis heute im Code, als lumiera-output-probe.
+    
      
+  
+      
+      
+
+
+
+
+
+
+
+
+
+  
+  
+    
      
+      In der aktuellen Codebasis ist kein Code von ihm (mehr) enthalten, und sein Code wurde nie verwendet. Sein Beitrag ist auf der »Credits« page gewürdigt, allerdings auch da nur unter "IRC crew"
+    
      
+  
+      
+
+
+      
+      
+
+
+
+
+
+  
+  
+    
      
+      Die Authorschaft am Code hat rechtliche Relevanz, denn sie begründet eine Lizenz und auch ein Veto-Recht im Falle einer intendierten Lizenz-Änderung (z.B. Kommerzialisierung). Auf diesem Hintergrund halte ich es nicht sinnvoll, jemanden als "Code-Author" zu führen, der keinen signifikante  Beitrag zum Code geleistet hat, denn Copyright setzt eine gewisse »Schöpfungshöhe« vorraus.
+    
      
+  
+      
+
+
+      
+      
+      
+
+
+  
+  
+    
      
+      Die Zeiträume des Copyright mit aufgeführt, und explizit auf das Git-Repo verwiesen, den allgemeinen Einsichten gemäß, die ich heute über die Wirkungsweise des GPL-Copyright gewonnen habe: Zeitpunkt und Autoren-Namen müssen für die GPL verbindlich mitgeführt werden, es ist aber nicht eigens eine »Attribution« notwendig (jedoch die Git-Historie allein genügt nicht, sondern die summarische Info muß auch irgendwo im Content zu finden sein)
+    
      
+  
+      
+
       
       
       
@@ -181708,7 +182018,19 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
+
+
+
+
+
+
+
+
+
+
+
 
   
   

From 3812c801fbfcfd8f92ee3b2fc17983ce843c2cbe Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Mon, 24 Nov 2025 22:03:11 +0100
Subject: [PATCH 45/51] Build: ensure that installed shared libs are not
 executable

This is a Debian policy, which collides with the default behaviour
of GCC rsp. the plattform linker. The latter creates all ELF files as
executable, possibly because some platforms require that, and also
because some libraries provide a main() function for diagnostics.

The argument by the Debian people is that most libraries don't provide
such a main() and that this is an esoteric feature which should not be
supported by default.

We can fix that in our SCons build, since we use a specialised Builder
to also define the install targets systematically; it suffices to add
a post-action to these install targets for shared objects.

Note: currently Debian/Trixie provides SCons 4.8, but v4.10 will provide
a shorthand notation with the env.Chmod Action factory.
---
 admin/scons/LumieraEnvironment.py |  22 ++-
 wiki/thinkPad.ichthyo.mm          | 299 +++++++++++++++++++++++++++++-
 2 files changed, 316 insertions(+), 5 deletions(-)

diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py
index 99a10199f..196b619a1 100644
--- a/admin/scons/LumieraEnvironment.py
+++ b/admin/scons/LumieraEnvironment.py
@@ -320,7 +320,7 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder):
             Lumiera modules; modules are assumed to reside in a subdirectory below the executable.
         """
         custEnv = lumiEnv.Clone()
-        custEnv.Append(LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw))
+        custEnv.Append( LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw))
         custEnv.Append( LINKFLAGS = "-Wl,-rpath=\\$$ORIGIN/../modules,--enable-new-dtags" )
         if 'addLibs' in kw:
             custEnv.Append(LIBS = kw['addLibs'])
@@ -330,6 +330,26 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder):
     def getInstallDestination(self, lumiEnv): return lumiEnv.path.installLib
     
     
+    def installTarget(self, env, buildTarget, **kw):
+        """ ensure a shared library is not marked executable.
+            The default toolchain on Linux often installs shared libraries as executable, which seems
+            to be necessary on some arcane Unix platforms. However, Debian Policy prohibits that.
+            See https://unix.stackexchange.com/questions/400187/why-should-or-should-not-shared-libraries-be-executable-e-g-red-hat-vs-debian
+        """
+        toInstall = super().installTarget(env, buildTarget, **kw)
+        if toInstall:
+            def _Chmod(target, source, env):
+                """ Workaround since env.Chmod is present only in SCons 4.10 """
+                import os
+                for t in target:
+                    os.chmod(str(t), 0o644)
+                return None
+#           removeExecBit = env.Chmod(toInstall, 0o644)
+            msg = '....... clear exec perm %s' % [str(t) for t in toInstall]
+            removeExecBit = env.Action(_Chmod, msg)
+            env.AddPostAction(toInstall, removeExecBit)
+        return toInstall
+    
     def defineSoname (self, target, **kw):
         """ internal helper to extract or guess
             a suitable library SONAME, either using an
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 2cfafb541..79190b7ce 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -159320,6 +159320,34 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -178649,6 +178677,268 @@ Since then others have made contributions, see the log for the history.
       
       
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      der verhält sich nach dem Motto: »schad ja nix«...
+    
      
+    
      
+      Auf einigen esoterischen Platformen müssen Shared-Libs tatsächlich executable sein, und auf allen anderen Plattformen wird das Flag ignoriert
+    
      
+  
+
+      
+      
+
+
+  
+    
+  
+  
+    
      
+      Es ist nämlich so: Shared-Libs können eine main()-Funktion enthalten; und wenn das der Fall ist, können sie auch als Executables aufgerufen werden. Rein theoretisch könnte das ein Baustein in einem komplexen Exploit sein, der aus einer überraschenden Ecke käme, da das ein Thema ist, was niemand »auf dem Radar hat«. Manche Libraries haben in der Tat ein Main, und das macht typischerweise gewisse Diagnose-Funktionalität.
+    
      
+    
      
+      
+    
      
+    
      
+      Klingt alles doch einigermaßen an den Haaren herbeigezogen, aber Debian stellt sich auf den Standpunkt: Unnötiges verbieten schad' nix
+    
      
+  
+
+      
+      
+
+
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      ...das liegt daran, daß ich das Bauen von Executables und Libraries und Plugins bereits hochgradig customised habe, im LumieraEnvironment. Das bedeutet, es gibt bereits einen env.Install()-Aufruf, tief in Lumiera-spezifischem Framework-Code. Genau diesen Aufruf muß ich nun so modifizieren, daß entweder davor oder danach noch die Permissions geändert werden.
+    
      
+  
+
+      
+
+
+
+
+  
+    
+  
+  
+    
      
+      Use one of these approaches: chain actions in a single Command, or install first then attach a post-action (via AddPostAction  or Command on the installed node). Both keep the install and chmod as a single build step.
+    
      
+    
      
+    
+
+    
      
+      Examples
+    
      
+    
        
+      
      • 
+        Chain actions in a single Command (recommended when you want one target built by a composed action):
+      
        • 
+    
      
+    
      
+    
      
+      
      
+        py
+      
      
+    
      
+    
      env.Command(
+    target = '$INSTDIR/myfile',
+    source = 'myfile',
+    action = [
+        env.Install('$INSTDIR', '$SOURCE'),
+        SCons.Action.Action('chmod 0644 $TARGET')
+    ]
+)
      
+    
        
+      
      • 
+        Install then add a post-action to change permissions (clear intent, uses SCons helpers):
+      
        • 
+    
      
+    
      
+    
      
+      
      
+        py
+      
      
+    
      
+    
      installed = env.Install('$INSTDIR', 'myfile')
+env.AddPostAction(installed, SCons.Action.Action('chmod 0644 $TARGET'))
      
+    
        
+      
      • 
+        Install then use the built-in Chmod builder on the installed node:
+      
        • 
+    
      
+    
      
+    
      
+      
      
+        py
+      
      
+    
      
+    
      installed = env.Install('$INSTDIR', 'myfile')
+env.Chmod(installed[0], 0o644)
      
+    
      
+    
+
+    
      
+      Tips & Alternatives
+    
      
+    
        
+      
      • 
+        Prefer env.Command when you need a single atomic step that both installs and changes permissions.
+      
        • 
+      
      • 
+        Use AddPostAction when you want to keep the install separate and express a follow-up operation.
+      
        • 
+      
      • 
+        env.Chmod is a portable, Python-level builder; string chmod  commands rely on the shell/OS.
+      
        • 
+    
      
+  
+
+      
+
+
+
+  
+    
+  
+  
+    
      
+      das wäre schön ... demnach ist ja SCons wirklich so generisch, wie ich gehofft hatte
+    
      
+  
+
+      
+      
+
+
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      die entsprechende Methode hanhabt einen Builder-Parameter install=True
+    
      
+  
+
+      
+
+  
+    
+  
+  
+    
      
+      ...den habe ich wohl so eingebaut, damit dieser Umstand auch deklarativ sichtbar wird; zudem gibt es Build-Resultate, die nicht installiert werden (z.B. Tests)
+    
      
+  
+
+      
+      
+
+
+  
+    
+  
+  
+    
      
+      Es ist klar wie das geht, ich empfinde es aber nach heutigen Standards nicht mehr als besonders schön, aber praktisch, da das hier ein letztlich in sich geschlossenes Ökosystem ist
+    
      
+  
+
+      
+      
+
+
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      Debian/Trixie hat 4.8
+    
      
+  
+      
+
+      
+      
+      
+
+
+
+
+
+
+  
+    
+  
+  
+    
      
+      Nein. Macht den Code viel komplexer und steht in keinem Verhältnis zum Nutzen, denn die paar Library-Builder invocations werden uns nicht umbringen
+    
      
+  
+
+      
+
+      
+
+
+
+      
+      
+      
+      
 
 
 
@@ -181166,7 +181456,8 @@ Since then others have made contributions, see the log for the history.      ARCHFLAGS=" -fstack-protector-strong"
     
      
   
-
+
+
       
       
 
@@ -181426,7 +181717,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
 
@@ -181442,7 +181734,6 @@ Since then others have made contributions, see the log for the history.
 
 
-
 
 
 
@@ -181479,7 +181770,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 

From 88ae398e67bb78f7955de72611e624dcee90ba3f Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Mon, 24 Nov 2025 23:12:39 +0100
Subject: [PATCH 46/51] Build: remove old workaround for transitive shared
 object lookup (closes: #965)

Lumiera is built such that it can be invoked from a ''bundle directory''
without the need to install it into the system; this requires to perform
a relative lookup of shared modules loaded as dependencies.

Since Lumiera has a layered architecture, and each layer is built into a shared object,
we get transitive dependencies and thus transitive relative lookup.

There was a bug in binutils 2.23, which caused that transitive relative lookup to fail.

 * as of 2025, Debian/Trixie is defined as ''Reference Platform''
 * in Trixie the binutils version is v2.44-3
 * after removing the workaround, Lumiera and all tests can be launched
 * thus ''considering this workaround as obsolete now''
---
 admin/scons/LumieraEnvironment.py |  1 -
 wiki/thinkPad.ichthyo.mm          | 14 ++++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py
index 196b619a1..5a759e995 100644
--- a/admin/scons/LumieraEnvironment.py
+++ b/admin/scons/LumieraEnvironment.py
@@ -300,7 +300,6 @@ class LumieraExeBuilder(WrappedStandardExeBuilder):
         """
         custEnv = lumiEnv.Clone()
         custEnv.Append( LINKFLAGS = "-Wl,-rpath=\\$$ORIGIN/modules,--enable-new-dtags" )
-        custEnv.Append( LINKFLAGS = "-Wl,-rpath-link=target/modules" ) ### Workaround for bug in binutils > 2.23   /////TICKET #965
         if 'addLibs' in kw:
             custEnv.Append(LIBS = kw['addLibs'])
         return custEnv
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 79190b7ce..0af6e08bd 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -178982,6 +178982,20 @@ env.Chmod(installed[0], 0o644)
 
 
 
+
+
+  
+    
+  
+  
+    
      
+      ...aber derzeit läuft unser Trac nicht, und ich kann nicht auf das Ticket zugreifen. Hab die Zeile mit dem Workaround einfach wieder rausgenommen
+    
      
+  
+
+      
+
+      
       
 
 

From 8b2a329898aea5515b8666ea6eabe34af82eab9c Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Tue, 25 Nov 2025 02:14:21 +0100
Subject: [PATCH 47/51] Build: some further code clean-up and documentation

 * Simplify some constructs from the Python-3 migration
 * update copyright, since I did maintain the SCons build continuosly
 * remove unused method from Buildhelper

Furthermore, the documentation page for our build system
https://lumiera.org/documentation/technical/build/SCons.html
has been reworked, to add a synopsis, some further background
information about the internal structure of SCons and about
the specific conventions and definitions used for Lumiera
---
 SConstruct                        |   7 +-
 admin/scons/Buildhelper.py        |  17 +-
 admin/scons/LumieraEnvironment.py |  11 +-
 admin/scons/Platform.py           |   5 +-
 admin/scons/Setup.py              |   2 +-
 doc/technical/build/SCons.txt     | 268 ++++++++++++++++++++++++------
 doc/technical/build/index.txt     |   2 +-
 tests/SConscript                  |   8 +-
 wiki/thinkPad.ichthyo.mm          | 131 ++++++++-------
 9 files changed, 300 insertions(+), 151 deletions(-)

diff --git a/SConstruct b/SConstruct
index 32afeaab0..147b8b7cd 100644
--- a/SConstruct
+++ b/SConstruct
@@ -4,7 +4,7 @@
 ##
 
 #  Copyright (C)
-#    2008,            Hermann Vosseler 
+#    2008-2025        Hermann Vosseler 
 #
 # **Lumiera** is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by the
@@ -16,7 +16,7 @@
 # NOTE: scons -h for help.
 # This script /defines/ the components and how they fit together.
 # SCons will derive dependencies and the necessary build steps.
-# Read more about the SCons build system at: http://www.scons.org
+# Read more about the SCons build system at: https://www.scons.org
 
 
 # NOTE: Lumiera SCons extension modules and plugins
@@ -52,7 +52,6 @@ SConscript(dirs=['data','src','src/tool','research','tests','doc'], exports='env
 
 # additional files to be cleaned when cleaning 'build'
 env.Clean ('build', [ 'scache.conf', '.sconf_temp', '.sconsign.dblite', 'config.log' ])
-env.Clean ('build', [ 'src/pre.gch' ])
 
 
 
@@ -63,8 +62,8 @@ env.Clean ('build', [ 'src/pre.gch' ])
 Import('lumiera plugins tools gui testsuite')
 
 build = env.Alias('build', lumiera + plugins + tools + gui)
+# this defines the SCons **default target**
 env.Default('build')
-# SCons default target
 
 
 #env.Alias ('all', build + testsuite + doxydoc)
diff --git a/admin/scons/Buildhelper.py b/admin/scons/Buildhelper.py
index a6cc7006f..a0c9e5de7 100644
--- a/admin/scons/Buildhelper.py
+++ b/admin/scons/Buildhelper.py
@@ -4,7 +4,7 @@
 ##
 
 #  Copyright (C)
-#    2008,            Hermann Vosseler 
+#    2008-2025        Hermann Vosseler 
 #
 # **Lumiera** is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by the
@@ -104,19 +104,6 @@ def isSrcDir(path, patterns=SRCPATTERNS):
 
 
 
-def filterNodes(nlist, removeName=None):
-    """ filter out scons build nodes using the given criteria.
-        removeName: if set, remove all nodes with this srcname
-    """
-    if removeName:
-        predicate = lambda n : not fnmatch.fnmatch(os.path.basename(str(n[0])), removeName)
-    else:
-        predicate = lambda n : True
-    
-    return list(filter(predicate, nlist))
-
-
-
 def getDirname (d, basePrefix=None):
     """ extract directory name without leading path,
         or without the explicitly given basePrefix
@@ -218,7 +205,7 @@ def extract_localPathDefs (localDefs):
         pattern and returns them wrapped into a Record for convenient access
     """
     def relevantPathDefs (mapping):
-        for (k,v) in list(mapping.items()):
+        for (k,v) in mapping.items():
             if (k.startswith('src') or k.startswith('build') or k.startswith('install')) and Util.is_String(v):
                 v = v.strip()
                 if not v.endswith('/'): v += '/'
diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py
index 5a759e995..19c07c4b5 100644
--- a/admin/scons/LumieraEnvironment.py
+++ b/admin/scons/LumieraEnvironment.py
@@ -4,7 +4,7 @@
 ##
 
 #  Copyright (C)
-#    2008,            Hermann Vosseler 
+#    2008-2025        Hermann Vosseler 
 #
 # **Lumiera** is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by the
@@ -75,9 +75,9 @@ class LumieraEnvironment(Environment):
             if other in self.libInfo:
                 self.mergeConf(self.libInfo[other])
         else:
-            self.Append (LIBS = other.get ('LIBS',[]))
-            self.Append (LIBPATH = other.get('LIBPATH', []))
-            self.Append (CPPPATH = other.get('CPPPATH', []))
+            self.Append (LIBS      = other.get('LIBS',[]))
+            self.Append (LIBPATH   = other.get('LIBPATH', []))
+            self.Append (CPPPATH   = other.get('CPPPATH', []))
             self.Append (LINKFLAGS = other.get('LINKFLAGS', []))
         
         return self
@@ -123,6 +123,7 @@ class LumieraConfigContext(ConfigBase):
 
 
 
+
 ###############################################################################
 ####### Lumiera custom tools and builders #####################################
 
@@ -343,7 +344,7 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder):
                 for t in target:
                     os.chmod(str(t), 0o644)
                 return None
-#           removeExecBit = env.Chmod(toInstall, 0o644)
+#           removeExecBit = env.Chmod(toInstall, 0o644)                    # ◁◁◁ could use this for SCons > 4.10
             msg = '....... clear exec perm %s' % [str(t) for t in toInstall]
             removeExecBit = env.Action(_Chmod, msg)
             env.AddPostAction(toInstall, removeExecBit)
diff --git a/admin/scons/Platform.py b/admin/scons/Platform.py
index 9083a39cf..9edc7de0b 100644
--- a/admin/scons/Platform.py
+++ b/admin/scons/Platform.py
@@ -4,7 +4,7 @@
 ##
 
 #  Copyright (C)
-#    2012,            Hermann Vosseler 
+#    2012-2025        Hermann Vosseler 
 #
 # **Lumiera** is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by the
@@ -140,8 +140,7 @@ def configure(env):
         print("*** unable to build due to the following problems:")
         for isue in problems:
             print(" *  %s" % isue)
-        print()
-        print("build aborted.")
+        print("\nbuild aborted.")
         Exit(1)
     
     print("** Gathered Library Info: %s" % list(conf.env.libInfo.keys()))
diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py
index ba15e32d7..5070f0254 100644
--- a/admin/scons/Setup.py
+++ b/admin/scons/Setup.py
@@ -4,7 +4,7 @@
 ##
 
 #  Copyright (C)
-#    2012,            Hermann Vosseler 
+#    2012-2025        Hermann Vosseler 
 #
 # **Lumiera** is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by the
diff --git a/doc/technical/build/SCons.txt b/doc/technical/build/SCons.txt
index 5a2f44316..e4341cb11 100644
--- a/doc/technical/build/SCons.txt
+++ b/doc/technical/build/SCons.txt
@@ -1,16 +1,44 @@
 SCons Build-System
 ==================
 :author: Ichthyo
-:date: 2012
+:date: 2012 · 2025
+:toc:
 
 //MENU: label SCons Build
 
 Lumiera uses a build system based on https://scons.org/[SCons]
 
-SCons is an open source software construction tool based on Python build definition scripts.
-Within these build scripts, we define a data structure to describe the parts and dependencies
-of our software. When executed, SCons evaluates those definitions and the actual files in
-the source tree to derive a build strategy, which is then performed.
+SCons is an open source software construction tool based on build definition scripts
+written in Python. Within these build scripts, we define a data structure to describe
+the parts and dependencies of our software. When executed, SCons evaluates those
+definitions and the actual files in the source tree to derive a build strategy,
+which is then performed to actually (re)build the software.
+
+Synopsis
+--------
+[cols=">, all cores
+| build + run Tests:  | scons -j# check      | -> see 'target/,testlog'
+| development build:  | scons -j# testcode   | -> `target/test-suite `
+| install:            | scons -j# install    | installs below '/usr/local/', ⚠ sudo
+| see possible config:| scons -h             | ⚠ settings are *sticky* -> see './optcache'
+|=====================
+
+
+
+.Known shortcomings of SCons
+[NOTE]
+--
+* No one knows it
+* It is written in Python
+* It is _declarative_ not _imperative_ +
+  Thus people hate that they can not just figure out some script
+* A SCons build can not be manipulated by setting environment variables
+* SCons has no default interface for package managers. +
+  Each project has to solve that individually...
+* SCons is not a platform-, package- and dependency manager.
+--
 
 SCons core concepts
 -------------------
@@ -18,19 +46,21 @@ SCons core concepts
 
 .SCons Environment
 When SCons starts building the project, it creates its own environment with dependency trees,
-helper functions, builders and other stuff. The SCons environment is created in memory and some parts of it
+helper functions, builders and other stuff. The SCons environment is built in memory and some parts of it
 are saved to disk to speed up things on the next start. The definition of the build happens within this
-artificial build environment. This often confuses people who used Makefiles, where environment is actually
+abstracted build environment. This often confuses people who used Makefiles, where ``environment'' is actually
 the System Environment.
 
 .System Environment
 the familiar operating system container with environment variables such as PATH, HOME etc.
 It is usually accessible via os.environ mapping in Python and therefore in SCons too.
-SCons doesn't import any settings from System Environment automatically (like flags for compilers,
-or paths for tools), because it's designed to be a cross platform tool with _predictable behaviour._
-That's why, if you rely on any system PATHs or environment variables -- you need to extract
+SCons does not automatically import any settings from System Environment automatically
+(like flags for compilers, or paths for tools), because it's designed to be a cross platform tool
+with _predictable behaviour._
+If you rely on any system PATHs or environment variables -- you need to extract
 those settings explicitly in your build definition.
 
+
 .SConstruct
 when SCons executes, it performs a build definition python script written by the user.
 By convention, this main script is called 'SConstruct' and is located in the root of the source tree.
@@ -44,10 +74,22 @@ the sub-trees of the project.
 
 .Builder
 The SCons buildsystem revolves around the metaphor of a _Builder_. This is a SCons object that you explicitly
-invoke from the scripts to _define_ that there is something to build, transforming a _source_ into a _target_.
+invoke from the scripts to _define_ that there is something to build, thereby transforming a _source_ into a _target_.
 So the target depends on the sources, and typically those _source nodes_ were created by previous builder invocations.
-The power of SCons is in the fact that dependencies are tracked automatically. When source files change, the system
-is able to derive which targets to rebuild.
+The use of Builders is _declarative:_ it is a statement _that_ a transformation (build step) has to happen, while
+the knowledge _how_ this can be achieved is kept implicit within the buildsystem.
+
+.Action
+These are are functors that perform something (execute an external command or call a python function, for instance).
+A Builder retains a list of Actions needed to update its targets; those Actions are run when needed.
+
+.Node
+This is the basic building block of the dependency graph, while the arcs are created by using Builders:
+a Node represents a filesystem object, such as a file or directory which can also be a build result and
+as such does not exist yet. There are also Alias nodes and Value nodes which represent setting values.
+The power of SCons is in the fact that dependencies can be tracked and a build strategy can be derived,
+automatically, based on the structure of this dependency graph. And because the building blocks of that
+graph are _abstract,_ users can _represent the specifics of their build_ in an uniform way.
 
 .Scanner
 when defining a builder, SCons relies on modular scanner components to ``understand'' the source of the build step.
@@ -58,26 +100,46 @@ through plug-ins.
 .Tool
 any further, external component that adds Builders, Scanners and other helpers to SCons environments
 for use within scripts. There are special tools for _configuring the platform_ to detect libraries and
-further requirements. Relying on those tools. the build environment will be outfitted to reflect the
-needs of the specific build. Sub-environments with special configuration may be created.
+further requirements. Tools do not operate themselves, rather they will configure the build environment
+to reflect the needs of the specific build.
+
+.Construction Variable
+All key-value settings within a Construction Environment which are used to instruct SCons about builds.
+Construction Variables can describe compiler flags, locations of commands to execute, and many other characteristics.
+They are used for _text substitution_ in command template strings for invocation of external commands, relying on
+the usual `$VARIABLE` syntax. Since the configuration of a SCons environment is defined by its
+Construction Variables, sub-environments with special configuration may be created.
+
+.Signature
+SCons computes a signature for elements on the dependency graph using a cryptographic hash function which
+has the property that the same input repeatably leads to the same signature. The default function is MD5.
+Signatures are used throughout SCons to identify file contents, build command lines, or to identify cached
+build artefacts. Signatures are chained to determine if something needs to be re-built.
 
 .Target
-any _node_ or ``build step'' encountered through the definition of the build is a _target_. The actual build
+any _Node_ or ``build result'' encountered through the definition of the build is a _target_. The actual build
 will be triggered by requesting a target, which typically might be just an executable known to reside at some
-location in the tree. Special _alias targets_ may be defined, based on other targets, to trigger off standard
-build situations. Especially, a _default_ target may be defined.
+location in the tree, or a _target directory_ where the build is assumed to place build results.
+Special _alias targets_ may be defined, based on other targets, to set off standard
+build sequences. Notably, a _default_ target can be defined for the build.
 
 ''''
+....
+​
+​
+​
+....
+
 
 Organisation of the Lumiera SCons build
 ---------------------------------------
-Within our build system, we build upon the power of the Python programming language to create abstractions
-tailored to the needs of our project. Located in the `admin/scons` subdirectory, you'll find a collection
+Within our build system, we leverage the power of the Python programming language to create abstractions
+tailored to the needs of our project. Located in the 'admin/scons' subdirectory, you'll find a collection
 of Python modules to provide these building blocks.
 
 - the *LumieraEnvironment* is created as a subclass of the standard SCons build environment; it is
-  outfitted with pre-configured custom builders for executables, libraries, extension module, Lumiera plug-in
-  and icon resources.
+  outfitted with pre-configured custom builders for executables, libraries, extension modules,
+  Lumiera plug-ins and icon resources.
 - all these *custom builders* implement a set of conventions and directory locations within the tree.
   These are defined (and can be adjusted) in the *Setup.py* module. This way, each builder automatically
   places the generated artefacts at standard build and installation locations.
@@ -89,15 +151,15 @@ Sub-trees
 ~~~~~~~~~
 .the source tree
 All sourcecode of the core application resides below `src/`. Building these components is controlled by
-the SConscript residing in this application source root. By convention, this is also the root for header
+the SConscript located within this application source root. By convention, this is also the root for header
 includes -- _all headers should be included relative_ to `src/`.
 
 .the three layers
 Within this application core tree, there are sub-trees for the main layers comprising the application.
 Each of these sub-trees will be built into a shared library and then linked against the application framework
-and common services residing in `src/common`. These common services in turn are also built into a shared
+and common services residing in 'src/common'. These common services in turn are also built into a shared
 library `liblumieracommon.so`, as is the collection of helper classes and support facilities, known as
-our 'support library' `liblumierasupport.so`. Besides, there is a sub-tree for core plug-ins and helper tools.
+our `support library' `liblumierasupport.so`. Besides, there is a sub-tree for core plug-ins and helper tools.
 
 .the GTK Gui
 one of the sub-trees, residing in `src/stage` forms the _upper layer_ or _user-interaction layer_. Contrary to
@@ -106,51 +168,68 @@ Thus, the GTK Gui is built and loaded as Lumiera a plug-in.
 
 .unit tests
 Since our development is test-driven, about half of the overall code can be found in unit- and integration
-tests, residing below `test/`. There is a separate SConscript file, to define the various
+tests, arranged below 'test/'. There is a separate SConscript file, to define the various
 link:{ldoc}/technical/infra/TestSupport.html[kinds of test artefacts] to be created.
 
-- plain-C tests are defined in _test-collections_, grouped thematically into several subdirectories.
-  Here, each translation unit provides a separate +main()+ function and is linked into a stand-alone
-  executable (yet still linked against the appropriate shared libraries of the main application layers)
-- the tests covering C++ components are organised into test-suites, residing in separate sub-trees.
-  Currently (as of 5/2015), we link each sub-tree into a shared test library. Here
-  individual translation units define individual test case classes. At the end, all these unit tests
+- the tests to cover C++ components are organised into test-suites, residing in separate sub-trees.
+  Currently (as of 11/2025), we link each sub-tree into a shared test library. Here, individual
+  translation units define individual test case classes. At the end, all these test units
   are linked together with a testrunner `main()` into the `test-suite` executable.
+- plain-C tests are defined in _test-collections_, grouped thematically into several subdirectories.
+  Here, each translation unit provides a separate `main()` function and is linked into a stand-alone
+  executable (yet still linked against the appropriate shared libraries of the main application layers)
 
 .research
-There is a separate subtree for research and experiments. The rationale being to avoid re-building most
-of the core application when it comes to experimenting and trying out new technologies.
+There is a separate subtree for research and experiments. The rationale is to provide a simplified
+and flexible dependency structure for investigating fundamental problems and to try out new technologies.
+Notably there is a source file 'try.cpp', which is linked against all of the core libraries and is re-used
+any time some language features need further investigation or when new implementation techniques are pioneered.
 
 .icons and resources
-the +data/+ subtree holds resources, configuration files and icons for the GUI. Most of our icons
-are defined as SVG graphics. The build process creates a helper executable (+rsvg_convert+) to render
+the 'data/' subtree holds resources, configuration files and icons for the GUI. Most of our icons
+are defined as SVG graphics. The build process creates a helper executable (`rsvg_convert`) to render
 these vector graphics with the help of lib Cairo into icon collections of various sizes.
 
 .documentation
-Largely, the documentation is written in Asciidoc and provided online at link:{ldoc}/[the documentation section]
-of our website. The plain-text sources of this documentation tree is shipped alongside with the code.
-Besides, we build *Doxygen* API documentation there, and we create design and technical specs and drawings
-in SVG and in UML.
+Largely, the documentation is written in Asciidoc and provided online in the link:{ldoc}/[documentation section]
+of our website. The plain-text sources of this documentation tree are shipped alongside with the code.
+Besides, we build *Doxygen* link:/doxy/[API documentation] there, and we create design and
+technical specs and drawings in SVG and in UML.
 
 .the target directory
 This is where the results of the build process are created. Lumiera is organised into a
-_self contained folder structure_. As long as the relative locations, as found within +target/+,
+_self contained folder structure_. As long as the relative locations, as found within 'target/',
 are kept intact, the Application will be able to start up and find all its resources. Consequently,
-there is no need to ``install'' Lumiera (and the ``install'' target just copies this folder structure
-into the standard installation locations of a typical Unix system)
+there is no need to ``install'' Lumiera -- in can always be launched from a package bundle placed
+into some directory. In fact, the ``install'' target just copies this folder structure into the
+standard installation locations in accordance with the Filesystem Hierarchy Standard for Unix systems
 
-Unfortunately SCons is a bit weird regarding the object files created during the build process.
-So, for the time being, we're just building in-tree. Apologies for that.
+WARNING: Unfortunately SCons is a bit weird regarding the object files created during the build process.
+         So, for the time being, we're building in-tree. Apologies for that. +
+         [underline]#2025#: this aspect has been improved _upstream,_ yet we did not find the time
+         to rework our build system accordingly. Apologies for that...
+
+.installation
+As described xref:_organisation_of_the_lumiera_scons_build[above], a custom environment
+baseclass `LumieraEnvironment` is used to configure preconfigured builders, which always define
+an installation target alongside with the build target. These installation targets are arranged
+into a subtree with a _prefix,_ which is by default 'usr/local' -- following the conventions of
+the Filesystem Hierarchy Standard. As long as you just build stuff, you won't notice these
+installation targets, since by default they are located outside of the project tree. However,
+by customising the build options `PREFIX` and `INSTALLDIR`, this installation tree can be relocated.
+For example, our DEB package uses `PREFIX=usr INSTALLDIR=debian/lumiera`
+(please note that such settings are cached in './optcache' and that
+changing them causes a full rebuild)
 
 
 Invoking the Build
 ~~~~~~~~~~~~~~~~~~
-All of the build process is launched through the `scons` python script, usually installed into
-`/usr/bin` when installing the SCons package onto the system. Just invoking
+All of the build processing is launched through the `scons` python script, usually installed into
+`/usr/bin` when installing the SCons package onto the system. And by just invoking
 
  scons -h
 
-prints a summary of all custom options, targets and toggles defined for our build.
+a summary of all custom options is printed, with targets and toggles defined for our build.
 
 Targets
 ^^^^^^^
@@ -162,15 +241,19 @@ Targets
 - *all* builds the Application, test-suites and documentation
 - *install* builds and installs the Lumiera Application
 
-By convention, invoking `scons -c`  will _clean up_ everything the given target _would_ build.
+Cleaning
+^^^^^^^^
+By convention, an invocation of `scons -c`  will _clean up_ everything the given target _would_ build.
 Thus, invoking `scons -c /` is the most global clean operation: it will clean up al build artefacts and
 will un-install Lumiera (recall: every defined node, or directory is also a target).
 
 Configure checks
 ^^^^^^^^^^^^^^^^
-SCons does not support the concept of a separate ``configure'' step. The necessary dependency detection is
-performed before each build. Currently, we expect _all dependencies to be installed first-class_ into
-the system. We do not (yet) support custom libraries in strange locations. Please use your package manager.
+By deliberate choice, SCons does not support the concept of a separate ``configure'' stage.
+The necessary dependency detection is performed before each build, but with effective caching
+of detected settings. Currently, we expect _all dependencies to be installed first-class_ into
+the system. Custom packages can be installed at '/usr/local' -- however, we do not (yet) support
+custom libraries in arbitrary locations, passed as configuration. Please use your package manager.
 
 Caching and MD5 sums
 ^^^^^^^^^^^^^^^^^^^^
@@ -191,3 +274,84 @@ We provide several custom configuration options (run `scons -h` to get a summary
 options are *sticky*: once set, the build system will recall them in a file '.optcache' and apply
 them the same way in subsequent builds. It is fine to edit '.optcache' with a text editor.
 
+
+Technical Details
+~~~~~~~~~~~~~~~~~
+The following sections provide additional information helpful when adapting the build system.
+It should be noted that the SCons scripts are _Python modules_, invoked within a special setup.
+Python has a host of specific tweaks and kinks, notably regarding visibility, definition order,
+imports and the use of standard data types like lists, dictionaries and generator functions.
+Python knowledge is widespread nowadays, yet we had ample opportunity to notice that, for
+people not familiar with the Python idiom, the SCons scripts may seem arcane and confusing.
+
+Invocation
+^^^^^^^^^^
+After some basic checks of setup and the given command line, the SCons builder immediately
+loads the 'SConstruct' as module -- and expects that this python DSL code builds a project
+model data structure. The actual build is then driven by evaluating the dependency graph
+as implied by that model.
+
+The individual 'SConscript' definitions for each subfolder must be activated explicitly
+from the 'SConstruct', using the `SConscript(dirs=[...])` builder function. Note furthermore
+that the order of the dirs mentioned in this invocation matters, since each 'SCconscript'
+usually _imports_ some global variables at the beginning and _exports_ other settings
+at the end. Before evaluating a 'SConscript', the working directory is changed.
+
+TIP: you can launch `scons` with a python debugger, using the Lumiera directory as
+     working location and set breakpoints in 'SConstruct' or in any of our custom
+     python modules to investigate problems with some build definition not taking effect
+     as expected. Inspect the dictionary of the `Environment` with the debugger to
+     find out what has actually been configured...
+
+Start-up sequence
+^^^^^^^^^^^^^^^^^
+The Lumiera build system engages in a specific start-up sequence, which is explicitly
+coded and expands beyond the standards of the SCons build system.
+
+- first we add our _tool directory_ below 'admin/scons' to the search path,
+  so that tools and python modules defined there become visible.
+  You _must familiarise yourself_ with the contents of this directory!
+- next we create our custom root `LumieraEnvironment` instance, which is stored
+  and exported in the global variable `env`. This environment setup is done by
+  the python module 'admin/scons/Setup.py'
+- this module has some module-level definitions for standard path locations,
+  and all these settings are imported into a dictionary and placed into the
+  member field `env.path` of the `LumieraEnvironment`. All our custom builders
+  use these central settings as shared configuration.
+- once the base constructor of the SCons `Environment` class is invoked,
+  the command line is evaluated to populate the Construction Variables.
+- next, the constructor of our custom `LumieraEnvironment` installs
+  our custom tools and builder functions.
+- the last step in the start-up sequence is to invoke the `Platform.configure(env)`
+  function, which performs all the library and platform checks. This function
+  also configures the default compiler flags.
+
+Nested Build Environment
+^^^^^^^^^^^^^^^^^^^^^^^^
+Several of the 'SConscript' in subdirectories will create a nested build environment,
+which obviously derives from `LumieraEnvironment`. This way we can configure
+additional link dependencies and build configurations for some subtrees, like
+building the GUI against GTK or handling plug-in modules specifically.
+
+The custom ELF builders
+^^^^^^^^^^^^^^^^^^^^^^^
+These custom builders like `env.Program`, `env.SharedLibrary`, `env.LoadableModule`
+and `env.LumieraPlugin` are also defined in the `LumieraEnvironment.py` module.
+All these classes inherit from the SCons `Environment` through the common baseclass
+`WrappedStandardExeBuilder` -- which defines a special arrangement where an _install target_
+is always defined alongside the build target. This install target is ``dropped off'' as
+a side-effect, while _the build target will be returned._
+
+Composite targets
+^^^^^^^^^^^^^^^^^
+In SCons, a builder returns a list of target nodes, and these can be passed in a flexible
+way to further builders. At several places in our 'SConscript' definitions, we use
+Python functions defined within that script to manipulate and aggregate such
+target lists. Notably, specific sets of targets can be combined into a
+shared object (dynamic library), which is then again a SCons target
+and can be passed to other executable builders as library dependency
+for compilation and linking. Look into 'src/SConscript' or 'test/SConscript'
+to see examples of that technique -- which we also use to define that
+global compound target variables like `core`, `app_lib`, `core_lib`,
+`vault_lib`, and `support_lib`. These in turn are essential for
+building the layered dependency hierarchy in our code.
diff --git a/doc/technical/build/index.txt b/doc/technical/build/index.txt
index 687b8465d..f43416c42 100644
--- a/doc/technical/build/index.txt
+++ b/doc/technical/build/index.txt
@@ -10,7 +10,7 @@ As work progresses, we will add more information on the Lumiera build system.
 
 build -- continuous integration -- packaging
 
-* link:SCons.html[Buildsystem]
+* link:SCons.html[SCons Buildsystem]
 * link:BuildDependencies.html[Lumiera Build Dependencies]
 * link:BuildDroneDraft.html[»Builddrone« concept from 2008]
 * Packaging: link:LumieraDebianPackage.html[Debian] RPM
diff --git a/tests/SConscript b/tests/SConscript
index c233bf178..b74f84cce 100644
--- a/tests/SConscript
+++ b/tests/SConscript
@@ -80,8 +80,8 @@ testSrcDirs = globRootdirs('*')
 
 
 testcases  = [testCases(env, dir)  for dir in testSrcDirs if not dir in specialDirs]
-testLibs   = sharedTestLibs.values()
-testrunner = envSuite.Program("test-suite", ["testrunner.cpp"]+list(testLibs)+list(core_lib))
+testLibs   = list(sharedTestLibs.values())
+testrunner = envSuite.Program("test-suite", ["testrunner.cpp"]+testLibs+core_lib)
 
 
 testsuite = ( testcases
@@ -96,7 +96,7 @@ Export('testsuite')
 
 
 # for creating a Valgrind-Suppression file
-vgsuppression = envSuite.Program('vgsuppression',['tool/vgsuppression.c']+list(testLibs)+list(core_lib))   ## for suppressing false valgrind alarms
+vgsuppression = envSuite.Program('vgsuppression',['tool/vgsuppression.c']+testLibs+core_lib)   ## for suppressing false valgrind alarms
 
 
 #
@@ -139,7 +139,7 @@ Depends(runTests,vgsuppression)
 
 
 #
-# define Phony targets
+# define Alias targets
 #  - 'scons testcode' triggers building of the Testsuite
 #  - 'scons check' triggers building and running
 #
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 0af6e08bd..c99e90a7f 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -167947,7 +167947,8 @@ that situation will improve in forseeable future.
 
 
 
-
+
+
 
 
 
@@ -169006,8 +169007,7 @@ that situation will improve in forseeable future.
       Wobei in diesem Kontext zweifelhaft ist, was ein maschinenlesbarer Code auf einer allgemeinen Lizenz-Seite bringen soll. Das würde eigentlich nur Sinn machen, wenn der Button auf jeder Seite wäre
     
      
   
-
-
+
 
 
 
@@ -169018,8 +169018,7 @@ that situation will improve in forseeable future.
       So stellt es zumindest ChatGPT dar. Demnach habe man die Empfehlungen bei CC vereinfacht, und biete nun einfach Grafiken an, die die User in ihre Website packen können.
     
      
   
-
-
+
       
 
 
@@ -169200,8 +169199,7 @@ that situation will improve in forseeable future.
       ....und jeweils sehen ob sich das bewährt und entsprechend klar ist
     
      
   
-
-
+
       
 
 
@@ -171892,7 +171890,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -171905,6 +171903,21 @@ Since then others have made contributions, see the log for the history.
 
 
+
+
+  
+  
+    
        
+      
      • 
+        wenn ich gleich wieder darüber iteriere, ist es nicht notwendig, zu materialisieren
+      
        • 
+      
      • 
+        und für Debendencies gilt: sie müssen ohnehin eine Liste sein in SCons, also besser an der Erzeugungsstelle einmal in eine Liste packen
+      
        • 
+    
      
+  
+      
+      
       
 
 
@@ -177986,10 +177999,17 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
+
 
 
 
+
+
+
+
+
+
 
 
 
@@ -178446,9 +178466,20 @@ Since then others have made contributions, see the log for the history.      
       
       
-
+
 
-
+
+
+
+
+  
+  
+    
      
+      ...naja, nicht wirklich, denn dazu müßte ich mal die ganze SCons-Doku durhclesen, um zu sehen, was man modernisieren könnte. Aber da ich nun nur noch mit entsprechend neuerer Software arbeite, ist es auch nicht mehr angemessen, eine niedrigere Version zu deklarieren, da ich nicht merke, wenn ich neuere Feature verwende, die irgendwo im Internet beschrieben sind.
+    
      
+  
+      
+      
       
       
 
@@ -178682,9 +178713,7 @@ Since then others have made contributions, see the log for the history.
 
 
-  
-    
-  
+  
   
     
      
       der verhält sich nach dem Motto: »schad ja nix«...
@@ -178693,14 +178722,11 @@ Since then others have made contributions, see the log for the history.
   
-
-
+
 
 
 
-  
-    
-  
+  
   
     
      
       Es ist nämlich so: Shared-Libs können eine main()-Funktion enthalten; und wenn das der Fall ist, können sie auch als Executables aufgerufen werden. Rein theoretisch könnte das ein Baustein in einem komplexen Exploit sein, der aus einer überraschenden Ecke käme, da das ein Thema ist, was niemand »auf dem Radar hat«. Manche Libraries haben in der Tat ein Main, und das macht typischerweise gewisse Diagnose-Funktionalität.
@@ -178712,8 +178738,7 @@ Since then others have made contributions, see the log for the history.
   
-
-
+
 
 
 
@@ -178722,23 +178747,18 @@ Since then others have made contributions, see the log for the history.
 
 
-  
-    
-  
+  
   
     
      
       ...das liegt daran, daß ich das Bauen von Executables und Libraries und Plugins bereits hochgradig customised habe, im LumieraEnvironment. Das bedeutet, es gibt bereits einen env.Install()-Aufruf, tief in Lumiera-spezifischem Framework-Code. Genau diesen Aufruf muß ich nun so modifizieren, daß entweder davor oder danach noch die Permissions geändert werden.
     
      
   
-
-      
+
 
 
 
 
-  
-    
-  
+  
   
     
      
       Use one of these approaches: chain actions in a single Command, or install first then attach a post-action (via AddPostAction  or Command on the installed node). Both keep the install and chmod as a single build step.
@@ -178836,21 +178856,17 @@ env.Chmod(installed[0], 0o644)
       
      • 
     
    
   
-
-
+
 
 
 
-  
-    
-  
+  
   
     
    
       das wäre schön ... demnach ist ja SCons wirklich so generisch, wie ich gehofft hatte
     
    
   
-
-    
+
     
 
 
@@ -178859,40 +178875,31 @@ env.Chmod(installed[0], 0o644)
 
 
 
-  
-    
-  
+  
   
     
    
       die entsprechende Methode hanhabt einen Builder-Parameter install=True
     
    
   
-
-    
+
 
-  
-    
-  
+  
   
     
    
       ...den habe ich wohl so eingebaut, damit dieser Umstand auch deklarativ sichtbar wird; zudem gibt es Build-Resultate, die nicht installiert werden (z.B. Tests)
     
    
   
-
-    
+
     
 
 
-  
-    
-  
+  
   
     
    
       Es ist klar wie das geht, ich empfinde es aber nach heutigen Standards nicht mehr als besonders schön, aber praktisch, da das hier ein letztlich in sich geschlossenes Ökosystem ist
     
    
   
-
-    
+
     
 
 
@@ -178901,9 +178908,7 @@ env.Chmod(installed[0], 0o644)
 
 
 
-  
-    
-  
+  
   
     
    
       Debian/Trixie hat 4.8
@@ -178920,16 +178925,13 @@ env.Chmod(installed[0], 0o644)
 
 
 
-  
-    
-  
+  
   
     
    
       Nein. Macht den Code viel komplexer und steht in keinem Verhältnis zum Nutzen, denn die paar Library-Builder invocations werden uns nicht umbringen
     
    
   
-
-    
+
 
     
 
@@ -178984,17 +178986,15 @@ env.Chmod(installed[0], 0o644)
 
 
 
-  
-    
-  
+  
   
     
    
       ...aber derzeit läuft unser Trac nicht, und ich kann nicht auf das Ticket zugreifen. Hab die Zeile mit dem Workaround einfach wieder rausgenommen
     
    
   
-
-    
+
 
+
 
     
 
@@ -181470,8 +181470,7 @@ env.Chmod(installed[0], 0o644)
       ARCHFLAGS=" -fstack-protector-strong"
     
    
   
-
-
+
     
     
 

From d24e025de2cb589fd0c20716a9bf7631fe108ae3 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Thu, 27 Nov 2025 02:08:50 +0100
Subject: [PATCH 48/51] Build: chase down and solve spurious SVG icon rebuilds
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Many years ago, I integrated the IconSvgRenderer (written by Joel Holdsworth)
directly into the SCons build by means of a custom builder with an ''emitter function''.

The build as such works fine and automatically determines which icons can be
generated from a given SVG source. However, those SVG icons tend to be rebuilt
very frequently, even while none of the SVG sources has changed.

Basically this was more of an annoyance, since we have now about 15 icons
and the rendering is really fast ... it is just ugly, especially on
incremental builds (and it could become a problem once we have a
massive amount of graphics to process.

So I took the opportunity to take close look now, since I am doing
uninspiring clean-up work since several weeks now. But that problem
turned out to be quite insidious and hard to spot.

First, AI set me off into a completely wrong angle, since it is ''not''
caused by a missing string representation of the custom Action class.
However, from there I went to watching the target checks with the debugger,
and this eventually got me to realise, that SCons mistakenly detects
a change in the Executor / the Action class.

The root cause is, that we invoke Python code from an external Module,
IconSvgRenderer.py, and this is »materialised« by SCons automatically
into a string representation, which includes memory addresses of functions
in that module. And that yields a signature, that is, quite obviously,
not stable, even while you end up sometimes with loading the code to
the same memory location.

As a solution / workaround, we now subclass the standard implementation
from SCons and override the signature function; instead of fingerprinting
the binary code, we just compute a MD5 over the python source file,
which can be easily achieved with the help of the File-Node from SCons.

Essential resources:
https://scons.org/doc/4.8.0/HTML/scons-user.html#chap-builders-writing

...and the Reference / Manpage of SCons
https://scons.org/doc/4.8.0/HTML/scons-man.html#action_objects

SCons/Action.py
SCons/Node/__init__.py
---
 admin/scons/LumieraEnvironment.py |  66 ++-
 admin/scons/Setup.py              |   2 +-
 wiki/thinkPad.ichthyo.mm          | 820 +++++++++++++++++++++++++++++-
 3 files changed, 866 insertions(+), 22 deletions(-)

diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py
index 19c07c4b5..dd8f8a6fe 100644
--- a/admin/scons/LumieraEnvironment.py
+++ b/admin/scons/LumieraEnvironment.py
@@ -16,7 +16,8 @@
 from os import path
 
 import SCons.SConf
-from SCons.Action import Action
+from SCons.Action import Action, FunctionAction
+from SCons.Script import File as SConsFile
 from SCons.Environment import Environment
 
 from Buildhelper import *
@@ -45,7 +46,8 @@ class LumieraEnvironment(Environment):
         self.Tool("BuilderDoxygen")
         self.Tool("ToolDistCC")
         self.Tool("ToolCCache")
-        register_LumieraResourceBuilder(self)
+        register_LumieraIconBuilder(self)
+        register_LumieraResourceBuilders(self)
         register_LumieraCustomBuilders(self)
     
     def _anchor_relative(self, key):
@@ -124,12 +126,13 @@ class LumieraConfigContext(ConfigBase):
 
 
 
+
 ###############################################################################
 ####### Lumiera custom tools and builders #####################################
 
 
-def register_LumieraResourceBuilder(env):
-    """ Registers Custom Builders for generating and installing Icons.
+def register_LumieraIconBuilder(env):
+    """ Registers a custom Builder for generating and installing Icons from SVG.
         Additionally you need to build the tool (rsvg-convert.c)
         used to generate png from the svg source using librsvg.
     """
@@ -138,13 +141,39 @@ def register_LumieraResourceBuilder(env):
     renderer.rsvgPath = env.subst("$TARGDIR/rsvg-convert").removeprefix('#')
     #                                                    # the prefix '#' is a SCons specific convention,
     #                                                    # which the external tool can not handle
+    #
+    # MD5 signature for this specific python source code...
+    thisCodeSignature = SConsFile(__file__).get_csig() + SConsFile(renderer.__file__).get_csig()
+    thisCodeSignature = bytearray(thisCodeSignature, 'utf-8')
     
-    def invokeRenderer(target, source, env):
-        source = str(source[0])
-        targetdir = env.subst(env.path.buildIcon).removeprefix('#')
-        renderer.main([source,targetdir])
-        return 0
+    
+    class IconRenderAction(FunctionAction):
+        """ SCons Action subclass to provide a controlled cache signature.
+            @note: usually it would be sufficient to pass just a callable to the Builder,
+                   however, our implementation calls into an external Python module and thus
+                   the default signature from SCons would not be stable, since it relies
+                   on a code representation including memory addresses. Without this,
+                   the icons would be frequently rebuilt unnecessarily.
+        """
         
+        def __init__(self):
+            FunctionAction.__init__(self, IconRenderAction.invokeRenderer
+                                        , {'cmdstr' : "rendering Icon: $SOURCE --> $TARGETS"}
+                                   )
+        
+        def get_contents(self, target, source, env):
+            """ a stable signature based on the source code """
+            return thisCodeSignature
+        
+        @staticmethod
+        def invokeRenderer(target, source, env):
+            """ render the SVG icon with libRSVG """
+            source = str(source[0])
+            targetdir = env.subst(env.path.buildIcon).removeprefix('#')
+            renderer.main([source,targetdir])
+            return 0
+    
+    
     def createIconTargets(target,source,env):
         """ parse the SVG to get the target file names """
         source = str(source[0])
@@ -162,6 +191,20 @@ def register_LumieraResourceBuilder(env):
         
         return (generateTargets, source)
     
+    
+    buildIcon = env.Builder( action = IconRenderAction()
+                           , single_source = True
+                           , emitter = createIconTargets
+                           )
+    env.Append(BUILDERS = {'IconRender' : buildIcon})
+
+
+
+
+def register_LumieraResourceBuilders(env):
+    """ Registers further Custom Methods for installing various Resources.
+    """
+    
     def IconResource(env, source):
         """ copy icon pixmap to corresponding icon dir. """
         subdir = getDirname(str(source))
@@ -227,11 +270,6 @@ def register_LumieraResourceBuilder(env):
             return env.InstallAs(toInstall, source) # this renames at target
     
     
-    buildIcon = env.Builder( action = Action(invokeRenderer, "rendering Icon: $SOURCE --> $TARGETS")
-                           , single_source = True
-                           , emitter = createIconTargets
-                           )
-    env.Append(BUILDERS = {'IconRender' : buildIcon})
     env.AddMethod(IconResource)
     env.AddMethod(GuiResource)
     env.AddMethod(ConfigData)
diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py
index 5070f0254..ce97167af 100644
--- a/admin/scons/Setup.py
+++ b/admin/scons/Setup.py
@@ -59,7 +59,7 @@ def defineBuildEnvironment():
     """
     EnsureSConsVersion(2,0)
     EnsurePythonVersion(2,6)
-    Decider('MD5-timestamp')  # detect changed files by timestamp, then do a MD5
+    Decider('content-timestamp')  # detect changed files by timestamp, then do a MD5
     
     buildVars = Variables([OPTCACHE, CUSTOPTFILE])
     Options.defineCmdlineVariables(buildVars)
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index c99e90a7f..9fe5ec78c 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -159345,6 +159345,39 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -168298,6 +168331,9 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
 
 
 
@@ -170257,14 +170293,54 @@ that situation will improve in forseeable future.
 
 
 
+
+
+  
+  
+    
    
+      technical/build/LumieraDebianPackage.html
+    
    
+  
+    
+
+
+  
+  
+    
    
+      enthält auch Beschreibung des Installation-Bundle
+    
    
+  
+    
+
+  
+  
+    
    
+      die ist gut und auch nützlich dort; könnte aber auch übernommen werden in die Beschreibun des Buildsystems
+    
    
+  
+    
+
     
-
-
+
+
+
+
 
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
   
   
@@ -170301,6 +170377,25 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -171942,7 +172037,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -178941,6 +179036,717 @@ env.Chmod(installed[0], 0o644)
 
 
 
+
+
+
+
+  
+  
+    
    
+      ....und jetzt wird's mal Zeit, das aufzuräumen, da ich nun sowiso schon so viel Aufwand in Clean-up gesteckt habe!!!
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      wenn Files als Seiteneffekt erzeugt werden, kann es helfen, explizit ein Manifest-File als HIlfs-Target zu erzeugen
+    
    
+  
+    
+    
+
+
+
+
+    
+
+
+
+  
+  
+    
    
+      ...und wir fügen das erzeugte Objekt per env.Append(BUILDERS=) hinzu. Genau wie in der Doku immer noch dargestellt
+    
    
+  
+    
+    
+
+
+
+
+
+
+  
+  
+    
    
+      Anmerkung: das war alles eine falsche Fährte
+    
    
+  
+    
+    
+    
+
+
+
+
+
+  
+  
+    
    
+      Parsing icons/svg/track-unlocked.svg 
+    
    
+    
    
+      scons: rebuilding `target/gui/icons/24x24/track-unlocked.png' because: 
+    
    
+    
    
+                 `data/icons/svg/track-unlocked.svg' changed 
+    
    
+    
    
+                 `target/rsvg-convert' changed 
+    
    
+    
    
+      rendering Icon: data/icons/svg/track-unlocked.svg --> target/gui/icons/24x24/track-unlocked.png target/gui/icons/22x22/track-unlocked.png target/gui/icons/16x16/track-unlocked.png 
+    
    
+    
    
+      Parsing data/icons/svg/track-unlocked.svg 
+    
    
+  
+    
+    
+
+
+
+
+  
+  
+    
    
+      in tool/SConscript (letzte Zeile)
+    
    
+    
    
+      
    
+        
    
+          # Rendering the SVG Icons depends on rsvg-convert
+        
    
+        
    
+          env.Depends(icons, rsvg)
+        
    
+        
    
+          
+        
    
+      
    
+    
    
+  
+    
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      daß er nämlich wenig systematisch aufgebaut ist, und darauf angewiesen, daß alle Daten korrekt normalisiert sind, und die Aufrufe jeweils richtig erfolgen:
+    
    
+    
      
+      
    • 
+        aufgerufen werden muß auf der Dependency
+      
      • 
+      
    • 
+        aber das 'node'-Argument muß die Node des davon abhängigen Targets liefern
+      
      • 
+      
    • 
+        denn es werden die Dependencies des Targets mit der Build-Information der Source verglichen
+      
      • 
+    
    
+  
+    
+    
+    
+
+
+
+
+
+  
+  
+    
    
+      ...um all die Komplexität von unserem SCons-Build auszuschalten; also praktisch das beispiel für einen Builder mit Emitter aus der Doku nachbauen
+    
    
+  
+    
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      
    
+        
    
+          from SCons.Environment import  Environment
+        
    
+        
    
+          from SCons.Builder import Builder
+        
    
+        
    
+          from SCons.Script import Decider
+        
    
+        
    
+          
    
+          
+        
    
+        
    
+          
    
+          
+        
    
+        
    
+          Decider('content-timestamp')
+        
    
+        
    
+          
    
+          
+        
    
+        
    
+          env = Environment()
+        
    
+        
    
+          bld = Builder(action='(echo -n "FOO `date -Isecond` :"; cat) < $SOURCE > $TARGET')
+        
    
+        
    
+          env.Append(BUILDERS={'Foo': bld})
+        
    
+        
    
+          
    
+          
+        
    
+        
    
+          
    
+          
+        
    
+        
    
+          env.Foo('file.foo', 'file.input')
+        
    
+        
    
+          env.Program('hello.c')
+        
    
+        
    
+          
    
+          
+        
    
+        
    
+          
+        
    
+      
    
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      sondern enthält genau einen Eintrag, nämlich die SOURCE
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      Die Action ist hier ein Python-Objekt
+    
    
+  
+    
+    
+
+
+
+
+
+
+  
+  
+    
    
+      ...und hier wird self (=die Target-Node) als 4.Parameter mitgegeben, die Prüfung erfolgt auf dem child, also der Source-Node
+    
    
+  
+    
+    
+
+
+
+
+  
+  
+    
    
+      was korrekt wit, da auch explain() auf der Source-Node aufgerufen wird
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      scons: rebuilding `target/gui/icons/24x24/track-unlocked.png' because the contents of the build action changed
+    
    
+  
+    
+    
+    
+    
+    
+    
+    
+    
+    
+
+
+
+
+  
+  
+    
    
+      Short answer
+    
    
+    
    
+      Make the Action expose a stable, deterministic signature by providing an explicit string function (strfunction) and/or an explicit variable list (varlist) when creating the Action, and avoid putting non-deterministic values (timestamps, randoms, VM-specific paths) into that signature.
+    
    
+    
    
+      Why
+    
    
+    
    
+      SCons decides whether to rebuild partly from the Action's signature  (a string representing the action) and from node signatures. A Python Action built without an explicit strfunction can produce unstable or overly-broad signatures and cause unnecessary rebuilds.
+    
    
+    
    
+      How (concise example)
+    
    
+    
      
+      
    • 
+        Import SCons Action and make the Python function do the work.
+      
      • 
+      
    • 
+        Provide an explicit strfunction that returns a deterministic string (or a short label).
+      
      • 
+      
    • 
+        Optionally provide varlist to include relevant environment variables in the signature.
+      
      • 
+    
    
+    
    
+      Example:
+    
    
+    
    
+    
    
+      
    
+        python
+      
    
+    
    
+    
    from SCons.Action import Action
+
+def my_build(target, source, env):
+    # do deterministic build steps
+    with open(str(target[0]), "wb") as out:
+        out.write(open(str(source[0]), "rb").read())
+    return None
+
+# deterministic signature string; keep it short and stable
+def my_strfunc(act, target, source, env):
+    return "my_build: %s -> %s" % (",".join([s.path for s in source]), ",".join([t.path for t in target]))
+
+# optionally include env variables that should affect rebuilds
+my_action = Action(my_build, my_strfunc, varlist=['MYFLAG', 'OTHER_VAR'])
+
+env.Command('out.bin', 'in.bin', my_action)
    
+    
    
+      Practical rules
+    
    
+    
      
+      
    • 
+        Provide strfunction (or cmdstr) so the action signature is explicit and stable.
+      
      • 
+      
    • 
+        Use varlist to include only environment variables that legitimately change build output.
+      
      • 
+      
    • 
+        Avoid including timestamps, absolute temp paths, random values, or local-only data in the signature.
+      
      • 
+      
    • 
+        Prefer content-based decider (SCons default) for file changes; only make action signature sensitive to what truly affects outputs.
+      
      • 
+    
    
+    
    
+      Tips & Alternatives
+    
    
+    
      
+      
    • 
+        To debug why SCons rebuilds, run SCons with --debug=explain to see which signature or node change triggered the rebuild.
+      
      • 
+      
    • 
+        If you need fully content-driven rebuilds, ensure the decider is set appropriately and rely on file content signatures rather than variable-heavy action signatures.
+      
      • 
+    
    
+  
+    
+
+
+
+
+
+
+  
+  
+    
    
+      aber ist komplett falsch und irreführend
+    
    
+  
+    
+    
+
+
+
+
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      Muß schon sagen, nach einiger Zeit Debugging bin ich schon wieder am Kotzen. Dieser Stil!!!!
+    
    
+    
    
+      Man akzeptiert irgendwas und geht dann durch eine zigfach verschachtelte Kette von Adaptern, solange bis es irgendwann.... wenn ... dann ... eben doch irgendwie paßt
+    
    
+  
+    
+
+    
+
+
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      die Builder-Funktion in Lumiera ruft ein externes Python-Modul auf
+    
    
+  
+    
+    
+
+
+
+  
+  
+    
    
+      copyMergeDirectory=<function copyMergeDirectory at 0x7f0eeb296ac0>
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      copyMergeDirectory=<function copyMergeDirectory at 0x7f5e85912ac0>
+    
    
+  
+    
+    
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      r-grep über das ganze SCons-Paket gemacht....
+    
    
+    
    
+      Die Klasse erbt von der 'ABC' - Basisklasse (Python-3-Konstrukt). Aber die Argumente von gc(...) sprechen eigentlich dafür, daß das zu SCons gehört
+    
    
+  
+    
+    
+
+
+
+
+  
+  
+    
    
+      Diese Mentalität der Leute macht mich wütend.
+    
    
+    
    
+      Kann man mal sein Hirn einschalten, bevor man loshackt??
+    
    
+    
    
+      Wenn jemand eine eigene Implementierung liefert, dann hat er Gründe dafür und man kann erwarten, daß dann auch der Kontrakt erfüllt wird. Woher wollen die denn wissen, ob eine custom-Implementierung überhaupteine »Varlist« eingeschlossen haben möchte???!!  Zumal die ABC (ActionBase) gar kein Attribut 'self.varilist' hat... das kommt erst im nächsten Layer dazu.
+    
    
+  
+    
+
+    
+    
+
+
+
+
+
+  
+  
+    
    
+      es teht ja nur darum, re-Builds der Icons zu vermeiden
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+    
+
+
+
+
+
+
+  
+  
+    
    
+      ...die Standard-Implementierung dieser get_contents()-Methode vewendet ein Rendering der involvierten Code-Objekte, inklusive der Variablen. Hier würde der IconSvgRenderer auftauchen. Stattdessen setzen wir eine Prüfsumme auf den Python-Quellcode; das Executable rsvog-convert ist sowiso auch noch eine Dependency, und auch Änderungen daran würden erkannt. Und natürlich Änderungen am SVG-Quellcode.
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      ...und das lassen wir SCons machen, das kann das ja sehr gut...
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 

From eb4c49e1b26aa5022331c99bb46d79e320edb686 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Thu, 27 Nov 2025 23:16:30 +0100
Subject: [PATCH 49/51] Build: upgrade, tighten and document the prerequisites
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Many versions enforced with this changeset are chosen such
as to support Ubuntu/Noble (24.04) and otherwise use versions
reasonably close to Debian-Trixie (≙reference-platform)

Since we now require a fairly modern compiler for C++23,
I have added now an explicit version check, which however
is performed only if the defined compiler is named `g++*`

Furthermore, I combed through all of our build tutorials and documentation pages
and updated a lot of information regarding dependencies and build practices...
---
 admin/scons/Platform.py                   |  43 ++-
 admin/scons/Setup.py                      |   6 +-
 doc/technical/build/BuildDependencies.txt | 159 ++++++++---
 doc/technical/build/SCons.txt             |   2 +-
 doc/user/tutorials/DebianBuilding.txt     |   2 +-
 doc/user/tutorials/building.txt           |  59 ++--
 doc/user/tutorials/contributing.txt       |  49 +++-
 wiki/thinkPad.ichthyo.mm                  | 321 +++++++++++++++++-----
 8 files changed, 472 insertions(+), 169 deletions(-)

diff --git a/admin/scons/Platform.py b/admin/scons/Platform.py
index 9edc7de0b..ea11fd9c3 100644
--- a/admin/scons/Platform.py
+++ b/admin/scons/Platform.py
@@ -35,6 +35,23 @@ def configure(env):
     if not conf.TryAction('pkg-config --version > $TARGET')[0]:
         problems.append('We need pkg-config for including library configurations, exiting.')
     
+    # A special check in case we are compiling with GCC...
+    compiler = env.subst('$CXX')
+    verGCCmin = (14,)          # note no trailing zero for version ordering check
+    expectedFeature = 'solid C++23 support'
+    if compiler.startswith("g++"):
+        # verify sufficient compiler version
+        try:
+            import subprocess
+            res = subprocess.check_output([compiler,'-dumpversion'], universal_newlines=True).strip()
+            res = tuple(int(x) for x in res.split('.'))
+        except Exception:
+            res = None
+        #
+        if res and res < verGCCmin:
+            problems.append('The compiler "%s" reports version %s, yet we need at least %s for %s.'
+                           % (compiler, res, verGCCmin, expectedFeature))
+    
     if not conf.CheckLibWithHeader('m', 'math.h','C'):
         problems.append('Did not find math.h / libm.')
     
@@ -60,7 +77,7 @@ def configure(env):
         print('Valgrind not found. The use of Valgrind is optional; building without.')
     
     if not conf.CheckPkgConfig('nobugmt', 201008.1):
-        problems.append('Did not find NoBug [http://nobug.pipapo.org/].')
+        problems.append('Did not find NoBug [https://nobug.pipapo.org/].')
     else:
         conf.env.mergeConf('nobugmt')
     
@@ -84,45 +101,45 @@ def configure(env):
             problems.append('We need boost::program_options (including binary lib for linking).')
     
     
-    if not conf.CheckPkgConfig('gavl', '1.4'):
+    if not conf.CheckPkgConfig('gavl', '2.0'):
         problems.append('Did not find Gmerlin Audio Video Lib [https://github.com/bplaum/gavl].')
     else:
         conf.env.mergeConf('gavl')
     
-    if not conf.CheckPkgConfig('alsa', '1.0.23'):
+    if not conf.CheckPkgConfig('alsa', '1.2'):
         problems.append('Support for ALSA sound output is required')
     
-    if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'):
+    if not conf.CheckPkgConfig('gtkmm-3.0', '3.20'):
         problems.append('Unable to configure the mm-bindings for GTK-3')
     
-    if not conf.CheckPkgConfig('glibmm-2.4', '2.39'):
+    if not conf.CheckPkgConfig('glibmm-2.4', '2.66'):
         problems.append('Unable to configure the mm-bindings for Glib')
     
-    if not conf.CheckPkgConfig('sigc++-2.0', '2.2.10'):
+    if not conf.CheckPkgConfig('sigc++-2.0', '2.12'):
         problems.append('Need the signal-slot-binding library SigC++2')
     
-    if not conf.CheckPkgConfig('glib-2.0', '2.40'):
+    if not conf.CheckPkgConfig('glib-2.0', '2.80'):
         problems.append('Need a suitable Glib version.')
     
-    if not conf.CheckPkgConfig('gthread-2.0', '2.40'):
+    if not conf.CheckPkgConfig('gthread-2.0', '2.80'):
         problems.append('Need gthread support lib for Glib based thread handling.')
     
-    if not conf.CheckPkgConfig('cairomm-1.0', '1.10'):
+    if not conf.CheckPkgConfig('cairomm-1.0', '1.14'):
         problems.append('Unable to configure Cairo--')
     
-    verGDL   = '3.8'    # lowered requirements to allow building on Ubuntu/Trusty & Mint (was originally '3.12')
+    verGDL   = '3.40'  # now orphaned and thus directly provided from Lumiera.org -> can require latest available
     verGDLmm = '3.7.3'
-    urlGDLmm = 'http://ftp.gnome.org/pub/GNOME/sources/gdlmm/'
+    urlGDLmm = 'git://git.lumiera.org/debian/gdlmm'
     urlGDLmmDEB = 'http://lumiera.org/debian/'
     if not conf.CheckPkgConfig('gdl-3.0', verGDL):
         problems.append('GNOME Docking Library not found. We need at least GDL %s '
                         'and suitable C++ ("mm")-bindings (GDLmm >=%s)' % (verGDL, verGDLmm))
     if not conf.CheckPkgConfig('gdlmm-3.0', verGDLmm, alias='gdl'):
         problems.append('We need the C++ bindings for GDL by Fabien Parent: GDLmm >=%s '
-                        '(either from GNOME %s or use the debian package from %s)' %
+                        '(either from %s or use the debian package from %s)' %
                         (verGDLmm, urlGDLmm, urlGDLmmDEB))
     
-    if not conf.CheckPkgConfig('librsvg-2.0', '2.30'):
+    if not conf.CheckPkgConfig('librsvg-2.0', '2.40'):
         problems.append('Need rsvg Library for rendering icons.')
     
     if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'):
diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py
index ce97167af..d4a09fa12 100644
--- a/admin/scons/Setup.py
+++ b/admin/scons/Setup.py
@@ -57,8 +57,8 @@ def defineBuildEnvironment():
         define locations in source and target tree,
         parse the commandline and pick up options
     """
-    EnsureSConsVersion(2,0)
-    EnsurePythonVersion(2,6)
+    EnsureSConsVersion(4,0)
+    EnsurePythonVersion(3,10)
     Decider('content-timestamp')  # detect changed files by timestamp, then do a MD5
     
     buildVars = Variables([OPTCACHE, CUSTOPTFILE])
@@ -83,7 +83,7 @@ def defineBuildEnvironment():
     appendVal(env,'OPTIMIZE', 'CCFLAGS',   val=' -O3')
     appendVal(env,'DEBUG',    'CCFLAGS',   val=' -ggdb')
     
-    # NOTE: could define optional copile features here....
+    # NOTE: could define optional compile features here....
     
     Options.prepareOptionsHelp(buildVars,env)
     buildVars.Save(OPTCACHE, env)
diff --git a/doc/technical/build/BuildDependencies.txt b/doc/technical/build/BuildDependencies.txt
index 38dfe9581..f841c1583 100644
--- a/doc/technical/build/BuildDependencies.txt
+++ b/doc/technical/build/BuildDependencies.txt
@@ -1,7 +1,7 @@
 Build Dependencies
 ==================
 :Author: core-devs
-:Date: 2/2020
+:Date: 11/2025
 :toc:
 
 
@@ -10,26 +10,52 @@ We try to get the best out of modern system programming
 techniques to reach a solid performance and good throughput.
 Lumiera shall scale with the provided Hardware,
 the more RAM and the more/faster CPU's you have the better.
-Nevertheless lower end 32bit machines are supported too.
+Nevertheless lower end 64bit machines are supported too.
 
 Secondary targets will be other free operating systems which offer a decent Posix API.
 Porting to other more or less similar platforms will be possible, if -- by coincidence --
 Someone(TM) helps with porting.
 
-Having said that -- for the time being, the core team won't spend much effort on porting.
+Having said that -- for the time being, the core team won't spend much effort on porting,
+be it to special hardware or some other popular OS.
+
 
 Platform
 --------
-We develop and test on standard PC hardware, 32 and 64 bit.
+We develop and test on standard PC hardware, 64 bit.footnote:[
+  We attempt to write code mostly in a portable way, yet we have encountered
+  several aspects now where our solution effectively assumes 64bit layout --
+  and thus the code might compile on 32bit, but then not perform as expected.
+  A notorious example are _hash values_, which are typed as `size_t` following
+  the C++ idiom. We now use a hash function that is clearly optimised for 64bit,
+  and we know that a 32bit hash would produce collisions on a regular base, while
+  our solution assumes that collisions can be ruled out effectively. This is just
+  one example, which shows that handling such aspects in a portable fashion, while
+  certainly possibly, requires a significant amount of design work and incurs
+  additional complexity.
+  For the time being, we are content to document such cases as tickets.
+]
 It is intended to target other platforms running GNU/Linux eventually.
-Lumiera expects a `standard' desktop installation running a XServer.
+Lumiera expects a ``standard'' desktop installation running a XServer.footnote:[
+  Wayland is ``just around the corner'' since 10 years now. Well, recently it
+  seems it is _really_ just around the corner. We are aware of the necessary
+  changes, which are not very complicated to implement (since we are using
+  GTK-3). However, as long as Wayland simply crashes or hands in our
+  everyday work setup with XFCE, we will not consider this topic
+  a priority. In the meantime, please report any problems
+  you encounter with Lumiera running on XWayland.
+]
 
 Graphics::
-  There are no special requirements for the graphic system.
-  Hardware acceleration will likely be added later through extensions,
-  but will remain strictly optional.footnote:[For the time being, we'll watch
-  the evolution in that area and might revisit that topic when there are more
-  compelling and widely supported solutions available]
+  There are no special requirements for the graphic system, other than
+  some GPU supported for common desktop display in the standard setup.
+  Hardware acceleration for video processing will likely be added later
+  through extensions,  but will remain strictly optional.footnote:[
+    For the time being, we'll watch the evolution in that area
+    and might revisit that topic when there are more compelling
+    and widely supported solutions available. Support for 32bit
+    floating point data formats is considered more important.
+  ]
 
 Disks::
   No special requirements. Video editing requires decent disk speed though,
@@ -42,6 +68,7 @@ Special Hardware::
 * Specs and APIs must be open.
 * someone to do the actual interfacing and support needs to join the team
 
+
 Compatibility
 ~~~~~~~~~~~~~
 We try to keep our depdendencies close to Debian/stable and the most recent Ubuntu LTS.
@@ -54,55 +81,101 @@ Languages and Tools
 
 * C / C++
 
- - a C99 / C++17 compatible compiler footnote:[in practice, we build using GCC and
-   occasionally we check using Clang]
- - GCC *7* or Clang *6* should be fine footnote:[basically we try to use just the stock language.
-   On rare occasions in the past, we _did_ use some GCC extensions, like `typeof()`, but we care for
-   workarounds, in case this becomes a problem. Incidentally, `typeof()` is obsoleted by the new
-   C++ standard, which provides `decltype()` for this purpose.].
+ - A C\+\+23 compatible compiler is required.footnote:[
+     In practice, we build using GCC and occasionally we check using Clang.
+     Right now (7/2025) Clang has fallen behind regarding support of type dependent
+     name resolution in templates and does not even comply with C++20 in this respect.
+     We have dropped most usages of the `typename` keyword recently, and as long as
+     Clang can not cope with that, we have to postpone further tests with Clang.
+   ]
+ - GCC-**14** or better should be fine.footnote:[
+     Basically we try to use just the stock language.
+     But we actually compile with the GNU extensions, i.e. `-std=gnu++23` / `-std=gnu99`.
+     And any language feature is used to the degree that it is available and stable
+     in this build environment.
+   ]
 
 * BOOST (listed below are the Debian package names)
- - libboost-dev (at least *1.67*)
- - libboost-program-options-dev
+ - libboost-dev (at least *1.83*)
  - libboost-program-options-dev
 
 * Script languages
- - Python (*2.x*) might still be handy for build scripts.footnote:[SCons supports both Python 2.x
-   and Python 3.x transparently. Basically there is no reason to stick to Python 2.x -- just the standard
-   python is not yet switched on Debian/stable, and so we might miss out on some scripts.]
+ - Python (*3.10*) required for building (->SCons)
  - bash (some test scripts use bash specific extensions)
 
 Build Tools
 ~~~~~~~~~~~
 
-* Git
-* SCons *2.0* footnote:[we build with SCons >= 3.0 since a long time. However, since the times of 2.0,
-  there are no major breaking improvements we rely on -- so chances are that the Build works fine with
-  older versions. In addition, we use some SCons plug-ins, which are all shipped in-tree (`admin/scons`)]
+* https://www.scons.org/[SCons build system] v**4.8** footnote:[
+    Unfortunately, SCons still sets the conceptual standard how a modern build system should be:
+    It is declarative, defines the _what_ and not the _how_ and uses build scripts written in
+    a clean and modern language (Python).
+    Autotools should be considered legacy, and CMake turned out to be rather disappointing and
+    lacks adequate conceptual grounding. Meson has a somewhat more modern appeal, yet seems to
+    require us to do much more work to get even remotely to that level of clarity and flexibility
+    which we enjoy every day when working with SCons. +
+    We are aware of the shortcomings of SCons in practice however, notably that it is not widely
+    known and thus requires additional learning effort, and that it could become prohibitively
+    slow on very large projects. At the current project size, the delay on incremental builds
+    does not really seem relevant in practice, given that C++ compilation as such is slow anyway.
+    We are not aware of using any notable features of SCons beyond v2.0, and we use some SCons
+    plug-ins, which are all shipped in-tree (directory 'admin/scons')]
 * pkg-config
-* Doxygen
+* Doxygen (optional)
+* Asciidoc (optional)
+* Git -> https://git.lumiera.org/?p=LUMIERA;a=summary[git://git.lumiera.org/LUMIERA]
+  footnote:[
+    _Ichthyo_ maintains a repo at https://github.com/Ichthyostega/Lumiera/[Github ^~Ichthyostega/Lumiera^]
+  ]
 
-We maintain a link:/documentation/technical/infra/debianDepot.html[Debian/Ubuntu package] (relying on debhelper, CDBS, git-buildpackage)
+💡 We maintain a link:{ldoc}/technical/infra/debianDepot.html[Debian/Ubuntu package] (based on `git-buildpackage`)
 
 Libraries
 ~~~~~~~~~
 
-* BOOST
-* link:http://nobug.pipapo.org/[NoBug]
+* https://www.boost.org/[Boost libraries]
+* https://nobug.pipapo.org/[NoBug library]
 * https://github.com/bplaum/gavl[GAVL] (for raw media support)
-* ALSA: libasound2-dev
-* for the GUI: (*GTK-3*) gtkmm-3.0 gdlmm-3.0 glibmm-2.4 cairomm-1.0 xv
- - libgtkmm-3.0-dev
- - libcairomm-1.0-dev
- - libglibmm-2.4-dev, requiring at least glib2.0 (2.40 or better) and gthread-2.0
- - libxv-dev footnote:[for the XV viewer widget `gui/output/xvdisplayer.cpp`
-     -- currently obsolete as of [yellow-background]#5/2015#][yellow-background]#TODO 5/2015# and X-lib
- - librsvg-2.0 and librsvg2-dev for rendering Icons
- - libgdl-3 (3.12 or better) through libgdlmm-3 -- the »Gnome Docking Library«footnote:[GDL isn't directly related to GNOME any more.
-   We contributed to the improvement of this library in the past. These improvements went upstream
-   with GDL-2.27. At times, we used to ship our own GDL package. Right now, a recent upstream version
-   together with the corresponding *mm-bindings will do. We provide a debian package for the latter,
-   until they will be available in the official Debian/Ubuntu/Mint repos. But we don't have any
-   special requirements on these `gdlmm` bindings.]
+* https://www.alsa-project.org/[ALSA (libasound2-dev)]
+* for the GUI: (*GTK-3*) gtkmm, glibmm-2.4, cairomm-1, gdlmm-3, Xv
+ - libgtkmm-3.0-dev (`>=3.20`)
+ - libglibmm-2.4-dev (`>= 2.66`), requiring at least glib2.0 (`>=2.80`)
+ - libcairomm-1.0-dev (`>= 1.14`)
+ - librsvg2-dev (`>=2.40`) for rendering Icons
+ - libxv-dev footnote:[
+     For the time being, this is a placeholder and fallback to integrate
+     any technology for displaying video frames on the dektop. It is now used in the
+     XV viewer widget 'stage/output/xv-displayer.hpp|cpp' -- currently expected
+     to be obsolete soon, but it is yet [yellow-background]#undecided as of 11/2025#
+     what we use as starting point for video output from the Lumiera Render Engine.
+     XV might be retained as a fall-back solution, the libraries GLX or EGL might be used...
+   ]
+   and X-lib ^[yellow-background]#TODO 11/2025#^
+ - libgdl-3-dev (`>= 3.40`) through libgdlmm-3 -- the »Gnome Docking Library«footnote:[
+     https://gitlab.gnome.org/Archive/gdl.git[lib GDL] isn't directly related to GNOME any more.
+     We use this library for docking panels in the GUI with GTK-3. This solution was maintained
+     for some time by the »Anjuta« project -- we also contributed to the improvement of this library
+     in the past, and these improvements went upstream with GDL-2.27. Unfortunately, GDL was abandoned
+     meanwhile. and we do not see a clear pathway for the future here, short of upgrading to GTK-4,
+     which is possible, but would require some considerable effort. As of 2025, GDL is still usable,
+     but no longer available through the standard distribution channels. +
+     We provide a Git repository at our Website for
+     https://git.lumiera.org/?p=debian/gdl;a=summary[libGDL (3.40) +git://git.lumiera.org/debian/gdl+]
+     and the
+     https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL C++ bindings (3.7.3) +git://git.lumiera.org/debian/gdlmm+]
+     and we maintain custom Debian packages for both in our
+     link:/debian/[Debian DEB depot].
+   ]
 
+''''
 
+.Documentation and Resources
+[TIP]
+--
+* Tutorial link:{ldoc}/user/tutorials/building.html[Building Lumiera from source]
+* Tutorial link:{ldoc}/user/tutorials/DebianBuilding.html[Building the »Debian Way«]
+* About the link:{ldoc}/technical/build/LumieraDebianPackage.html[Lumiera Debian Package]
+* About the link:{ldoc}/technical/build/SCons.html[SCons Build-System of Lumiera]
+* About the link:{ldoc}/technical/code/index.html[Code Base Organisation]
+* link:/debian/[Lumiera Debian DEB depot]
+--
diff --git a/doc/technical/build/SCons.txt b/doc/technical/build/SCons.txt
index e4341cb11..cd4acb7e2 100644
--- a/doc/technical/build/SCons.txt
+++ b/doc/technical/build/SCons.txt
@@ -18,7 +18,7 @@ Synopsis
 --------
 [cols=">, all cores
+| just build Lumiera: | scons -j#            | # ≔ number of CPUs
 | build + run Tests:  | scons -j# check      | -> see 'target/,testlog'
 | development build:  | scons -j# testcode   | -> `target/test-suite `
 | install:            | scons -j# install    | installs below '/usr/local/', ⚠ sudo
diff --git a/doc/user/tutorials/DebianBuilding.txt b/doc/user/tutorials/DebianBuilding.txt
index 1af8aa542..d0f461fba 100644
--- a/doc/user/tutorials/DebianBuilding.txt
+++ b/doc/user/tutorials/DebianBuilding.txt
@@ -63,7 +63,7 @@ the build. You need to _install_ these packages then using the basic Debian pack
 manager `dpkg`
 +
 ----
-sudo dpkg -i libnobug2_201008.1-1_i386.deb nobug-dev_201008.1-1_i386.deb
+sudo dpkg -i libnobug2_201008.1-4~trixie_amd64.deb nobug-dev_201008.1-4~trixie_amd64.deb
 ----
 +
 of course, the package names, versions and architecture will vary, depending on your
diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt
index a5c390c0d..5323570eb 100644
--- a/doc/user/tutorials/building.txt
+++ b/doc/user/tutorials/building.txt
@@ -1,6 +1,6 @@
 Building Lumiera from source
 ============================
-:Date: 2020
+:Date: 2025
 :toc:
 
 At the moment you can build Lumiera, start the standard Lumiera GUI and run the
@@ -46,33 +46,33 @@ authoritative information about the build dependencies is encoded into the
 link:{ldoc}/technical/build/SCons.html[build system]. Thus, when the build
 system aborts, indicating that a never version of some library is required,
 then usually the build system is right...]
-More specifically, you'll need the GNU C/C\++ compiler with C++17 support (Version >= 7)
+More specifically, you'll need the GNU C/C\++ compiler with C++23 support (Version >= 14)
 in addition to the following tools and libraries:
 
  * https://git-scm.com/[Git] (version management system)
  * https://www.scons.org/[SCons build system]
  * https://www.boost.org/[Boost libraries]
  * https://github.com/bplaum/gavl[GAVL library]
- * https://nobug.pipapo.org/[NoBug] (see below)
- * Lumiera source code
+ * https://nobug.pipapo.org/[NoBug] ~([purple]#⚠ see below#)~
+ * Lumiera https://git.lumiera.org/?p=LUMIERA;a=summary[source code]
 
 The GUI depends on the following:
 
  * https://gtkmm.gnome.org/en/[gtkmm]
  * https://cgit.freedesktop.org/xorg/lib/libXv[libXv]
  * https://wiki.gnome.org/Projects/LibRsvg[lib rSVG]
- * https://gitlab.gnome.org/Archive/gdl.git[lib GDL]
+ * https://gitlab.gnome.org/Archive/gdl.git[lib GDL] ~([purple]#⚠ see below#)~
 
 TIP: Generally speaking, when you want to build software, you'll need the
 _development_ version of the packages that contain the headers and pre-built
 libraries to link against. These packages are usually named `-devel` or `-dev`.
 
-For Debian based systems, e.g. Mint, Ubuntu..., you can install these packages as follows:
+For Debian based systems, e.g. Ubuntu, Mint... you can install these packages as follows:
 
 -------------------------------------------------------------------------------------
-sudo apt-get install build-essential scons git-core valgrind intltool \
-libboost-dev libboost-program-options-dev \
-libgavl-dev libgtkmm-3.0-dev libgdl-3-dev librsvg2-dev libxv-dev
+sudo apt-get install build-essential g++ git pkgconf scons intltool \
+libboost-dev libboost-program-options-dev libasound2-dev libgavl-dev \
+libgtkmm-3.0-dev librsvg2-dev libxv-dev
 -------------------------------------------------------------------------------------
 
 
@@ -91,17 +91,23 @@ Lumiera Specific Libraries
 Now that you have your basic build environment prepared, the next step is to care
 for some special libraries required by Lumiera that are not directly part of the
 Lumiera project itself, but aren't readily available through the usual package
-manager of the common distributions either. footnote:[we maintain our own Debian
-package depot at Lumiera.org and provide binary Debian packages for a range of
-distributions; yet this tutorial strives at showing the basic and generic method
-for building. Thus we'll show you here how to build these libraries from source
-yourself] Thus, we'll have to get the source code for these support libraries,
+manager of the common distributions either.footnote:[
+  We maintain our own
+  link:/debian/[Debian package depot at Lumiera.org]
+  and provide binary Debian packages for a range of distributions;
+  yet this tutorial strives at showing the basic and generic method for building.
+  Thus we'll show you here how to build these libraries from source yourself --
+  however, in many cases it can be more convenient to use the DEB packages
+  we provide, if applicable, for these extra library dependencies of Lumiera
+  and just care for building the Lumiera main tree on your system.
+]
+Thus, we'll have to get the source code for these support libraries,
 build and install them before we're able to compile Lumiera.
 
 WARNING: Note that the following procedures will try to install files into your
-base system below `/usr/local`. +
-To do so, you'll need administrative permission for the machine you're working
-on. These additions might interfere with other libraries installed by your
+base system below '/usr/local'. +
+To do so, you'll need [red]#administrative permission# for the machine you're
+working on. These additions might interfere with other libraries installed by your
 package manager (if you get into trouble updating your system later on,
 you might have to manually remove these libraries).
 
@@ -208,24 +214,31 @@ footnote:[more options for building with scons can be found via: `scons -h` ]
 -----------------
 git clone git://git.lumiera.org/LUMIERA
 cd LUMIERA
-scons
+scons -j#
 -----------------
 
-maybe build and run the test suite by issuing `scons check`
-
 The build process will take some time, so sit back and relax.
+You can use for `#` (at least) the number of cores available on your system
+to speed up the build -- but it will take several minutes even for a debug
+build and significantly more for an optimised release build (-> see `scons -h`)
+
+And if you feel like waiting even more, you might build and run the test suite
+by issuing `scons -j# check`...
+
 
 NOTE: you do not need to _install_ Lumiera. It will find all files it requires
 relative to the directory structure it generates, which is freely relocatable
-as a whole. Just invoke the +target/lumiera+ executable. The current
+as a whole. Just invoke the 'target/lumiera' executable. The current
 working directory is not particularly relevant.
 
 After the build has finished successfully, you should be able to start Lumiera.
-Currently, this will bring up the GUI, _without any further functionality_ (!)
+Currently, this will bring up the GUI, _without much further functionality_ (!)
 
 You should see something like this:
 
-image:/images/lumiera_gui_small.png[Current Lumiera GUI Screenshot]
+image:{imgg}/lumiera20250823.png["Current Lumiera GUI Screenshot",width=650]
+
+-> 💡 see link:{ldoc}/user/manual.html#_ui_experiments[here] for some demo features available...
 
 
 What's next?
diff --git a/doc/user/tutorials/contributing.txt b/doc/user/tutorials/contributing.txt
index a647e7fcf..440733825 100644
--- a/doc/user/tutorials/contributing.txt
+++ b/doc/user/tutorials/contributing.txt
@@ -1,7 +1,7 @@
 Contributing to Lumiera
 =======================
 :Author: Benny 
-:Date: Oct 2013
+:Date: Oct 2013 · Nov 2025
 :toc:
 
 
@@ -86,12 +86,12 @@ Lumiera. These additional packages are of two kinds:
 
 Packages normally available with your distribution::
   for a Debian based system (including Mint, Ubuntu and similar flavours),
-  you should be able to install the necessary dependencies with the command
+  you should be able to install the necessary dependencies with the command...
 +
 -------------------------------------------------------------------------------------
-sudo apt-get install build-essential scons git-core valgrind intltool \
-libboost-dev libboost-program-options-dev \
-libgavl-dev libgtkmm-3.0-dev libgdl-3-dev librsvg2-dev libxv-dev
+sudo apt-get install build-essential g++ git pkgconf scons intltool \
+libboost-dev libboost-program-options-dev libasound2-dev libgavl-dev \
+libgtkmm-3.0-dev librsvg2-dev libxv-dev
 -------------------------------------------------------------------------------------
 Packages not normally part of your distribution::
   there are two packages most likely not available with your operating system
@@ -101,7 +101,7 @@ Packages not normally part of your distribution::
   - *NoBug* -- a diagnostics library
 +
 ------------------------------------------------------------
-git clone git://git.pipapo.org/nobug
+git clone git://git.lumiera.org/debian/nobug
 cd nobug
 autoreconf -i
 mkdir build && cd build
@@ -109,22 +109,43 @@ mkdir build && cd build
 make
 sudo make install
 ------------------------------------------------------------
-  - **mm**-bindings for *GDL* -- a window docking library footnote:[GDL itself _is_
-    available through the standard package manager, in a version compatible to GTK-3.
-    What is not yet available are the corresponding C++ bindings `gdlmm-3`]
+  - the *libGDL* with **mm**-bindings -- a window docking library footnote:[
+      GDL is compatible with GTK-3 and was available through the standard package manager,
+      but was orphaned in 2021. Since it is currently a prerequisite for building Lumiera,
+      we maintain a clone of the original repository and a Debian package on Lumiera.org.
+      This is relevant both for
+      https://git.lumiera.org/?p=debian/gdl;a=summary[libGDL (3.40) +git://git.lumiera.org/debian/gdl+]
+      and the
+      https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL C++ bindings (3.7.3) +git://git.lumiera.org/debian/gdlmm+].
+    ]
+
+    * first you have to build libGTL itself...
 +
 ------------------------------------------------------------
-git clone git://git.lumiera.org/debian/gdlmm
-cd gdlmm
-./configure
+git clone git://git.lumiera.org/debian/gdl
+cd gdl
+git checkout master
+./autogen.sh
 make
 sudo make install
 ------------------------------------------------------------
 
+     * then followed by building the C++ bindings...
++
+------------------------------------------------------------
+git clone git://git.lumiera.org/debian/gdlmm
+cd gdlmm
+git checkout master
+./autogen.sh
+make
+sudo make install
+------------------------------------------------------------
+
+
 Start the Lumiera build process::
 ------------------------------------------------------------
 cd LUMIERA
-scons
+scons -j#
 ------------------------------------------------------------
 
 If Lumiera is built correctly on your system, you should be able to shoot up
@@ -197,7 +218,7 @@ Finally you can *push* your changes to the Lumiera server on the 'mob'
 repository:
 
 ------------------------------------------------------------
-$ git push git://git.lumiera.org/lumiera/mob master:refs/heads/YOURNAME
+$ git push git://git.lumiera.org/lumiera/mob master:YOURNAME
 ------------------------------------------------------------
 
 This creates a new branch +YOURNAME+ on the mob repository.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 9fe5ec78c..c7f392f3f 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -166815,8 +166815,8 @@ that situation will improve in forseeable future.
 
 
 
-
-
+
+
 
 
 
@@ -170170,9 +170170,9 @@ that situation will improve in forseeable future.
 
 
 
-
-
-
+
+
+
 
 
 
@@ -170690,22 +170690,23 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
-
 
-
-
+
+
 
+
 
 
-
-
+
+
+
 
 
-
-
+
+
 
 
 
@@ -170715,10 +170716,15 @@ that situation will improve in forseeable future.
 
 
 
+
 
 
-
-
+
+
+
+
+
+
 
 
 
@@ -171094,20 +171100,51 @@ actively maintained upstream. Please remove gdl from Debian.
 
 
 
-
-
-
+
+
+
+
+
+
 
 
 
 
 
 
-
-
-
+
+
+
+
+
+
+
+  
+  
+    
    
+      Das betrifft auch das Thema »Video-Output«, zu dem Benny und ich einen Vortrag auf der FrOSCon25 gehalten haben. In dem Zusammenhang haben wir uns Basiskenntnisse in OpenGL und Shader-Programmierung angeeignet, aber beschlossen, das Thema vorerst noch nicht zu priorisieren — für die Integration von Lumiera genügt es wenn »irgendwie« Video ausgegeben werden kann....
+    
    
+  
+    
     
-
+
+
+  
+  
+    
    
+      ...rückt jetzt immer näher, in viele Distributionen wird er derzeit reingedrückt; für mich selber kommt Wayland aber erst in Frage, wenn er auf XFCE stabil läuft und mein »pragmatisches Farbmanagement« dadurch nicht gefärdet wird. Vermutlich bedeutet das, daß ich dazu erst mal mich von meiner UrUrUralten Grafikkarte trennen muß... (die sowiso nur noch für Debian/Trixie ein letztes Mal mit dem Tesla-Treiber unterstützt wurde). Haha, ich arbeite immer noch zufrieden und glücklich mit Hardware von 2011, das soll mir erst mal jemand nachmachen
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+
 
 
 
@@ -171599,7 +171636,7 @@ actively maintained upstream. Please remove gdl from Debian.
 
 
 
-
+
 
 
 
@@ -171983,9 +172020,9 @@ Since then others have made contributions, see the log for the history.    
     
     
-
-
-
+
+
+
 
 
 
@@ -172014,9 +172051,9 @@ Since then others have made contributions, see the log for the history.    
     
     
-
-
-
+
+
+
 
 
 
@@ -172071,7 +172108,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -172292,7 +172329,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
   
   
@@ -172320,6 +172357,26 @@ Since then others have made contributions, see the log for the history.
 
 
+
+
+  
+  
+    
    
+      Oh weh!
+    
    
+    
    
+      Hätte ich das Thema doch bloß nicht angefaßt ... das war jetzt mehr als ein Tag ekelhafte Debugging-Arbeit, und ich hab nun Interna von SCons gesehen, die ich lieber nicht wissen würde....
+    
    
+    
    
+      
+    
    
+    
    
+      Meine Einschätzung bleibt allerdings trotzdem, daß SCons konzeptionell  eines der modernsten Buildsysteme ist, das ich kenne, und das einzige unter Linux geläufige Buildsystem, das auch nur anähernd zeitgemäß ist. Auch wenn die Implementierung dann sowohl »pythonisch«, alsauch „hemdsärmelig“ ist.....
+    
    
+  
+    
+
+    
     
     
 
@@ -172644,7 +172701,7 @@ Since then others have made contributions, see the log for the history.
 
     
-
+
 
 
 
@@ -172664,8 +172721,8 @@ Since then others have made contributions, see the log for the history.
 
 
-
-
+
+
 
 
 
@@ -178143,9 +178200,9 @@ Since then others have made contributions, see the log for the history.
 
 
-
-
-
+
+
+
 
 
 
@@ -178476,22 +178533,23 @@ Since then others have made contributions, see the log for the history.
 
 
-
-
-
+
+
+
 
 
-
+
 
 
 
 
 
 
-
-
-
-
+
+
+
+
+
 
 
 
@@ -178510,7 +178568,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
   
   
@@ -178519,8 +178577,9 @@ Since then others have made contributions, see the log for the history.
   
 
+
 
-
+
 
   
   
@@ -178529,22 +178588,123 @@ Since then others have made contributions, see the log for the history.
   
 
-
-
-
-
-
-
+
+
+
+
+  
+  
+    
    
+      das ist derzeit tatsächlich verbindlich ... und auch relativ knapp so, weshalb es im Buildsystem gecheckt werden sollte
+    
    
+  
+    
+
+
+
+  
+  
+    
    
+      ...im Grunde ist das gegen den Basis-Kontrakt, daß man lediglich »einen Compiler« verlangt...
+    
    
+  
+    
+
     
-
+
+
 
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      Das berücksichtigt auch Ubuntu-Noble(24.04), ist aber derzeit auch genau der Level, der in Debian-Trixie standardmäßig zum Einsatz kommt
+    
    
+  
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      ist keine direkte Dependency mehr
+    
    
+  
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
+
+
+
 
 
 
@@ -178561,25 +178721,34 @@ Since then others have made contributions, see the log for the history.    
     
     
-
-
+
+
 
-
-
+
 
   
   
     
    
-      ...naja, nicht wirklich, denn dazu müßte ich mal die ganze SCons-Doku durhclesen, um zu sehen, was man modernisieren könnte. Aber da ich nun nur noch mit entsprechend neuerer Software arbeite, ist es auch nicht mehr angemessen, eine niedrigere Version zu deklarieren, da ich nicht merke, wenn ich neuere Feature verwende, die irgendwo im Internet beschrieben sind.
+      explizite Wahl, wegen Ubuntu/Noble
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      ...naja, nicht wirklich, denn dazu müßte ich mal die ganze SCons-Doku durhclesen, um zu sehen, was man modernisieren könnte. Aber da ich nun nur noch mit entsprechend neuerer Software arbeite, ist es auch nicht mehr angemessen, eine niedrigere Version zu deklarieren, da ich nicht merke, wenn ich neuere Feature verwende, die irgendwo im Internet beschrieben sind. Konkret bin ich jetzt auf SCons 4.8 (habe 4.10 Features explizit noch nicht verwenden können). Allerdings ist Ubuntu-Noble erst auf 4.5 (hoffen wir mal daß das alles gut geht...)
     
    
   
     
     
     
     
-
+
 
-
+
 
 
 
@@ -178703,9 +178872,18 @@ Since then others have made contributions, see the log for the history.    
     
     
-
+
+
+  
+  
+    
    
+      Lifecycle/Start-up ist immer noch nicht failsafe ⟶ auf später vertagt, da es zusätzlich verkompliziert ist durch das Design des Subsystem-Runners, das eine zusätzliche Fehlerbehandlung jenseits der Event-Loop schwierig macht; und ich bin mit diesem Design ohnehin nicht zufrieden, betrachte es aber nicht als ein dringendes Problem
+    
    
+  
+    
 
 
+
     
     
 
@@ -179036,7 +179214,7 @@ env.Chmod(installed[0], 0o644)
 
     
     
-
+
 
 
 
@@ -179048,7 +179226,7 @@ env.Chmod(installed[0], 0o644)
   
 
 
-
+
 
 
 
@@ -179197,7 +179375,7 @@ env.Chmod(installed[0], 0o644)
 
 
 
-
+
 
 
 
@@ -179239,7 +179417,7 @@ env.Chmod(installed[0], 0o644)
 
 
 
-
+
 
   
   
@@ -179431,7 +179609,7 @@ env.Chmod(installed[0], 0o644)
 
 
 
-
+
 
 
 
@@ -182176,6 +182354,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
 
 
 

From 797174ef194f0e836a3401e5b7499da78ab01578 Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Fri, 28 Nov 2025 20:23:55 +0100
Subject: [PATCH 50/51] Release: extensive makeover of Build and Debian
 documentation

On the Website, there is a set of interconnected pages related
to compiling from source, the Debian package and our DEB depot.

Although these pages have always been superficially kept up-to-date,
the overall presentation feels dated and generally not well organized.
During the last weeks, I have almost entirely rewritten all those pages,
added information about the (now reworked) DEB package, explained the
alternate ways to build from a Debian source package (notably the
`mk-build-deps` for handling the build dependencies, which effectively
the only method which always worked during the last years, since our
DEB package was totally outdated)

Furthermore, I have tested most of the build steps with the current
source trees, repositories and package definition, and finally I
have also updated and polished the front-page of our DEB-Depot
(-> see commit on the depot-Branch)

Wheew ... quite some work done!
---
 doc/technical/build/LumieraDebianPackage.txt | 158 +++--
 doc/technical/build/index.txt                |   5 +-
 doc/technical/infra/debianDepot.txt          | 154 +++--
 doc/user/tutorials/DebianBuilding.txt        | 441 +++++++++-----
 wiki/thinkPad.ichthyo.mm                     | 589 +++++++++++++++++--
 5 files changed, 1051 insertions(+), 296 deletions(-)

diff --git a/doc/technical/build/LumieraDebianPackage.txt b/doc/technical/build/LumieraDebianPackage.txt
index 88f95a228..9d374613f 100644
--- a/doc/technical/build/LumieraDebianPackage.txt
+++ b/doc/technical/build/LumieraDebianPackage.txt
@@ -1,107 +1,151 @@
 The Lumiera Debian Package
 ==========================
 :Author: Hermann Voßeler deb@ichthyostega.de
-:Date: 11/2011
+:Date: 11/2011 · 11/2025
 
 //Menu: label Debian Package
 
 Since several of the Lumiera core developers run a Debian flavour as their primary development platform,
-it seems natural to care for the debian packaging of Lumiera ourselves. Moreover, we've declared
-Debian/Stable to be our *reference platform* -- we'll provide any additionally required, more recent
-packages through our own link:http://Lumiera.org/debian[Debian Apt-Repository] (Debian depot).
+it seems obvious also to care for the Debian packaging of Lumiera. Furthermore, we have declared
+Debian/Stable to be our *reference platform* -- and we will provide any required additional
+packages through our own link:/debian[Debian DEB depot] (for the Apt package manager).
 
 TIP: readers new to Debian packages may want to have a look into our
-     link:{ldoc}/user/tutorials/DebianBuilding.html[Debian build tutorial],
+     link:{ldoc}/user/tutorials/DebianBuilding.html[Debian Build Tutorial],
      where we describe the commands for building and explain the structure
      of a Debian (source) package in general
 
 
 Package build process
 ---------------------
-As our whole infrastructure relies heavily on the Git version management tool, it's only natural
-also to organise the (debian) packaging with the help of Git. Fortunately, there is a nifty tool
+As our whole infrastructure relies heavily on the Git version management tool, it seems natural
+to organise also the (Debian) packaging with the help of Git. Fortunately, there is a nifty tool
 called link:https://honk.sigxcpu.org/piki/projects/git-buildpackage/[git-buildpackage], written
 by Guido Günther exactly for this purpose: It treats the _debianisation_ as a branch in the
 Git repository, forking off the mainline at the release point.
+~ -> see also https://wiki.debian.org/PackagingWithGit[Debian packaging with Git (Debian Wiki)]~
 
-For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the
-link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git:/git.lumiera.org/debian/lumiera] repository.
+For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the Repository
+https://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git://git.lumiera.org/debian/lumiera].
 
 Installing Lumiera
 ~~~~~~~~~~~~~~~~~~
-The link:SCons.html[SCons build] generates a relocatable distribution directory structure,
-holding the main executable, additional tools and utilities, plus the core libraries and resources.
+The link:SCons.html[SCons build] generates a distribution directory structure, which is relocatable,
+comprising the main executable, additional tools and utilities, plus the core libraries and resources.
 Here _relocatable_ means that this subtree can be moved and placed anywhere on the system.
 As long as the relative directory layout remains intact, the executables will be able to find
-and load the accompanying libraries and resources. By invoking the `scons install` target,
-this directory structure is placed into the installation target directory.
+and load the accompanying libraries and resources. By invoking the `install` target, this
+directory structure is placed into the target installation directory, with an layout
+conforming to the Filesystem Hierarchy Standard.
 
 Actually, this lookup process at application startup is performed in two phases
 
-- in the first phase the main application locates the explicitly linked shared libraries.
-  footnote:[generally speaking, we have to distinguish between dynamic libraries explicitly
-  linked as part of the application, libraries linked as direct library dependencies, other
-  transitive library dependencies, and finally shared objects, which are loaded at runtime
-  through the `dlopen()` call.]
-  Especially those libraries belonging first class to the Lumiera application are built
-  with a relative search path ('rpath' with `$ORIGIN` token). These libraries are placed
-  into the +modules/+ subfolder
+- in the first phase the main application locates the explicitly linked shared libraries.footnote:[
+    Generally speaking, we have to distinguish between dynamic libraries explicitly
+    linked as part of the application, libraries marked and linked as direct library dependencies,
+    other transitive library dependencies, and finally shared objects, which are loaded at runtime
+    as »plug-in« through the `dlopen()` call.
+  ]
+  Some parts of the Lumiera code are built as shared library, but are non the less considered
+  a mandatory part of the application. Especially those libraries are built with a relative
+  search path ('rpath' with `$ORIGIN` token), and will be placed  into the 'modules/' subfolder
+  This implies that the dynamic linker will look for this subfolder in the same directory as
+  the `lumiera` executable and will fail to launch the application unless all those further
+  mandatory application components can be located.
 
-- after successfully launching the executable, the second phase performs a lookup programmatically,
-  starting from the path location of the executable. The goal is to find a +setup.ini+ which defines
-  additional plug-ins and resources to load. Notably, the GUI to launch is loaded as a
-  plug-in through this mechanism. Moreover, this *bootstrap configuration* defines the
+- after successfully launching the executable, the second start-up phase performs a programmatic
+  lookup, starting again from the path location of the executable. The goal is to find a file 'setup.ini'
+  which defines additional plug-ins and resources to load. Notably, the GUI to launch is loaded as
+  a plug-in through this mechanism. Moreover, this *bootstrap configuration* defines the
   additional platform and user configuration to load for further outfitting of the system.
 
-LSB Installation Layout
+
+FHS Installation Layout
 ~~~~~~~~~~~~~~~~~~~~~~~
-This organisation is used as foundation for packaging and installing. The primary application
-distribution structure will be located into a subfolder below +/usr/lib/+. Only the main application
-executable will be symlinked into +/usr/bin/+. The LSB explicitly allows for such a layout, which is
-typically used by large application bundles (OpenOffice, Gimp, Eclipse). Since the application
-startup encompasses two phases, loading the extended configuration programmatically after
-launching the application, extended resources from the application bundle can easily be
-relocated into a separate folder below `/usr/share/`, as required by LSB.
+So this organisation of the application executables and resources into an installation bundle in a
+subdirectory tree is used as foundation for packaging and installing. The primary application
+distribution structure with all the executable code will be placed into a sub-tree below
+'/usr/lib/lumiera'. Only the main application executable `lumiera` will then be symlinked into '/usr/bin/'.
+This pattern is in accordance with the
+https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard[Filesystem Hierarchy Standard (FHS)],
+and it is typically used by large application bundles (e.g. Libreoffice, Firefox-esr).
+Since the application startup of Lumiera encompasses two phases, where loading the extended configuration
+happens programmatically after launching the main application, all extended (platform-independent)
+resources from the application bundle can easily be relocated into a separate folder
+below `/usr/share/lumiera`, as required by FHS.
+
+How the Lumiera Debian package works
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Since we maintain both the Debian package and our build system, we can always try to do
+_the heavy lifting_ in our link:{ldoc}/technical/build/SCons.html[SCons build system],
+as this helps to keep the Debian packaging as simple as possible. Please have a look at the
+-> https://git.lumiera.org/?p=debian/lumiera;a=blob;hb=refs/heads/deb;f=debian/control[control file]
+·  https://git.lumiera.org/?p=debian/lumiera;a=blob;hb=refs/heads/deb;f=debian/rules[debian/rules]
+
+- we rely on the _Debhelper Sequencer_ "`dh_*`" in our 'debian/rules' +
+  -> https://manpages.debian.org/trixie/debhelper/dh.1.en.html[Manpage]
+  ·  https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules[Debian-Policy §4.9]
+
+- but we define three _override targets_ in order to invoke SCons explicitly,
+  so that it is immediately clear what configuration is passed to the build.
+
+- we configure SCons with `INSTALLDIR=debian/lumiera PREFIX=usr`, and thus
+  the installation will happen below 'debian/lumiera', which is the location
+  expected by the following DEB building steps
+
 
 
 Releases, Branches and Conventions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Official releases are marked by a tag on the master branch. At that point, master should be
-in good shape, release documentation is polished; experimental features are removed or disabled.
-Usually, we'll also fork a  *release branch* at that point, featuring bugfixes only.
-From here we'll merge to the **debian branch**footnote:[the 'release' branch will be merged back at
-times, while the 'debian' branch won't. This 'debian' branch is published through a separate
-link:git://git.lumiera.org/debian/lumiera[debian/lumiera git repository] and not merged back,
-since all tweaks here are strictly for debian packaging. There might be other packaging related
-repositories in the future. Yet still, the 'debian' branch is based on the same common tree
-and can in therory kept in the same git repository. Contrast this to the branch 'depot', which
-is also published through our 'debian/lumiera' git repository. This latter branch corresponds
-to a completely separate tree and holds the administrative part of our
-link:http://Lumiera.org/debian[Debian package depot] (Repository) on Lumiera.org.]
+Lumiera uses the link:{ldoc}/technical/code/GitBranching.html[Git-flow branching pattern]
+to organise releases and patches in the Git history. All official releases are marked by
+_a tag on the master_ branch. This tag is published in the primary Lumiera repository at
+`git://git.lumiera.org/LUMIERA` at the time of the release. Bugfixes are also merged
+into `master` and marked with a tag there.
 
-Typically the release will lead to the discovery of more or less serious bugs, which are
-fixed on the release branch and backported to master. The result is a sequence of point
-releases. At the end of a stable release series, the release branch will be upgraded
-with a single merge commit to the level of the next major release.
+For the actual packaging, we use these release tags as _upstream tag_ and perform a merge
+from that tag into the **debian branch**.footnote:[
+  This _debian branch_ is called `deb` by convention. As mentioned above, it is published through
+  a separate https://git.lumiera.org/?p=debian/lumiera;a=summary[Git repository `git://git.lumiera.org/debian/lumiera`],
+  which is kept separate, since packaging is considered a ``downstream process''.
+]
+This branch carries only the additions and tweaks done for debian packaging. Yet still, this `deb`
+branch is based on the common tree of the codebase and could in theory be kept within the same Git
+repository as the `master` branch. When the packaging process is complete, the published
+DEB version is marked with a tag `debian/`
+
+Note however that there is another branch in the aforementioned `debian/lumiera` repository,
+which is called https://git.lumiera.org/?p=debian/lumiera;a=shortlog;h=refs/heads/depot[depot]
+and is related to our link:/debian[DEB package depot] on Lumiera.org. This branch carries a completely
+different directory structure, since it is used with the
+https://wiki.debian.org/DebianRepository/SetupWithReprepro[»reprepro« tool from Debian]
+to manage the contents of that depot.
 
 
 Package build commands
 ~~~~~~~~~~~~~~~~~~~~~~
 To (re)build the debian package
 
-. +git clone git:/git.lumiera.org/lumiera/debian+
-. +mkdir pack.deb+
-. +cd debian+
-. +git-buildpackage --git-upstream-branch=+ _RELEASE-TAG_
+. step into a packaging work directory
+. `git clone git://git.lumiera.org/debian/lumiera -b deb`
+. `cd lumiera`
+. `gbp buildpackage`
+
+Typically you will have to install some _build dependencies_ before you can
+build the package. This can be checked by invoking `dpkg-checkbuilddeps` from
+within the package directory (here 'lumiera'). These dependencies can be
+managed automatically with the Debian tooling, by using one of the following
+two alternative solutions
+
+- `apt-get build-dep lumiera` (requires Lumiera DEB depot in the apt sources)
+- invoking `mk-build-deps` from within the package directory (requires `equivs` package)
 
--- here _RELEASE-TAG_ denotes the point in the Git history, which should become
-the reference source and be packaged into the *.orig.tar.gz. Usually, it's just
-sufficient to use branch 'release' for that purpose.
 
 
 Debian-Depot for installation via Apt
 -------------------------------------
 In addition to the packaging, we maintain a dedicated Apt-Repository for automated
 installation and upgrades. We try to build the package for several Debian derived
-distributions (like Ubuntu). -> link:../infra/debianDepot.html[more on the repository organisation]
+distributions (like Ubuntu).
+-> link:{ldoc}/technical/infra/debianDepot.html[more on the repository organisation]
 
diff --git a/doc/technical/build/index.txt b/doc/technical/build/index.txt
index f43416c42..cd8ef9424 100644
--- a/doc/technical/build/index.txt
+++ b/doc/technical/build/index.txt
@@ -8,12 +8,11 @@ As work progresses, we will add more information on the Lumiera build system.
 //Menu: prepend child 'SCons'
 
 
-build -- continuous integration -- packaging
+Topics: build -- continuous integration -- packaging
 
 * link:SCons.html[SCons Buildsystem]
 * link:BuildDependencies.html[Lumiera Build Dependencies]
-* link:BuildDroneDraft.html[»Builddrone« concept from 2008]
-* Packaging: link:LumieraDebianPackage.html[Debian] RPM
+* Packaging: link:LumieraDebianPackage.html[Debian] (⌛ RPM)
 * Lumiera link:{ldoc}/technical/infra/debianDepot.html[debian depot]
 
 
diff --git a/doc/technical/infra/debianDepot.txt b/doc/technical/infra/debianDepot.txt
index bd9b2e439..12f5cb32f 100644
--- a/doc/technical/infra/debianDepot.txt
+++ b/doc/technical/infra/debianDepot.txt
@@ -1,49 +1,57 @@
-Lumiera Debian Package and Depot maintainance
-=============================================
+Lumiera Debian Depot maintenance
+================================
 :Author: Hermann Voßeler deb@ichthyostega.de
-:Date: 3/2011
+:Date: 3/2011 · 11/2025
 
 //Menu: label Debian Depot
 
+
+At Lumiera.org, we maintain a link:/debian[Debian DEB depot],
+that can be used as _package source_ for Apt to allow automatic installation
+of our custom packages for Lumiera.
+
 This Debian-Depot is part of the Lumiera build infrastructure.
-It is managed automatically, based on the
-https://salsa.debian.org/brlink/reprepro[reprepro] tool by Bernhard Link
--> https://manpages.debian.org/trixie/reprepro/reprepro.1.en.html[man page]
+It is managed (semi) automatically, based on the
+https://salsa.debian.org/brlink/reprepro[reprepro] tool by Bernhard Link +
+-> https://wiki.debian.org/DebianRepository/SetupWithReprepro[Debian Wiki]
+·  https://manpages.debian.org/trixie/reprepro/reprepro.1.en.html[man page]
 
 
 The Lumiera debian package
 --------------------------
-As our whole infrastructure relies heavily on the Git version management tool, it's only natural
-also to organise the (debian) packaging with the help of Git. Fortunatlely, there is a nifty tool
+Since our whole infrastructure relies heavily on the Git version management tool, it seems natural
+to organise also the (debian) packaging with the help of Git. Fortunately, there is a nifty tool
 called link:https://honk.sigxcpu.org/piki/projects/git-buildpackage/[git-buildpackage], written
-by Guido Günther exactly for this purpuse: It treats the _debianisation_ as a branch in the
+by Guido Günther exactly for this purpose: It treats the _debianisation_ as a branch in the
 Git repository, forking off the mainline at the release point.
 
-For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the
-link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git:/git.lumiera.org/debian/lumiera] repository.
+For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the Repository
+https://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git://git.lumiera.org/debian/lumiera].
 
-To (re)build the debian package
+.(re)build the debian package
+[NOTE]
+--
+. step into a packaging work directory
+. `git clone git://git.lumiera.org/debian/lumiera -b deb`
+. `cd lumiera`
+. `gbp buildpackage`
 
-. +git clone git:/git.lumiera.org/debian/lumiera+
-. +mkdir pack.deb+
-. +cd debian+
-. +git-buildpackage --git-upstream-branch=+ _RELEASE-TAG_
-
--- here _RELEASE-TAG_ denotes the point in the Git history, which should become
-the reference source and be packaged into the *.orig.tar.gz. Usually, it's just
-sufficient to use 'master' for that purpose.
+-> more explanations regarding the
+link:{ldoc}/technical/build/LumieraDebianPackage.html[Lumiera Debian package]
+--
 
 
 Debian-Depot for installation via Apt
 -------------------------------------
-While it is easy just to build a debian package and then install it locally through
-+dpkg -i+, if we want to support automated installation and upgrades using the Apt
-package manager, we need to build up more infrastructure. The primary reason is that
-for any source package, a multitude of binary packages might be built for different
-architectures; moreover, we want to support several different distributions.
+It is rather easy to build a simplistic DEB package and then install it locally through
+`dpkg -i` -- however, if we want to support automated installation and upgrades using
+the Apt package manager, we need to build up more infrastructure. One of the reasons
+is that for any source package, a multitude of binary packages might be built and
+provided for different architectures; in addition, we also want to support several
+different distributions (Debian, Mint, Ubuntu...)
 For this purpose,the Apt package manager requires a precisely defined folder structure,
-accessible online via 'http:' or 'ftp:'. For maintaining this folder structure, there
-are three concievable levels of complexy:
+accessible online via 'https:' or 'ftp:'. For maintaining this folder structure, three
+different levels of complexity are conceivable:
 
 minimal layout, manual maintainance::
   place everything in a single directory accessible online. Use only one pseudo-distribution
@@ -51,80 +59,104 @@ minimal layout, manual maintainance::
   the packages list
 
 multiple distributions and components, pool directory::
-  this setup is already a full-blown debian depot, just there are some limitations
+  this setup is already a full-featured Debian depot, just there are some limitations
   on the flexibility: there might be only _one_ version of each package per distribution,
   and all different distributions use a shared pool (and thus require different packages
   to be labeled stringently)
 
 major distribution or mirror site::
-  similar to the above, this is a complete debian depot, but it is backed by a database
+  similar to the above, this is a complete Debian depot, but it is backed by a database
   and allows for much more flexible configuration and is highly automated.
 
 
 For Lumiera, it seems the middle option is the right choice: while it still keeps the
 infrastructure simple, it allows for multiple _distributions_ (Debian/stable, Ubuntu....)
-and multiple _components_ (experimental, development, release). The mentioned 'reprepro'
-tool provides this degree of functionality: Basically, this is a fixed directory structure
-with some control files; the frontent is a commandline tool with a plethora of options
-and quite some automation- and extension hooks. Internally, it uses an embedded BerkelyDB.
+and multiple _components_ (experimental, development, release). The `reprepro` tool
+mentioned above does provide this degree of functionality: Basically it requires a fixed
+directory structure with some control files; the front-end is a commandline tool with a
+lot of options and quite some automation- and extension hooks.
+Internally, it uses an embedded lightweight database.
 
-Using 'reprepro', existing source, binary or comined packages can be _added_ (imported)
+Using `reprepro`, existing source, binary or combined packages can be _added_ (imported)
 into the structure with a single command; the files comprising the package are then
 added automatically to the pool directory and all the indices, directories and GPG
 signatures are created and updated automatically. Previous versions of the same
-package are purged, when not needed by any existing package anymore
+package are purged, when not referred by any existing package anymore
+
+To summarise the work procedure:
+
+. somehow build the DEB package
+. import it with `reprepro` into the depot folder structure
+. share this structure over the web
+
 
 everyday usage
 ~~~~~~~~~~~~~~
 
 import a package::
-  +reprepro -V -C experimental include squeeze lumiera_0.pre.03-1+jessie_i386.changes+
+  `reprepro -V -C experimental include trixie  lumiera_0.pre.04-1_amd64.changes`
 +
 this adds the given binary lumiera package, together with all sources and the original
-tarball to the 'squeeze' repository, into the 'experimental' section
+tarball to the `trixie' repository, and there into the `experimental' section
 
 dump out an entire repository::
-  +reprepro -V export squeeze+
+  `reprepro -V export trixie`
 +
 this will __re__generate all of the indices, signatures and metadata of the 'squeeze' repository
 
 
 Configuration
 ~~~~~~~~~~~~~
-The current configuration and the state of the Debian Depot index files is tracked
-is a separate branch in the
-link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=shortlog;h=refs/heads/depot[debian/lumiera]
-repository. (Note: this is a somewhat unconventional setup, insofar the 'depot' branch tracks
-a directory tree completely separete from the main lumiera source tree tracked by the deb branch;
-I choose this layout because of the marginal relevance of this depot management; I just didn't
-want to create _yet another not so useful Git repository..._)
+All the current configuration and the state of the Debian depot index files is tracked
+in the aforementioned ``debian/lumiera'' Git repository, on a separate branch called
+https://git.lumiera.org/?p=debian/lumiera;a=shortlog;h=refs/heads/depot[`depot']
+
+TIP: this is a slightly unconventional setup, insofar the `depot' branch carries
+     a directory tree that is completely separate from the main Lumiera source tree, which
+     is tracked by the deb branch in the same repository... +
+     I did choose this layout because of the marginal relevance of this depot management;
+     I just did not want to create __yet another not so useful repo...__
+
+The details of our configuration and the current state can be seen here...
+
+ * primary https://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=conf/distributions;hb=refs/heads/depot[configuration]
+ * Logfile of imports: https://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=log/trixie.log;hb=refs/heads/depot[for Debian/Trixie]
+ * Logfile of imports: https://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=log/noble.log;hb=refs/heads/depot[for Ubuntu/Noble]
 
- * primary link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=conf/distributions;hb=refs/heads/depot[configuration]
- * Logfile of imports: link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=log/squeeze.log;hb=refs/heads/depot[for Debian/Squeeze]
 
 [NOTE]
-.some special details to note in our setup
+.Details to note in our setup
 =======================================================================================================================
-- each block in the 'distributions' file defines a repository for a ``distribution'' (e.g. Jessie, Trusty, Rafaela).
+- each block in the file 'conf/distributions' defines a repository for a ``distribution'' (e.g. Trixie, Forky, Noble).
   Within such a repo, there are sections named 'Components'.
 - The _override_ files mentioned in the configuration allow to overwrite / replace arbitrary fields in the metadata of
-  all packages added to that distribution.
-- In this setup, we enabled the 'tracking' function: thereby reprepro will keep track of the dependencies between
+  all packages added to that distribution (We do not currently use this feature however).
+- In this setup, we enabled the _tracking_ function: thereby `reprepro` will keep track of the dependencies between
   binary packages, signatures, debianisation patches and original upstream tarballs. Never packages overwirte older
   ones -- _at any time there is at most one version of a package in the repository._ Parts not referred to anymore
-  are automatically discareded. In our configuration, they are moved into the 'morguedir'
-- Please make sure the *gpg signing key* is in proper order, because it protects against evil spirited manipulations.
-
+  will be discarded automatically. In our configuration, they are moved into the 'morguedir'
+- Please be sure that the *GPG signing key* is maintained properly and kept secure,
+  because it protects our users against evil spirited manipulations by powerful entities.
 =======================================================================================================================
 
 
-current setup 3/2011
-^^^^^^^^^^^^^^^^^^^^
-While later we want to automate most of this packaging business, currently it's done semi-manual.
-Mostly, Ichthyo builds the packages on his local PC (or a VM) and then adds/imports them to the
-'reprepro' -- changes are then propagated to lumiera.org via rsync; as kind of a backup, the
-index files are also pushed to link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=shortlog;h=refs/heads/depot[Git].
+current setup 2025
+^^^^^^^^^^^^^^^^^^
+While we plan to automate most of this packaging business eventually, currently our releases
+and the packaing tasks are performed in a semi-manual fashion. This means that we use some base
+level automation (like `git-buildpackage` or `mk-build-deps` or `reprepro`) -- but the manifests
+and changelogs are maintained manually and the steps for building and importing are launched
+one by one at the console. Our _preview releases_ happen only occasionally and each of them
+changes and breaks a lot, so that an effort towards a higher level of automation seems futile.
+
+Typically, _Ichthyo_ builds the packages on his local PC in suitable Docker/Podman containers
+and adds/imports them into the `reprepro` -- changes are then propagated to Lumiera.org via rsync,
+and the changed index files are checked into the `depot` branch and pushed into
+https://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git://git.lumiera.org/debian/lumiera].
+
+The rsync to upload is done with
 ----
-rsync -rclvz --progress --partial --delete /local/filesys/path/to/Lumirep/depot/ ichthyo@www.lumiera.org:/var/local/www_debian
+rsync -rclvz --progress --partial --delete \
+  /local/path/to/Lumirep/depot/ ichthyo@www.lumiera.org:/var/local/www_debian
 ----
 
diff --git a/doc/user/tutorials/DebianBuilding.txt b/doc/user/tutorials/DebianBuilding.txt
index d0f461fba..de86c4432 100644
--- a/doc/user/tutorials/DebianBuilding.txt
+++ b/doc/user/tutorials/DebianBuilding.txt
@@ -1,146 +1,358 @@
-building from source -- the »Debian Way«
-========================================
+Building Lumiera -- the »Debian Way«
+====================================
 :Author: Ichthyostega
-:Date: 3/2011
+:Date: 3/2011 · 11/2025
 :toc:
 
-In case you're using a Debian-based system (e.g. Mint, Ubuntu...), there
-is a simple alternative to the manual compiling and installing of library
-dependencies. Instead of building Lumiera from source in the classical (hard)
+Building Lumiera becomes much simpler if you are using a Debian-based
+Linux system (e.g. Mint, Ubuntu...). Instead of having to build Lumiera
+and further required libraries step by step from source the classical (hard)
 way, you might prefer *building from the Debian source packages*.
 
-Why -- what are the benefits?
+Why so -- what are the benefits?
 
- * rely on the Debian/Ubuntu package manager for sorting out the library
-   and build dependencies
+ * let the Debian/Ubuntu package manager sort out the build dependencies
+ * have a controlled environment where the build is already known to work
+ * have a single common interface for starting any build process
  * install Lumiera as a first-class package, like all the other software
-   you're using regularly. This way, the package manager ``knows'' about
-   the library dependencies and can't mix up things due to a system upgrade.
+   you're using regularly. So that the package manager ``knows'' about all
+   the library dependencies and handles conflicts at next system upgrade.
 
-Under some circumstances, these very benefits might be a drawback, though.
-Sometimes you don't want to install; or you might have a version of Lumiera
-installed, but want to try out a (maybe newer / development) version...
+Sometimes these very benefits might be a drawback; if you need more
+flexibility, you can treat the Debian tooling like a construction kit,
+where you can choose which part of the automation you want to employ...
 
-No problem -- basically it is always possible to run Lumiera _without installation._
-We deliberately constructed the application such as to find its components actively,
-within the standard directory structure created by the buildsystem. However, while,
-Lumiera itself can be just run directly from such a folder tree, the software still
-relies on some other libraries, which somehow need to be installed on your system.
+There are various variants to consider:
+
+- Bootstrap into a newer distro version, by using only the source packages
+  provided for another roughly similar platform
+
+- Use the prerequisite libraries from the link:/debian[DEB depot at Lumiera.org]
+  and only use our Debian source package to setup the build of Lumiera itself.
+
+- Avoid to add any (custom) Apt repository source: only download the
+  source pacakge(s) and build them directly
 
 
-building from source package
-----------------------------
+
+Building from a Debian source package
+-------------------------------------
+A _Debian source package_ is the complete ``upstream'' source tree plus
+a 'debian' subdirectory with build configuration. This is a very controlled
+setup which allows the _Debian build tooling_ to automate most of the build process.
+
 NOTE: Generally speaking, operations which _modify_ the installation/configuration of your
-linux system require root permissions. To the contrary, just _building_ a package
+Linux system require [red]#root# permissions. To the contrary, just _building_ a package
 should _not_ be done as root.
 
-. add a suitable source line to your *Apt configuration* ('/etc/apt/sources.lst')
-+
+.Prerequisites for building
+For performing any compiling and packaging tasks, you need some additional software,
+which by default isn't installed on a desktop system -- most notably the GNU C compiler.
+On any Debian based system, you get this basic tooling by
 ----
-deb-src https://lumiera.org/debian/ buster experimental
-----
-. get all the *build dependencies*
-+
-----
-sudo apt-get build-dep nobug-dev
-sudo apt-get build-dep gdlmm-3
-sudo apt-get build-dep lumiera
-----
-. *build* using the source package.
-+
-----
-apt-get source --compile nobug-dev
+sudo apt-get install build-essential devscripts equivs
 ----
 
-  * After building went through without error, it might happen that you're be
-    prompted for signing with your GPG key. But because you're not going to upload
-    the created binary packages anywhere, this step can be considered optional.
+The Lumiera DEB depot
+~~~~~~~~~~~~~~~~~~~~~
+At link:/debian[Lumiera.org/debian] we provide the Debian packages maintained
+by the project in a setup that can be added as _package source_ with your
+Apt package manager. If you trust us to do our work properly (are you really
+ready to trust us?), then installation and upgrades of the packages provided
+this way can be handled automatically
 
-  * install the created package.
+[[LumieraAptCfg]]
+. add a suitable source spec to your *Apt configuration*
 +
-Finally, you'll find several new +*.deb+ packages in the directory where you started
-the build. You need to _install_ these packages then using the basic Debian package
-manager `dpkg`
+('/etc/apt/sources.list.d/lumiera.sources')
 +
 ----
-sudo dpkg -i libnobug2_201008.1-4~trixie_amd64.deb nobug-dev_201008.1-4~trixie_amd64.deb
+Types: deb deb-src
+URIs: https://lumiera.org/debian/
+Suites: trixie
+Components: experimental
+Signed-By: /etc/apt/keyrings/lumiera-keyring.gpg
 ----
+
+. get and install _Ichthyo's_ **GPG signing** public key
+
+  * This key has GPG key fingerprint +11FD F5D2 DBD7 BBD7 F4D9  D9C4 2CF2 5392 6238 2557+
+  * It can be found on many public keyservers, like
+    link:http://keyserver.ubuntu.com:11371/pks/lookup?search=2CF2539262382557&op=index[Ubuntu] or
+    link:https://keys.openpgp.org/search?q=deb%40ichthyostega.de[Openpgp.org].
 +
-of course, the package names, versions and architecture will vary, depending on your
-situation.
+.Apt requires a signing key installed into the system in _binary format_
+[IMPORTANT]
+--
+After fetching this public key, you need to store it in binary format at a suitable
+location (typically '/etc/apt/keyrings'), and [red]#owned by root# (not writable by ordinary users).
+This location can then be referred to from the source configuration `lumiera.sources` -- as showed above
+----
+gpg --keyserver keyserver.ubuntu.com --recv 62382557
+gpg --export 62382557 > lumiera-keyring.gpg
+----
+--
 
-  * repeat those steps to work your way up to the +lumiera+ package; build and install
-    Nobug, maybe build and install the GDL mm-bindings and finally build and install Lumiera
-
-. clean up.
+. you should be able now to refresh the package lists without any error...
 +
-You can delete the source tree used for compiling. If you never intend to
-re-install the package, you could also delete the created package and source package
-components after installing it. But especially when trying out development versions
-it might be a good idea to stash those packages somewhere, as we're not keeping _every_
-package in the online Lumiera Debian depot. While any package could be reproduced
-exactly with a bit of Git knowledge, just keeping the `*.deb` might be more convenient.
+----
+sudo apt update
+----
 
-*That's it* -- you're done! Debian building is convenient, isn't it?
+💡[underline]#Tip#: for added protection against unintended package upgrades,
+you may mark the Lumiera Apt source configuration with a _lowered priority_ in the
+file '/etc/apt/preferences'
+----
+Package: *
+Explanation: Lumiera-Repository
+Pin: release o=Lumiera.org
+Pin-Priority: 60
+----
+^The default priority here is 500, and priorities < 100 will never be updated automatically.^
 
-NOTE: What follows is a background information and configuration for advanced users.
-      You can safely skip and ignore the remainder of this page if in doubt.
+
+How to build from a Debian source package
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You need a work directory where to download, store and expand the DEB packages. +
+Over time, you will accumulate a lot of packages and sub directories there... 😀
+
+Build dependencies::
+  Install all build dependencies for a package +
+  `sudo apt-get build-dep `
+
+Complete build::
+  Retrieve and immediately build from a source package +
+  `apt-get source --compile `
+
+Retrieve::
+  Download and unpack source package from the Repositories +
+  `apt-get source `
+
+Unpack::
+  Unpack a source package which you have downloaded manually +
+  `dpkg-source --extract  [target-dir]`
+
+Build::
+  Build DEBs from an already extracted source package +
+  `cd ; debuild -b`
+
+[TIP]
+--
+* Obviously, all the package names, versions and architecture will vary, depending on your situation.
+* After building went through without error, it might happen that you're be
+  prompted for signing with your GPG key. But because you're not going to upload
+  the created binary packages anywhere, this step can be considered optional.
+
+Install created packages::
+  After a successful build, you'll find several new '*.deb' packages in the directory
+  above the source package tree. If you want to use those packages as prerequisites for
+  the next package, you need to _install_ these packages into your system using the basic
+  Debian package manager `dpkg`
++
+----
+sudo dpkg -i  [...]
+----
+
+Clean up::
+  You can delete the source tree used for compiling. If you never intend to
+  re-install the package, you could also delete the created package and source package
+  components after installing it. But especially when trying out development versions
+  it might be a good idea to stash those packages somewhere, as we're not keeping _every_
+  package in the online Lumiera Debian depot. While any package could be reproduced
+  exactly with a bit of Git knowledge, just keeping the `*.deb` might be more convenient.
+
+--
+
+
+Bootstrap Lumiera starting from a source package
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following section describes the complete build sequence, where you start with
+the Lumiera source package repository, possibly even for another distribution.
+So, for example, you might be on Ubuntu/Resolute, but start from the source
+package entry in the Lumiera repository for Debian/Trixie.
+
+. Add the source repository to your Apt configuration, as described
+  xref:LumieraAptCfg[above]. Use the proper ``Suites'' entry; if this is
+  anoter distro than you are currently on, you might want to use only the
+  `Types: deb-src` (source packages, but not the binary packages)
+
+. build and install NoBug
+
+  * `apt-get build-dep nobug`
+  * `apt-get source --compile nobug`
+  * install with: +
+    `sudo dpkg -i libnobug2_201008.1-4~trixie_amd64.deb nobug-dev_201008.1-4~trixie_amd64.deb`
+
+. build and install libGDL
+
+  * `apt-get build-dep gdl`
+  * `apt-get source --compile gdl`
+  * install the `libgdl-3-5*deb` and `libgdl-3-common*deb` and `libgdl-3-dev*deb` packages
+
+. build and install the C++ bindings GDLmm
+
+  * `apt-get build-dep gdlmm3`
+  * `apt-get source --compile gdlmm3`
+  * install the `libgdlmm-3.0*deb` and `libgdlmm-3-dev*deb`
+
+. now you are ready for Lumiera...
++
+--
+* `apt-get build-dep lumiera`
+* `apt-get source --compile lumiera`
+--
++
+If all went well, you can launch it right away as `lumiera-0.pre.04/target/lumiera`
+
+*That's it* -- __building the Debian way is convenient, isn't it?__
+
+
+
+Building from Debian source package without Apt repo
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This is a variation of the procedure and can be used when you can not
+(or do not want to) rely on the Lumiera DEB depot configured into your system.
+Instead, we somehow get / download and extract the respective source
+packages and then use the `mk-build-deps` helper from the `devscripts`
+to create a pseudo-package on the fly, which depends on all the
+build dependencies of a package.
+
+. For this to work we somehow need to get the source package downloaded
+  into the local system. There are several ways to achieve that
++
+--
+* You may use Git to check out our Debian packaging repositories:
++
+----
+git clone git://git.lumiera.org/debian/nobug -b deb
+git clone git://git.lumiera.org/debian/gdl   -b deb
+git clone git://git.lumiera.org/debian/gdlmm -b deb
+git clone git://git.lumiera.org/debian/lumiera -b deb
+----
+
+* Alternatively, you may browse the
+  link:/debian/pool[package pool] and download the packages with your web browser;
+  note that for each source package, you need to download three components
++
+--
+  ** the `.orig.tar.xz` (or .gz or whatever...)
+  ** the _debianisation_ called `.debian.tar.xz`
+  ** the source package descriptor `.dsc`
+--
++
+After downloading those components, you need to extract them manually:
++
+----
+dpkg-source -x 
+----
+--
+
+
+. Next we need to install the build dependencies
+
+  * step into the root of the extracted package tree
+  * invoke `sudo mk-build-deps --install --remove`
+
+    ** if all works well, this will result in Apt proposing to
+       download and install a huge load of further packages;
+       confirm this with `y' ...
+    ** but it might happen that some dependency can not be satisfied,
+       in which case `mk-build-deps` aborts and removes already installed parts.
+       You need to figure out from the printed messages then what was the reason
+       why the dependencies can not be satisfied (💡 in the case of Lumiera,
+       typically the reason lies in the fact that `nobug-dev`, `libgdl-3-dev` and
+       `libgdlmm3-dev` are not available from the official package repositories;
+       you may need to build and install them yourselves...)
+
+. Then, finally we can build the package itself: +
+  step into the package tree and invoke: `debuild -b`
+
+TIP: The `mk-build-deps` tool reads the package manifest and fabricates a
+     pseudo-package, which is called `-build-deps`, (e.g. 'lumiera-build-deps').
+     This package gets installed into your system and thereby ``pulls in'' all the
+     required build dependencies. This setup remains in place even when you update
+     your system, and thus ensures that the ability to build this package is not lost.
+     Once you do no longer need this special configuration, you can _manually remove_
+     this package (e.g. `sudo apt remove lumiera-build-deps`), and then clean-up by
+     invoking `sudo apt autoremove` to get rid of all packages which are no longer
+     required...
+
+''''
+~What follows is background information and configuration for advanced users.~ +
+^💡 You can safely skip and ignore the remainder of this page if in doubt.^
+....
+​
+​
+​
+​
+....
+
+
+
+
+More about Debian source packages
+---------------------------------
+Building packages from Git
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+This tutorial describes the classic way of building a Debian package, which also is the
+foundation for any shortcuts and convenience scripts. In practice, people maintaining
+Debian packages happen to use various shortcuts and helper scripts to automate repetitive
+tasks. One such helper especially worth mentioning is
+https://wiki.debian.org/PackagingWithGit[the tool `git-buildpackage`]. With a little bit
+of configuration, this cleverly made tool is able to create a full Debian package just
+form a Git checkout in a single shot. At Lumiera.org, we maintain all our Debian packages
+this way, so the necessary configuration 'debian/gbp.conf' is already in place.
+
+To use the NoBug package for illustration, the procedure to build a package is:
+
+. `git clone git://git.lumiera.org/debian/nobug -b deb`
+. `cd nobug; sudo mk-build-deps --install --remove`
+. `gbp buildpackage --git-tag`
+
+-> more about our link:{ldoc}/technical/infra/debianDepot.html[DEB depot at Lumiera.org]
 
 
 Required and recommended Debian packages
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The Debian package manager stores for each package not only the required prerequisites,
-but also some additional _recommended_ packages: Software likely to make using the given
-package more convenient or improve the usage in some way. In addition, it also stores
+but also some additional _recommended_ packages: This is software likely to make using the
+given package more convenient or improve the usage in some way. In addition, it also stores
 a list of _suggested_ additional things to try. Now, since some time, the 'Apt' package
 management tool by default automatically installs also the _recommended_ software, not
 only the bare required prerequisites.
 
-While this is certainly fine for users not into the details of package management, it
-has the downside of installing sometimes _a lot_ of additional software no one asked
-about. Plus, all these installed packages are upgraded from time to time. An impressive
-example of this kind of _bloat_ is the *asciidoc* package, which recommends to install
-dockbook, an complete XML toolchain plus a TeX distribution, giving you an average of
+While this is certainly fine for users not interested in the details of package management,
+this setup has the downside of installing sometimes _a lot_ of additional software no one
+ever asked about. Plus, all these installed packages are upgraded from time to time. An
+impressive example of this kind of _bloat_ is the *asciidoc* package, which recommends to
+install Dockbook, a complete XML toolchain plus a Teχ distribution, giving you an average of
 additional 500MB to download and install.
 
 Of course, this behaviour can be changed. Just add the following line to your Apt configuration
 ----
 APT::Install-Recommends "false";
 ----
-^_Disclaimer:_ please be sure you understand the consequences...^
+⚠^_Disclaimer:_ please be sure you understand the consequences...^
 
 
-Building packages from git
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-This tutorial describes the classic way of building a Debian package, which also is the
-foundation for any shortcuts and convenience scripts. In practice, people maintaining
-Debian packages happen to use various shortcuts and helper scripts to automate repetitive
-tasks. One such helper especially worth mentioning is **git-buildpackage**. With a little bit
-of configuration, this nifty script is able to create a full Debian package just form a
-git checkout in a single shot. At Lumiera.org, we maintain all our Debian packages this
-way, so the necessary configuration +debian/gbp.conf* is already in place.
 
 
-''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-The rest of this tutorial contains some more in-depth explanations for the curious
 
-
-anatomy of a Debian source package
-----------------------------------
-
-Debian source packages provide a standardised way of compiling software. These
-packages are not intended to be _installed_ on your system; rather you just download
-them and use them to build the software.
+Anatomy of a source package
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Debian source packages provide a standardised way of compiling software.
+These packages are not intended to be _installed_ on your system; rather
+you just download them and use them to _build_ the software.
 
 Each Debian source package is based on an original _upstream_ tarball. In addition to
-this '\*.orig.tar.gz', there is a '\*.diff.gz' which contains all the _modifications_
+this '\*.orig.tar.gz', there is a '\*.debian.tar.gz' which contains all the _modifications_
 done to the original upstream sources in order to compile it with Debian. Especially,
 this so called ``debianisation patch'' adds a 'debian/' subdirectory to the source tree,
 which then holds all the control files used by Debian package management. Finally, the
 third part of each Debian source package is a _manifest_ file ('*.dsc'), which states
 that this is a Debian package and contains the primary control informations, the
 name and version number. Of course, these three files are named with a common name
-prefix, which matches the 'official' package name and version.
+prefix, which matches the ``official'' package name and version.
 
 Quite frequently, a given source package generates several binary packages, e.g. the
 main program, maybe a library and a documentation bundle. Because of this, often the
@@ -150,7 +362,7 @@ search] or the link:https://packages.ubuntu.com[equivalent for Ubuntu] to locate
 versions, even individual files, or to get at the bug tracker for a package.
 
 interesting files in the debian subdirectory
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Most of the files in that subdirectory are relevant only for the people maintaining
 the package. With the exception of the following:
 
@@ -158,52 +370,19 @@ the package. With the exception of the following:
   find the definition of the prerequisites, the name of the packager, the explanatory text.
 - the top entry in the 'debian/changelog' defines the *actual package name and version*
 - the actual build process is conducted by invoking several pre defined targets in the
-  'debian/rules' *makefile*. But modern debian packages often make use of the ``common
-  debian build system''
-  https://web.archive.org/web/20170708155303/http://build-common.alioth.debian.org/cdbs-doc.html[CDBS] --
-  basically a set of macros allowing to write these _rules_ in a very short and concise fashion
+  'debian/rules' *makefile*.
+- However, Debian packages typically rely on the _Debhelper Sequencer_ to perform
+  all the steps necessary for building a package.
+
+  * see the https://manpages.debian.org/trixie/debhelper/dh.1.en.html[Manpage]
+    and https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules[Debian-Policy §4.9]
+  * every step in that sequence can invoke a pre- or post- target and can also
+    be overridden altogether in the 'debian/rules'
 
 
-commands for handling source packages
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-For all package building tasks, you can use an arbitrary directory of your choice.
-It is recommended to build with normal user permissions (not as root).
 
-- 'apt-get source' PACKAGENAME downloads the three parts of the source package. You may
-  use both the name of a binary or the source package in this command. After downloading,
-  the original tarball is extracted and the debianisation patch is applied. That is,
-  the tree is ready for building
-- 'apt-get source \--compile' PACKAGENAME does even more: it starts off the build
-  of a binary package after downloading and preparing the sources...
-- 'dpkg-source -x' SRCPACKAGE.dsc just extracts a source package and applies the diff
-- 'sudo apt-get buld-dep' PACKAGENAME fetches and installs all the prerequisites
-  necessary for building the denoted package. (however, it does _not_ download the
-  source package itself)
-- 'sudo dpkg -i' BIN-PACKAGE.deb finally installs the result of your building efforts.
-  Note, if several packages depend on each other, you need to give them all as list
-  in a single command invocation.
 
-After having prepared the sources this way, you need to step into the root of the
-source tree, if you want to build the whole package, or even want to tweak and
-modify parts.
-
-- 'dpkg-checkbuilddeps' checks that all the requirements of the package are satisfied.
-  It just prints out what is missing; this is especially useful if the fully automated
-  install did not work entirely, so you have to fix / reinstall parts manually
-- 'dpkg-buildpackage' starts the full build. This includes re-generating
-  the source package (and especially the diff). If you only want to build the binary
-  package, you can skip the diff- / source-package generation with '-b'
-
-prerequisites for building
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-For performing any compiling and packaging tasks, you need some additional software,
-which by default isn't installed on a desktop system -- most notably the GNU C compiler.
-On any Debian based system, you get these basic tooling by
-----
-sudo apt-get install build-essential
-----
-
-library development packages
+Library development packages
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 When building software linked against some library, we need additional 'header files'
 provided together with the library. Conventionally, these headers are packaged separately
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index c7f392f3f..d5fa1f364 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -160243,9 +160243,21 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
+
+
+
+  
+  
+    
    
+      Für Lumiera habe ich das letztlich so gemacht, und ich halte es für sinnvoll, denn so ist in debian/rules unmittelbar ersichtlich, wie konfiguriert wird ... generell sind implizite Default-Regeln nur dann sinnvoll, wenn der Default einfach und allgegenwärtig ist
+    
    
+  
+    
+
+    
     
 
 
@@ -160265,6 +160277,42 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
     
+
+
+
+
+  
+  
+    
    
+      ...wie .svn, .git, Autotools-Müll...
+    
    
+    
    
+      Man sieht den Default mit dpkg-source --help
+    
    
+    
    
+        -i, --diff-ignore[=<regex>] 
+    
    
+    
    
+                                 filter out files to ignore diffs of 
+    
    
+    
    
+                                   (defaults to: '(?:^|/).*~$|(?:^|/)\.#.*$|(?:^|/)\..*\.sw.$|(?:^|/),,.*(?:$|/.*$)|(?:^|/)(?:DEADJOE|\.arch-inventory|\.(?:bzr|cvs|hg|git|mtn-)ignore)$|(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg(?:tags|sigs)?|_darcs|\.git(?:attributes|modules|review)?|\.mailmap|\.shelf|_MTN|\.be|\.bzr(?:\.backup|tags)?)(?:$|/.*$)'). 
+    
    
+    
    
+        -I, --tar-ignore[=<pattern>] 
+    
    
+    
    
+                                 filter out files when building tarballs 
+    
    
+    
    
+                                   (defaults to: -I*.a -I*.la -I*.o -I*.so -I.*.sw? -I*/*~ -I,,* -I.[#~]* -I.arch-ids -I.arch-inventory -I.be -I.bzr -I.bzr.backup -I.bzr.tags -I.bzrignore -I.cvsignore -I.deps -I.git -I.gitattributes -I.gitignore -I.gitmodules -I.gitreview -I.hg -I.hgignore -I.hgsigs -I.hgtags -I.mailmap -I.mtn-ignore -I.shelf -I.svn -ICVS -IDEADJOE -IRCS -I_MTN -I_darcs -I{arch}). 
+    
    
+  
+    
+
+    
+
+
     
     
     
@@ -168331,9 +168379,12 @@ that situation will improve in forseeable future.
     
 
 
-
+
 
 
+
+
+
 
 
 
@@ -169323,7 +169374,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
   
   
@@ -169332,7 +169383,7 @@ that situation will improve in forseeable future.
     
    
   
     
-
+
 
 
     
@@ -170174,7 +170225,7 @@ that situation will improve in forseeable future.
 
 
     
-
+
 
 
 
@@ -170287,13 +170338,19 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
+
 
-
-
-
+
+
+
+
 
+
 
-
+
 
   
   
@@ -170302,7 +170359,8 @@ that situation will improve in forseeable future.
     
    
   
     
-
+
+
 
   
   
@@ -170315,17 +170373,77 @@ that situation will improve in forseeable future.
   
   
     
    
-      die ist gut und auch nützlich dort; könnte aber auch übernommen werden in die Beschreibun des Buildsystems
+      die ist gut und auch nützlich dort; könnte aber auch übernommen werden in die Beschreibung des Buildsystems
     
    
   
     
 
     
-
+
 
 
-
-
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      Verweise auf den Debhalper-Sequencer,
+    
    
+    
    
+      mit Manpage und dem Abschnitt in der Policy,
+    
    
+    
    
+      in dem die Override-Targets erläutert sind
+    
    
+  
+    
+    
+    
+    
+
+
+  
+  
+    
    
+      ...nicht nur daß diverse Paketnamen peinlich veraltet sind — auch die ganze Darstellung ist verwirrend, und inzwischen einseitig....
+    
    
+    
      
+      
    • 
+        sollte die grundsätzliche Prozedur zu Beginn abstrakt darstellen
+      
      • 
+      
    • 
+        sollte eine kompakte Anleitung für den kompletten Bootstrap vom Quellpaket auflisten
+      
      • 
+      
    • 
+        sollte aber auch die Variante mit mk-build-deps darstellen, da hierfür nicht das Lumiera DEB-Depot ins System konfiguriert werden muß; in all den letzten Jahren was das nämlich die einzige Methode, die überhaupt noch funktioniert hat, auch wenn sie deutlich umständlicher ist als mit dem Apt-Repo
+      
      • 
+    
    
+    
    
+      Der allgemeine Teil dafür kann nun gestrafft werden, da wir mache Information schon woanders breit darstellen
+    
    
+  
+    
+
+    
+
+
+  
+  
+    
    
+      Aktuelle Distributionen und Daten, Text gestrafft und viele xrefs eingebaut, vor allem auf die Apt-Konfiguration und die Anleitung für den GPG-Key (denn leider ist das ganze Thema komplexer geworden; früher mußte man nur eine Zeile in die sources.list reinklatschen...)
+    
    
+  
+    
+
+
+
 
     
     
@@ -172762,7 +172880,7 @@ Since then others have made contributions, see the log for the history.    
     
     
-
+
 
 
 
@@ -175838,7 +175956,7 @@ Since then others have made contributions, see the log for the history.    
       
    
         
    
-          /** derive total ordering from base class */
+          /** derive total ordering from base class */
         
    
         
    
           std::strong_ordering operator<=>(FrameRate  const&) const =  default;
@@ -176671,7 +176789,7 @@ Since then others have made contributions, see the log for the history.src/vault/gear/work-force.cpp:69:43: warning: '++' expression of 'volatile'-qualified type is deprecated [-Wvolatile]
         
    
         
    
-          69 | for (volatile size_t i=0; i<degree; ++i) {/*SPIN*/}
+          69 | for (volatile size_t i=0; i<degree; ++i) {/*SPIN*/}
         
    
         
    
           
@@ -177056,7 +177174,7 @@ Since then others have made contributions, see the log for the history.
       
    
         
    
-          /**
+          /**
         
    
         
    
           * Identification tuple for addressing frames unambiguously.
@@ -177077,7 +177195,7 @@ Since then others have made contributions, see the log for the history.* be replaced by a combined C/C++ header
         
    
         
    
-          */
+          */
         
    
         
    
           class FrameID : boost::totally_ordered<FrameID>  ////////////TODO it seems we don't need total ordering, only comparison. Clarify this!
@@ -177715,7 +177833,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -177863,7 +177981,7 @@ Since then others have made contributions, see the log for the history.* which in turn becomes the only child of the new Record.
         
    
         
    
-          */
+          */
         
    
         
    
           Record (Mutator const&  mut)
@@ -178203,7 +178321,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
 
 
@@ -178579,7 +178697,7 @@ Since then others have made contributions, see the log for the history.
 
 
-
+
 
   
   
@@ -180667,7 +180785,7 @@ env.Command('out.bin', 'in.bin', my_action)
   
   
     
    
-      /* 
+      /* 
     
    
     
    
         INDEX-ITER.hpp  -  iterator with indexed random-access to referred container 
@@ -180700,7 +180818,7 @@ env.Command('out.bin', 'in.bin', my_action)
       
     
    
     
    
-      */ 
+      */ 
     
    
   
 
@@ -181250,7 +181368,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
   
   
@@ -181294,7 +181412,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
@@ -182383,7 +182501,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
@@ -182458,7 +182576,8 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
+
 
 
 
@@ -182687,7 +182806,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
@@ -182715,7 +182834,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
@@ -182766,6 +182885,37 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
+
+
+
+
+
+  
+  
+    
    
+      doc-base-file-references-missing-file /usr/share/doc/lumiera/README.debian
+    
    
+  
+    
+
+  
+  
+    
    
+      dämlicher Typo
+    
    
+  
+    
+
+    
+
+
+
+
+
+
+
+
 
     
 
@@ -182781,7 +182931,8 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
+
 
 
 
@@ -183047,8 +183198,9 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
-
+
+
+
 
 
 
@@ -183151,6 +183303,10 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
+
+
+
 
 
 
@@ -183302,6 +183458,202 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
+
+
+
+
+
+
+  
+  
+    
    
+      Hypothese: ich hab bisher nie aus einem komplett gecleanten Git-Tree heraus gebaut, sondern das Signaturfile war bereits da und es wurden daher zumindest die Plattform-Tests gecached. Vielleicht lag es aber auch daran, daß bisher CDBS das SCons clean erst nach der Source-Erstellung aufgerufen hat?
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+  
+  
+    
    
+      soll nicht in den Orig-Source-Tarball
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      Änderungen daran sollen ignoriert werden, da sonst der Paketbau nach dem ersten Clean abbrechen würde
+    
    
+  
+    
+    
+    
+    
+    
+
+
+  
+  
+    
    
+      WorkForce_test und SchedulerStress_test
+    
    
+    
    
+      Der Paket-Build ist eine schwierige Ausgangssituation, da kurz vorher das System unter Vollast stand. Es ist mir zwar gelungen, die Tests im normalen Entwicklungs-Setup weithin zuverlässig zu bekommen, aber es ist nahezu unmöglich, herauszufinden, was genau beim Paketbuild dann doch anders läuft
+    
    
+  
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      Forky ist im Moment noch weitgehend identisch zu Trixie; daher hatte ich es ja auch (noch) nicht als unterstützte Platform definiert. Das wird erst in etwa einem Jahr sinnvoll sein, wenn sich Forky deutlich weiterentwickelt hat. Insofern ist es jetzt auch (noch) nicht sinnvoll, die Vorläuferpakte zu bauen, denn sie werden in einem Jahr obsolet sein
+    
    
+  
+    
+
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      0000000515: CHECK: file-support-test.cpp:85: thread_1: simplifiedPermissionAccess: (not out.good())
+    
    
+  
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      CHECK: incidence-count-test.cpp:127: thread_1: verify_incidentCount: (isLimited ( 5500, stat.timeCase(1), 6800))
+    
    
+  
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+    
+
+
+  
+  
+    
    
+      Das DEB-Paket ist nun reif für das Release
+    
    
+    
      
+      
    • 
+        Paketinhalt ist nun so wie definiert
+      
      • 
+      
    • 
+        alle relevanten Lintian-Meldungen wurden behoben
+      
      • 
+      
    • 
+        Lumiera wird nun korrekt ins Menü eingebunden
+      
      • 
+      
    • 
+        einige instabile Tests (von marginaler Bedeutung) wurden per Patch deaktiviert
+      
      • 
+      
    • 
+        Paketbau auch auf Ubuntu/Noble bestätigt
+      
      • 
+    
    
+  
+    
+
+
+    
     
     
     
@@ -183318,6 +183670,81 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
     
+
+
+
+
+
+
+  
+  
+    
    
+      dpkg-shlibdeps: Warnung: Name und Version können nicht aus Bibliotheksnamen »liblumierasteam.so« entnommen werden
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      LumieraEnvironment.py, Line 391:
+    
    
+    
    
+      
+    
    
+    
    
+      
    
+        
    
+          def defineSoname (self,  target, **kw):
+        
    
+        
    
+          """ internal helper to extract or guess
+        
    
+        
    
+          a suitable library SONAME, either using an
+        
    
+        
    
+          explicit spec, falling back on the lib filename
+        
    
+        
    
+          """
+        
    
+        
    
+          if 'soname' in  kw:
+        
    
+        
    
+          soname = self.subst(kw['soname'])  # explicitly defined by user
+        
    
+        
    
+          else: # else: use the library filename as DT_SONAME
+        
    
+        
    
+          
+        
    
+      
    
+    
    
+  
+    
+    
+
+
+
+
+
+
+
+  
+  
+    
    
+      Die Manpage ist komplex, und das Thema auch ... so auf die Schnelle verstehe ich nicht, was hier von wem wie ausgewertet wird
+    
    
+  
+    
+    
+    
+    
     
 
 
@@ -184210,7 +184637,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
@@ -184317,6 +184744,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
 
 
 
@@ -184708,6 +185136,25 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -184933,7 +185380,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
   
@@ -185143,24 +185590,43 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
+
+  
+  
+    
    
+      Reguläres Upgrade der »Referenz-Plattform« ⟼ Debian/Trixie.
+    
    
+    
    
+      Diese relevanten Versionen sind allesamt sehr knapp gewählt, unterstüzten aber auch noch Ubuntu/Noble (24.04)
+    
    
+  
+    
+
+
+
+
 
-
-
-
+
+
+
+
 
-
+
+
 
+
 
 
 
 
 
-
-
-
+
+
+
 
 
-
+
 
 
 
@@ -185232,6 +185698,41 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
+
+
+
+  
+  
+    
    
+      das inhärente Problem können wir nicht lösen: wir haben nämlich keinen geordneten Betrieb, weil wir keine Firma sind, sondern uns irgendwie durchwurschteln. Nur auf dieser Basis funktioniert unser Projekt ... leider kann eine zunehmende Regulierung so etwas nicht gestatten, und treibt damit all die »Kleinen« in die Arme des Plattform-Kapitalismus
+    
    
+  
+    
+    
+
+
+  
+  
+    
      
+      
    • 
+        Das ganze Thema Server führt immer zu Spannungen, sobald wir drüber reden. Es geht so lange wunderbar gut, wie die Kiste „irgendwie tut“ und man Christian vertraut...
+      
      • 
+      
    • 
+        Und noch wichtiger: die Rechtslage ist mir nicht klar. Inwiefern sind wir verpflichtet, unsere Prozeduren überhaupt zu konkretisieren? Genügt es nicht, daß wir uns pauschal zum Datenschutz verpflichten? Letztlich läuft unser Setup darauf hinaus, daß irgend jemand diesen Server nach den »Regeln des Handwerks« betreibt und sonst niemand drauf darf. Und letztlich erheben und extrahieren wir ja tatsächlich keine Daten. Auf diese Situation bezogen hab ich Bedenken, daß wir uns in falsche Tatsachenbehauptungen hineinmanövrieren, wenn wir suggerieren, bestimmte Prozeduren zu haben.
+      
      • 
+    
    
+  
+    
+    
+
+
+
+    
+
+
+
+
     
     
     

From 651cf144a5474ce54b52f072c31150ba6c7fbc6b Mon Sep 17 00:00:00 2001
From: Ichthyostega 
Date: Fri, 28 Nov 2025 21:21:13 +0100
Subject: [PATCH 51/51] Release: general washdown

- comb through the Website, starting at the frontpage
- add a **news** entry to confirm this major upgrade step (C++23)
- improve the wording in various overview pages
- adapt the ''release checklist'' to align it with **git-flow**
- reorganise the image folder(s) on the website
- the animated beating heart is back ;-)
---
 admin/build_lumiera-build-dependencies.sh     |  61 ---
 admin/deb.lumiera.org.PUB.gpg                 | Bin 6927 -> 17715 bytes
 admin/docker_open-lumiera-buildenv.sh         |  44 --
 admin/gnu-indent.sh                           |   5 -
 .../GuiDiscussion/ConceptProposals/AkhiL.txt  |   2 +-
 .../ConceptProposals/Alcarinque.txt           |   2 +-
 .../GuiDiscussion/ConceptProposals/Barnes.txt |   8 +-
 .../ConceptProposals/RichardSpindler.txt      |   2 +-
 .../GuiBrainstormingReviewed.txt              |   5 +-
 .../archive/rawGuiBrainstorming.moinmoin      |  55 ++-
 doc/devel/meeting_summary/2008-10-10.txt      |   2 +-
 doc/devel/meeting_summary/index.txt           |  11 +
 doc/technical/build/BuildDroneDraft.txt       | 200 --------
 doc/technical/code/CodingGuidelines.txt       |  12 +-
 doc/technical/code/c++11.txt                  |   6 +
 doc/technical/code/index.txt                  |  51 ++-
 doc/technical/infra/Release.txt               | 134 ++++--
 doc/technical/infra/index.txt                 |  41 +-
 doc/user/intro/intro.txt                      |   1 +
 doc/user/tutorials/building.txt               |   3 +-
 doc/user/tutorials/contributing.txt           |  45 +-
 wiki/thinkPad.ichthyo.mm                      | 430 ++++++++++++++++--
 22 files changed, 632 insertions(+), 488 deletions(-)
 delete mode 100755 admin/build_lumiera-build-dependencies.sh
 delete mode 100755 admin/docker_open-lumiera-buildenv.sh
 delete mode 100644 admin/gnu-indent.sh
 delete mode 100644 doc/technical/build/BuildDroneDraft.txt

diff --git a/admin/build_lumiera-build-dependencies.sh b/admin/build_lumiera-build-dependencies.sh
deleted file mode 100755
index 96fbf8a76..000000000
--- a/admin/build_lumiera-build-dependencies.sh
+++ /dev/null
@@ -1,61 +0,0 @@
-#!/bin/sh
-#
-# build_lumiera-build-dependencies.sh  - prepare/build on a pristine Debian/Ubuntu system (Docker)
-#
-#
-#------------------------------------------------------Setup
-# The Debian DEB Depot to retrieve the source packages
-DEBIAN_REPO="http://lumiera.org/debian/"
-SRC_DISTRO="stretch"
-REPO_SECTION="experimental"
-#
-# GPG pubkey to trust for signed packages
-TRUSTED_GPG=$(dirname $0)/deb.lumiera.org.PUB.gpg
-#
-# Directory for building DEB packages
-PACK_DIR=./pack
-#
-#------------------------------------------------------Setup(End)
-#
-fail() {
-    echo "\nFAIL: $1\n\n"
-    exit 1
-}
-
-# Sanity-Checks
-[ -f $TRUSTED_GPG ] || fail "GPG Key not found: $TRUSTED_GPG"
-mkdir -p $PACK_DIR
-[ -w $PACK_DIR ]    || fail "Unable to build. Can not write to $PACK_DIR"
-
-
-# prepare the host system with Lumiera package sources
-cp $TRUSTED_GPG /etc/apt/trusted.gpg.d/
-chmod a+r-x /etc/apt/trusted.gpg.d/$(basename $TRUSTED_GPG)
-echo "deb-src $DEBIAN_REPO $SRC_DISTRO $REPO_SECTION" > /etc/apt/sources.list.d/55-lumiera.list
-
-apt update
-apt install -y build-essential ca-certificates
-apt update
-
-# build some special build dependencies from source
-WORKDIR=$(pwd -P)
-cd $PACK_DIR
-
-echo "\n\n======= building NoBug =======\n"
-apt-get -y build-dep nobug
-apt-get source --compile nobug
-dpkg -i nobug-dev*deb libnobug*deb            || fail "installing NoBug"
-echo "\n\n======= building GDLmm =======\n"
-apt-get -y build-dep libgdlmm-3-dev
-apt-get source --compile libgdlmm-3-dev       || fail "installing GDLmm"
-dpkg -i libgdlmm-3*deb
-
-# install the build dependencies of Lumiera from DEB
-echo "\n\nInstalling Lumiera build dependencies...\n"
-apt-get -y build-dep lumiera
-
-# return to the working directory
-cd $WORKDIR
-
-echo "Build-Dependencies of Lumiera successfully installed.\n\n"
-
diff --git a/admin/deb.lumiera.org.PUB.gpg b/admin/deb.lumiera.org.PUB.gpg
index 6403dc3b65d41cd281de173ec2ec5717839012c1..f049db8f8893f3e4c42cca22d6228dd205fd4633 100644
GIT binary patch
literal 17715
zcmeIZWn5g#wl6wy5AN<3AUMGx5FCON+})iZ9SDTr?ivX0?vg-o3GVLhE`2*|?S1w-
z=bn4+-ur!c@58J9)vVE@Mpf6S{?9RM))Ek~_#IPI+q_L;NDYisaSa7`
zPbg|6`Q3Q+Om9cw;jRlKIgCE?QJy4bG=uhyJN!j|CzR%F?q`86r66W#RWq)+7yL?LCg*O`y+f8iRX71{X_TRXYUd*5v_zBt~XgK
z>`W8qQGK@GM#nlogu&qAJOu_dIC}K#hNs&;$=JiUN%j-(zE=A>T8ioFwkgv>#s}oY
zVw2G8YCfrKD0x=6sBqPukT;Wg##Zv(h3Ovl_&dYP$79%b9`^JS4T-dCpHRO|{y{0q
zkV+}QQP!)_8F>~MP_b1=jYiY>-FZUc-eGO=nVC0U`9mu5nEw(ZEXT2iR|1vOMOF0d
z9Qpg8X=xE!g?6)}U6o%dz#~A;N{C(5PkBF_!=kqnrN`q1Ye*7CpT)*%SKk&IQ#FW>
z@KTCwmYut2gBCaExic^&Mm1=y5W_D&zu%_oqunB(kNA}2`xptv4ppjoOm{3=MK!Ja
zu0r!`_?V`QX?d)Aue}~rFvG{|dvz^;smhy-6`Cdh6AFN;rIInRbhY$yaB(%WFrpCr
z>o-vkGh7zPdrYX}B_LqS4BfQH9KMnXh^hQ))1fr2K3g2w-d
zM+uAhbTz&((=u~8H`o30Ts791k5&^7+W0PM51J4PKt{s&J5w?b1L%ngMPO5GKzG$h
zZ-w5^-rU7ItDbi(oK-xQWApy`X_Lz!eY4JPhE`&xSGd}Nq1c^N$n#_paBR-|elKN6
zINI`p=hQ|~Ks4LDx!Q!I$~duxVSKZfo^ZisuaS_&Fn;>SlNv|A$MBdbnMxypM1PT_
zM6CHZx`%kK=qddV>hC1WEjsNVHKGDFnX{bevMg43JH)qkZbe;X2%~=`zTu&DS2x6s
zrPgz}2%TZK?{zD`%XwLL_Vo277kTJF+Rvqt?${UcUJ~z@T(SD;_{BbZU)V-c@b&~|
z+ej7}7o;vG4p^?4xc1#u(BLkh2Ty&5ifC_SJ^1EEg01xcJxHjWM!y9cP_w;=*qeH5
z{jF{{0)*Kx41UTh%ORZ|d}Ny8Us_mqh;)&@`x#wK6uy>ANU)Z-Iq-ATXndL0B)la{
z)bzX!I>TF{pzC0dUiAfjifmT(PjDIn%ZGgJs_2guORoofR&FIjaE0(*h|>;9t-v&?
z2|CKrCCmD;#R1cl(4Sr>-|?Y3P=36!d2=~{B
zBE0)*o>%NR^6J%_jY>E>MPH;e7M(OVqii8ln~tf;uNH$
zWj3FZmH$3&R&RswbveHJH*OM#Vc_6Ae*@?5TsapYOI`VwmL{pP!*&K@-mF(AKnENR
z0NLrKPBT67Kl*Y}#nUfiG~*8X?e}VF{|0Fa2G!pXXQU8xbhZ$+`U~p+#JJiY7#IE@
zAe_>TWfBDtFnmn)Tabti@C%@F*J)0@tt;Tu{>OP
zy)8nY+O%Nhx;s9nUv`-4j9PW9AXBA%JbLBGZyt#DQOxY7;1@ZR>dWGkVr~>uVXiAO
zB`G6(Ggef}wWKh~o9haqWkStUna_zHn5!?l=Lw1X5Q(6&5@M;HqxfDsYHIFr-s;xu
z`Z>%p3l}BDEh|&Y}ZH}NRD%A?+L7RG~?fn
zT-Yjvz>LV&!)aV-FrOfNKlPLyO%sKxaOd^!bL?&9q+t0Jm>?&hnult0_i<6$OP9Vo
zq7xQZn@f6!NGP~*)`eX6^}g7LDY;Z-Jm%^hk9Z7+Du$qiJo#i}r1|LEy2(|x0dK}7
zweNi2$zXs**-zt*7jIU=He76)xJaW*f*EKo->riX2GPG>RfOG3%UrWG9ZgbLbZm4~
zj4d&(j-nO|kUCi%ybDpo4_GQm9+0fT@TVb6j_R(RELnB)5{
z_fakFJl|dObj+YB;HsH35n_SqVct7Y&vCbNmZ{sm3cD25X)bm-oEB8FmGFFW*o}h{
z(_ai;C0;?!HTow2o`m~f0Zx?*Wa&m5yrVi}#IHPWxjNgf#OMAXo(E+4CTDiv;0KKa
z2*kYZPRMtYQQ0-ArE#@1lQwgeU-};*>Ry;*`jVZ
z3)t+xQR3|S;azOBFhXikvyMirE)c3OR*SuHp%y(-DfnKbVy3y?q(SfHoQYO-@Z;D3
ze!Am{9IXMq2b3>Uh7pf{&^C-t&2~u)H2lK%V)+lXT=7g6GNtOZ(?dVP^q9lh>(uFb
zIbC`6P8O;^#vJqKQq2~o&6GNlJihTrB)wB4dXWgqC6@DqWsgO+Mmdmh<9*qB*hq-}
zdW?`@*U@A5em7$!c;a5z+Vx}NIHQkeHzLTE_~hQ%D|3O^kgOXCga6vsI=o>>UtWom
zuafL=;n`giz3m%uM<%Y;iI-Z{i#91=k6C?|>W?Zb)xBDre?lveOg$Ty?DlNtDD@Qw3d@%`isWM8CWwYNhb
zI&D?mNMp^NK=WZQ#RJ(rRZgVj>n~PVh(#;~u98$zrM0kYi4CM>Gz=inwsQZsV4WcR
zFTt9F6a(n%txM9b)qvSb2tKWW{>*s6Iu$cc(T)4nYGzb`FNkNgsNM^9W~wSg#N((f
zaesXT>^{OX!N4MGu7md?%Y29yle4XawNF*L4r&X|{Xwmj55YqnfkAF>eB}K5cdLiT
zu5Z0D*n!TXg56Ih$-5j!^-PX7rztV3Ps(zO<(pQUfsR@JFC$1^Hr7>pA_j16GrwaO
z>8KSSIsEl{G>ix~Atl3VD15~ujs9y3miVm>pESpM`7fDHL`Ld{XLdN(JMQ#k4*9*t
z5!_QvZM#KxWfmCY&TT~gFKJAT_@6vzhwYHd!7T^9QxA?OtBK$_A6oq69<0ISSjMHk
z8zcHaRI2Py=ql8k1Hb*og#I6d7cdBLn
zk9CQJq&UkvBNH1V3p2>-#MI3A--3Cf(Z2+91x*Yfl02j)a{sOp-RJ>*=+2DlP9*ul
zQkpw~RO9O~UmAIK=kuJNA<|L?0h{M9=dsHUOroAnf=F*kv-NExZ2dxHE`!2jDWVeB
z$908zyg1s}B-~;l-`ABix~*UJLX()KLY3y|F*LbCrakrZ6(;R0tD1T@1MTB|Qm{$2
z<*r$sD^|jqmCuL0(8F;GWD-?F`*)G}kiG1-wnM-uI@;$AOKQBlAN{
z*``StravnvoxTFE5q!S;QE!4*Gl&YF?FlGn#=g|%VA^)69Sx}J{QUj$Qq~
zAt6T!AFj)FFBL8ewrlyRxDG|vf>`sXEe*WJ*a=wPc^bxQP=~!^NuhvRDL@r2pX7gH
zW|(0>W%g*%mY@GkbW*;$sJqM3d<*x7L?ot;B=dgg1VM&Z;_Q#>Zuf1_5A&r$
zH=!|^-CP>fY-bpUxM{3qe}2kz?e@EXNqCFnL>SM5#E8=t7CXfYZ8YSdFl)_l%r$D)
zSx>*Sn@X8=(b{a1Ukd@$<-b0)S6bVX8HK=BRpo;=Oy_I6nS_bCO_n3`-tfx1qKCgh
zm}g1vO$wBoy!wO!GAH`bDZ-#mMtQufZP^y$^eN5;KAJ2;)FyKGK{UiR@qQf;%k!cX
zcx0j1{8bsJjA3%${Xv!eOHMJU;>vHfx$ED8`R5iOdvvr$nBT{^Dx{}6`_;}5G5wAy
zJs>;F4jaM$m-1kyS05UR60OB9gFCbS41qBQI(HwGt`U?#W1p~l9BwQgG215Uqf&ZQV
zLgW68{w)Uu{bxTPAT;#fXmT>h7f3?<f{c9mU4nbBC*8kNJv7Enf8<
zS7q#!hSS(N00|inpMa2vmX4l*k%^0&hnMd){~HO(w^GtFvZ`w88k$<~wM|UT%q=Xf
ztX*8)+&w(KK70xc`W*ZvBs4ZIJ|QtFIVCkG_gh|mL19sGbxmzueM4hY^N+6XpFO>O
z{R86@lT*_(vvc!n>l>R}+dI2^`)B7Dmsi&}w|Doy_4=*n-_xI({TID3A$mc>!ot8J
z{MHK!+T*w4n6Pk^?C@A($_PeI*i;<;h&bXgU#q?&QFE%C;u<@TA>+|-tY^L$QD8H4mV|KtcXI7)(F}7|jV~9uyMI31tBO|NQ^T96+;k*^PC`8n6q2
zWQVlszGgJ*eFp;#9wodQ_oW(6{V%cvhPv&QXe0S{{7+=h+R81CFl~mE491g&l(Yv@
zxOWX@h@~6f&2E*YzevDZvi3rrmM4E`S2ZtDTrJjJfW?d%PplT6E9xcF9x9I9ro*Md
zZ-`~}@t+}~%$Y~e(4ELBk)mC|Y+ec$S>zU`F}V7oIYAMcmeUly&qQAPw!=@tKt5e1
zEE)Z=KI-`ar`K7VF-Jm(RO#3FXN0dfK&`SQfb&mek9z5djv>1?_7NfL?3R!Ea>S!p
z#j#MV2p@J?x!7usz<|tBi^%t=1Krcpg87pIFrYA(XbuL{Gr@rN-Lt0Yj0(eKuE)>~
zj~hYhv1^!N160(&tR}*(f)mJy!?UDsfqriEu@>ej{AzEy<@S+fYwkyf?Z}jJ7W2Y^
zLfnrmv+#WpyQPNb_jg)gz@psxba0+gDorhoBSI2kppI|wh+{ZYPD!ZY>>Po(g)BLL
z&eIB!OnZrUv1Umff`JM>hrm{mYdcvPzo`~iSd+nC
zx0~{&jXXsjUpV!*NG+KTg4)B$JMtN7q}gpPQ5WO6a!=xdgm&&G<-4=SZ5zs`4%b0B
z=nZ#XhG1adW%lf*?I8G!JixCXt^fJgN`u2=RgX*5bxCoA*NB2F&-k`$g-GDq`V@^h
zRJS2n8>pv@cAvbB#w1I-3L&s{+u-uhLgai9GA_l|)2O+!t+=Cw`nNh{8l3*mS8D8B
zrboVhW|QHoeL<55-_AfQ##uX(U_eOq`5rfn^z&@00q3#lhJ&t}u@4CSKo6OBc62_k
zsht%4t-(l=^L^Av)AzDF(D_L^(1q-<9^DDb{SzX{9)R?DsPMhM_Cl^zsY3Zi*G$V5}p$xJI+V#J<@$k
zZb3U)U_ie)mjDbTW{c#%byCmPyHQ~>G!YqT6wWCY8^M@z<(u;QIlui1CC}sG`&JY>9gVhD?zXV)%)|LWuIGPoZN*Fum2%3Gr7d*`IXXIBtux
zT74>plIV`dwtiXq`PEkY=Gq@Ga6XD?*DjOJtw(Tx>MRBm=@z!Gx^|}9aBUCOeSX&X
z>r`PfaI31;h3fI|cHvmLY&M4KW#ibAU`SCTWHM`hQd5bGJ+`_EksZ*(4QIpEyCeGc
z?r^CcbHpjU205;adHbm(-NfRmLTK8DeZ5Tlj84zirz&W0NiOr-z4wg5>4Wq%m%$PF
zk+Kik4wsci)9tRoz}4iq&b;2d)#(WQ89j|=wgpeC9M?5-;jQjn$Yu+3A()}3?J(#{SajqAdRUT@I)
z^TO%TH=Wij0TAC(xPY$^b753hCi%tk+h3RCIy70;QgNf>RaYX|yO}txi6WIUBpS1K
zEJmX6tNf^uM~??yszI8BMYQg5dNT&C$K4uT!`cZv87=8sV4$m_)-zV>d1|4B#5YT%
zQ)Ir7^%>uxB?45>-UyXd;|&Hn^z?$GxD*tnkBzIF$;=(~X+{ajm#@n}^hZUKOfs=J6`pydBq<;w;j}*pah)!Fte@b^7HNTQ}^;z-Gb5$tjBs
za@!>8@n;=h-Bch{Pj=MvKJWCOS3T;~q(7j`-qWjccz%AShKVsApiEshIq&1}fX<}|
zc=7r`{1!!y{OsVH)hjUIZC73H%g>^LO|JCfTQ2AsC^TTlrw3&u!&+~
zdT}xCFZUZ>JAcS~7T=Z~^d`yZ2;$6}@4a4WA#&LQ)m)Xb*sPUrW~n|;_bxrH%(aKj
zcwAO!{cNUy#zp1>7}iS$ovfIN-+p{0^oD}@K(DswrC?Kmy1=tJOZ_Om0rFGkEGYkY
z0Sw4jtsE#tbqSQ2Ha%F}XDhC-mBWA7Zd1~XlO3;Zs$hLdZJE2!q=HMc_38^~6ZE)53)#?#W7FJkgkEg$4eQg(rW#2Cn=q2^
z#UydwK|wOYSg1M}2rekh(;CyN&I$Ms&CF7lMr`ZVK5IS?<>L*}uOiQQQ9_d-z55xx(Y_ebBDh>^@W^tiYb5+}`n;SdD_z%l|
zQqEGr)P0;*xCtH*aGJ=hlTx2{Z6nsMn~3O*bK-j&DHOgC#;!bqND`&JkyTlusLngJ
z8<9I~ufDHSGe#FlMgOYBe#BXc{7Z?!+!6i~W;v*(_p-FVu4rT0jzzKuOG8xCaEB$b
zvE&{MeBoL`IRpdqy!uiZEf&XfHQ^T7!Z}T^PaD&*bt4$&T$P-C_XhfE3bTdvSJCx5
zf_OaXY@`F7;r13I*|jp+rfF&)$mi(iTKrC;NjB{HqsnYbXRvm8IC|z1HX@Q&T@tp#
z)f^YE(iHcY?~baFId7Xewucj|EQl+is5@|f+W6r#HBawM74TH=9W}h_lfw=|8HkB&
zy(%v&NH`k9t)b{y^WPhmB_p(b9(8u^Jz*1WB4uWn>6$8BG>zRFKk_lyxlJOJWmXvB
z2LnHbeb-*I)OsGhtRN>-8)(-bl1AEk`&N`XN_%^Vzc$0FrfK%Mv6?gw_=X>jAv>9$W&~jUSh9jO*ihFg>5Fg*D
z?qzA^3ydO$h8B-2FhE^!!0j7VrBUPaQ{=OU@y!qX8C8dbjpk^CxNV~^zfP5=n=?dI
z-)!4opeuGnwRwVp?-e9gc+JF?+V!~&@7gCr-=IhDc)CU4*sFIAnmS8y(+hrB#JNLYphMuv3w#-kYVf}CPrb_1(lfVwK+R!r79*BzP}B)KHuLn
zt55Rl>kj|vyc&tvE2gUsc_3phfD-5SGFc8vqSV^QZL^!sV3*&ys+rH1rAYS^i24%G
z*SVzXZ^q|M&p&nRB(3wCH%D?_Fk_~>;&eILuJDDSJsst85A#N}axDsf9R)4+&ph81
zmHFtb4Th-jop{)fAS6&c$1mBc#VX=mg$PE@6Z4XrH~W9hgiGYLCcXO2Tewg&Dv%XNTdbE)O{v6M5aOnVlZG^cTM|3S*?eMOA&wwzw%n{G1r
zhN&xQ2bR*>Nz9&-hrW-tpXtLHuZqLglE!PA?4;7bfM9Sz1y4PNd
zgQC-8N&EXqsy4py_*&`soQy+B7ZWq@hLPF;y_DV*0$Ym-5!v$<%v%IaxstF(`_hg2
z#I11U(n#bY8vl=t1Y`*Z#I*XK?o@Pj-nby=joXWg^+@lWKH89QTh}tx)){!-=v$0>
zo7FeQF26?+l*q-9f&CQ8)a?un>~QZ1)17jEn{IaxD=Jg67>;bL;Fvrr
zzqHfV(WyO`*IH~s3ooRO$x_xIMn0_|{`uIP_9Itus7g{ZbXDdvT7vKtA4Mdy>Q{lV
z-&V@S+slb=ltX@lZ&h8ablB9R_5uI+QziM{kuvuo*2YjKZLd-~^3b$dJx|D%V&t-6
z-wSjT{g+R3G*_Hq8nW}G68b!ep3^8oZ(RG}x6Va7Nythf8;fWBm}bWGHrhG~zMtoU
z0pyKKg{pmy7M@@4&J_`q_44Yo3Jk3F$CuVtUaQA=lNZ$4sY`aa%^|a5PUUJ0{qxTGw#ah&@j0YI7{ON%{ceZsW*C5cm<0!I(dtfxl&{H5(I>%Vp
z;d&`TWb?{;#pwA*{^0
zeecGe4~EYeL6ILyYu>}(wTxq#*{!h!vkN0cTS_+?fDvKSXU-iTpYHx?gS!8nGhzhA
zC2rwBUzm!^3{ka!nALlEenJ0R6P;XAWZ};!kwroay0FvK_^8%9Ii}K1h}oQZY`H{(pH+m
z07XmHYCGSpU7@Ez_w|RFAlIxKt5jDcFRm3U&GXHOxs>|8pOLs~tI#j_HEsgh>8(>c
z7CLIVqj(3-uR*y?8v-?B2-y{CXJ+vqf`i?3%-J3e2y=e8y?#sLePO`8vez6H;L~xK
zhLZ9;lf`+2QDZk3ZemHkEMzlP@I3d{DQ=oa?irDO;ArtikHgoRoOi_5f?!SPiCOXa
zL3FazxNhp(1*$10>l{1@G&=K@@Ko1cJ6Fo%$`O2ZeGiX4Ew9_C#!kbIdYo26TYIw5
zaHaTre@&7L$byg5aDS|(ph@E?uCNBHEs2@+J7b
zW`|tS@50vxI0*YD(STRI(02%Jv_MVjjk%}8uM}>cL20Eu3^A5SWF1GUp5YS4@e6g2
z-wT?Vm#m&&*0#8f=ggNxv2B0Zpw4RbtIKi}W=4rW7nxjj00U75`X4UFTM)S~6SuU6
zZ9eTTuW0{L(B?H1+~tW2c!PdcpoDF@QWJJ1uGF;SyzC>>&>CVMXN`q|s*}k%Dmzc<^ixTjAt)!HGTCAMWj
zrZ?n!HbZf*;WsBc;HYe{q@7^X=8pf2=MXq^vJVE7F0DYfp+V2go)nK2WzOi-hc%!x
z+#rY*S@_QByX5B*b-err40KQXuKehL=|KSl4ojvDuUms5OOEnB)$awR1s+fCxG76}
zD;R<-MY6`#laIYf9po1AKCK@r8jH2Bh5uJaIo*x7=4$jM9Vt|<%CmSD*g?u}J?eU(Q-qtgaIvnp)ijZ;TV
zDm=9%$9G-4VY%2lAp{~C74uh>bEECTbIfkgMgF3htH{bUyto@+sm+j6%SBqXQp`&h
zP}t-VldImZ;t7+QsONBa3kIZ?TAo@#vK0>A^;oKRxw{f>Gc3Qqja=zrHf)!y{7`k8v7S6>67ykI(3$cCnxS;z;q&kfz}&q
zx~y;a2=!)*zUfQPXvTN7kL;ZXm*pK@_3Q-D$A0F$%Dc?OQlE~R(r)}N2z#LH
zvw}RDHG`jj;6E|@(X2dIkYzqk^=$ChT-&_K)U9u#xffI@(3MPS_ndVKKNn8u&%nJL
zy}b!tdmL?Ra|!oFXmg*B%)7>CztcHSt7#!?U!DpUZrZT}18;joAnW}DO`Weqn48wy
zns!S#G)=J=gz9&oW+5AeE8N(b?>4UxG0nrPt{{{4J=s^1c0`q-!%Bfjii
z1hgmg(l*T78pio8?UsdG5aQYlJ+NkMnYb@M2~28!?Q1f*!No}v;GQ;SN1IrPx`iyy
zi2`;E&Z#^C;hS)uj)R
zznlRBq>y=>#gV}&GsaP!mNRhimZ
z(7yPxwszH~e}FUSqB;+;
z@byyGkNR-S4>?&s;s&Cgy$YVr8TO1;^ibb6tUPM%2r-0`Qz_FO%^rnotR#>>UMM|m
zDsTRTEbJzp?{IV#44f6kBp63{!(d(qt4-RXCYbe%6zLyw;v-u$ozpT$?0gRg(ZB4VAuLp
zq`Jj0jgj4p&pRp)Z&#M=7P8hyFH3s`Of8;
zs44eZr(fGkC+14t{
zvM}d5tr)T+d)Lu)!Mkx=6>hPxoZ(b*clXq@Snu}?%6s=f(y?qXG$B09K>t#NQ*wfw
zHe=8La_i)SZm;0M0L+u-vyj>lmc@K7Z~+Eh
zcAP=9pxP&A|67m6@Vw+d?7G}(taTLmB{q)_(4_(Nv8SQ9T2dl{MYj$OnSwjKtHwGckC_r54q>L
z15poQcdCWi@LtMbV3Z3Cv`dnyfi8wcPGXdD{87)1M|{4GKIBBvvE6NF-SicViDKSi
zf<|fn5R@?ZLr_Iowu}0l3Jhe*fB~OSgMY|={1+p);eyD}nA+Jx`iIu~lQ#WL`~0TuY~3JZ`y>6<5Y^0HT@_N&Kr#s+1;_vjz&n5f
zFb3QJE5H`w%4dO;_7IK>paQ8E|39=R`lJ0jNGoGVD=WYR(n11o0PFyxKiUJo{{x5&
zB>iJz$&1riAGe}^ypo{7IDIEWV?9sw2+
z5(B{XN9Y11asd_z?$6r4g)UISV_~yXiNzq`8u{Z;bBHUes5-^salWZqgS3L2Hh`Q<
z_M&Ui|8SY@MAY#dxMC;uw&fAZ0X<}qr)-{vuj
zBCEs$kOHT8Ml@;e=eOvQHiU*(ubAnzZL7;RH7Qy$nNn91dqd>*Fd3YQ%$jp~X)jYAQt;X0zG~gJ!pH4UygvMAxv+
zqAZvcn2T7Pkv*-|%uy54Q!;XDhd4RcW{k3`G`_e`R$XS>`?}n%eJ|h%
zYS5}3p%$#aO!9?&KDyH4j?kV9kI`kxE4!gec)5wn?8O!_85dQ#V9)tId+Lgzj^H?Y
zNn(F7Z}KyxVCU#a^Q}Hv-D;RHMJ!+DmhP)e2bA2CH35=i>0-{aZ|l|SKCBS0!DDhF
zr`;!&anD#3Z*M(CF@Cs2iJJ6_ugIJvL5`Y7?tCJReP#MHI*k*apD$#m?80ve(WOmBy@HC^Cve%a~7}p0IyN(~PnENM``q~qG8S`ZQ
znPz)`1z*P9h8B#iKH)r5Rge28zH}-Y$SJx-ZjaAK2hW8-|KHC#bdLN>(S+R37(js6
z`jy98Y
zmSgTPF0AV`kfa{#l*X%4nKfStg|xfzkAd2W-aQbgDv4XSF}g=Iq64<(G4GN%;Bm
zqWOs9bS8b0?$QQa_vM?hp}pJa*llWo`()Hm}PSk=aRcdldj0
z(Y$>9E-4{v(DZ0Lry*^PL{=u>Iw+=aw!X4+bN9`6t$TK@{VH3(;C?eta3b5a
zsM&$Yn4fIte)1tsPF>-D=
zb+E!Q=Rb8wPU9d6Y*TU_mT=(Ki~dr^OG~gkQ*-qwYcep_Dm!vY>T`6?LYIjC(xC=<
zc6f7(1B`fxM~P9@c&vM~yg4f9cI0bx>r5Nuq@g@L#RLB8u7Q5Ov{NsQ8iZ^}vqB@O
zeI;3Q-C<*#>Gpl-((C5izSDtGL77}+Oo5_fGA>fbJTn>(06uG-!F(+;rG7q_ME8#`3G=?S)#}M
zp~bM_OS=}HZfU6-u8c+VIjSgwK2^{&;$uI~wK4JX&(MLcx9fE@{>tY$1ZNCJl1qgz
zP*^Jp9@vyF&0G%Ne&5S2)$-xHJu*@DcV$r{Y@58bIl3|r(?5C)9Nog6Q=u^Qal-zm
z;A1)0Lk5S0&>eO0SNO=!Lyib?&TsqMYYjeHRCQ;FdHbg4H^4$2nF|J){u-za%amGc
zL0hO7347k6y-ltBMu^!l7xO)!_)B^nchu;YuT8$V7FpxACKr#J-F6>{M)3?Rb};f8
z5T;MQp!za?p?@h+MwjRFqR3@<5yqPmzZBmiTsYTz_>~8#O~T;BF;x0>)U9f*WeXyr
z6>P7wRwi!TzA&25q@Wxud6wEy8`~W|5j~|zS{o1M&B2vNIdCFZpBY`nb!DR{=FO{J`E>Z2
z&SO4P%_3?`b((Xz(4_eRX0(w(_j_sySS)DeRo!I_ux!1=i@uNP2~`-QExLv#9}K{W
zED2xdZ}BoL+ahtE+vtkLtDzBk!xs!UkID7o;hWF-dn>YmjdMjjsZ6C5F^vzerh(T!
zA2C$|QPU@66d#!NOMB;QwGH;DCe~sI2EJU{CqTDI?t7wL*Vn`AW=-FX@pQw1CaS4)
zu-c-}|_)2Z)P;Ury&EHKH)&FF&ihi4{_eX%gI|VEu9wI;r5uQpP>3Z1U`PLmI^agUa
z@}_#x66*I!+pjghq4{@?*f11OgzZG<+MvxsseI|C85dtm_c~S#oxEyDqkZ}zSsauC
z1>_{5jWVF`O9%{yc7%|<%&J#u>>Q>P~xNc
zBaQS0w~X_WUNlcH$iY6_mr-U^1;L4w(dNRr;qdKNr%PbXkKl9yb(l9fm6>FM+cfem
zHOEZ^zeI?2l0)j{rr%UMjiJn)#mn|q9?v2q9`eGvrg%k{37Xn$qA73t;kIxKK6L-|
z-;o&@i`iKx9cBZ)Q)%CO+
zC69`|kUO4vL{$gwK=#+d)+c#}kPfmy^#u$t
zJdcOkz4X|z{Fyv4eL$vkM?q5{lv6UldjAS9>DPhF2G1vurk1O+#jUt#mkTixF{5;B
z-Uup6Xej;B{s1zWb$yr?x*LJnlF89;Z}zO&B}ujF!q!|!T-
zi0|Moq%v8rV`&Hl-z&NIG*CcIfCKTx!k#FMUWuFwk)`C$%XPm~NpIUCbAPetw4@Q=
zRT2f_E4#Ljs5TE|A{#5^!R|gtQM@eo9p3+vw-BtZ*7I0!l9u*@awJpO>$RV>j~31r
zwGid}1;7`1?zc)2Med;8C+GfMBaiS$B)TbzD_`2(bHZq^guS(NZ5jCsGTj`jT*O`e
z)|cP-&kEk!#GV%n1t7LOuJX#r>FuGn(97oE5|GB+z3Bg^Pz$k?tiLT~gx&uKP&@Mx
z1IRW*5_j8tah>12H;5ovP-9Q4IVDL%+;tN^ggkTQq*Q7o0gdpQtsk}2*3a{e_Q}56
z?6G19aT^Lj5G@uDKJKAl6d(}zw)~NORy9hxrKgf&T(cYn@%8y8;BTJpLF7_(2H0~qubDYv7V!#PVJJ#-J=9mlmouo2yl4GGZi>C1`5~h*y8bi;*@9ZVK6WI_fq!nYC%SV@_A~4Gi4!oVIh2?bF<#c4%kdm6$q|iE}L!V%Wla(lreQB-9k-+0oXPx#

literal 6927
zcmb`Mbx<7J_NZqD26rdHEqJitB)9|#F2QAR7?=RT37SEJ6M_xyK6r4~-~@*t!8O4N
zFX#O3edoM-uTI^1b^EXG{$uy9y}xg*wO6MCb5O-EktKwvfU~wMmYo3LfW_#hlLApF
zJlM6vT;F?3-q!y(73wE7=zCz;oKKtjqH3|Wf
z!*M`VP;3-cCdin{x3#Uz#Mp8sbtW#;#$UsI&n0*%l4zx
z*Pol+`*t^p!WXT*Rsy~=Qblee(#x8Lj%_CzCS0G;dq@jhD%NkaJkU39U9FOyBQTZn
z8Yaz7mbues?-GNuY$uFHgKb4l=YwGALQvy4iX`-?%|+%<07c{v`Pp
zV!>?%c@CFHB_;#`(7+&RB4Qc<7ACkBLE_vBA#|o+6w-O)1f?TjA|;U
zjmi^{DJYg9kq!JV49!;W93`tYdaJQ|3b#ik_&p8-h!O~*0fNZifkCf#@qVFUV`8AA
zfWV|!m>Ae#G87;P03bq#D5xs{fIv(FNWBAk_DW)nfG{A-y6EMh#1Y9*z&;NO36eVi
znJ{z?Kx};&+;?`3c&S5RqU86=n=yT^b~+qHg-Y;yq~DW%Wo#z*$E4L+eeVNupkLU-
z@gIx|Om#K*uzneZ5~e6iqL3f!Z^~_V@B)lD@)}WJS)V7%CDhmD%X`w6RQT8!U3QxL
z2;dNAV(t#-gsJyDf)kOS(DI?+u~1&SZ3hERU7$ek`X{dHLSl>e7pu&LvIX_=X{iyO7iH^$^Ykvzcbs-3!|N5sE>amX8TAGb*KhiqT%J+M!t+$8%wi#(
zdJlb8jkYr_!*SeKBv(qYy|~qs8FFZ7<6SST{6zXFZLmBD2U2`;=LPsJ54i|cPb_Ak
z+HYgpwPikd^TX%7yz&flh3WudRepgwfi~|6)Pj!q#nf`Ab*kbOJoWKsPo!Q0
z32eVl&Ukmg>Wy*37jj0&>wSnLOoj=0NkO9{$03p&PF-PHwdHaOY({Y-5tn&#NG3O1
zh#~~$WbW)tCvN*cH
zy)WE$ow>)rO^|py0Aj|J^D;3}K;g^w%f4nK&6LvnFW`RwwTy@W&{*OeXWO-8WZg07
zQo%@#Z4tkhf71&fxn|!0Ht?Y}qlgqzDx<
zXic-TbyeOShkAYUNErgx#rrfEBHwBAk8w&htGBf+;Fo^CInYLVM-(5r2=@VYrdk`A{{&(%oZ
z7xak8v2jZU;T84SN5n!HOWtt5#9T)|Hg-nOnr06hqVQOb+g|8eQNc4HTJ$!yK@q9)@H@znymgFH4+UuG;N{h-6K=12!CM>
z&O1jp(H}oB1}yLrPwBC=v%zr{PL3}|5@gU@U0lW|fVTGmxYdaj0JKUL9B(rB;~FoU
z(Yp{Rj&QAWTc+y_`Pt2n?1m$xl~v6rL?{$k;)nW(Mdn+*iOy7=UukU^vf%vtBg!Mt
z)QekcRPwcmXYIxB#jPJD7b+~Cv8`n9QceuqzoOG1F?+^FoBP(;Rd<89X|lomWef7@
zPqf#>dVR1oO%bxl^0&UInrl1?suNsB_+HjLU5v2JYdqwu1{|512@S%``
zP*BJ~{|cmkgtvd=mv08hWX63Lg=$V-6r?H2L%>&`$qZ9C24tC^s*QZ>IN#{ZydkqY
zL)7yqkqGrMh&Go`qQ>}~Yei8QqE(f8&i
zL|YyDW9_4tMQ7&Wg!GcPa@K(=S@xW)%k(Ox;@Hz`b3`ly
zi70UrC$-->?`yR*n%HXwPLvpMiNR!{!h(wRgK1%$X?M+*Ad9vY$6xk5LKHRUm~I~R
zt9i?_$J0j{kM2^&jtBAWoPwPdo4+jEJ`lz*oypK6G!P1Tig-CY*qn?)JZ*wLaz&A4l^1X#W(T@dizshp5ARQ?)n6u%6swe;ujzG=5mwCaV!Csup7nRNk3qh!
zIa`GXfaAa6I1rYT4%$$ES3=H-#ebt*3oAeZd%6b)&>TW&aP?u+=!Y_3Q|K8*%`f_I
z4TYITubD3p`Oz@qI-|Aob*)vA6Rpn%iM^OdGim{gT)f%~oS))t#Vo0+uSF&)`FS15
zqDuf!S={Gbi$2k%sz7U0MMu-(me6x%cTY%1LEi%r-~
z{7}SK@TDpXA#WwQSNew2TqEy&MSvWVvWW)`;4zrE4pF1uHu;ersdcGyDfDC0uIY*Bc9!wujpjeA6GggtEGO_zbI;B=Q^0p
zck%ViVlIvXVcFG~<+nHEW|@gNeh%&6T#1&AaDG-~ZEF)Qs04iBCDd(SG%sYxJJ<_1
zTg_!C#ESP1o-8sg9&!IBMqkwM?N!KBQP7PL_7&k(-{z@`0==wjcHT&fkR*g!jXkFbKsZ4Jb%WeFnUiqU7PsJ+Pb|)ppmFl@}WoQSXjSc%9lvOUgzvK@Lxr8S~hLCyUbXk2C5J0m0
zWySwEKqqbmvG^|~h+lSqG%)s_s*x<_GM>;1g5MLpwC*%`=6Bv2|H)t1R9jqYO@bQY
z18Yu{184t(3V|{NfYj-3=&VK**}JUHDh;m^_IZ_*gt@|B){eX|iDoWNO$qYwL08FA
zwgUQ6WIZhCdS1aUsyz09(la*!T?6`sa*#4}I(;S4DLU0Yq5y}2C;uv6SAxTe(Xspx
z@Ke5xVfP24K%(_1UVaH%bL_GQANu(blkDCT%g~`mRb=
zc6+CfY~RYy7&pkPSShnMJ*Ydi2eWq^Zshw$#S!B^I2p#&SroK+EXlwsWmjXRjY25z
z36YeP?~+o*Kg1F;MRBO?(jb$cTs)&#Kr}@vq94aU;>pw^1do^^#4)g*)EdT5+eg0G
z2$#K&d|Zv_6%#s4uOaY1NPQcoPqlXRLzJSQ^wD*yToyxyu*s_u6Ey)7w_mD0$&K5L
z7F^DY0_;Bi-juL3u0cgfizeFH51s5bY3{tbMPs~o@>o*Y5D(g|OqARxa&hOI
zH|?V>mFJWNiQFcvm%GoHQH#zo%^sQ))&ky$Zi&`zpJdLKr>za`7L|y)_dvI@uRE)(
zkG8}|Y-eb<&xWs=KMZ_(5C2xM%jZ{u`9@+%bxrfhnA6v}H&c&o2&=Pkb)la~_ZrUW
zdTB5ck9XB}4)e!iotF
zQ4T&^;um>709`TUc6m2bxy87-n${aI8R7S2zBl|ik^HkL0BSqg=dcuAvuxZjuj>8R
zmRg^0Ko4A(RWX#pBu+1J`?S#Mz69FOh=yWmAD$O$OCqT>)B->E?cign_K;O|lHY~2
zDInf#GfK%ZB4U-A3Gd|-m%P|%f>$Onky^46>%=EEXzQU{SZJrNeXPufBm9C5>8}}w
zV+;mAdejD3dpCY``_b(kjh`yu=Amvatt6B!KVS=
za&*N}*cj{yj(bxzaqz7S4pdB8x2&CnG_c}R`i-B5S1q8yXImCj0(p+;BG>h9Rid6Z
zwds?p^V*54bt_OOdqUFJuKkc@3aRJg5d?8}LCV=S^QOMWo;E$BQ=y~vN+{eURWYp`
zX{+05N?j?H-n5NamY#R&7EtVo=g}lhO9jgLo(k)8xZ2a~Yoz-4>l(0*fC80%bJRQU
z<4qj=oFb+q#(IP3M)F>e>#qsF3Nk
z8v5w6y*S%Fe~xOY4fCW@lQ;nq3V>xn@ob~6azv#6A??rcRsFwfv10$9X)&7*$Yc{w
zdJ~ipLHK?|6^MM`G18v=>gmR0lCw*GK%7vYjvD?imCV|lNPr2dx#bmA^BoBvX3
z2r33-vOd&fcF3bV^DX9sRMoz8e`o6WQX&5j4h*E?
z-%}mdeR)XIFf3_L=;@QIxf1ESZ(*iM1Fc=J(n^#>f4$u$IViI{6OyO&mt2tkSa*l#
zvC11HB6d%lU#{@u0hNTJWjnB<*9&f4=08j
zmkiw{QvsVF(jT<&VV@PyKgEI^4Uoi*VHyR7jXf?G@k)@pmceUCww_HG84+I*g151+3Y
zjegvm`ugT57~4tO|0{puD$rM9!<AHdc;><*%B}
z_Ve%hSomF8w>K|)F5wy2Tb&?fy{u|hKC((r6TtZ{h7k*c@6Y!bPl{;bE0ea?^=h+^
zY0PVJ%M$OLhGZH2Nm5N}sqOYV(M8rJK7AVW@2vhPFL<{(%buEK(m%_VXGOBqoI<zAvwdZ&%SHdK``F+?F335X);yd#-}@;Km|Np1c|`2^Q`0zFm1kYU
zX_6S(#e$1;stc4p<;G)n+FlJ5qRlU#!8zZxwbH^s{XsJA?-XUDouDCH8~oi8S+v1K9=Ya|B()FEVMCbFzFyZvgugh%2O++2=-IiTwE
ziTyuwU{MQzSc?Wn5q~IPI^feA`YHIbv_y2P9e~Jw@~%%XmJqe95)?XeVzANnwPU&o
zg!^ZUn*alFA+6Vd5r9Ds%W0l1mOcmXTx$`EysAHSZc-MeTL2d7=927wkkmOJNADY!
zDNZcERIv(Ey21%=h3t|~XHThL{WLIL^3Z%GArZYemb$JNZ!mh_SmE}n_s-*UaIXT7
z`IzsZ^#kd3%YB?lKd@xVFf$sF4-=h!bkZ&l(C66t0l(K*Q(7FQLuPEop$j_jI|}2<
zQRDlpWwrtaRVjaAgKcmgdqNlWv_|
zK5Q`n2!#G%3A8TBy(nkru^s*u?$RLZj)
zV&!2uIP@bjB7CFq8YESUl^nJ7x*p}|Jxf{VqAx;6uIFa=EJ5!qDM>CZx$f?>~v
zOe9E0MTvJ1dLB9-X_m#Uc`gxThuQhGLRs1Dr^yFFXN!y=RLX$p6o1;0#+c>zNm?{H
zKNc-gPw?*bd%imfSFhaCTTg`0Lg!E^#V)%rzg{
z=+BDxf!m?7{_b$IfkCQ1`Q8lFC@`qIo1HU+&eGQ0*#<%fwWfnOTf)3t-0YyvbPf=&
zzgHy`J%DsfRe8Zdjw^lad{b+0B<~<~f2S@WlaCh*-}vbGq02imAe-KmIUp>i5U!0%
z@%vLaV9+1`Sip~Q0KYGyzuG|mZlL!;0Ekay65sFrOU5*ViRnt_!-Tx>EVlrNg`C?g
zHXZM;>p0R_(5G{|Xda#zO+Z{!Ri8XJAO@hf2-cAow>rfLd3v)j&k{opE}gC*_?}TI
z89bX3i}I7|;F^V}APA*gcQ{?pCxDbuGKegx5S?j%JBPDP0B&y<)FHSxY_SZ9u1O7%+Lc+iL`*LV=NR5PNV>_WGb
z17|&i>xDU0-YV_La3{99m%2AcIH)G_GnSDkMrsarU>S(EA_4lePc(J6sgvuV36fE4
z?-nYwJS@<++k>W0JgfujJ#ojNO#!dTa!Q)Hj@`}?#gaP?k^A~vGZyLeC^46Gl*YkP
zi@IZUn?gekt5R1c(^~!Z@cTeXp)3F)5CDWL{kh7Re{5*p@9Glg?;B=#2|%|n|#HjfRYVkU=rRJZGOln|6i>s{WAan

diff --git a/admin/docker_open-lumiera-buildenv.sh b/admin/docker_open-lumiera-buildenv.sh
deleted file mode 100755
index 2c245c209..000000000
--- a/admin/docker_open-lumiera-buildenv.sh
+++ /dev/null
@@ -1,44 +0,0 @@
-#!/bin/sh
-#
-# docker_open-lumiera-buildenv.sh  -  launch Docker container with interactive build shell
-#
-#
-#------------------------------------------------------Setup
-#
-# Working directory path on the host
-WORKDIR_HOST="/home/$USER/devel/lumi"
-#
-# bind-mount of the working dir in the container
-WORKDIR_GUEST="/lumi"
-#
-# Docker image-ID to launch
-DOCKER_IMAGE="ubuntu:bionic"
-#
-# Script code to inject into interactive shell
-COMMANDS=$(cat) <# his reservation. Prior to this meeting some people joined a brainstorming session and came up with _another design_([purple]#broken-URL `combo.png`#) compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users.
+This summer, one of the proposals by link:{imgg}/LumieraLogoLeonardoRiberio.2008.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and explained [purple]## his reservation. Prior to this meeting some people joined a brainstorming session and came up with _another design_([purple]#broken-URL `combo.png`#) compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users.
 
 Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest:
 
diff --git a/doc/devel/meeting_summary/index.txt b/doc/devel/meeting_summary/index.txt
index e237f1526..75b137845 100644
--- a/doc/devel/meeting_summary/index.txt
+++ b/doc/devel/meeting_summary/index.txt
@@ -11,6 +11,17 @@ spending time on the task of writing a summary.
 Anyone interested in Lumiera development is also encouraged to read mailing list
 archives and other documentation.
 
+2024-2025
+---------
+All meetings were informal in style; usually _Ichthyo_ gave a summary
+of recent achievements and explained some of the problems he was facing.
+Usually this leads into a rather detailed and technical discussion.
+
+Since Spring 2005, _Wouter Verwijlen_ has regularly participated in
+renewed discussions for a
+of a renewed link:{ldoc}/design/workflow/Verwijlen/[Workflow Concept].
+
+
 8 May / 12 June 2024
 --------------------
 Discussion regarding the approach taken towards the next core topic, which
diff --git a/doc/technical/build/BuildDroneDraft.txt b/doc/technical/build/BuildDroneDraft.txt
deleted file mode 100644
index 84cb38fb0..000000000
--- a/doc/technical/build/BuildDroneDraft.txt
+++ /dev/null
@@ -1,200 +0,0 @@
-A Build Drone for Lumiera
-=========================
-:Author: Christian Thäter
-:Date: 2008
-
-
-This is a brainstorming page for what a build system on the server would need.
-First of all, it should be simple and extensible, preferably by simple shell
-scripts (note that *anything* else is a subset of a shell script!). We should
-use existing good ol' unix utilities when applicable (batch, mail,...).
-In my opinion this all can be a lot shell code glued together. Things should be
-isolated to single tasks and well refactored to make it maintainable.
-
-Lets go:
-
-
-Whats needed?
--------------
-
- * A description/configuration what needs to be done, these may be recursive.
- * a batch/scheduling system (batch)
- * triggers/events which are passed along (initiate a build by a git commit, ...)
- * actions to perform
- * handlers for success and failure cases which act on the outcome of a action
-   (scp, mail, rsync, filters to produce asciidoc output...)
- * maybe some dependency handing (only build lumiera after installing the recent nobug version successfully)
-
-
-Top Down scratch
-----------------
-
-Lets say the configs are shell scripts.
-
-first a verbose one:
-
-------------------------------------------------------------
-cd project_dir
-if git pull; then
-  # call handlers for success case
-  sendmail foo@bar.com <>,build_drone_report
-}
-
-function GitPull()
-{
-  local dir="$1"
-  local repo="${2:-origin}"
-  local branch="${3:-master}"
-  ACTION="GitPull $*"
-  RESULT=FAILURE
-  cd "$dir" 2>&1 | AddToReport ,  return 1
-  git pull "$repo" "$branch" 2>&1 | AddToReport ,  return 1
-  RESULT=SUCCESS
-  return 0
-}
-
-function SendMail
-{
-  cat ,build_drone_mail <>,build_drone_mail
- 
-  for i in "$@"; do
-    sendmail "$i" <,build_drone_mail
-  done
-}
-------------------------------------------------------------
-
-
-now we can do following: (looks much nicer or?)
-
-------------------------------------------------------------
-if GitPull project_dir; then
-  SendMail foo@bar.com other@blah.net
-else
-  SendMail boss@bar.com
-fi
-------------------------------------------------------------
-
-the above snippet can be a file in some config dir and will be processed by sourcing it with proper setup
-lets place it in /build_drone/project/10GitPull
-
-------------------------------------------------------------
-for i in "/build_drone/project/*"; do
-  (
-    source "$i"
-  )
-  CallTrigger
-done
-------------------------------------------------------------
-
-... ok enough for now, whats needed is the CallTrigger implementation,
-stopping processes waiting (either reading on a pipe or wait for signal (-CONT
-for success, -TERM for failure))
-
-setup of the function scriptlets:
- for i in link:/usr/local/lib/BuildDrone/[]*; do source $i; done ...
-and so on
-..
-
-
-Conventions
------------
-
-. one drone runs always in a well defined directory, if commands have to go into subdirs, use subshells (good idea anyways)
-. all jobs need to run in serial order, nothing parallel. What the job then does itself (make -j3 ..) can be parallelized.
-. we need a well defined environment and some file where it is registered ,bd_env or so
-. all jobs append write their output to some well defined logfile (logfiles ..)
-. the status must be recorded in a file too
-
-Example:
-
-
-------------------------------------------------------------
-function BatchJob()
-{
-  batch <&log
-echo $? >,bd_exitcode
-
-kill -CONT $$
-EOF
-
-  # wait for signal
-  suspend
-  return $(<,bd_exitcode)
-}
-------------------------------------------------------------
-
-This of course needs some more work, trap handlers for signals etc. I am not
-sure if the idea with signals is good, maybe better use a pipe, lets see.
-
-
- 
-
-Actions and Handlers Brainstorming
-----------------------------------
-
-Ideas, not in order
-
-SendMail::
-  send report as email
-GitPull::
-  updates a git checkout +
-  Split this in
-  * GitFetch
-    fetch from remote
-  * GitHasChanges
-    are there changes between HEAD and remote?
-  * GitCheckout
-    reset to the remote head and checkout
-Bootstrap::
-  autoreconf and configure
-Make::
-  runs 'make'
-Check::
-  runs 'make check'
-Distcheck::
-  runs 'make distcheck'
-Doxygen::
-  runs doxygen
-StyleCheck::
-  checks if files violate the style rules, something like:
-  'astyle --style=gnu <$FILE.c | diff -u FILE.c - ...'
-ToDos::
-  greps for TODO (with some -A context) and produces a report
-  * beautify (asciidoc) reports
-  * publish reports, packages etc to the webserver (scp, rsync)
-
diff --git a/doc/technical/code/CodingGuidelines.txt b/doc/technical/code/CodingGuidelines.txt
index ae82c5e85..c399c91ab 100644
--- a/doc/technical/code/CodingGuidelines.txt
+++ b/doc/technical/code/CodingGuidelines.txt
@@ -52,9 +52,11 @@ The Lumiera project uses GNU indentation style with slight adaptations.
     beyond just a short list of names -- especially when including initialisers -- they are
     preferably written on a separate line, directly above the argument list in parenthesis
   * the opening brace of namespaces is placed on the same line. Optionally, the namespace
-    body may be indented, as long as this helps underpinning the nesting structure. But
-    there is no need to use 3 indents on a 3 level nested namespace. One level is enough
-    to highlight the presence of a nesting.
+    body may be indented (by one half-indent), as long as this helps underpinning the
+    nesting structure. But there is no need to use three indents on a 3-level deep
+    nested namespace. One step is enough to highlight the presence of a nesting.
+    Effectively this implies that the majority of code is set apart from the
+    left border by two spaces.
 
 - the shorthand type names `uint`, `ulong`, `uchar`, `short`, `ushort`, `llong`, `ullong`
   are preferred, as it is clearer to write the fundamental type in a single word. Index
@@ -71,12 +73,12 @@ The Lumiera project uses GNU indentation style with slight adaptations.
   to define a type alias for the _function signature_ first.
 - in a similar vein, we distinguish between an ```const object`'' which _is really in-itself_
   unmodifiable, as opposed to _taking a const-reference,_ which is always spelled out
-  post-fix as `object const&`, or a constant-pointer spelled as `const*`.
+  post-fix as `SomeType const&`, or a constant-pointer spelled as `SomeType const*`.
 - we use the textual form of the boolean operators `and`, `or` and `not`, because this
   allows to make the code resemble complete meaningful sentences in human language.
   We _do use_ the »line noise« variant however for all low-level bit manipulation,
   `&`,`|`, `^`, sometimes also for `!` -- using those is taken as an indication of
-  entering the ``danger zone''...
+  having entered the ``danger zone''...
 
 
 Spelling
diff --git a/doc/technical/code/c++11.txt b/doc/technical/code/c++11.txt
index 50755c1ae..d6f59a47b 100644
--- a/doc/technical/code/c++11.txt
+++ b/doc/technical/code/c++11.txt
@@ -225,6 +225,11 @@ February 2020::
 
   * still running into problems with perfect forwarding in combination with overload resolution;
     not clear if this is a shortcoming of current compilers, or the current shape of the language
+May 2025::
+  We did the big leap and are now on C\+\+23, with Debian/Trixie as the »reference system«.
+  The new language features, notably the **Concepts** will be adopted gradually and we
+  will certainly have to face some new challenges...
+
 
 
 
@@ -321,3 +326,4 @@ impose some challenging effort to retrofit existing structures.
   much cleaner and high-level than most ``mainstream'' usage of other common build systems out there.footnote:[
   ``hello CMake'', ``hello Autotools'', anyone else? Meson, Ninja? Maven? should maybe consider a switch to WAF?]
 
+NOTE: in May 2025, we achieved that switch and require now C\+\+23 and at least GCC-14.
diff --git a/doc/technical/code/index.txt b/doc/technical/code/index.txt
index 6e94c6321..30161021e 100644
--- a/doc/technical/code/index.txt
+++ b/doc/technical/code/index.txt
@@ -7,46 +7,53 @@ Code Base Organisation
 //Menu: put child GitBranching after LinkingStructure
 
 
-This section of Lumiera's technical documentation deals with the code base as such,
-not so much with the internals of the Lumiera application. It is targeted towards
-people participating in Lumiera development.
+This section of the Lumiera technical documentation deals with the code base itself,
+and is less concerned with the internals of the Lumiera application. It is primarily
+aimed at people who want to participate in Lumiera development.
 
-The Lumiera source base is huge and expected to grow for some time to come. Just
-judging by the _lines of code_, Lumiera can be considered as a *medium sized system*,
-which gives us some hints towards the adequate practices, conventions and the
-degree of formalism to apply.
+The Lumiera source base is huge already, and expected to grow for some time to come.
+Judging based on the _lines of code_ metric, Lumiera can be considered a
+*medium sized system* -- which gives us some hints towards the adequate practices,
+conventions and the degree of formalism to apply.
 
 Generally speaking, a *small system* doesn't exceed the mental capacity of a single
-knowledgeable human. A single person can know everything and understand everything
-in such a code base. Thus, any formalism and organisational overhead is detrimental;
-we're best off doing away with ``Methods'' and just rely on taste and craftsmanship.
+knowledgeable human person. A single developer can reasonably know everything and
+understand everything in such a code base. Thus, any further formalism and organisational
+overhead is detrimental; we're best off doing away with any kind of ``Method'' and just
+rely on our taste and craftsmanship.
 
-But there is a hard limit for this approach, kind of a _sonic wall_ -- usually somewhere
-around a size of 60000 LoC. At that point, the adequate value system flips around as a
-whole. Since beyond that point, no single person can understand and know everything about
-such a system, _communication and understanding become the primary concerns_ of the
-development process. Suddenly, we _do need_ some organisation, some rituals and
-a methodical approach. Yet still we don't need a high degree of formalism, since
-at least we can easily _know and recall everyone involved_.
+Yet this approach reaches a hard limit, a kind of sonic barrier -- usually somewhere
+at a size of about 60000 LoC. From this point on, the appropriate value system is
+completely reversed: since no single person can _understand and know everything_ about
+such a system, _communication and understanding become the primary concerns_
+of the development process. Suddenly, we _do need_ some organisation, some rituals
+and a methodical approach. Yet still we don't need a high degree of formalism --
+as long as we can at least easily _know and recall everyone involved_.
 
-To give a delineation to the other side, a constantly growing project might eventually
+To create a distinction from the other side, a constantly growing project might eventually
 reach the point where the actual coding of new functionality makes up less than 25%
-of the overall work required. More people might be involved than anyone can recall or
-overlook reasonably. A code size of 1 Million LoC seems to exceed any kind of sufficiently
+of the overall work required. More people might be involved than anyone can reasonably
+recall or survey. A code size of 1 Million LoC seems to exceed any kind of sufficiently
 precise imagination. From that point on, a rigorously formalised organisation is vital
 to keep such a *large scale project* from floundering.
 
-////
 Conventions
 -----------
-_to be written_
+- link:/project/legal/legal.html[Lumiera is **Free Software**] (GPL-2+)
+- link:CodingGuidelines.html[Lumiera code uses]: *GNU style*, 4-space indent, CamelCase and British spelling
+- link:GitBranching.html[Branches and Releases] are organised according to *Git-flow*
 
+////
 Guidelines
 ----------
 ////
 
 ''''
+[TIP]
+--
+ * link:{ldoc}/devel/meeting_summary/index.html[Developers Meetings] and protocols
  * also see the link:/x/DesignProcess.html[Design Process] for ongoing discussions
  * see the link:/devs-vault/[Developers Vault] for frequently used developer's resources
+--
 
 
diff --git a/doc/technical/infra/Release.txt b/doc/technical/infra/Release.txt
index 2b884fe8c..1abf38dd2 100644
--- a/doc/technical/infra/Release.txt
+++ b/doc/technical/infra/Release.txt
@@ -1,17 +1,53 @@
 Release preparation
 ===================
 :Author: Ichthyo
-:Date: Nov 2015
+:Date: Nov 2025
 
-we have nothing to show and don't provide public releases yet --
+We have nothing to show and don't provide public releases yet --
 but we ought to rehearse and practice the release process.
 This document contains some hints and a checklist of steps
 to perform for a proper release.
 
+IMPORTANT: Lumiera uses link:{ldoc}/technical/code/GitBranching.html[Git-flow]
+           for the organisation of release branches and tags. Releases are still
+           considered ``experimental'' and happen infrequently, so that a full
+           automation of these steps was not yet considered. So please be
+           sure to adhere to the established conventions.
+
+
 Steps to perform for a release
 ------------------------------
 
- . release prep: clean-up obsolete information
+ . Pre-Release _»convergence phase«_
+
+   - care for code stability and refrain from breaking changes
+   - verify that the _current version number_ is already set to
+     the version number expected for the upcoming release, yet
+     decorated with the `~dev` suffix -- if it turns out that
+     the upcoming release shall make a _major version bump,_
+     then the expected version must be set *now*. Once
+     the release branch has been forked, the version
+     must not be changed any more.
+
+ . Release cut
+
+ - create the _Release Branch_ with name `rel/#.#.#`
+ - after that fork, immediately perform the *version bump*
+   on branch `integration`
++
+--
+** use the Script: `admin/buildVersion --bump=maj|min|rev --suffix=dev`
+** typical usage
+----
+admin/setVersion `admin/buildVersion.py --bump -s dev`
+----
+--
++
+[IMPORTANT]
+what you set here *must* be the next version _after the release_
+
+
+ . Release preparation: clean-up obsolete information
 
    - Debian package descriptions
    - Build-Tutorial
@@ -21,55 +57,81 @@ Steps to perform for a release
      * contributing
 
    - technical/build/Dependencies
+   - check and update *Release-Notes*
 
- . release prep: bump version number
+     * check that 'README' is up-to-date
+     * add a new summary entry into 'NEWS'
+     * check the 'AUTHORS' info
 
-   - `admin/scons/Setup.py`
-   - `data/config/setup.ini`
-   - `doc/devel/Doxyfile`
-   - `doc/devel/Doxyfile.browse`
+       ** ensure that the copyright time span
+          mentioned for each relevant contributor
+          is correct and possibly spans the current year
+       ** it is _crucial_ (legally relevant) that at least
+          the person preparing the release and thus acting as
+          publisher is mentioned here with the _current year_
+       ** ensure that a correct summary is presented in the "About"
+          dialog of the GTK-UI. The necessary config is currently (2025)
+          maintained in the file 'setup.ini' (the info displayed here
+          should be the list of all _significant contributors_ and
+          cover the whole time span from 2007 until _NOW_)
 
- . perform a back-merge from the release branch. +
-   It is relevant not to loose any bugfixes. Especially verify
+     * check that the 'LICENSE' file mentions the core authors,
+       again with the correct copyright time span
 
-   - that all ongoing fixes from DEBs and other build activities
-     are properly represented as patches and committed to the release branch
-   - that adjustments to platform dependencies are picked up adequately
+ . Test phase
 
- . perform the *Release-commit*:
-   it should mention the kind of the release and the version number.
-   Typically, with this commit, you'll update some top level stuff in the
-   source tree, like
+   - even while we have automated tests, be sure at least to do
+     some ``smoke test''. Ideally have _someone else_ use the new
+     version on a real-world project.
+   - depending on the circumstances, possibly set a _release candidate_ version, +
+     using a `--suffix=rc.#`
 
-   - `README`
-   - `AUTHORS`
-     
-     * also in the ``about'' box in the GTK-UI
-     * see `setup.ini`
+ . Publish the Release
 
-   - check the `LICENSE` file and add new license
-     declarations and notes, clean obsolete info here.
+   - merge the release branch into `master`
+   - set the version again, this time without any `--suffix`
+   - amend the merge commit to _include that final version_
+   - set the *Release Tag* in accordance with the
+     link:{ldoc}/devel/rfc/VersionNumberScheme.html[Version-Number scheme].
+   - fast forward also the _release branch_ to sit at that tag
+   - *publish* by pushing into git://git/lumiera/org/LUMIERA
 
- . update the *release branch*: ``upgrade current release to ##.##'' +
-   Make sure the release branch now really reflects current master, maybe
-   with the omission of some stuff to be kept out of the packages.
-   Set the *release tag*
+     ** the latest state of `master`
+     ** the release tag
 
- . packaging...
+ . Back-Merge: +
+   **never loose any release work**
 
-   - merge release -> deb
+   - `git checkout integration`
+   - `git merge rel/#.#.#`
+   - work through possible merge conflicts and resolve them
+   - conflicts on the version number *must* be resolved in favour
+     of the _next version number_ -- you can perform that as an
+     extra step, _after the merge_ is otherwise complete:
+     `admin/buildVersion --bump ... --suffix=dev` (and then
+     amend the merge!)
+   - *delete* the release-branch
+   - push this delete to the public repos, incl the main repo!
+
+ . Packaging...
+
+   - merge release-tag -> branch `deb`
    - verify the package description
-   - have a look at manpages and similar packaging documents
-   - update `debian/control` to reflect current version dependencies
-   - have a look into `debian/rules` (e.g. build flags and similar)
+   - have a look at manpages and similar packaging documents; +
+     notably look into 'debian/README.Debian', since we deliver
+     that instead of 'README' for the Debian users, since they
+     do not need instructions how to build the software...
+   - update 'debian/control' to reflect current version dependencies
+   - have a look into 'debian/rules' (e.g. build flags and similar)
+   - update 'debian/copyright' to reflect authors and copyright!
 
- . delivery
+ . Delivery
 
    - use whatever infrastructure is available to build packages.
-   - verify packages can be installed on a pristine VM
+   - verify packages can be installed on a pristine VM / Container
    - upload packages to debian depot or commit them to PPAs
    - clean-up and discard obsoleted old distributions and packages
 
- . close the **release ticket**
+ . Close the **Release Ticket**
 
 
diff --git a/doc/technical/infra/index.txt b/doc/technical/infra/index.txt
index a47abbf95..1dc7c3670 100644
--- a/doc/technical/infra/index.txt
+++ b/doc/technical/infra/index.txt
@@ -1,12 +1,18 @@
 Infrastructure
 ==============
 
+// Menu :  prepend child Release
+// Menu :  prepend child MenuGen
+// Menu :  prepend child Webserver
+// Menu :  prepend child TestSupport
+// Menu :  prepend child debianDepot
+
 
 Various details, documentation and other pieces of information regarding
 the infrastructure of the Lumiera project. This includes the infrastructure
 used for building and maintaining documentation and website.
 
- * see link:../build/index.html[separate page for the Buildsystem]
+ * see link:{ldoc}/technical/build/index.html[separate page for the Buildsystem]
  * generating the link:MenuGen.html[navigation menu] for the website
  * how to use the link:rfcsh.html[rfc.sh] script for maintaining RFC's
 
@@ -18,14 +24,27 @@ Other tools in the ./admin folder
 There are various other small tools and scripts in the admin folder which are
 not yet fully documented (Read the Source!).
 
-.headercheck
-This is a small tool which checks that all headers are sufficiently standalone
-and include anything they need. In future we might extend this to find out
-bogus includes by predefining (-D) headerguards they include, effectively
-disableing this include for a test.
 
-.render_icon.py
-used by the buildsystem to translate svg icons to bitmaps (png)
+.buildVersion.py
+Uses some Git magic to figure out the current version number
+based on the HEAD revision. In addition, it allows to bump select
+components of this version number, and to append a decoration suffix.
+We use the link:{ldoc}/technical/code/GitBranching.html[Git-flow]
+branching structure, and thus this script is typically used to
+generate an input for the setVersion script,
+immediately after forking off a _Release branch_.
+
+.setVersion
+This shell script uses `sed` to update the current Lumiera version number.
+It contains hard coded knowledge of all relevant locations in the code base
+where this version number is embedded and must be updated.
+
+.rfc.sh
+This shell script (written by Cehteh) was used in the early days of Lumiera
+to create, update and manage the link:{ldoc}/devel/design_process.html[»RfC« entries]
+for the _Lumiera Design Process_. While this formal documentation of design decisions
+is still considered relevant, this formalised process is suspended, as long as _Ichthyo_
+is working basically alone on the project.
 
 .treeinfo.sh
 Generates a report about the projects directory structure by parsing the
@@ -39,9 +58,6 @@ more details.
 A directory containing example git hooks for signing and pushing on commit.
 Only use them when you know what you are doing.
 
-.lumiera_c_skeleton
-A script which instantiates a new pair of .c/.h files.
-
 .vg-run.sh
 convenience wrapper script to run an executable with valgrind
 using "typical options"; output goes to a logfile, which is
@@ -51,9 +67,6 @@ A valgrind suppression file is generated automatically, in
 case there is an executable "vgsuppression" located in the same
 directory as the target executable.
 
-.gnu-indent
-call the "indent" tool with parameters suitable for our (GNU derrived) coding style
-
 .testrunner
 Script driving make and running a test, possibly under valgrind. Works only
 for autotools build.
diff --git a/doc/user/intro/intro.txt b/doc/user/intro/intro.txt
index b193a8f7c..5c1e5bdc2 100755
--- a/doc/user/intro/intro.txt
+++ b/doc/user/intro/intro.txt
@@ -2,6 +2,7 @@ Lumiera (as seen) from Outer Space
 ==================================
 :Author: Lumiera_Core_Developers
 :Date: 2012 / 2025
+:webidx:
 :toc:
 
 ******************************************************************************
diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt
index 5323570eb..3638e73b1 100644
--- a/doc/user/tutorials/building.txt
+++ b/doc/user/tutorials/building.txt
@@ -220,7 +220,8 @@ scons -j#
 The build process will take some time, so sit back and relax.
 You can use for `#` (at least) the number of cores available on your system
 to speed up the build -- but it will take several minutes even for a debug
-build and significantly more for an optimised release build (-> see `scons -h`)
+build and significantly more for an optimised release build +
+(-> see `scons -h` for build options you can change)
 
 And if you feel like waiting even more, you might build and run the test suite
 by issuing `scons -j# check`...
diff --git a/doc/user/tutorials/contributing.txt b/doc/user/tutorials/contributing.txt
index 440733825..aa53825db 100644
--- a/doc/user/tutorials/contributing.txt
+++ b/doc/user/tutorials/contributing.txt
@@ -25,7 +25,7 @@ require considerable experience, some sections require less experience whereas
 certain aspects might be ideal to new programmers. Thus we attempt here to
 describe a number of areas in the project to assist you in selecting an area in
 which you might like to make a contribution.
-Of course, you are more than welcome--and even encouraged--to select other areas
+Of course, you are more than welcome -- and even encouraged -- to select other areas
 in Lumiera towards which you would like to contribute.
 
 
@@ -34,9 +34,10 @@ How to contribute to Lumiera
 
 Git: Essentials for Lumiera
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-All files in the Lumiera project are managed by *Git*, the distributed sourcecode
-management software. Although Git was primarily brought to life to manage source
-code, it plays a fundamental role in the Lumiera project. It is central to
+image:{img}/git.png[title="Git"] All files in the Lumiera project are managed by
+https://git-scm.com/[Git], the distributed sourcecode management software.
+Although Git was primarily brought to life to manage source code,
+it plays a fundamental role in the Lumiera project. It is central to
 communication and contribution in the project. If you'd like to contribute to
 Lumiera, you will have to acquire some understanding of Git at some stage or
 other. Please note, this is not the only way to contribute to Lumiera, you can
@@ -260,20 +261,20 @@ fact, many user interfaces should be possible.
 - the stylesheet has been roughly ported to GTK-3, but needs a lot more polishing
 - we urgently need conceptual (non-coding) contributions
 
-  * work out a coherent UI handling concept, in accordance with model and core
-  * we need a concept for key bindings and focus
-  * we need a concept for integration with control surfaces
-  * we need a concept for pen based handling
+  * work out a
+    http://localhost:8888/documentation/design/workflow/Verwijlen/index.html[coherent UI handling concept]
+
+    ** we need a concept for key bindings and focus
+    ** we need a concept for integration with control surfaces
+    ** we need a concept for pen based handling
 
 
 Steam Layer::
 - external connection systems
 
-  * investigate good ways to output video, both in-window and full screen.
-    Especially, the integration is what counts: it should be a well maintained
-    library, and play well with our intended framework and memory management.
   * expand on the work done for ALSA and Jack audio.
-  * expand on the work done for LADSPA / L2. Make Lumiera a host for these plugin systems
+  * expand on the work done for LADSPA / LV2; +
+    make Lumiera a host for these plugin systems...
   * investigate how to discover sound card properties. Develop a concept how to describe
     these in a generic fashion, independent of the concrete library used for output.
     The purpose is to allow binding with the structure of the session model
@@ -283,12 +284,6 @@ Steam Layer::
   * expand on the work done for a pooling small objects allocator.
   * develop a backend for our various allocation schemes to use this allocator.
 
-- Command system at the GUI interface
-
-  * expand on the work done for generic commands
-  * implement a command dispatcher to allow blocking and queuing of commands
-  * develop a scheme how to code the GUI commands in practice
-
 - provide the foundation for symbolic rules and script bindings
 
   * expand on the work done for symbolic and hash references
@@ -314,10 +309,20 @@ Website and infrastructure::
 - help with our continuous integration setup
 
 
+Current goals of development::
+- achive a link:{ldoc}/design/governance/integration.html[first integration] of the application...
+- https://issues.lumiera.org/report/17[»Focus Topics«] for further development.
+
 
 ''''
-''''
+....
+​
+​
+​
+....
 
-Do you have any further ideas?  Please speak up on the mailing list or on IRC.
+Do you have any further ideas?
+
+Please speak up on the mailing list or on IRC. +
 Such are always welcome.
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index d5fa1f364..60265eb76 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -159529,10 +159529,58 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
     
     
     
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      {date} : eine lokale Konvention nur für Lumiera
+    
    
+  
+    
+
+  
+  
+    
    
+      ...einfach weil wir dieses Attribut explizit in unserer page.conf verwenden — und wenn es nicht definiert ist, fällt die ganze Zeile mit dem umschließenden <span>-Element weg!
+    
    
+  
+    
+
+    
+    
+
+
+
+
+
+
+
+
+
+    
 
 
 
-
+
 
 
 
@@ -159678,7 +159726,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -160094,10 +160142,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
-
+
 
 
   
@@ -160381,7 +160429,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -160528,7 +160576,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
+
 
 
 
@@ -161877,7 +161926,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -162039,7 +162088,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
   
   
@@ -162342,7 +162391,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
 
@@ -162683,7 +162732,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
+
 
 
   
@@ -162695,8 +162744,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo
 
 
 
-
-
+
+
 
 
 
@@ -165574,8 +165623,9 @@ on some aspects of file handling media loading.
 
 
 
-
+
 
+
 
 
   
@@ -165612,7 +165662,8 @@ on some aspects of file handling media loading.
 
 
 
-
+
+
 
 
   
@@ -166050,8 +166101,42 @@ that situation will improve in forseeable future.
 
 
 
+
+
+  
+  
+    
    
+      Die Umstände sind nicht ganz klar — seinem Nachbarn (Fritz) geht es schlecht, und die Heizung ist (jetzt wohl endgültig) kaputt, und was sonst noch so durch den Wind is...
+    
    
+  
+    
+
+
     
-
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      ...denn ich habe sie ganz bewußt in eine größere Aufräum-Aktion mit eingebunden; die Texte müssen also in der Git-Historie in diesem Kontext stehen, weil dadurch auch meine Entscheidungen in den RfCs mit in den Kontext gestellt sind. Außerdem habe ich den sehr gewichtigen Essay zur Komplexität geschrieben, der die adäqate Antwort auf den Streit zur Plugin-Architektur darstellt. Und all das zusammen ist jetzt »dezent versteckt« in einem riesigen Schall an genereller Aufräum-Arbeit, die ich nunmehr gut zuende gebracht habe.
+    
    
+  
+    
+
+    
+
+
+
+
+    
+    
+
 
 
 
@@ -166167,7 +166252,7 @@ that situation will improve in forseeable future.
 
 
     
-
+
 
 
 
@@ -166276,7 +166361,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -166315,7 +166400,7 @@ that situation will improve in forseeable future.
     
    
   
     
-
+
     
 
 
@@ -166408,7 +166493,7 @@ that situation will improve in forseeable future.
 
     
     
-
+
 
 
 
@@ -166543,7 +166628,7 @@ that situation will improve in forseeable future.
   
     
     
-
+
 
 
 
@@ -166701,6 +166786,78 @@ that situation will improve in forseeable future.
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      ...was ich super finde!
+    
    
+    
    
+      Denn dadruch wird eine Seite auch neu gerendert, wenn sich ein Include geändert hat, oder das page-Template
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      wodurch diese neuer wird als das zugehörige HTML — und damit von der eigentlichen Render-Schleife in build_website.sh aufgegriffen...
+    
    
+  
+    
+    
+    
+
+
+
+
+
+  
+  
+    
    
+      auf jeder Seite steht im Footer das Datum der letzten Änderung gemöß Git
+    
    
+  
+    
+
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+    
+    
 
 
 
@@ -166718,7 +166875,7 @@ that situation will improve in forseeable future.
 
     
     
-
+
 
 
 
@@ -168377,13 +168534,159 @@ that situation will improve in forseeable future.
 
 
     
-
-
+
+
 
 
 
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      Ha! ich fand diese Seite bisher immer schon lustlos im Design — so gut der Text auch ist (Benny's Hilfe sei Dank!)
+    
    
+    
    
+      Dieses Logo ist eine banal-einfache Idee mit erheblicher Wirkung: nun stehen die zwei Blöcke oben prominent da, und die drei Textblöcke darunter setzen sich klarer ab...
+    
    
+    
    
+      
+    
    
+    
    
+      Die Breite der Grafik läßt sich leider nur
+    
    
+  
+    
+
+    
+
+
+  
+  
+    
    
+      Diese Geschichte ist nun doch endlos lange her, und eigentlich etwas peinlich (wie meine erneute Unterschung der Anfänge gezeigt hat). Aus heutiger Sicht könnte dieser Text schon knapper sein ... und die beiden Abschnitte schließen nun direkt aneinander an, und sind auch insgesamt Abstrakter. Diesen ganzen Schlenker mit dem Namen "Cinelerra-3" brauchts wirklich nicht mehr!
+    
    
+  
+    
+
+    
+    
+
+
+
+
+
+
+
+  
+  
+    
    
+      auch wenn wir die Storage nicht mehr loswerden können, immerhin kann man es mal unter den Teppich kehren
+    
    
+  
+    
+
+    
+
+
+
+
+
+
+
+
+
+
+  
+  
+    
    
+      als »Müll« gelten Grafiken, hinter denen keine wirkliche Idee steht und auf die niemals aufgebaut wurde; ein Beispiel sind Screenshots aus der Prototypen-Zeit — da genügt es, einen einzigen aufzuheben
+    
    
+  
+    
+
+    
+    
+    
+
+
+
+
+
+
+
+  
+  
+    
    
+      ich teile definitiv nicht den Glauben an spontane Selbstheilungskräfte
+    
    
+  
+    
+    
+
+
+
+
+
+  
+  
+    
    
+      Das läuft bloß darauf hinaus, daß wieder mal ein neues »Design« erfunden wird und dann die Umsetzung anderen überlassen bleibt. Oder mir jemand erzählt, wie man heute im Internet kommuniziert (obwohl ich das sehr gut selber weiß)
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      sowas funktioniert möglicherweise bei einem gut eingespielten, professionellen Team.
+    
    
+  
+    
+    
+
+
+  
+  
+    
    
+      Es ist mir völlig klar, daß »Jedermann« vor allem erschlagen und befremdet ist nach Lektüre der Design-Seiten. Und was ich gleich schon gar nicht mehr haben kann, wäre ein weiteres »GUI brainstorming«
+    
    
+  
+    
+    
+    
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -168944,16 +169247,44 @@ that situation will improve in forseeable future.
 
 
 
-
+
+
+
 
 
-
+
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
-
+
 
   
   
@@ -168970,14 +169301,16 @@ that situation will improve in forseeable future.
     

   
 
-
+
 
 
 
 
 
 
-
+
+
+
 
 
   
@@ -169086,7 +169419,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
   
   
@@ -169113,7 +169446,7 @@ that situation will improve in forseeable future.
 
 
 
-
+
 
 
 
@@ -170080,14 +170413,15 @@ that situation will improve in forseeable future.
 
 
 
-
-
-
+
+
+
+
 
-
-
+
+
 
-
+
 
 
 
@@ -180159,14 +180493,14 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
 
 
 
-
+
 
 
 
@@ -180187,7 +180521,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
@@ -180656,7 +180990,11 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
+
+
+
+
 
 
   
@@ -180690,7 +181028,7 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
 
 
@@ -180839,8 +181177,9 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
-
+
 
+
 
 
 
@@ -180970,6 +181309,9 @@ env.Command('out.bin', 'in.bin', my_action)
 
 
 
+
+
+