diff --git a/src/lib/util.hpp b/src/lib/util.hpp index f83b70ec1..ddccbd360 100644 --- a/src/lib/util.hpp +++ b/src/lib/util.hpp @@ -278,7 +278,7 @@ namespace util { * in any sequential collection */ template inline typename SEQ::iterator - removeall (SEQ& coll, typename SEQ::value_type& val) + removeall (SEQ& coll, typename SEQ::value_type const& val) { typename SEQ::iterator collEnd = coll.end(); return coll.erase (std::remove (coll.begin(), collEnd, val), diff --git a/src/stage/timeline/track-body.cpp b/src/stage/timeline/track-body.cpp index 088207596..ae5831b12 100644 --- a/src/stage/timeline/track-body.cpp +++ b/src/stage/timeline/track-body.cpp @@ -95,24 +95,17 @@ namespace timeline { } - void - TrackBody::attachSubTrack (TrackBody* subBody) - { - REQUIRE (subBody); - subTracks_.push_back (subBody); /////////////////////////////////////////////////////TICKET #1199 : this can not possibly work; we need a way to retain the order of tracks, and we need to detach tracks... - - // detect changes of the track structure - subBody->signalStructureChange_ = signalStructureChange_; - signalStructureChange_(); // this _is_ such a change - } - - /* ==== Interface: ViewHook ===== */ void TrackBody::hook (TrackBody& subBody, int xPos, int yPos) { - UNIMPLEMENTED ("attach sub-TrackBody"); + REQUIRE (xPos==0 && yPos==0, "arbitrary positioning of TrackBody contradicts the concept of track-profile."); ///TODO remove that API + subTracks_.push_back (&subBody); + + // notify presentation code of the changed structure + subBody.signalStructureChange_ = signalStructureChange_; + signalStructureChange_(); // this _is_ such a change } void @@ -124,13 +117,16 @@ namespace timeline { void TrackBody::remove (TrackBody& subBody) { - UNIMPLEMENTED ("detach sub-TrackBody"); + util::removeall (subTracks_, &subBody); + signalStructureChange_(); } void TrackBody::rehook (ViewHooked& subBody) noexcept { - UNIMPLEMENTED ("re-attach sub-TrackBody"); + util::removeall (subTracks_, &subBody); + subTracks_.push_back (&subBody); + signalStructureChange_(); } diff --git a/src/stage/timeline/track-body.hpp b/src/stage/timeline/track-body.hpp index b9e6abd8a..cabdfa2f7 100644 --- a/src/stage/timeline/track-body.hpp +++ b/src/stage/timeline/track-body.hpp @@ -114,7 +114,6 @@ namespace timeline { void setTrackName (cuString&); uint establishTrackSpace (TrackProfile&); - void attachSubTrack (TrackBody*); uint calcRulerHeight(); uint calcHeight(); diff --git a/src/stage/timeline/track-head-widget.cpp b/src/stage/timeline/track-head-widget.cpp index a096adb5b..3422c70ad 100644 --- a/src/stage/timeline/track-head-widget.cpp +++ b/src/stage/timeline/track-head-widget.cpp @@ -94,15 +94,31 @@ namespace timeline { * the whole structure has to be re-built accordingly. */ void - TrackHeadWidget::injectSubFork (TrackHeadWidget& subForkHead) + TrackHeadWidget::attachSubFork (TrackHeadWidget& subForkHead) { ++childCnt_; this->attach (subForkHead, 1, childCnt_, 1,1); } + /** + * @internal remove a complete sub-fork from display. + * @remarks due to the automatic ref-counting system of GTK+, it is sufficient + * just to remove the entry from the `Gtk::Container` baseclass, which + * automatically decrements the refcount; alternatively we could as well + * destroy the Gtkmm wrapper-Object (i.e. the `Gtk::Widget` subclass), + * since this also destroys the underlying `gobj` and automatically + * detaches it from any container. + */ + void + TrackHeadWidget::detachSubFork (TrackHeadWidget& subForkHead) + { + --childCnt_; + this->remove (subForkHead); + } + void - TrackHeadWidget::clearSubFork() + TrackHeadWidget::clearFork() { while (childCnt_ > 0) { @@ -117,7 +133,8 @@ namespace timeline { void TrackHeadWidget::hook (TrackHeadWidget& subHead, int xPos, int yPos) { - UNIMPLEMENTED ("attach sub-TrackHead"); + REQUIRE (xPos==0 && yPos==0, "selection of arbitrary row not yet implemented"); + attachSubFork (subHead); } void @@ -129,13 +146,22 @@ namespace timeline { void TrackHeadWidget::remove (TrackHeadWidget& subHead) { - UNIMPLEMENTED ("detach sub-TrackHead"); + detachSubFork (subHead); } + /** @remark This implementation will not interfere with the widget's lifecycle. + * The widget with all its children is just detached from presentation (leaving an + * empty grid cell), and immediately re-attached into the "bottom most" cell, as + * given by the current childCnt_ + * @note in theory it is possible to end up with several widgets in a single cell, + * and GTK can handle that. Given our actual usage of these functions, such should + * never happen, since we manage all widgets as slave of the model::Tangible in charge. + */ void TrackHeadWidget::rehook (ViewHooked& hookedSubHead) noexcept { - UNIMPLEMENTED ("re-attach sub-TrackHead"); + detachSubFork (hookedSubHead); + attachSubFork (hookedSubHead); } diff --git a/src/stage/timeline/track-head-widget.hpp b/src/stage/timeline/track-head-widget.hpp index d38704b17..626a2bad9 100644 --- a/src/stage/timeline/track-head-widget.hpp +++ b/src/stage/timeline/track-head-widget.hpp @@ -91,14 +91,15 @@ namespace timeline { ~TrackHeadWidget(); void setTrackName (cuString&); - - /** Integrate the control area for a nested sub track fork. */ - void injectSubFork (TrackHeadWidget& subForkHead); - - /** Discard all nested sub track display widgets. */ - void clearSubFork(); private:/* ===== Internals ===== */ + + /** Integrate the control area for a nested sub track fork. */ + void attachSubFork (TrackHeadWidget& subForkHead); + void detachSubFork (TrackHeadWidget& subForkHead); + + /** Discard all nested sub track display widgets. */ + void clearFork(); }; diff --git a/src/stage/timeline/track-presenter.hpp b/src/stage/timeline/track-presenter.hpp index 7d377b8ab..ca386e678 100644 --- a/src/stage/timeline/track-presenter.hpp +++ b/src/stage/timeline/track-presenter.hpp @@ -131,8 +131,8 @@ namespace timeline { , public DisplayViewHooks , public CanvasOffsetHook { - TrackHeadWidget head_; - TrackBody body_; + ViewHooked head_; + ViewHooked body_; /* ==== Interface: DisplayViewHooks===== */ @@ -149,8 +149,8 @@ namespace timeline { public: DisplayFrame (DisplayViewHooks& displayAnchor) : CanvasOffsetHook{displayAnchor.getClipHook()} - , head_{} - , body_{} + , head_{displayAnchor.getHeadHook()} + , body_{displayAnchor.getBodyHook()} { } void @@ -159,13 +159,6 @@ namespace timeline { head_.setTrackName (name); body_.setTrackName (name); ///////////////////////////////////TICKET #1017 -- TODO 11/18 : not clear yet if TrackBody needs to know its name } - - void - injectSubTrack (TrackHeadWidget& subHead, TrackBody& subBody) - { - head_.injectSubFork (subHead); - body_.attachSubTrack (&subBody); - } vector>& bindRulers() diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 43d4e2640..f50a082e8 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -135,8 +135,7 @@ - - + @@ -161,8 +160,7 @@ Ganz anders Model::Tangible: dieses registriert sich bei der Konstruktion

- - + @@ -178,8 +176,7 @@ aber so herum macht es mehr Sinn

- - + @@ -232,8 +229,7 @@ BusTerm, das damit Nachrichten an den Nexus schicken kann.

- - + @@ -273,8 +269,7 @@ Wartet nur noch auf proof-of-concept (DemoGuiRoundtrip)

- - + @@ -289,8 +284,7 @@ aber nur via einfacher "uplink"-Verbindung

- - + @@ -356,8 +350,7 @@ ...es könnte auch den Feedback des Users meinen

- - + @@ -394,8 +387,7 @@ Term-Signal nicht ausgesendet würde.

- - + @@ -487,8 +479,7 @@ Anmerkung: ein "frestehendes" BusTerm ist valide und zugelassen, es hat halt nur eine uplink-Connection.

- - + @@ -503,8 +494,7 @@ es muß dazu auch jede Menge Methoden implementieren.

- - + @@ -633,8 +623,7 @@ Ein zu früher bzw. zu später Aufruf "fällt einfach hinten runter"

- - + @@ -703,8 +692,7 @@ dann kann der Shutdown-Prozeß den Start des GUI überholen.

- - + @@ -739,8 +727,7 @@ wirkt alles mehr oder weniger beliebig...

- - + @@ -776,8 +763,7 @@ Speicherzugriffsfehler

- - + @@ -797,8 +783,7 @@ - - + @@ -881,8 +866,7 @@ terminiert und dann tatsächlich den Fuktor aufrufen möchte

- - + @@ -960,8 +944,7 @@ und ihre "Methoden" sind Commands auf der Session!

- - + @@ -1128,8 +1111,7 @@ - - + @@ -1350,8 +1332,7 @@ Das wird eine ganze Me

- - + @@ -1458,8 +1439,7 @@ aber noch irgend ein Hund begraben liegt

- - + @@ -1475,8 +1455,7 @@ Im Moment loggen wir nur ins textuelle Konsole-Log (NoBug)

- - + @@ -1501,8 +1480,7 @@ mehr erscheint mir nicht sinnvoll; behandeln kann man solche Fehler ohnehin nicht.

- - + @@ -1541,8 +1519,7 @@ obwohl jener doch genau der Anlaß war, diesen neuen Mechanismus zu bauen.

- - + @@ -3961,8 +3938,7 @@ indem wir ein GTK-Signal erzeugen, das das Hauptfenster schließt

- - + @@ -4038,8 +4014,7 @@ eine einzige Funktion konkret durchdenkt: es läuft auf Spaghetti-Code hinaus

- - + @@ -4072,8 +4047,7 @@ ...indem der NotificatonService nun vom UI-Manager gemanaged wird :)

- - + @@ -4165,8 +4139,7 @@ }

- - + @@ -4367,8 +4340,7 @@ Daher macht es Sinn, den Interface-Lebenszyklus ganz starr an den Disspatcher zu binden

- - + @@ -4389,8 +4361,7 @@ was zwar jederzeit (via statisches/internes Session-API) verifizierbar ist, jedoch nicht offensichtlich

- - + @@ -4414,8 +4385,7 @@ jederzeit wegbrechen kann, was dann heißt, daß irgend ein Aufruf eine Exception wirft

- - + @@ -4453,8 +4423,7 @@ meint: zwei gekoppelte Statusvariable

- - + @@ -4493,8 +4462,7 @@ meint: zwei gekoppelte Statusvariable

- - + @@ -4561,8 +4529,7 @@ Aber ich akzeptiere es und verwende es jetzt als Treiber

- - + @@ -4631,8 +4598,7 @@ das Lock sorgt hier für konsistenten Zustand und Sichtbarkeit (memory barrier)

- - + @@ -4644,8 +4610,7 @@ Lock ist hier das Dispatcher-Lock

- - + @@ -4701,8 +4666,7 @@ ...wenn jemand zugreift

- - + @@ -4727,8 +4691,7 @@ - - + @@ -4801,8 +4764,7 @@ Ich halte diese Fälle aber für in der Praxis nicht relevant,  und verzichte daher auf eine Spezialbehandlung

- - + @@ -4927,8 +4889,7 @@ - - + @@ -5048,8 +5009,7 @@ die mehrfachen Indirektionen und das Ein-/Auspacken der Argumente

- - + @@ -5106,8 +5066,7 @@ und die Argumente von links her zu schließen (currying)

- - + @@ -5148,8 +5107,7 @@ wenn in der UI ein InvocationTrail angelegt wird.

- - + @@ -5302,8 +5260,7 @@ and shift the allocation logic to the aforementioned higher level.

- - + @@ -5316,8 +5273,7 @@ ...der aber irgendwann (demnächst in diesem Theater) umgebaut/zurückgebaut werden soll

- - + @@ -5512,8 +5468,7 @@ - - + @@ -5546,8 +5501,7 @@ - - + @@ -5572,8 +5526,7 @@ vorbereitete Grundstrukturen für immer wiederkehrende Setups

- - + @@ -5617,8 +5570,7 @@ Und der Rest sollte so vertraut aussehen, daß es selbsterklärend wird.

- - + @@ -5720,8 +5672,7 @@ ...welche ad hoc mit beiläufig geschriebenem Debug/Test-Code belegt werden

- - + @@ -5842,8 +5793,7 @@ Im Zweifelsfall den GTK+ Inspector verwenden!

- - + @@ -5872,8 +5822,7 @@ CSS genügt

- - + @@ -5921,8 +5870,7 @@ }

- - + @@ -6009,8 +5957,7 @@ daß die alte, obsolete Timeline zurückgebaut ist

- - + @@ -6029,8 +5976,7 @@ bevor die Notification-Facade geöffnet werden konnte

- - + @@ -6113,8 +6059,7 @@ Allerdings habe ich an der Stelle immer noch GTK-Assertions

- - + @@ -6190,8 +6135,7 @@ ist, daß Gio::Application sofort auch gleich eine dBus-Verbindung hochfährt.

- - + @@ -6364,8 +6308,7 @@ diesen "aktuellen Kontext" irgendwo aufzufischen

- - + @@ -6440,8 +6383,7 @@ und verwendet, und das ist auch gut so

- - + @@ -6550,8 +6492,7 @@ InvocationTrail ist tot

- - + @@ -6601,8 +6542,7 @@ und den Teufelskreis zu durchbrechen!

- - + @@ -6654,8 +6594,7 @@ (Beispiel "in-point fehlt")

- - + @@ -6673,8 +6612,7 @@ aber von einem externen State-Change getriggert wird

- - + @@ -6712,8 +6650,7 @@ und das wäre unsinnig.

- - + @@ -6738,8 +6675,7 @@ da es nur darum geht, via globalCtx auf den passenden Controller zuzugreifen

- - + @@ -7010,8 +6946,7 @@ ...and this anchorage can be covered and backed by the currently existing UI configuration

- - + @@ -7023,8 +6958,7 @@ ...by interpolation of some wildcards

- - + @@ -7036,8 +6970,7 @@ ...need to be extended to allow anchoring

- - + @@ -7075,8 +7008,7 @@ we may construct the covered part of a given spec, including automatic anchoring.

- - + @@ -7098,8 +7030,7 @@ designated by the given coordinate spec

- - + @@ -7128,8 +7059,7 @@ und dann kann man es auch extern belassen.

- - + @@ -7176,8 +7106,7 @@ sind denkbar und müssen in der Strategy konfigurierbar sein?

- - + @@ -7300,8 +7229,7 @@ jedoch genügend aufgeschlossen, um die konkrete Implementierung fortzusetzen

- - + @@ -7739,8 +7667,7 @@ Grund: wir wollen vermeiden, abschließende Wildcards bloß irgendwie zu binden

- - + @@ -7755,8 +7682,7 @@ dann aber Wildcards enthält, die nicht nach den verschärften Bedingungen gecovert werden können.

- - + @@ -7779,8 +7705,7 @@ - - + @@ -7880,8 +7805,7 @@ denn eine Verletzung kann weithin unbemerkt bleiben

- - + @@ -7907,8 +7831,7 @@ daraus resultierenden Pfad zugreift

- - + @@ -7928,8 +7851,7 @@ Hierbei ist aktive Lebensdauer wie bei einem Iterator zu verstehen.

- - + @@ -7946,8 +7868,7 @@ wenn die Auswertung aufgrund einer gebrochenen Konvention entgleist

- - + @@ -7972,8 +7893,7 @@ Es gilt die erste maximal abdeckende Lösung

- - + @@ -7997,8 +7917,7 @@ Sofern der Pfad bereits explizit ist, genügt diese Info allein

- - + @@ -8018,8 +7937,7 @@ - - + @@ -12164,8 +12082,7 @@ YAGNI

- - + @@ -12268,8 +12185,7 @@ oder verfangen wir uns da sofort zu sehr in der Implementierungs-Technik?

- - + @@ -12451,8 +12367,7 @@ Also sollte das auf dem API der default sein

- - + @@ -12505,8 +12420,7 @@ ...das heißt: keine Wildcards, keine pseudo-Specs (currentWindow)

- - + @@ -12524,8 +12438,7 @@ Zweck ist vor allem, meta-Specs wie firstWindow, currentWindow aufzulösen

- - + @@ -12553,8 +12466,7 @@ als Repräsentation des real-existierenden UI

- - + @@ -12628,8 +12540,7 @@ an einer Stelle über eine allgemeine Abstraktion

- - + @@ -12684,8 +12595,7 @@ ...als Namespace-globale Variable mit externer Linkage

- - + @@ -12711,8 +12621,7 @@ Grundsätzlich gilt hier die Einschätzung: Klarheit der Schnittstelle hat Vorrang

- - + @@ -12812,8 +12721,7 @@ zweite hart-gecodete Fallback-Konfig

- - + @@ -13288,8 +13196,7 @@ gegen den Kontext, mit dem sie matchen soll

- - + @@ -14685,8 +14592,7 @@ nämlich in lib::meta::func::PApply::bindBack

- - + @@ -14735,8 +14641,7 @@ };

