GtkLumiera in Konstruktion @@ -569,9 +567,7 @@
NotificationFacade noch nicht offen
@@ -598,9 +594,7 @@
müssen eigens aktiviert werden
@@ -1701,9 +1695,7 @@
Schlußfolgerung: Wizzard wird ein Interface
@@ -3021,9 +3013,7 @@
Session-Subsystem implementieren (#318)
@@ -6654,9 +6642,7 @@
Style / CSS ⟶ delegiert an UiStyle
@@ -9491,9 +9477,7 @@
In instantiation of 'lib::{anonymous}::_ExpansionTraits<FUN, SRC>::Res lib::{anonymous}::_ExpansionTraits<FUN, SRC>::Functor::operator()(ARG&) [with ARG = long int; FUN = lib::test::IterTreeExplorer_test::verify_transformOperation()::<lambda(auto:2)>&; SRC = lib::iter_explorer::IterableDecorator<long int, lib::iter_explorer::WrappedIteratorCore<lib::TreeExplorer<lib::iter_explorer::StlRange<std::vector<long int>&> > > >; lib::{anonymous}::_ExpansionTraits<FUN, SRC>::Res = std::basic_string<char>]':
@@ -86372,13 +86356,23 @@ Date: Thu Apr 20 18:53:17 2023 +0200
+ virtual BuffHandle weave(TurnoutSystem&)
+
+ nämlich in den Kontext vom Render-Job; dort wird das OutputSlot-Protokoll zeitgebunden durchgespielt
+
+ Das war schon beim allerersten Entwurf 2009 ein Problem, daß ich immerfort das Bild eines komplexen Interaktions-Protokolls im Kopf hatte; im Bezug auf die tatsächlich zu realisierenden Abläufe mag das ja stimmen, aber es muß nicht explizit in Software-Strukturen repräsentiert werden. Jetzt, für das überarbeitete Schema habe ich zwar die Interaktionen genauer verstanden, und auch ein anderes Erkenntnisbild zugrundegelegt (ein Webe-Vorgang) — trotzdem unterliege ich immer wieder dem gleichen Denkfehler, diese per Analyse offentlegten Strukturen auch in Software-Komponenten verkörpern zu wollen. +
+ + +