- - + @@ -15176,8 +15081,7 @@ Daher denkt der Compiler, er kann das Ursprungsobjekt jezt wergwerfen.

- - + @@ -15215,8 +15119,7 @@ bei der Navigation in einem realen GUI auftreten

- - + @@ -15242,8 +15145,7 @@ daß ich mich wieder mal "akademisch" verspielt habe.... :-P

- - + @@ -15275,8 +15177,7 @@ Schichten-Prinzip...

- - + @@ -15740,8 +15641,7 @@ warum ViewLocator so nebulös bleibt: es gibt noch kein Lumiera GUI

- - + @@ -15809,8 +15709,7 @@ Policy: Unit-Tests dürfen keine GTK-Abhängigkeit haben

- - + @@ -15855,8 +15754,7 @@ - - + @@ -15935,8 +15833,7 @@ bewirkt nur eine Entkoppelung vom Implementierungs-Kontext

- - + @@ -15970,8 +15867,7 @@ sondern interpretieren jeweils nur eine einzige feste Konfiguration

- - + @@ -16034,8 +15930,7 @@ um auszudrücken, daß gewissen Angaben ausgelassen wurden

- - + @@ -16388,8 +16283,7 @@ dann bekommt man einen UICoord::Builder  und das ist noch keine Klausel!

- - + @@ -16487,8 +16381,7 @@ aber es könnte durchaus sein, daß man auf sie generisch zugreifen möchte

- - + @@ -16545,8 +16438,7 @@ In Fall-1 wird man eine bool-Abfrage machen wollen, und man kann auch mit einer false-Antwort umgehen. In Fall-2 dagegen bleibt nur noch der Tod. Und davon ist im Regelfall nicht auszugehen. Im Moment sehe ich Fall-2 als den standard-use-Case

- - + @@ -16563,8 +16455,7 @@ - - + @@ -16617,8 +16508,7 @@ Die einzig interessante Information ist, ob es gelungen ist

- - + @@ -16926,8 +16816,7 @@ und daher auf "inaktiv" geschaltet ist.

- - + @@ -16978,8 +16867,7 @@ Habe verifiziert, daß diese Assertion tatsächlich greift

- - + @@ -17193,8 +17081,7 @@ der es selbst vom Bus abkoppelt

- - + @@ -17329,8 +17216,7 @@ ...denn das ist das vereinfachte Setup für "einfache" Applikationen

- - + @@ -17513,8 +17399,7 @@ wenn es schon wirkliche und funktionierende Widgets im System gibt.

- - + @@ -17539,8 +17424,7 @@ ...bisher erzeugt die lookup-Operation automatisch

- - + @@ -17718,8 +17602,7 @@ das Diff wird auf den Platzhalter angewendet

- - + @@ -17734,8 +17617,7 @@ dann muß dieses automatisch deregistriert werden

- - + @@ -17918,8 +17800,7 @@ d.h. das Widget unternimmt selber nichts, und überläßt GTK die Größenbestimmung

- - + @@ -17934,8 +17815,7 @@ Und sonst wird er Körper/Hintergrund ausgedehnt

- - + @@ -17973,8 +17853,7 @@ Sehr wichtig für die Anzeige von langen Clips und Effekten.

- - + @@ -18116,8 +17995,7 @@ und welchen Teil des Verhaltens überlassen wir GTK

- - + @@ -18176,8 +18054,7 @@ Aus Gründen der Konsistenz und Zukunftsfähigkeit

- - + @@ -18210,8 +18087,7 @@ - - + @@ -18242,8 +18118,7 @@ Details im  TiddlyWiki....

- - + @@ -18307,8 +18182,7 @@ braucht feste Speicher-Addresse

- - + @@ -18331,8 +18205,7 @@ und sei es auch bloß über ein Interface!

- - + @@ -18382,8 +18255,7 @@ - - + @@ -18410,8 +18282,7 @@ Das bedeutet: viele Kind-Widgets werden auf diesem Canvas platziert und müssen daher mit ihm interagieren

- - + @@ -18437,8 +18308,7 @@ Allerdings lebt das erzeugte Kind-ViewHooked danach eigenständig und es gibt keine weitere Beziehung

- - + @@ -18457,8 +18327,7 @@ Erläuterung: man könnte auf die Idee kommen, die vier notwendigen Operationen auf dem Ziel durch Lambdas zu verkapseln. Wenn man dann aber nicht aufpaßt, resultiert das in einer Closure für jedes dieser vier Lamdas, und diese Closure hält zumindest einen Pointer auf das Zielobjekt. Der Vorteil eines solchen Ansatzes wäre natürlich, daß der konkrete Typ von Quelle und Ziel aus der Definition des ViewHook verschwindet (allerdings auch nur, wenn diese Lambdas in std::function-Objekte gewickelt sind)

- - + @@ -18482,8 +18351,7 @@ - - + @@ -18503,8 +18371,7 @@ da der ViewHook schon zwei Pointer zu zwei Entitäten halten muß, kann man Redundanzen vermeiden, indem man ihn an einem dritten Ort anbringt. Nämlich an einem Ort, an dem ohnehin schon eine Dreiecksbeziehung mit diesen beiden Elementen besteht

- - + @@ -18528,8 +18395,7 @@ Dies wäre dann das Rückgrat in der View-Behandlung in der Timeline

- - + @@ -19346,8 +19212,7 @@ ...weil der Vater ja auch neue Kinder "hooken" kann

- - + @@ -19362,8 +19227,7 @@ d.h. zugleich wird die alte Verbindung gelöst und die neue konstruiert

- - + @@ -19402,8 +19266,7 @@ es gibt keinen prinzipiellen Grund, warum sie scheitern könnte

- - + @@ -19444,8 +19307,7 @@ denn auch der Canvas ist ein Gtk::Container und hat eine Liste von Widgets

- - + @@ -19485,8 +19347,7 @@ "the children of your friends ain't necessarily your friends"

- - + @@ -19498,8 +19359,7 @@ ...sonst müßte man das Einfügen als eine weitere (protected)-Operation auf dem ViewHook ausdrücken und könnte dann die Erzeugung des ViewHooked fest in den ViewHook ABC implementieren....

- - + @@ -19521,8 +19381,7 @@ Das hängt auch damit zusammen, daß in der Praxsis die urspünglich konzipierte »Beziehungs-Entität« niemals eigens und eigenständig auftretend wird; vielmehr bekommen wir es mit einem speziellen Dekorator zu tun. Und dieser wird besser ViewHooked<X> heißen. Damit ist das bisher schon verwirrend benannte "ViewHookable" komplett daneben, und es erscheint viel sinnvoller, diesem den titelgebenenden Namen ViewHook  zu zuzuordnen

- - + @@ -19549,8 +19408,7 @@ weil nun ViewHooked schon als ctor-Parameter einen ViewHook bekommen muß...

- - + @@ -19594,8 +19452,7 @@ denn vernünftigerweise muß man davon ausgehen, daß der Canvas (oder wo auch immer das element platziert wird) sich einen Pointer speichert, und diesen später auch aktiv verwenden wird

- - + @@ -19646,8 +19503,7 @@ again the problem with the reversed order due to forward_list

- - + @@ -19700,8 +19556,7 @@ auf der rechten Seite, wo der Content angezeigt wird

- - + @@ -19725,8 +19580,7 @@ Das muß auch so sein, denn sonst wäre das systematische Modell und die Controller zu eng mit dem Display-Code verwoben. Der Nachteil ist aber, daß derart aufgedoppelte Struktur bei jeder Strukturänderung invalide wird

- - + @@ -19805,8 +19659,7 @@ ...für die dritte Lösung, die Repräsentation bereits in der Session

- - + @@ -19910,8 +19763,7 @@ Implementiert würde sie vom jeweiligen Widget

- - + @@ -19941,8 +19793,7 @@ Der Dekorator würde also auf dem TreeMutator sitzen...

- - + @@ -19963,8 +19814,7 @@ Daher gibt es die matchSrc-Operation. Effektiv wird die aber nur bei einem Delete aufgerufen...

- - + @@ -19987,8 +19837,7 @@ - - + @@ -20091,8 +19940,7 @@ d.h. eine LUID

- - + @@ -20136,8 +19984,7 @@ weil dies ggfs vom Theme her schon gestyled wird

- - + @@ -20171,8 +20018,7 @@ in der C "class init function" passieren muß

- - + @@ -20200,8 +20046,7 @@ Irgend eine BareEntryID genügt

- - + @@ -20228,8 +20073,7 @@ Daher sollte eine inkompatible Strukturänderung überhaupt nicht auftreten können

- - + @@ -20289,8 +20133,7 @@ ...abstraktes Interface

- - + @@ -20312,8 +20155,7 @@ um die Bindung herzustellen

- - + @@ -20343,8 +20185,7 @@ und erwarten abweichend vom Standard ein vollständiges Skelett im INS-Verb

- - + @@ -20377,8 +20218,7 @@ - - + @@ -20424,8 +20264,7 @@ typischerweise wird es das in einem Populationsdiff sofort als Nächstes machen.

- - + @@ -20468,8 +20307,7 @@ "was kann denn schon passieren??"

- - + @@ -20521,8 +20359,7 @@ - - + @@ -20534,8 +20371,7 @@ einen Fall, der praktisch nie auftritt

- - + @@ -20728,8 +20564,7 @@ - - + @@ -20829,8 +20664,7 @@ weil ein Layout-Manager immer nur im Bereich eines TimelineWidget relevant ist

- - + @@ -20871,8 +20705,7 @@ ...und für Signale sind diese Probleme bereits gelöst

- - + @@ -20899,8 +20732,7 @@ - - + @@ -20976,8 +20808,7 @@ aber die tatsächliche Neuberechnung erfolgt erst spät, und bei Bedarf

- - + @@ -21291,8 +21122,7 @@ - - + @@ -21313,8 +21143,7 @@ - - + @@ -21338,8 +21167,7 @@ - - + @@ -21361,8 +21189,7 @@ STOP. Damit ist die virtuelle Methode nur verschoben

- - + @@ -21378,8 +21205,7 @@ von dem nur erwartet wird, daß er eine "Verankerungs"-Funktion bietet

- - + @@ -21394,8 +21220,7 @@ welchen er aufruft, um seine neu erstellten Widgets zu verankern

- - + @@ -21459,8 +21284,7 @@ - - + @@ -21480,8 +21304,7 @@ Und zudem kristallisiert sich bereits heraus, daß wir es nicht mit einem "Universum" generischer Typen zu tun bekommen, sondern mit einer kleinen Auswahl, für die wir halt dann die Quer-Verbindungen direkt auscoden und gut is...

- - + @@ -21524,8 +21347,7 @@ und zwar der ctor-TrackPresenter

- - + @@ -21541,8 +21363,7 @@ alle anderen verschachtelten ctors aber von den TrackPresentern

- - + @@ -21558,8 +21379,7 @@ weil nur sie sowohl durch ihren Display-Frame die beiden Kind-Widgets kennen

- - + @@ -21571,8 +21391,7 @@ inwiefern gibt es Beschränkungen, wenn man ein Kind-Widget von einem Container entfernt?

- - + @@ -21587,8 +21406,7 @@ "This interface is used for all single item holding containers. Multi-item containers provide their own unique interface as their items are generally more complex. The methods of the derived classes should be prefered over these..."

- - + @@ -21601,11 +21419,33 @@ - + + + + + + + + + + + +

+ ...und hält damit sein unterliegendes C-Objekt am Leben +

+

+ (genauer gesagt, die Basisklasse Gtk::Object macht das) +

+ + + + + + @@ -21719,8 +21559,7 @@ ...das ist zunächst ein Versuch, ein mühsam errungenes Design zu verifizieren...

- - + @@ -21760,8 +21599,14 @@ - + + + + + + + @@ -21801,8 +21646,7 @@ denn, wie sich herausgestellt hat, muß das Interface ViewHook hierarchisch heruntergebrochen werden

- - + @@ -21860,8 +21704,7 @@ Oder, anders, wie bekommen wir diese Dinger jeweils in den richtigen unter-Bereich des Track-Layouts??

- - + @@ -21924,8 +21767,8 @@ - - + + @@ -21961,7 +21804,7 @@ - + @@ -21988,8 +21831,7 @@ und zwar, genauer gesagt, eine Konsequenz der Entscheidung, nicht nur einen ViewHook, sondern ein ViewHooked zu machen. Ich hab die Beziehung in's Strukturelle hinen genommen. Damit muß auch die Wurzel diese Struktur unterstützen, und damit wird an dieser Stelle die Abstraktion undicht.

- - + @@ -22005,7 +21847,8 @@ - + + @@ -22014,9 +21857,15 @@ - - - + + + + + + + + + @@ -22038,8 +21887,7 @@ nur wenn DisplayFrame selber ein ViewHook wäre

- - + @@ -22053,16 +21901,17 @@ weil der Trigger irgendwo unten passiert, und nicht auf dem top-Level ViewHook

- - + - + + - + + @@ -22214,8 +22063,7 @@ so z.B. sein Placement, welches teilweise als Properties des Track abgebildet wird.

- - + @@ -22342,8 +22190,7 @@ weil der Ruler ja in die Präsentation mit einbezogen ist

- - + @@ -22422,8 +22269,7 @@ ....ob es was sinnvolles in einem Overview-Ruler anzuzeigen gibt

- - + @@ -22475,8 +22321,7 @@ zur Anwendung kommt

- - + @@ -22525,8 +22370,7 @@ am Anfang des Track-Profils, welche immer sichtbar bleiben soll

- - + @@ -22570,8 +22414,7 @@ stets besser ist, als repetitives aufdoppeln und variieren

- - + @@ -22591,8 +22434,7 @@ - - + @@ -22650,8 +22492,7 @@ und daher nicht a priori die Liste aller einzubettenden Varianten kenne

- - + @@ -23209,8 +23050,7 @@ sollten z.B. die Konstruktor-Funktionen nicht unmittelbar mit definiert werden?

- - + @@ -23225,8 +23065,7 @@ Wie auch im konkreten Fall das TrackProfile, was dann ein vector<VerbPack> werden würde?

- - + @@ -23248,8 +23087,7 @@ und es obliegt der nächst höheren Schicht, dies auch in sinnvollem Rahmen zu tun...

- - + @@ -23287,8 +23125,7 @@ innerhalb eines PolymorphicValue.

- - + @@ -23306,8 +23143,7 @@ stets selbst erzeugen und daher auf das korrekte Literal Verlaß ist)

- - + @@ -23340,8 +23176,7 @@ und soll von beiden sub-Canvas gleichermaßen jeweils passend interpretiert werden

- - + @@ -23367,8 +23202,7 @@ ...daher die Factory

- - + @@ -23385,8 +23219,7 @@ - - + @@ -23487,8 +23320,7 @@ weil man damit eine generische Klammer bauen kann

- - + @@ -23504,8 +23336,7 @@ und bleibt anderweitig ungenutzt

- - + @@ -23525,8 +23356,7 @@ ...ist klarer, und erlaubt nebenbei auch noch, zwei Methoden einzusparen

- - + @@ -23720,8 +23550,7 @@   }

- - + @@ -23740,8 +23569,7 @@ Macht trotzdem nix

- - + @@ -23765,8 +23593,7 @@ Problem ist aber, daß diese Zuweisung später, nach einem set_size auf dem Canvas nicht revidiert wird.

- - + @@ -23780,8 +23607,7 @@ die Funktionen zum expliziten Setzen und re-Sizing sind deprecated.

- - + @@ -23804,8 +23630,7 @@ ich sollte diese Logik besser selber explizit ausprogrammieren

- - + @@ -23841,8 +23666,7 @@ ...im Session-Modell für eine Timeline jeweils ein Property hierfür geben...

- - + @@ -23879,8 +23703,7 @@ Irgendjemand muß mal den Müll runtertragen

- - + @@ -24030,8 +23853,7 @@ Kein Wunder daß die meisten UIs aus Sicht des Programmierers ein Albtraum sind

- - + @@ -24248,8 +24070,7 @@ ...in dem der Timeline body-canvas nämlich liegt

- - + @@ -24331,8 +24152,7 @@ wir können nicht von 0 bis MAXINT zeichnen

- - + @@ -24400,8 +24220,7 @@ Und letztere neigt stets zur "Verschlimmbesserung"

- - + @@ -24432,8 +24251,7 @@ Wohl aber lassen sich lokale Nachbarschafts-Beziehungen (höhe / tiefer) durch Schattierung hervorheben

- - + @@ -24448,8 +24266,7 @@ Die Inhalts-Flächen selber sind zu groß und zu strukturiert, um sie per Schattierung zu verdeutlichen

- - + @@ -24491,8 +24308,7 @@ ...zum Beispiel um einen "Wall" auch expressiv zu schattieren

- - + @@ -25022,8 +24838,7 @@ wenn er mit der HeaderPane den benötigten Platz aushandelt

- - + @@ -25077,8 +24892,7 @@ Damit werden effektiv die "schließenden Klammern" in eine einzige zusammengefaßt

- - + @@ -25133,8 +24947,7 @@ nicht nur die Ruler, auch das Prelude selber ist ein solches gePinntes Element (selbst wenn es leer ist)

- - + @@ -25195,8 +25008,7 @@ - - + @@ -25218,8 +25030,7 @@ denn was passiert, wenn sich durch das Setzen einer neuen Größe der sichtbare Bereich ändert? Löst das dann nicht erneut einen draw()-Aufruf aus??

- - + @@ -25238,8 +25049,7 @@ ist ineffizient, aber der Code ist so klarer

- - + @@ -25303,8 +25113,7 @@ Core-Entwickler von GTK

- - + @@ -25503,8 +25312,7 @@ - - + @@ -25520,8 +25328,7 @@ der GTK-Zeichencode achtet sogar explizit darauf, einen CSS-Effekt mit dem korrekten Mischmodus über den bereits auf den CairoCanvas gezeichneten Content zu legen

- - + @@ -25552,8 +25359,7 @@ weil über alles andere darübergezeichnet wird

- - + @@ -25578,8 +25384,7 @@ den Zeichenvorgang für ein normales Frame-Widget analysieren

- - + @@ -25799,8 +25604,7 @@ weil er dann mehr oder weniger hartverdrahtet ist

- - + @@ -26163,8 +25967,7 @@ Daher verzichte ich global (für die Slopes) darauf, wende sie aber lokal  an

- - + @@ -26215,8 +26018,7 @@ ...wo parktischerweise der Style-Advice in einer lokalen statischen Variablen liegt

- - + @@ -26276,8 +26078,7 @@ Und nicht die sichtbare Größe

- - + @@ -26323,8 +26124,7 @@ - - + @@ -26393,8 +26193,7 @@ - - + @@ -26476,8 +26275,7 @@ weil dann der Platz für den "pinned" Ruler redundant im Body-Canvas vorhanden ist!

- - + @@ -26527,8 +26325,7 @@ weil die Canvas-Controls tief eingewickelt in der Struktur liegen

- - + @@ -26603,8 +26400,7 @@ die sich nur beim Scrollen bemerkbar macht

- - + @@ -26616,8 +26412,7 @@ man soll ohnehin keinen so großen box-shadow verwenden

- - + @@ -26727,8 +26522,7 @@ ...sie verwenden dann ein LabelWidget zur Darstellung

- - + @@ -26784,8 +26578,7 @@ ERR: nexus.hpp:189: worker_3: ~Nexus: Some UI components are still connected to the backbone.

- - + @@ -26876,8 +26669,7 @@ Verwende das als Leitgedanke, um das Layout zu entwickeln

- - + @@ -27042,8 +26834,7 @@ ...um mal was im UI anzeigen zu können

- - + @@ -27152,8 +26943,7 @@ mehr als ein top-level Fenster offen

- - + @@ -27175,8 +26965,7 @@ which reference actions from one or more action groups.

- - + @@ -27214,8 +27003,7 @@ AUA!

- - + @@ -27259,8 +27047,7 @@ auch nicht im Application-Shutdown!

- - + @@ -27275,8 +27062,7 @@ dock_.add_item(timelinePanel->getDockItem(),Gdl::DOCK_BOTTOM);

- - + @@ -27292,8 +27078,7 @@ Helper to build the menu and for registering and handling of user action events

- - + @@ -27319,8 +27104,7 @@ aber es kann davon mehrere geben

- - + @@ -27642,8 +27426,7 @@ die erlauben, eine Init-Aktion in die Loop zu schedulen

- - + @@ -27674,8 +27457,7 @@ sondern Sachen wie verallgemeinerte "Files", D-Bus-Connection etc etc

- - + @@ -27704,8 +27486,7 @@ - - + @@ -27736,8 +27517,7 @@   //registered. (At least if window is an ApplicationWindow.)

- - + @@ -27762,8 +27542,7 @@ when an activation occurs. See g_application_activate().

- - + @@ -27805,8 +27584,7 @@ - - + @@ -27884,8 +27662,7 @@ ...für Signale, die nicht automatisch detached werden können

- - + @@ -27906,8 +27683,7 @@ @deprecated: 3.4: Key snooping should not be done. Events should  be handled by widgets

- - + @@ -27943,8 +27719,7 @@ - - + @@ -28006,8 +27781,7 @@ - - + @@ -28112,8 +27886,7 @@ schon vor der Loop verfügbar zu sein (?)

- - + @@ -28127,8 +27900,7 @@ nur bei laufender Event-Loop

- - + @@ -28182,8 +27954,7 @@ Fenster gibt es gar keine Benutzer-Events.

- - + @@ -28271,8 +28042,7 @@ und daher der Diff direkt und kompakt in einem Durchgang emittiert werden kann

- - + @@ -28327,8 +28097,7 @@ - - + @@ -28346,8 +28115,7 @@ - - + @@ -28386,8 +28154,7 @@ - - + @@ -28542,8 +28309,7 @@ where 1 tick unit depends on the current zoom level

- - + @@ -28566,8 +28332,7 @@ - - + @@ -28594,8 +28359,7 @@ Theoretisch könnte eine Skala auf einer Seite oder auf beiden Seiten limitiert sein....?

- - + @@ -28682,8 +28446,7 @@ analog zu gui::model::Tangible

- - + @@ -28752,8 +28515,7 @@ weil wir einen Mechanismus haben, die <cnt>-Dekoration pro Typ global hochzuzählen (treadsafe)

- - + @@ -28793,8 +28555,7 @@ von dem Container (GenNode) wissen, der es zwei Ebenen höher enthält und umschließt

- - + @@ -28816,8 +28577,7 @@ Der Hash kann genausogut eine Zufallszahl sein

- - + @@ -28836,8 +28596,7 @@ sich über dieses Problem Gedanken zu machen

- - + @@ -28886,8 +28645,7 @@ für global eindeutige IDs an den relevanten Stellen zu sorgen

- - + @@ -28899,8 +28657,7 @@ ...dem man eine EntryID geben kann

- - + @@ -29123,8 +28880,7 @@ erfordert bereits Kenntnis der Innereien

- - + @@ -29188,8 +28944,7 @@ heißt: Element registriert sich am UI-Bus

- - + @@ -29201,8 +28956,7 @@ heißt: Element deregistriert sich am UI-Bus

- - + @@ -29216,8 +28970,7 @@ ...ist immer ein tangible

- - + @@ -29277,8 +29030,7 @@ dafür genügt der normale Reset

- - + @@ -29291,8 +29043,7 @@ mark "clearMsg"

- - + @@ -29304,8 +29055,7 @@ mark "clearErr"

- - + @@ -29317,8 +29067,7 @@ mark "reset"

- - + @@ -29367,8 +29116,7 @@ was haben alle UI-Elemente wirklich gemeinsam?

- - + @@ -29386,8 +29134,7 @@ oder handelt es sich nur um ein Implementierungsdetail der UI-Bus-Anbindung?

- - + @@ -29447,8 +29194,7 @@ Für die UI-Programmierung muß man Spaghetticode akzeptieren.

- - + @@ -29491,8 +29237,7 @@ Dann mußte das allerdigns jeweils für alle Elemente sinnvoll sein

- - + @@ -29505,8 +29250,7 @@ und der muß vom konkreten Widget implementiert werden

- - + @@ -29615,8 +29359,7 @@ wenn es nicht sichtbar ist. Denn Sichtbarkeit gehört zur UI-Mechanik und geht den Client nix an

- - + @@ -29653,8 +29396,7 @@ denn dann gäbe es eine Implementierung "von der Stange"

- - + @@ -29860,8 +29602,7 @@ und eine state mark "reset" zurückschicken...

- - + @@ -31289,8 +31030,7 @@ durch den das Problem mit der "absrakten, opaquen" Position entschärft wird

- - + @@ -31305,8 +31045,7 @@ Implementierung: Diff-Bindung -> Diff-System

- - + @@ -31342,8 +31081,7 @@ - - + @@ -31540,8 +31278,7 @@ Der Nexus speichert nämlich eine direkte Referenz in der Routingtabelle

- - + @@ -31631,8 +31368,7 @@ da im Übrigen das UI-Modell nur mit LUIDs und generischen Namen arbeitet

- - + @@ -31719,8 +31455,7 @@ ...was ich einen Monat später schon wieder vergessen hatte...

- - + @@ -31782,8 +31517,7 @@ das reicht für die erste Integrationsrunde völlig aus

- - + @@ -31800,8 +31534,7 @@ Instanz-Management ist automatisch

- - + @@ -32200,8 +31933,7 @@ denn hier nun läuft tatsächlicher Code aus dem Destruktor heraus!

- - + @@ -32227,8 +31959,7 @@ über den Core-Service, der Nexus nach dem Nexus....

- - + @@ -32243,8 +31974,7 @@ ich will nicht damit anfangen, daß man einen Zeiger umsetzen kann....

- - + @@ -32303,8 +32033,7 @@ - - + @@ -32328,8 +32057,7 @@ match("a").after("b") scheitert, weil sich die Suche am ersten "a" festbeißt.

- - + @@ -32397,8 +32125,7 @@          ^~~~~~~~~~

- - + @@ -32431,8 +32158,7 @@ - - + @@ -32479,8 +32205,7 @@ Implementierung der real-world-Variante fehlt!

- - + @@ -32500,8 +32225,7 @@ wie Session- und State-Managment, Commands etc.

- - + @@ -32808,8 +32532,7 @@ und ebenso die Gesten abstrahieren

- - + @@ -32854,8 +32577,7 @@ - - + @@ -32889,8 +32611,7 @@ sondern gegen eine Abstraction (Command), die eigens dafür geschaffen wurde

- - + @@ -32965,8 +32686,7 @@ - - + @@ -32982,8 +32702,7 @@ ...da die DispatcherQueue direkt Command-Objekte (=frontend handle) speichert

- - + @@ -33011,8 +32730,7 @@ und wenn es stirbt, dann stirbt es halt...

- - + @@ -33042,8 +32760,7 @@ aufruf direkt mit Command-ID -> erzeugt automatisch eine Klon-Kopie

- - + @@ -33122,8 +32839,7 @@ automatisch die Kontext-Accessor-Ausdrücke ausgewertet werden

- - + @@ -33145,8 +32861,7 @@ mit dem InteractionDirector verdrahtet sein muß!

- - + @@ -33164,8 +32879,7 @@ und auch nichts mit der Trennung zwischen Layern und Subsystemen

- - + @@ -33180,8 +32894,7 @@ aka DependencyInjection + Lifecycle Management

- - + @@ -33208,8 +32921,7 @@ - - + @@ -33235,8 +32947,7 @@ es könnte auch ausreichen, einfach die passende InteractionStateManager-Impl zu verwenden

- - + @@ -33249,8 +32960,7 @@ denn InteractionStateManager ist ein Interface!

- - + @@ -33273,8 +32983,7 @@ Das könnte ein Advice sein

- - + @@ -33295,8 +33004,7 @@ In diesem Fall wird das Command enabled

- - + @@ -33308,8 +33016,7 @@ eine Argumentliste mit mehreren Parametern wir Schritt für Schritt geschlossen

- - + @@ -33324,8 +33031,7 @@ wird das gemäß Scope "nächstgelegne" genommen

- - + @@ -33441,8 +33147,7 @@ die Instanz kommt nicht in der Fixture-Queue an

- - + @@ -33460,8 +33165,7 @@ gehört nicht zum Thema "Instanz-Management"

- - + @@ -33479,8 +33183,7 @@ schon "in der Mache ist"

- - + @@ -33528,8 +33231,7 @@ neues Command-Objekt kopiert wird. Was allerdings den RefCount erhöht.

- - + @@ -33551,8 +33253,7 @@ aber sich mit einem Refcount verrückt machen.....

- - + @@ -33580,8 +33281,7 @@ mithin in der GenNode::ID

- - + @@ -33605,8 +33305,7 @@ in der globalen Registry

- - + @@ -33658,8 +33357,7 @@ und die Form der ID-Dokoration zur Konvention machen

- - + @@ -33686,8 +33384,7 @@ Das wollte ich genau nicht

- - + @@ -33718,8 +33415,7 @@ da es letztlich nur darum geht ein ohnehin öffentliches  Interface aufzurufen

- - + @@ -33754,8 +33450,7 @@ und unsinnigerweise aufwendig

- - + @@ -33948,8 +33643,7 @@ - - + @@ -34030,8 +33724,7 @@ und mit einfachen, direkt gegebenen Objekten

- - + @@ -34119,8 +33812,7 @@ (Beispiel "in-point fehlt")

- - + @@ -34138,8 +33830,7 @@ aber von einem externen State-Change getriggert wird

- - + @@ -34178,8 +33869,7 @@ Insofern löst sich dieser Knoten langsam

- - + @@ -34227,8 +33917,7 @@ Oder man könnte sie anonym verarbeiten, weil Command selber ein smart-Handle ist.

- - + @@ -34264,8 +33953,7 @@ CommandID.KontextID == Instanz

- - + @@ -34360,8 +34048,7 @@ Nebenläufigkeit ist kein Argument (da das UI single-threaded läuft)

- - + @@ -34464,8 +34151,7 @@ oder ein Command an den Dispatcher übergeben...

- - + @@ -34553,8 +34239,7 @@ Den kann man aber mit geeigneter Syntax auch direkt angeben

- - + @@ -34569,8 +34254,7 @@ allein dafür genügt eine GenNode

- - + @@ -34697,8 +34381,7 @@ Also genügt es, einen anonymen Klon dieser Instanz zu halten

- - + @@ -34725,8 +34408,7 @@ Beispiel: Menü-Eintrag "create duplicate"

- - + @@ -34765,8 +34447,7 @@ oder andernfalls einen bestimmten Namen bekommt

- - + @@ -34809,8 +34490,7 @@ wieder komplett zurückgebaut habe

- - + @@ -34892,8 +34572,7 @@ - - + @@ -34992,8 +34671,7 @@ während bereits die nächste Instanz für das GUI ausgegeben wurde.

- - + @@ -35009,8 +34687,7 @@ ...damit die Nummer erhalten bleibt

- - + @@ -35062,8 +34739,7 @@ wenn wir context-bound -Commands verwenden

- - + @@ -35083,8 +34759,7 @@ deshalb ist auch der UI-Bus nicht das Universal-Interface schlechthin

- - + @@ -36282,8 +35957,7 @@ brauche Detektor für structural change

- - + @@ -36693,8 +36367,8 @@ - + @@ -38866,8 +38540,8 @@ - + @@ -38912,8 +38586,7 @@ MockElm, Z 260 : .attach (collection(attrib)

- - + @@ -41976,8 +41649,7 @@ das heißt: nicht einmal abhängig von der STL

- - + @@ -41990,8 +41662,7 @@ wie gson

- - + @@ -42009,8 +41680,7 @@ nach dem Umzug auf Github heißt es gason

- - + @@ -42021,8 +41691,7 @@ lt. eigenen Benchmakrs deutlich schneller als rapidjson, welches eigentlich immer als der "schnelle" JSON-Parser gilt.

- - + @@ -42036,8 +41705,7 @@ d.h. das Parsen schreibt den Eingabepuffer um, und Strings bleiben einfach liegen

- - + @@ -42060,8 +41728,7 @@ kein Repo auffindbar

- - + @@ -42145,8 +41812,7 @@ - - + @@ -42165,8 +41831,7 @@ habe einen usleep(1000) getimed

- - + @@ -42199,8 +41864,7 @@ Außerdem ist ja auch noch der Aufruf des Funktors mit im Spiel, wenngleich der auch typischerweise geinlined wird

- - + @@ -42240,8 +41904,7 @@ daß x86_64 tatsächlich cache-kohärent ist

- - + @@ -42307,8 +41970,7 @@ - - + @@ -44677,8 +44339,7 @@ Visitor ist entweder void, oder bool

- - + @@ -44719,8 +44380,7 @@ - - + @@ -44750,8 +44410,7 @@ - - + @@ -44877,8 +44536,7 @@ Denn letzteres ist bei uns eine Grundannahme. Es gibt keine ungefähren Diffs!

- - + @@ -47661,8 +47319,7 @@ - - + @@ -48054,8 +47711,7 @@ Ganz prominent fehlt hier also z.B: MIDI

- - + @@ -48075,8 +47731,7 @@ die Aufgrund von Klassifikationen automatisch bereits existieren

- - + @@ -48108,8 +47763,7 @@ Meta-Assets sind per Definition "immutable"
Es gibt einen Builder

- - + @@ -48145,8 +47799,7 @@ über den UI-Bus schickt, an einen Empfänger mit bekannter ID.

- - + @@ -48202,8 +47855,7 @@ dadurch werden Meta-Operationen auf gleiche Ebene gestellt wie normale Struktur-Manipulationen

- - + @@ -48233,8 +47885,7 @@ und verlieren ihren magischen Charakter außerhalb der Event-Sourcing-Struktur

- - + @@ -48368,8 +48019,7 @@ we need to wait for the current command or builder run to be completed

- - + @@ -48383,8 +48033,7 @@ ...noch nicht implementiert 1/17

- - + @@ -48413,8 +48062,7 @@ Guard beim Zugang über das Interface

- - + @@ -48533,8 +48181,7 @@ OO rocks!

- - + @@ -48619,8 +48266,7 @@ - - + @@ -48919,8 +48565,7 @@ insofern Container auf das DESTROY-Signal ihrer Kinder reagieren

- - + @@ -48982,8 +48627,7 @@ ...also abzüglich Dekoration und Margin

- - + @@ -49005,8 +48649,7 @@ sofern das Widget mit entsprechendem Modus eingefügt wurde

- - + @@ -49039,8 +48682,7 @@ "Widget is in a background toplevel window"

- - + @@ -49088,8 +48730,7 @@ indem man eine eigene XXX_class_init() - Funktion schreibt

- - + @@ -49103,8 +48744,7 @@ in den Fällen, die ich mir angeschaut habe, steht dieser String hart codiert in der XXXX_class_init()-Funktion

- - + @@ -49119,8 +48759,7 @@ d.h. die angegebenen Abmessungen entsprechen der bounding box

- - + @@ -49144,8 +48783,7 @@ in diesem Falle würde die linke Border mit der geerben Farbe gezeichnet, und nicht gelb

- - + @@ -49164,8 +48802,7 @@ <offX> <offY> [<blur> [<spread>]] <colour>

- - + @@ -49198,8 +48835,7 @@ d.h. wir haben Referenz-Semantik

- - + @@ -49227,8 +48863,7 @@ automatisch eine höhere Priorität haben, als das, was sich aus den Path-match ergibt

- - + @@ -49258,8 +48893,7 @@ Man muß also genügend Platz allozieren für border-top-width + border-bottom-width + gewünschter Content!

- - + @@ -49288,8 +48922,7 @@ context->add_class("ohMy");

- - + @@ -49335,8 +48968,7 @@ this->set_name("my-widget")

- - + @@ -49393,8 +49025,7 @@   // changed or removed in the future.

- - + @@ -49407,8 +49038,7 @@ gtk_widget_class_set_css_name (GTK_WIDGET_GET_CLASS(gobj()), "body");

- - + @@ -49464,8 +49094,7 @@ oder ist es eine Vererbungs-Hierarchie, wie sie für das CSS-Styling benötigt wird?

- - + @@ -49543,8 +49172,7 @@ apply styles to that specific widget their gtkrc file.

- - + @@ -49573,8 +49201,7 @@ mit automatischem Refcounting

- - + @@ -49592,8 +49219,7 @@ As a consequence, the style will be regenerated to match the new given path.

- - + @@ -49668,8 +49294,7 @@ - - + @@ -50141,8 +49766,7 @@ aber macht in etwa die gleichen Operationen

- - + @@ -50163,8 +49787,7 @@ Gtk-Main verwendet inzwischen den gleichen Mechanismus

- - + @@ -50199,8 +49822,7 @@ Das ist eine subtile Falle.

- - + @@ -50242,8 +49864,7 @@ alles das nicht aus dem GUI-Thread heraus geschieht

- - + @@ -50309,8 +49930,7 @@ ...ob beim Expand/Collapse das umschließende Widget resized werden soll

- - + @@ -50322,8 +49942,7 @@ ob eingeklappt oder ausgeklappt

- - + @@ -50341,8 +49960,7 @@ was dazu führt, daß das Kind stets allen verfügbaren Platz nimmt

- - + @@ -50456,8 +50074,7 @@ This function is only used by Gtk::Container subclasses, to assign a size, position and (optionally) baseline to their child widgets.

- - + @@ -50499,8 +50116,7 @@   _release_c_instance();

- - + @@ -50556,8 +50172,7 @@ wenn das managende Widget zerstört wird

- - + @@ -50592,8 +50207,7 @@ ggfs. neu gemapped und invalidiert wird, woraufhin es neu gezeichnet wird

- - + @@ -50638,8 +50252,7 @@ Siehe Beschreibung im Beispiel/Tutorial

- - + @@ -50661,8 +50274,7 @@ Im Besonderen kann man sich an Signale anderer Widgets anhängen

- - + @@ -51060,8 +50672,7 @@ und auch ein Signal für Parse-Fehler anschließt

- - + @@ -51106,8 +50717,7 @@ Beachte: der Text-Cursor (Marker "insert") hat right gravity

- - + @@ -51204,8 +50814,7 @@ The grip is implemented as a GdlDockItemGrip

- - + @@ -51296,8 +50905,7 @@ kann eines der Templates im Zyklus vorrübergehend als "incomplete" gelten.

- - + @@ -51321,8 +50929,7 @@ Konsequenz: man wählt dann z.B. eine subtil falsche Spezialisierung.

- - + @@ -51345,8 +50952,7 @@ werden u.U sillschweigend nicht generiert

- - + @@ -51356,8 +50962,7 @@ Wenn bestimmte Vorraussetzungen nicht erfüllt sind, dann unterbleibt das automatische Injizieren eines generierten Konstruktors. Die Klasse verhält sich dann so, als wäre die btr. Definition nicht gegeben...

- - + @@ -51372,8 +50977,7 @@ Und noch häufiger: wir schwenken von Move-Konstruktion auf Copy-Konstruktion um

- - + @@ -51422,8 +51026,7 @@ ...

- - + @@ -51493,8 +51096,7 @@ selber aus einem statischen Initialisierungs-Kontext heraus erfolgt.

- - + @@ -51696,8 +51298,7 @@   }

- - + @@ -51726,8 +51327,7 @@ das sind verschiedene Blickwinkel auf das gleiche Thema

- - + @@ -51754,8 +51354,7 @@ - - + @@ -51870,8 +51469,7 @@ Allerdinsg nicht auf einer Plattform, die ohnehin sequentiell-konsistent ist. Wie "zum Beispiel" x86/64

- - + @@ -51932,8 +51530,7 @@ die shared zone anzufassen!

- - + @@ -51968,8 +51565,7 @@ Query<RES>::resolveBy

- - + @@ -52006,8 +51602,7 @@ sonst kommt Doxygen durcheinander

- - + @@ -52036,8 +51631,7 @@ wird hier kein Link erzeugt

- - + @@ -52069,8 +51663,7 @@ Die Icon-Größen ergeben sich aus den Boxes auf 'plate'

- - + @@ -52095,8 +51688,7 @@ ...im Besonderen die guten Diagramme für Pulse, ALSA und Jack

- - + @@ -52276,8 +51868,7 @@ "-Wl,-rpath-link=target/modules"

- - + @@ -52290,8 +51881,7 @@ laufen wieder alle

- - + @@ -52308,8 +51898,7 @@ test.sh Zeile 138

- - + @@ -52363,8 +51952,7 @@ und wir verbringen unsere Zeit mit contention

- - + @@ -52379,8 +51967,7 @@ ist klar, hab ich gebrochen

- - + @@ -52409,8 +51996,7 @@ Vorher hatte ich erste Kollisionen nach 25000 Nummern

- - + @@ -52462,8 +52048,7 @@ Aug 10 04:51:39 flaucher kernel: traps: test-suite[8249] trap int3 ip:7ffff7deb241 sp:7fffffffe5c8 error:0

- - + @@ -52530,8 +52115,7 @@ bison dejagnu flex gobjc libncurses5-dev libreadline-dev liblzma-dev libbabeltrace-dev libbabeltrace-ctf-dev python3-dev

- - + @@ -52581,8 +52165,7 @@ au weia LEUTE!

- - + @@ -52622,8 +52205,7 @@ und tatsächlich: das ist daneben, GCC hat Recht!

- - + @@ -52636,8 +52218,7 @@ aktualisieren und neu bauen

- - + @@ -52667,8 +52248,7 @@ wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird.

- - + @@ -52719,8 +52299,7 @@ env.GuiResource(f) for f in env.Glob('stage/*.css')

- - + @@ -52737,8 +52316,7 @@ wenn ich doch mal noch komplexere Bäume transportieren muß

- - + @@ -52750,8 +52328,7 @@ ich mag code-nahe Resourcen lieber beim Code selber

- - + @@ -52781,8 +52358,7 @@ - - + @@ -52802,8 +52378,7 @@ Dann

- - + @@ -52821,8 +52396,7 @@ nämlich im src/SConscript, wenn es um das GUI geht

- - + @@ -52867,8 +52441,7 @@ Ich meine also: zu Beginn vom Build sollte das Buildsystem einmal eine Infozeile ausgeben

- - + @@ -52880,8 +52453,7 @@ ...denn die stören jeweils beim erzeugen eines Hotfix/Patch im Paketbau per dpkg --commit

- - + @@ -52938,8 +52510,7 @@ Doku durchkämmen nach Müll

- - + @@ -52956,8 +52527,7 @@ WICHTIG: keine vorgreifende Infor publizieren!!!!!

- - + @@ -52976,8 +52546,7 @@ insgesamt sorgfältig durchlesen

- - + @@ -52997,8 +52566,7 @@ knappe Kennzeichnung des Releases in den Kommentar

- - + @@ -53025,8 +52593,7 @@ denn wir wollen keine DEB-Info im Master haben!

- - + @@ -53052,8 +52619,7 @@ die unmittelbaren Release-Dokumente durchgehen

- - + @@ -53080,8 +52646,7 @@ Sollte konfliktfrei sein

- - + @@ -53114,8 +52679,7 @@ ...das heißt bauen und hochladen

- - + @@ -53182,8 +52746,7 @@ unter Debian/Jessie wird das ignoriert

- - + @@ -53211,8 +52774,7 @@ Die Wahrscheinlichkeit, daß irgend jemand Lumiera unter Ubuntu/Trusty installieren möchte, erscheint mir akademisch

- - + @@ -53248,8 +52810,7 @@ in lib/hash-standard.hpp

- - + @@ -53284,8 +52845,7 @@ es gibt Probleme beim Linken mit den Boost-Libraries, die auf Ubuntu/wily mit gcc-5 gebaut sind.

- - + @@ -53303,8 +52863,7 @@ Wichtig: hier nur was wirklich gebaut ist und funktioniert!

- - + @@ -53344,8 +52903,7 @@ bestehen, aber irgendwann müssen wir das schon glattziehen

- - + @@ -53393,8 +52951,7 @@ seit gcc-4.8 ist kein static_assert mehr in der STDlib

- - + @@ -53499,8 +53056,7 @@ !!!!!11!!

- - + @@ -53576,8 +53132,7 @@ END

- - + @@ -53590,8 +53145,7 @@ for I in `seq 1 50`; do target/test-suite CallQueue_test; done

- - + @@ -53611,8 +53165,7 @@ und eine Doxygen-Seite im Browser geladen

- - + @@ -53643,8 +53196,7 @@ weil sich die Threads gegenseitig ihre Counter inkrementieren.

- - + @@ -53669,8 +53221,7 @@ verwenden globale Variable oder überhaupt keine Objektfelder

- - + @@ -53743,8 +53294,7 @@ und dann auf den Deaktiviert-Zustand wartet

- - + @@ -53765,8 +53315,7 @@ nachdem einmal ein wait mit Timeout verwendet worden war

- - + @@ -53819,8 +53368,7 @@ obwohl noch der Builder läuft

- - +