From 1bcdf9860c55d9036fbf14e1f1bcd9b41df0921e Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 29 Nov 2019 19:25:27 +0100 Subject: [PATCH] Structure-Change: continue design/analysis --- wiki/thinkPad.ichthyo.mm | 3111 ++++++++++++++++++++++++-------------- 1 file changed, 1944 insertions(+), 1167 deletions(-) diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 08f4afce2..7b7722db3 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -117,7 +117,7 @@ - + @@ -135,13 +135,14 @@ - + + - + @@ -160,10 +161,11 @@ Ganz anders Model::Tangible: dieses registriert sich bei der Konstruktion

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

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

- + + @@ -256,7 +260,7 @@ - + @@ -269,9 +273,10 @@ Wartet nur noch auf proof-of-concept (DemoGuiRoundtrip)

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

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

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

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

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

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

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

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

- + + @@ -750,7 +763,7 @@ - + @@ -763,9 +776,10 @@ Speicherzugriffsfehler

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

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

- + + @@ -1093,7 +1110,7 @@ - + @@ -1111,7 +1128,8 @@ - + + @@ -1319,7 +1337,7 @@ - + @@ -1332,7 +1350,8 @@ Das wird eine ganze Me

- + + @@ -1423,7 +1442,7 @@ - + @@ -1439,10 +1458,11 @@ aber noch irgend ein Hund begraben liegt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- + + @@ -4656,7 +4691,7 @@ - + @@ -4666,14 +4701,15 @@ ...wenn jemand zugreift

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

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

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

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

- + + @@ -5229,7 +5271,7 @@ - + @@ -5260,10 +5302,11 @@ and shift the allocation logic to the aforementioned higher level.

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

- + + @@ -5438,7 +5482,7 @@ - + @@ -5468,13 +5512,14 @@ - + + - + @@ -5501,7 +5546,8 @@ - + + @@ -5516,7 +5562,7 @@ - + @@ -5526,7 +5572,8 @@ vorbereitete Grundstrukturen für immer wiederkehrende Setups

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

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

- + + @@ -5688,8 +5737,8 @@ - - + + @@ -5780,7 +5829,7 @@ - + @@ -5793,7 +5842,8 @@ Im Zweifelsfall den GTK+ Inspector verwenden!

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

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

- + + @@ -5944,7 +5996,7 @@ - + @@ -5957,10 +6009,11 @@ daß die alte, obsolete Timeline zurückgebaut ist

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

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

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

- + + @@ -6177,7 +6233,7 @@ - + @@ -6283,7 +6339,7 @@ - + @@ -6308,7 +6364,8 @@ diesen "aktuellen Kontext" irgendwo aufzufischen

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

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

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

- + + @@ -6581,7 +6641,7 @@ - + @@ -6594,9 +6654,10 @@ (Beispiel "in-point fehlt")

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

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

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

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

- + + - + @@ -6958,9 +7023,10 @@ ...by interpolation of some wildcards

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

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

- + + @@ -7017,7 +7085,7 @@ - + @@ -7030,14 +7098,15 @@ designated by the given coordinate spec

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

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

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

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

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

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

- + + - + @@ -7831,11 +7907,12 @@ daraus resultierenden Pfad zugreift

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

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

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

- + + @@ -7904,7 +7984,7 @@ - + @@ -7917,9 +7997,10 @@ Sofern der Pfad bereits explizit ist, genügt diese Info allein

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

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

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

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

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

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

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

- + + @@ -12585,7 +12674,7 @@ - + @@ -12595,9 +12684,10 @@ ...als Namespace-globale Variable mit externer Linkage

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- + + @@ -16417,7 +16524,7 @@ - + @@ -16438,9 +16545,10 @@ 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

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

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

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

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

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

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

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

- + + @@ -17592,7 +17708,7 @@ - + @@ -17602,9 +17718,10 @@ das Diff wird auf den Platzhalter angewendet

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

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

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

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

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

- + + @@ -18028,7 +18150,7 @@ - + @@ -18054,9 +18176,10 @@ Aus Gründen der Konsistenz und Zukunftsfähigkeit

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

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

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

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

- + + @@ -18295,7 +18424,7 @@ - + @@ -18308,7 +18437,8 @@ Allerdings lebt der erzeugte Kind-ViewHook danach eigenständig und es gibt keine weitere Beziehung

- + + @@ -18317,7 +18447,7 @@ - + @@ -18327,10 +18457,11 @@ 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)

- + + - + @@ -18351,7 +18482,8 @@ - + + @@ -18361,7 +18493,7 @@ - + @@ -18371,7 +18503,8 @@ 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

- + + @@ -18380,7 +18513,7 @@ - + @@ -18390,9 +18523,10 @@ "the children of your friends ain't necessarily your friends"

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

- + + @@ -18418,7 +18553,9 @@ - + + + @@ -18432,7 +18569,7 @@ - + @@ -18442,7 +18579,8 @@ Jeder neue TrackPresenter bekommt zur Erzeugung einen Funktor, mit dem sich der von ihm gehaltene DisplayFrame in einen Vater-Kontext "einhäkeln" kann...

- + + @@ -18491,10 +18629,131 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + +

+ alternativ kann man eine konkrete Template-Funktion deklarieren +

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

+ denn, ohne daß dies nach Außen sichtbar wäre, ist TrackBody selbst die ViewHookable-Implementierung +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -18640,9 +18899,48 @@ - + + + + + + + + + + + + + + + + + + + + +

+ denn auch der Canvas ist ein Gtk::Container und hat eine Liste von Widgets +

+ + + + + + + + + + + + + + + + + @@ -18691,7 +18989,7 @@ - + @@ -18704,7 +19002,8 @@ auf der rechten Seite, wo der Content angezeigt wird

- + + @@ -18718,7 +19017,7 @@ - + @@ -18728,7 +19027,8 @@ 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

- + + @@ -18786,7 +19086,7 @@ - + @@ -18796,7 +19096,8 @@ ...für die dritte Lösung, die Repräsentation bereits in der Session

- + + @@ -18884,7 +19185,7 @@ - + @@ -18900,9 +19201,10 @@ Implementiert würde sie vom jeweiligen Widget

- + + - + @@ -18930,9 +19232,10 @@ Der Dekorator würde also auf dem TreeMutator sitzen...

- + + - + @@ -18951,9 +19254,10 @@ Daher gibt es die matchSrc-Operation. Effektiv wird die aber nur bei einem Delete aufgerufen...

- + + - + @@ -18974,7 +19278,8 @@ - + + @@ -19067,7 +19372,7 @@ - + @@ -19077,7 +19382,8 @@ d.h. eine LUID

- + + @@ -19111,7 +19417,7 @@ - + @@ -19121,7 +19427,8 @@ weil dies ggfs vom Theme her schon gestyled wird

- + + @@ -19136,7 +19443,7 @@ - + @@ -19155,7 +19462,8 @@ in der C "class init function" passieren muß

- + + @@ -19170,7 +19478,7 @@ - + @@ -19183,7 +19491,8 @@ Irgend eine BareEntryID genügt

- + + @@ -19194,7 +19503,7 @@ - + @@ -19210,7 +19519,8 @@ Daher sollte eine inkompatible Strukturänderung überhaupt nicht auftreten können

- + + @@ -19260,7 +19570,7 @@ - + @@ -19270,13 +19580,14 @@ ...abstraktes Interface

- + + - + @@ -19292,7 +19603,8 @@ um die Bindung herzustellen

- + + @@ -19303,7 +19615,7 @@ - + @@ -19322,7 +19634,8 @@ und erwarten abweichend vom Standard ein vollständiges Skelett im INS-Verb

- + + @@ -19334,7 +19647,7 @@ - + @@ -19355,7 +19668,8 @@ - + + @@ -19373,7 +19687,7 @@ - + @@ -19401,7 +19715,8 @@ typischerweise wird es das in einem Populationsdiff sofort als Nächstes machen.

- + + @@ -19424,7 +19739,7 @@ - + @@ -19444,7 +19759,8 @@ "was kann denn schon passieren??"

- + + @@ -19475,7 +19791,7 @@ - + @@ -19496,9 +19812,10 @@ - + + - + @@ -19508,7 +19825,8 @@ einen Fall, der praktisch nie auftritt

- + + @@ -19677,7 +19995,7 @@ - + @@ -19701,7 +20019,8 @@ - + + @@ -19780,15 +20099,15 @@ - - + + - + @@ -19801,7 +20120,8 @@ weil ein Layout-Manager immer nur im Bereich eines TimelineWidget relevant ist

- + + @@ -19832,7 +20152,7 @@ - + @@ -19842,7 +20162,8 @@ ...und für Signale sind diese Probleme bereits gelöst

- + + @@ -19854,7 +20175,7 @@ - + @@ -19869,7 +20190,8 @@ - + + @@ -19880,9 +20202,9 @@ - + - + @@ -19929,7 +20251,7 @@ - + @@ -19945,7 +20267,8 @@ aber die tatsächliche Neuberechnung erfolgt erst spät, und bei Bedarf

- + + @@ -20241,7 +20564,7 @@ - + @@ -20259,10 +20582,11 @@ - + + - + @@ -20280,10 +20604,11 @@ - + + - + @@ -20304,10 +20629,11 @@ - + + - + @@ -20326,10 +20652,11 @@ STOP. Damit ist die virtuelle Methode nur verschoben

- + + - + @@ -20342,9 +20669,10 @@ von dem nur erwartet wird, daß er eine "Verankerungs"-Funktion bietet

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

- + + @@ -20422,7 +20751,7 @@ - + @@ -20435,10 +20764,11 @@ und zwar der ctor-TrackPresenter

- + + - + @@ -20451,13 +20781,14 @@ alle anderen verschachtelten ctors aber von den TrackPresentern

- + + - + @@ -20467,8 +20798,9 @@ weil nur sie sowohl durch ihren Display-Frame die beiden Kind-Widgets kennen

- - + + + @@ -20478,9 +20810,10 @@ inwiefern gibt es Beschränkungen, wenn man ein Kind-Widget von einem Container entfernt?

- + + - + @@ -20490,7 +20823,8 @@ "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..."

- + + @@ -20500,8 +20834,11 @@ - + + + + @@ -20584,7 +20921,7 @@ - + @@ -20597,7 +20934,8 @@ d.h. es wird dann nicht mehr gemanaged (was in diesem Fall hilfreich ist)

- + + @@ -20608,7 +20946,7 @@ - + @@ -20618,7 +20956,8 @@ ...das ist zunächst ein Versuch, ein mühsam errungenes Design zu verifizieren...

- + + @@ -20626,16 +20965,42 @@ - - + + + + + + + + + + +

+ ViewHooks können nach Hause telefonieren +

+ + + + + + + + + - - + + + + + + + + @@ -20654,15 +21019,29 @@ - - + + - - + + + + + + + + + +

+ denn, wie sich herausgestellt hat, muß das Interface ViewHookable hierarchisch heruntergebrochen werden +

+ + + + @@ -20673,6 +21052,14 @@ + + + + + + + + @@ -20767,7 +21154,7 @@ - + @@ -20780,7 +21167,8 @@ so z.B. sein Placement, welches teilweise als Properties des Track abgebildet wird.

- + + @@ -20897,7 +21285,7 @@ - + @@ -20907,7 +21295,8 @@ weil der Ruler ja in die Präsentation mit einbezogen ist

- + + @@ -20976,7 +21365,7 @@ - + @@ -20986,7 +21375,8 @@ ....ob es was sinnvolles in einem Overview-Ruler anzuzeigen gibt

- + + @@ -21009,7 +21399,7 @@ - + @@ -21038,7 +21428,8 @@ zur Anwendung kommt

- + + @@ -21068,7 +21459,7 @@ - + @@ -21087,7 +21478,8 @@ am Anfang des Track-Profils, welche immer sichtbar bleiben soll

- + + @@ -21118,7 +21510,7 @@ - + @@ -21131,9 +21523,10 @@ stets besser ist, als repetitives aufdoppeln und variieren

- + + - + @@ -21151,7 +21544,8 @@ - + + @@ -21184,7 +21578,7 @@ - + @@ -21209,7 +21603,8 @@ und daher nicht a priori die Liste aller einzubettenden Varianten kenne

- + + @@ -21757,7 +22152,7 @@ - + @@ -21767,9 +22162,10 @@ sollten z.B. die Konstruktor-Funktionen nicht unmittelbar mit definiert werden?

- + + - + @@ -21782,10 +22178,11 @@ Wie auch im konkreten Fall das TrackProfile, was dann ein vector<VerbPack> werden würde?

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

- + + @@ -21826,7 +22224,7 @@ - + @@ -21842,9 +22240,10 @@ innerhalb eines PolymorphicValue.

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

- + + @@ -21877,7 +22277,7 @@ - + @@ -21893,7 +22293,8 @@ und soll von beiden sub-Canvas gleichermaßen jeweils passend interpretiert werden

- + + @@ -21909,7 +22310,7 @@ - + @@ -21919,9 +22320,10 @@ ...daher die Factory

- + + - + @@ -21936,7 +22338,8 @@ - + + @@ -22027,7 +22430,7 @@ - + @@ -22037,13 +22440,14 @@ weil man damit eine generische Klammer bauen kann

- + + - + @@ -22053,7 +22457,8 @@ und bleibt anderweitig ungenutzt

- + + @@ -22063,7 +22468,7 @@ - + @@ -22073,7 +22478,8 @@ ...ist klarer, und erlaubt nebenbei auch noch, zwei Methoden einzusparen

- + + @@ -22174,8 +22580,8 @@ - - + + @@ -22209,7 +22615,7 @@ - + @@ -22267,10 +22673,11 @@   }

- + + - + @@ -22286,7 +22693,8 @@ Macht trotzdem nix

- + + @@ -22294,7 +22702,7 @@ - + @@ -22310,11 +22718,12 @@ Problem ist aber, daß diese Zuweisung später, nach einem set_size auf dem Canvas nicht revidiert wird.

- + + - + @@ -22324,11 +22733,12 @@ die Funktionen zum expliziten Setzen und re-Sizing sind deprecated.

- + + - + @@ -22347,7 +22757,8 @@ ich sollte diese Logik besser selber explizit ausprogrammieren

- + + @@ -22373,7 +22784,7 @@ - + @@ -22383,7 +22794,8 @@ ...im Session-Modell für eine Timeline jeweils ein Property hierfür geben...

- + + @@ -22401,7 +22813,7 @@ - + @@ -22420,7 +22832,8 @@ Irgendjemand muß mal den Müll runtertragen

- + + @@ -22526,8 +22939,8 @@ - - + + @@ -22557,7 +22970,7 @@ - + @@ -22570,7 +22983,8 @@ Kein Wunder daß die meisten UIs aus Sicht des Programmierers ein Albtraum sind

- + + @@ -22777,7 +23191,7 @@ - + @@ -22787,7 +23201,8 @@ ...in dem der Timeline body-canvas nämlich liegt

- + + @@ -22859,7 +23274,7 @@ - + @@ -22869,7 +23284,8 @@ wir können nicht von 0 bis MAXINT zeichnen

- + + @@ -22921,7 +23337,7 @@ - + @@ -22937,7 +23353,8 @@ Und letztere neigt stets zur "Verschlimmbesserung"

- + + @@ -22955,7 +23372,7 @@ - + @@ -22968,9 +23385,10 @@ Wohl aber lassen sich lokale Nachbarschafts-Beziehungen (höhe / tiefer) durch Schattierung hervorheben

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

- + + @@ -23015,7 +23434,7 @@ - + @@ -23025,7 +23444,8 @@ ...zum Beispiel um einen "Wall" auch expressiv zu schattieren

- + + @@ -23539,7 +23959,7 @@ - + @@ -23555,7 +23975,8 @@ wenn er mit der HeaderPane den benötigten Platz aushandelt

- + + @@ -23596,7 +24017,7 @@ - + @@ -23609,7 +24030,8 @@ Damit werden effektiv die "schließenden Klammern" in eine einzige zusammengefaßt

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

- + + @@ -23701,7 +24124,7 @@ - + @@ -23725,9 +24148,10 @@ - + + - + @@ -23747,7 +24171,8 @@ 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??

- + + @@ -23756,7 +24181,7 @@ - + @@ -23766,7 +24191,8 @@ ist ineffizient, aber der Code ist so klarer

- + + @@ -23810,7 +24236,7 @@ - + @@ -23830,7 +24256,8 @@ Core-Entwickler von GTK

- + + @@ -24011,7 +24438,7 @@ - + @@ -24029,13 +24456,14 @@ - + + - + @@ -24045,7 +24473,8 @@ der GTK-Zeichencode achtet sogar explizit darauf, einen CSS-Effekt mit dem korrekten Mischmodus über den bereits auf den CairoCanvas gezeichneten Content zu legen

- + + @@ -24066,7 +24495,7 @@ - + @@ -24076,7 +24505,8 @@ weil über alles andere darübergezeichnet wird

- + + @@ -24091,7 +24521,7 @@ - + @@ -24101,7 +24531,8 @@ den Zeichenvorgang für ein normales Frame-Widget analysieren

- + + @@ -24311,7 +24742,7 @@ - + @@ -24321,7 +24752,8 @@ weil er dann mehr oder weniger hartverdrahtet ist

- + + @@ -24671,7 +25103,7 @@ - + @@ -24684,7 +25116,8 @@ Daher verzichte ich global (für die Slopes) darauf, wende sie aber lokal  an

- + + @@ -24725,7 +25158,7 @@ - + @@ -24735,7 +25168,8 @@ ...wo parktischerweise der Style-Advice in einer lokalen statischen Variablen liegt

- + + @@ -24782,7 +25216,7 @@ - + @@ -24795,7 +25229,8 @@ Und nicht die sichtbare Größe

- + + @@ -24823,7 +25258,7 @@ - + @@ -24841,7 +25276,8 @@ - + + @@ -24858,8 +25294,8 @@ - - + + @@ -24892,7 +25328,7 @@ - + @@ -24910,7 +25346,8 @@ - + + @@ -24982,7 +25419,7 @@ - + @@ -24992,7 +25429,8 @@ weil dann der Platz für den "pinned" Ruler redundant im Body-Canvas vorhanden ist!

- + + @@ -25032,7 +25470,7 @@ - + @@ -25042,7 +25480,8 @@ weil die Canvas-Controls tief eingewickelt in der Struktur liegen

- + + @@ -25101,7 +25540,7 @@ - + @@ -25117,9 +25556,10 @@ die sich nur beim Scrollen bemerkbar macht

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

- + + @@ -25229,7 +25670,7 @@ - + @@ -25239,7 +25680,8 @@ ...sie verwenden dann ein LabelWidget zur Darstellung

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

- + + @@ -25370,7 +25813,7 @@ - + @@ -25386,7 +25829,8 @@ Verwende das als Leitgedanke, um das Layout zu entwickeln

- + + @@ -25541,7 +25985,7 @@ - + @@ -25551,7 +25995,8 @@ ...um mal was im UI anzeigen zu können

- + + @@ -25647,7 +26092,7 @@ - + @@ -25660,7 +26105,8 @@ mehr als ein top-level Fenster offen

- + + @@ -25669,7 +26115,7 @@ - + @@ -25682,7 +26128,8 @@ which reference actions from one or more action groups.

- + + @@ -25691,7 +26138,7 @@ - + @@ -25720,7 +26167,8 @@ AUA!

- + + @@ -25742,7 +26190,7 @@ - + @@ -25764,9 +26212,10 @@ auch nicht im Application-Shutdown!

- + + - + @@ -25779,13 +26228,14 @@ dock_.add_item(timelinePanel->getDockItem(),Gdl::DOCK_BOTTOM);

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

- + + @@ -25808,7 +26259,7 @@ - + @@ -25821,7 +26272,8 @@ aber es kann davon mehrere geben

- + + @@ -26001,8 +26453,8 @@ - - + + @@ -26130,7 +26582,7 @@ - + @@ -26143,7 +26595,8 @@ die erlauben, eine Init-Aktion in die Loop zu schedulen

- + + @@ -26151,7 +26604,7 @@ - + @@ -26174,7 +26627,8 @@ sondern Sachen wie verallgemeinerte "Files", D-Bus-Connection etc etc

- + + @@ -26188,7 +26642,7 @@ - + @@ -26203,7 +26657,8 @@ - + + @@ -26218,7 +26673,7 @@ - + @@ -26234,7 +26689,8 @@   //registered. (At least if window is an ApplicationWindow.)

- + + @@ -26246,7 +26702,7 @@ - + @@ -26259,7 +26715,8 @@ when an activation occurs. See g_application_activate().

- + + @@ -26280,7 +26737,7 @@ - + @@ -26301,7 +26758,8 @@ - + + @@ -26369,7 +26827,7 @@ - + @@ -26379,7 +26837,8 @@ ...für Signale, die nicht automatisch detached werden können

- + + @@ -26390,7 +26849,7 @@ - + @@ -26400,7 +26859,8 @@ @deprecated: 3.4: Key snooping should not be done. Events should  be handled by widgets

- + + @@ -26411,7 +26871,7 @@ - + @@ -26436,7 +26896,8 @@ - + + @@ -26471,7 +26932,7 @@ - + @@ -26498,7 +26959,8 @@ - + + @@ -26590,7 +27052,7 @@ - + @@ -26603,11 +27065,12 @@ schon vor der Loop verfügbar zu sein (?)

- + + - + @@ -26617,7 +27080,8 @@ nur bei laufender Event-Loop

- + + @@ -26652,7 +27116,7 @@ - + @@ -26671,7 +27135,8 @@ Fenster gibt es gar keine Benutzer-Events.

- + + @@ -26737,7 +27202,7 @@ - + @@ -26759,7 +27224,8 @@ und daher der Diff direkt und kompakt in einem Durchgang emittiert werden kann

- + + @@ -26796,7 +27262,7 @@ - + @@ -26814,10 +27280,11 @@ - + + - + @@ -26832,7 +27299,8 @@ - + + @@ -26846,7 +27314,7 @@ - + @@ -26871,7 +27339,8 @@ - + + @@ -27013,7 +27482,7 @@ - + @@ -27026,7 +27495,8 @@ where 1 tick unit depends on the current zoom level

- + + @@ -27034,7 +27504,7 @@ - + @@ -27049,12 +27519,13 @@ - + + - + @@ -27076,7 +27547,8 @@ Theoretisch könnte eine Skala auf einer Seite oder auf beiden Seiten limitiert sein....?

- + + @@ -27144,7 +27616,7 @@ - + @@ -27163,7 +27635,8 @@ analog zu gui::model::Tangible

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

- + + @@ -27259,7 +27733,7 @@ - + @@ -27272,13 +27746,14 @@ von dem Container (GenNode) wissen, der es zwei Ebenen höher enthält und umschließt

- + + - + @@ -27294,10 +27769,11 @@ Der Hash kann genausogut eine Zufallszahl sein

- + + - + @@ -27313,7 +27789,8 @@ sich über dieses Problem Gedanken zu machen

- + + @@ -27346,7 +27823,7 @@ - + @@ -27362,9 +27839,10 @@ für global eindeutige IDs an den relevanten Stellen zu sorgen

- + + - + @@ -27374,7 +27852,8 @@ ...dem man eine EntryID geben kann

- + + @@ -27578,7 +28057,7 @@ - + @@ -27597,7 +28076,8 @@ erfordert bereits Kenntnis der Innereien

- + + @@ -27651,7 +28131,7 @@ - + @@ -27661,9 +28141,10 @@ heißt: Element registriert sich am UI-Bus

- + + - + @@ -27673,11 +28154,12 @@ heißt: Element deregistriert sich am UI-Bus

- + + - + @@ -27687,7 +28169,8 @@ ...ist immer ein tangible

- + + @@ -27737,7 +28220,7 @@ - + @@ -27747,10 +28230,11 @@ dafür genügt der normale Reset

- + + - + @@ -27760,9 +28244,10 @@ mark "clearMsg"

- + + - + @@ -27772,9 +28257,10 @@ mark "clearErr"

- + + - + @@ -27784,7 +28270,8 @@ mark "reset"

- + + @@ -27810,7 +28297,7 @@ - + @@ -27833,9 +28320,10 @@ was haben alle UI-Elemente wirklich gemeinsam?

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

- + + @@ -27895,7 +28384,7 @@ - + @@ -27911,7 +28400,8 @@ Für die UI-Programmierung muß man Spaghetticode akzeptieren.

- + + @@ -27941,7 +28431,7 @@ - + @@ -27954,10 +28444,11 @@ Dann mußte das allerdigns jeweils für alle Elemente sinnvoll sein

- + + - + @@ -27967,7 +28458,8 @@ und der muß vom konkreten Widget implementiert werden

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

- + + @@ -28091,7 +28584,7 @@ - + @@ -28113,7 +28606,8 @@ denn dann gäbe es eine Implementierung "von der Stange"

- + + @@ -28284,7 +28778,7 @@ - + @@ -28319,7 +28813,8 @@ und eine state mark "reset" zurückschicken...

- + + @@ -28344,7 +28839,7 @@ - + @@ -28366,10 +28861,11 @@ Und ich muß das in einem Test zumindest emulieren können!

- + + - + @@ -28406,7 +28902,8 @@ - + + @@ -28437,7 +28934,7 @@ - + @@ -28463,7 +28960,8 @@ ist jedoch schon prototypisch implementiert

- + + @@ -28693,7 +29191,7 @@ - + @@ -28714,7 +29212,8 @@ - + + @@ -28722,7 +29221,7 @@ - + @@ -28743,7 +29242,8 @@ - + + @@ -28885,7 +29385,7 @@ - + @@ -28895,7 +29395,8 @@ since skipSrc performs both the `del` and the `skip` verb, it can not perform the match itself...

- + + @@ -28903,7 +29404,7 @@ - + @@ -28934,7 +29435,8 @@ to the next lower layer in both cases, and the result and behaviour depends on this next lower layer solely

- + + @@ -28963,7 +29465,7 @@ - + @@ -28985,10 +29487,11 @@ of this specific onion layer to accept forward until meeting this element.

- + + - + @@ -29014,7 +29517,8 @@ will check the bool return value and throw an exception in that case

- + + @@ -29079,7 +29583,7 @@ - + @@ -29095,7 +29599,8 @@ Wichtigster solcher Fall ist die Bindung auf Objekt-Felder

- + + @@ -29125,7 +29630,7 @@ - + @@ -29144,7 +29649,8 @@ to construct the new target data efficiently in place.

- + + @@ -29176,7 +29682,7 @@ - + @@ -29186,10 +29692,11 @@ Mutator enthält die Bindung auf die konkreten Daten

- + + - + @@ -29205,7 +29712,8 @@ welchen Mutator er erzeugt

- + + @@ -29280,7 +29788,7 @@ - + @@ -29293,7 +29801,8 @@ können wir rekursiv abfragen, wie groß alle möglichen Kind-Mutatoren werden können

- + + @@ -29352,7 +29861,7 @@ - + @@ -29362,7 +29871,8 @@ nur Zuweisung einiger Referenzen

- + + @@ -29379,7 +29889,7 @@ - + @@ -29395,7 +29905,8 @@ welches bestimmt, ob dieses Attribut angesprochen wird

- + + @@ -29413,7 +29924,7 @@ - + @@ -29438,9 +29949,10 @@ der "vernünftigen" (=pragmatischen) Lösung.

- + + - + @@ -29462,9 +29974,10 @@ daß es vergeblich ist. Einen Kampf gegen das Menschliche, Allzumenschliche kann man nicht gewinnen.

- + + - + @@ -29492,7 +30005,8 @@ Steuerung stattfindet, entfernt ist, entfernt in einen anderen Kontext.

- + + @@ -29649,7 +30163,7 @@ - + @@ -29674,7 +30188,8 @@ Also zählen Kinder-Collections nur als ein Strukturelement.

- + + @@ -29734,7 +30249,7 @@ - + @@ -29747,7 +30262,8 @@ durch den das Problem mit der "absrakten, opaquen" Position entschärft wird

- + + @@ -29756,7 +30272,7 @@ - + @@ -29777,9 +30293,10 @@ - + + - + @@ -29801,9 +30318,10 @@  -- das gibt einen wichtigen Hinweis --

- + + - + @@ -29816,7 +30334,8 @@ also einen double-dispatch haben

- + + @@ -29824,7 +30343,7 @@ - + @@ -29840,7 +30359,8 @@ das Diff-System noch einmal reimplementieren, dann mit einem vorgegebenen Diff-Typ

- + + @@ -29874,7 +30394,7 @@ - + @@ -29887,7 +30407,8 @@ (will sagen, es ist nicht sofort offensichtlich, daß wir jeweils einen Interpreter generieren)

- + + @@ -29956,7 +30477,7 @@ - + @@ -29975,7 +30496,8 @@ und protokolliert somit "nebenbei" was an Anforderungen an ihm vorbeigeht

- + + @@ -29994,7 +30516,7 @@ - + @@ -30004,7 +30526,8 @@ streng genommen ist es nur erlaubt, das ID-Symbol auszuwerten

- + + @@ -30013,7 +30536,7 @@ - + @@ -30033,7 +30556,8 @@ ...und das ist nicht akzeptabel für ein reines Selektor-Prädikat!

- + + @@ -30066,7 +30590,7 @@ - + @@ -30103,7 +30627,8 @@ wie z.B: eine Spur mit Labels und Clips

- + + @@ -30213,7 +30738,7 @@ - + @@ -30226,7 +30751,8 @@ für spezifische Arten von Bindings

- + + @@ -30237,7 +30763,7 @@ - + @@ -30269,7 +30795,8 @@ denn sonst würde er es für darunter liegende Layer verschatten.

- + + @@ -30328,7 +30855,7 @@ - + @@ -30347,7 +30874,8 @@ weil es eben grade noch nicht diesen neuen Wert trägt.

- + + @@ -30447,7 +30975,7 @@ - + @@ -30469,7 +30997,8 @@ sofern es gelingt, die Funktionalität gutmütig zu degradieren.

- + + @@ -30496,7 +31025,7 @@ - + @@ -30515,7 +31044,8 @@ eine womöglich irreführende Meldung generiert

- + + @@ -30556,7 +31086,7 @@ - + @@ -30593,10 +31123,11 @@ daneben auf die grüne Wiese stellen. Ist ja nur ein Test :-D

- + + - + @@ -30612,13 +31143,14 @@ dessen payload per default-konstruktor zu erzeugen.

- + + - + @@ -30660,7 +31192,8 @@ - + + @@ -30672,7 +31205,7 @@ - + @@ -30697,7 +31230,8 @@ Typisches Beispiel: eine STL-Collection von Strings.

- + + @@ -30708,7 +31242,7 @@ - + @@ -30727,7 +31261,8 @@ dann müssen Attribute irgendwie sinnvoll integriert sein

- + + @@ -30828,7 +31363,7 @@ - + @@ -30841,7 +31376,8 @@ "nicht nutzen" : meint ignorieren und verwerfen der Information

- + + @@ -30852,7 +31388,7 @@ - + @@ -30877,9 +31413,10 @@ zwingend die gleiche Reihenfolge erfordert!

- + + - + @@ -30901,7 +31438,8 @@ der sich letztlich nicht auf das Zielobjekt aufspielen läßt

- + + @@ -30924,7 +31462,7 @@ - + @@ -30937,10 +31475,11 @@ default : es gibt einen ausgezeichneten Standardwert

- + + - + @@ -30953,13 +31492,14 @@ nicht nur eine leere Record-Hülle, die nachfolgend populiert werden kann (aber nicht muß)

- + + - + @@ -30972,9 +31512,10 @@ Ab dem Punkt verhält es sich aber wie ein normales (mandatory) Feld

- + + - + @@ -30984,7 +31525,8 @@ das Objekt selber kann erkennen, ob das Feld sich im "default-Zustand" befindet

- + + @@ -31005,7 +31547,7 @@ - + @@ -31034,7 +31576,8 @@ alsauch der Check, daß überhaupt noch Quellelemente anstehen

- + + @@ -31185,7 +31728,7 @@

- + @@ -31198,7 +31741,8 @@ Somit könnten sofort Zuweisungen als Nächstes passieren

- + + @@ -31320,7 +31864,7 @@ - + @@ -31333,7 +31877,8 @@ zumal das erhebliche Statefulness bewirkt

- + + @@ -31365,7 +31910,7 @@ - + @@ -31378,7 +31923,8 @@ denn der Setter nimmt eine GenNode

- + + @@ -31418,7 +31964,7 @@ - + @@ -31428,9 +31974,10 @@ ....man könnte genausogut auch beim ersten Mal zuweisen

- + + - + @@ -31451,7 +31998,8 @@ - + + @@ -31493,7 +32041,7 @@ - + @@ -31512,7 +32060,8 @@ damit wir nicht in die ganzen Ungewissheiten der widening conversions laufen!

- + + @@ -31527,7 +32076,7 @@ - + @@ -31537,9 +32086,10 @@ d.h. der Attributwert hat Wertsemantik und wird einfach zugewiesen

- + + - + @@ -31549,7 +32099,8 @@ ...d.h. der Attributwert ist ein Objekt und damit ein nested Scope

- + + @@ -31613,7 +32164,7 @@ - + @@ -31635,7 +32186,8 @@ muß dies als INS geschehen, denn eine Zuweisung an nicht aufgeführtes Element ist verboten

- + + @@ -31660,7 +32212,7 @@ - + @@ -31673,7 +32225,8 @@ Aber es ist kein optional field, d.h. wir haben keine Flag, die es als "defaulted" kennzeichnet

- + + @@ -31801,7 +32354,7 @@ - + @@ -31814,7 +32367,8 @@ bevor ein anderes Verifikations-Prädikat angewendet wird.

- + + @@ -31868,7 +32422,7 @@ - + @@ -31884,14 +32438,15 @@ Das ist hier tatsächlich viel schlechter, als das bischen lineare Suche

- + + - + @@ -31904,7 +32459,8 @@ für den ich damals gezwungen war, die GenNode zu erfinden :)

- + + @@ -31948,7 +32504,7 @@ - + @@ -31958,9 +32514,10 @@ gleiches Argument...

- + + - + @@ -31973,7 +32530,8 @@ Dann kann man sich immer noch überlegen, ob man dann an dieser Stelle bereinigt

- + + @@ -32016,7 +32574,7 @@ - + @@ -32032,14 +32590,15 @@ Keine klare Linie

- + + - + @@ -32052,7 +32611,8 @@ Also ist die Verwendung von Vererbung hier sogar die beste Lösung

- + + @@ -32071,7 +32631,7 @@ - + @@ -32092,10 +32652,11 @@ - + + - + @@ -32113,10 +32674,11 @@ - + + - + @@ -32132,7 +32694,8 @@ also repräsentiert als Rec<GenNode>

- + + @@ -32237,7 +32800,7 @@ - + @@ -32262,7 +32825,8 @@ Die Inkonsequenz nun ist, daß im Rec::Mutator keine Magie dafür vorgesehen ist

- + + @@ -32285,7 +32849,7 @@ - + @@ -32304,7 +32868,8 @@ Denn die Lambdas haben keinen Zugriff auf die Ziel-Datenstruktur!

- + + @@ -32323,7 +32888,7 @@ - + @@ -32357,7 +32922,8 @@ um den Dekorator für die Behandlung des Typ-Feldes einzubringen.

- + + @@ -32425,7 +32991,7 @@ - + @@ -32447,10 +33013,11 @@ In jedem Fall gerät dadurch die relative Verzahnung der Elemente untereinander aus dem Takt

- + + - + @@ -32475,7 +33042,8 @@ und diese Elemente müssen geschlossen hintereinander in der Reihenfolge liegen

- + + @@ -32498,7 +33066,7 @@ - + @@ -32519,11 +33087,12 @@ - + + - + @@ -32542,7 +33111,8 @@ Letzten Endes lief  das auch in diesem Fall auf inline-Storage hinaus...

- + + @@ -32915,7 +33485,7 @@ - + @@ -32933,7 +33503,8 @@ - + + @@ -32944,7 +33515,7 @@ - + @@ -32960,7 +33531,8 @@ -- wie bzw. von wem bekommen wir dann ein Binding, das einen passenden TreeMutator konstruiert?

- + + @@ -32997,7 +33569,7 @@ - + @@ -33010,11 +33582,12 @@ und zwar per handle.get()

- + + - + @@ -33033,10 +33606,11 @@ Ich empfinde das als schlechten Stil

- + + - + @@ -33052,7 +33626,8 @@ weil die Implementierung den Zeiger auf den geschachtelen sub-Mutator umsetzen muß.

- + + @@ -33102,7 +33677,7 @@ - + @@ -33127,9 +33702,10 @@ und daher auch jeweils eigens per Unit-Test abgedeckt werden.

- + + - + @@ -33148,7 +33724,8 @@ der konkreten Bindings mit mehreren "onion layers"!

- + + @@ -33168,7 +33745,7 @@ - + @@ -33178,11 +33755,12 @@ ...denn es ist sehr verwirrend, welche Signatur denn nun die Lambdas haben müssen

- + + - + @@ -33192,7 +33770,8 @@ ...denn es kann keinen Default-Matcher geben....

- + + @@ -33210,7 +33789,7 @@ - + @@ -33226,7 +33805,8 @@ daß der Client hier eigentlich ein Protokoll implementieren muß.

- + + @@ -33283,7 +33863,7 @@ - + @@ -33311,7 +33891,8 @@ Daher habe ich mich entschlossen, dieses Sprachkonstrukt zu entfernen

- + + @@ -33359,7 +33940,7 @@ - + @@ -33369,7 +33950,8 @@ anscheinend nicht notwendig

- + + @@ -33397,7 +33979,7 @@ - + @@ -33412,7 +33994,8 @@ - + + @@ -33488,7 +34071,7 @@ - + @@ -33510,9 +34093,10 @@ Und für eine reine Ref erzeugt C++ niemals eine anonyme Instanz!

- + + - + @@ -33534,7 +34118,8 @@ MutationMessage(blaBlubb())

- + + @@ -33596,7 +34181,7 @@ - + @@ -33609,7 +34194,8 @@ Der Nexus speichert nämlich eine direkte Referenz in der Routingtabelle

- + + @@ -33626,7 +34212,7 @@ - + @@ -33647,7 +34233,8 @@ Und es gibt nicht sowas wie das "zuletzt behandelte" Element

- + + @@ -33685,7 +34272,7 @@ - + @@ -33698,10 +34285,11 @@ Das bricht mit unserem grundsätzlichen Konzept der kongruenten  Daten-Strukturen

- + + - + @@ -33714,7 +34302,8 @@ läßt sich nicht auf eine Map-Implementierung aufspielen

- + + @@ -33737,7 +34326,7 @@ - + @@ -33759,7 +34348,8 @@ und auch im Diff-Applikator nicht wirklich schwierig zu unterstützen

- + + @@ -33833,7 +34423,7 @@ - + @@ -33846,7 +34436,8 @@ da im Übrigen das UI-Modell nur mit LUIDs und generischen Namen arbeitet

- + + @@ -33923,7 +34514,7 @@ - + @@ -33933,7 +34524,8 @@ ...was ich einen Monat später schon wieder vergessen hatte...

- + + @@ -33967,7 +34559,7 @@ - + @@ -33995,14 +34587,15 @@ das reicht für die erste Integrationsrunde völlig aus

- + + - + @@ -34012,7 +34605,8 @@ Instanz-Management ist automatisch

- + + @@ -34162,8 +34756,8 @@ - - + + @@ -34386,7 +34980,7 @@ - + @@ -34411,7 +35005,8 @@ denn hier nun läuft tatsächlicher Code aus dem Destruktor heraus!

- + + @@ -34421,7 +35016,7 @@ - + @@ -34437,12 +35032,13 @@ über den Core-Service, der Nexus nach dem Nexus....

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

- + + @@ -34493,7 +35090,7 @@ - + @@ -34511,7 +35108,8 @@ - + + @@ -34519,7 +35117,7 @@ - + @@ -34535,7 +35133,8 @@ match("a").after("b") scheitert, weil sich die Suche am ersten "a" festbeißt.

- + + @@ -34557,7 +35156,7 @@ - + @@ -34603,7 +35202,8 @@          ^~~~~~~~~~

- + + @@ -34612,7 +35212,7 @@ - + @@ -34636,7 +35236,8 @@ - + + @@ -34670,7 +35271,7 @@ - + @@ -34683,11 +35284,12 @@ Implementierung der real-world-Variante fehlt!

- + + - + @@ -34703,7 +35305,8 @@ wie Session- und State-Managment, Commands etc.

- + + @@ -34994,7 +35597,7 @@ - + @@ -35010,7 +35613,8 @@ und ebenso die Gesten abstrahieren

- + + @@ -35027,7 +35631,7 @@ - + @@ -35055,7 +35659,8 @@ - + + @@ -35070,7 +35675,7 @@ - + @@ -35089,7 +35694,8 @@ sondern gegen eine Abstraction (Command), die eigens dafür geschaffen wurde

- + + @@ -35146,7 +35752,7 @@ - + @@ -35164,13 +35770,14 @@ - + + - + @@ -35180,7 +35787,8 @@ ...da die DispatcherQueue direkt Command-Objekte (=frontend handle) speichert

- + + @@ -35189,7 +35797,7 @@ - + @@ -35208,7 +35816,8 @@ und wenn es stirbt, dann stirbt es halt...

- + + @@ -35228,7 +35837,7 @@ - + @@ -35238,7 +35847,8 @@ aufruf direkt mit Command-ID -> erzeugt automatisch eine Klon-Kopie

- + + @@ -35301,7 +35911,7 @@ - + @@ -35317,13 +35927,14 @@ automatisch die Kontext-Accessor-Ausdrücke ausgewertet werden

- + + - + @@ -35339,12 +35950,13 @@ mit dem InteractionDirector verdrahtet sein muß!

- + + - + @@ -35357,9 +35969,10 @@ und auch nichts mit der Trennung zwischen Layern und Subsystemen

- + + - + @@ -35372,13 +35985,14 @@ aka DependencyInjection + Lifecycle Management

- + + - + @@ -35399,7 +36013,8 @@ - + + @@ -35412,7 +36027,7 @@ - + @@ -35425,10 +36040,11 @@ es könnte auch ausreichen, einfach die passende InteractionStateManager-Impl zu verwenden

- + + - + @@ -35438,11 +36054,12 @@ denn InteractionStateManager ist ein Interface!

- + + - + @@ -35461,9 +36078,10 @@ Das könnte ein Advice sein

- + + - + @@ -35482,9 +36100,10 @@ In diesem Fall wird das Command enabled

- + + - + @@ -35494,9 +36113,10 @@ eine Argumentliste mit mehreren Parametern wir Schritt für Schritt geschlossen

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

- + + @@ -35615,7 +36236,7 @@ - + @@ -35625,12 +36246,13 @@ die Instanz kommt nicht in der Fixture-Queue an

- + + - + @@ -35643,9 +36265,10 @@ gehört nicht zum Thema "Instanz-Management"

- + + - + @@ -35661,7 +36284,8 @@ schon "in der Mache ist"

- + + @@ -35681,7 +36305,7 @@ - + @@ -35709,7 +36333,8 @@ neues Command-Objekt kopiert wird. Was allerdings den RefCount erhöht.

- + + @@ -35721,7 +36346,7 @@ - + @@ -35731,7 +36356,8 @@ aber sich mit einem Refcount verrückt machen.....

- + + @@ -35743,7 +36369,7 @@ - + @@ -35759,9 +36385,10 @@ mithin in der GenNode::ID

- + + - + @@ -35783,7 +36410,8 @@ in der globalen Registry

- + + @@ -35822,7 +36450,7 @@ - + @@ -35835,9 +36463,10 @@ und die Form der ID-Dokoration zur Konvention machen

- + + - + @@ -35862,9 +36491,10 @@ Das wollte ich genau nicht

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

- + + @@ -35915,7 +36546,7 @@ - + @@ -35928,7 +36559,8 @@ und unsinnigerweise aufwendig

- + + @@ -36103,7 +36735,7 @@ - + @@ -36121,7 +36753,8 @@ - + + @@ -36183,7 +36816,7 @@ - + @@ -36202,7 +36835,8 @@ und mit einfachen, direkt gegebenen Objekten

- + + @@ -36277,7 +36911,7 @@ - + @@ -36290,9 +36924,10 @@ (Beispiel "in-point fehlt")

- + + - + @@ -36308,7 +36943,8 @@ aber von einem externen State-Change getriggert wird

- + + @@ -36334,7 +36970,7 @@ - + @@ -36347,7 +36983,8 @@ Insofern löst sich dieser Knoten langsam

- + + @@ -36376,7 +37013,7 @@ - + @@ -36395,7 +37032,8 @@ Oder man könnte sie anonym verarbeiten, weil Command selber ein smart-Handle ist.

- + + @@ -36415,7 +37053,7 @@ - + @@ -36431,7 +37069,8 @@ CommandID.KontextID == Instanz

- + + @@ -36457,7 +37096,7 @@ - + @@ -36510,7 +37149,7 @@ - + @@ -36526,7 +37165,8 @@ Nebenläufigkeit ist kein Argument (da das UI single-threaded läuft)

- + + @@ -36610,7 +37250,7 @@ - + @@ -36629,7 +37269,8 @@ oder ein Command an den Dispatcher übergeben...

- + + @@ -36701,7 +37342,7 @@ - + @@ -36717,9 +37358,10 @@ Den kann man aber mit geeigneter Syntax auch direkt angeben

- + + - + @@ -36732,7 +37374,8 @@ allein dafür genügt eine GenNode

- + + @@ -36760,7 +37403,7 @@ - + @@ -36843,7 +37486,7 @@ - + @@ -36859,12 +37502,13 @@ Also genügt es, einen anonymen Klon dieser Instanz zu halten

- + + - + @@ -36886,7 +37530,8 @@ Beispiel: Menü-Eintrag "create duplicate"

- + + @@ -36903,7 +37548,7 @@ - + @@ -36925,7 +37570,8 @@ oder andernfalls einen bestimmten Namen bekommt

- + + @@ -36949,7 +37595,7 @@ - + @@ -36968,7 +37614,8 @@ wieder komplett zurückgebaut habe

- + + @@ -37032,7 +37679,7 @@ - + @@ -37050,7 +37697,8 @@ - + + @@ -37136,7 +37784,7 @@ - + @@ -37149,13 +37797,14 @@ während bereits die nächste Instanz für das GUI ausgegeben wurde.

- + + - + @@ -37165,7 +37814,8 @@ ...damit die Nummer erhalten bleibt

- + + @@ -37204,7 +37854,7 @@ - + @@ -37217,11 +37867,12 @@ wenn wir context-bound -Commands verwenden

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

- + + @@ -39499,7 +40151,7 @@ - + @@ -39512,14 +40164,15 @@ die nur einmal verbraucht werden kann

- + + - + @@ -39532,9 +40185,10 @@ Paßt hier, da IterSource genau dieses Vorgehen nahelegt

- + + - + @@ -39544,7 +40198,8 @@ MutationMessage::updateDiagnostics()

- + + @@ -39553,7 +40208,7 @@ - + @@ -39563,7 +40218,8 @@ ...diejenige, die zum Zeitpunkt des updateDiagnostics() noch anstand

- + + @@ -39786,7 +40442,7 @@ - + @@ -39796,10 +40452,11 @@ das heißt: nicht einmal abhängig von der STL

- + + - + @@ -39809,12 +40466,13 @@ wie gson

- + + - + @@ -39827,8 +40485,9 @@ nach dem Umzug auf Github heißt es gason

- - + + + @@ -39838,11 +40497,12 @@ lt. eigenen Benchmakrs deutlich schneller als rapidjson, welches eigentlich immer als der "schnelle" JSON-Parser gilt.

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

- + + @@ -39865,7 +40526,7 @@ - + @@ -39875,7 +40536,8 @@ kein Repo auffindbar

- + + @@ -39935,7 +40597,7 @@ - + @@ -39959,7 +40621,8 @@ - + + @@ -39968,7 +40631,7 @@ - + @@ -39978,7 +40641,8 @@ habe einen usleep(1000) getimed

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

- + + @@ -40038,7 +40703,7 @@ - + @@ -40051,7 +40716,8 @@ daß x86_64 tatsächlich cache-kohärent ist

- + + @@ -40096,7 +40762,7 @@ - + @@ -40117,7 +40783,8 @@ - + + @@ -42473,7 +43140,7 @@ - + @@ -42486,7 +43153,8 @@ Visitor ist entweder void, oder bool

- + + @@ -42512,7 +43180,7 @@ - + @@ -42527,7 +43195,8 @@ - + + @@ -42536,7 +43205,7 @@ - + @@ -42557,7 +43226,8 @@ - + + @@ -42652,7 +43322,7 @@ - + @@ -42683,7 +43353,8 @@ Denn letzteres ist bei uns eine Grundannahme. Es gibt keine ungefähren Diffs!

- + + @@ -45448,7 +46119,7 @@ - + @@ -45466,7 +46137,8 @@ - + + @@ -45842,7 +46514,7 @@ - + @@ -45858,14 +46530,15 @@ Ganz prominent fehlt hier also z.B: MIDI

- + + - + @@ -45878,7 +46551,8 @@ die Aufgrund von Klassifikationen automatisch bereits existieren

- + + @@ -45900,7 +46574,7 @@ - + @@ -45910,7 +46584,8 @@ Meta-Assets sind per Definition "immutable"
Es gibt einen Builder

- + + @@ -45930,7 +46605,7 @@ - + @@ -45946,7 +46621,8 @@ über den UI-Bus schickt, an einen Empfänger mit bekannter ID.

- + + @@ -45989,7 +46665,7 @@ - + @@ -46002,10 +46678,11 @@ dadurch werden Meta-Operationen auf gleiche Ebene gestellt wie normale Struktur-Manipulationen

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

- + + @@ -46153,7 +46831,7 @@ - + @@ -46166,11 +46844,12 @@ we need to wait for the current command or builder run to be completed

- + + - + @@ -46180,7 +46859,8 @@ ...noch nicht implementiert 1/17

- + + @@ -46199,7 +46879,7 @@ - + @@ -46209,7 +46889,8 @@ Guard beim Zugang über das Interface

- + + @@ -46289,7 +46970,7 @@ - + @@ -46328,7 +47009,8 @@ OO rocks!

- + + @@ -46395,7 +47077,7 @@ - + @@ -46413,7 +47095,8 @@ - + + @@ -46699,7 +47382,7 @@ - + @@ -46712,7 +47395,8 @@ insofern Container auf das DESTROY-Signal ihrer Kinder reagieren

- + + @@ -46764,7 +47448,7 @@ - + @@ -46774,7 +47458,8 @@ ...also abzüglich Dekoration und Margin

- + + @@ -46783,7 +47468,7 @@ - + @@ -46796,7 +47481,8 @@ sofern das Widget mit entsprechendem Modus eingefügt wurde

- + + @@ -46819,7 +47505,7 @@ - + @@ -46829,7 +47515,8 @@ "Widget is in a background toplevel window"

- + + @@ -46852,7 +47539,7 @@ - + @@ -46877,11 +47564,12 @@ indem man eine eigene XXX_class_init() - Funktion schreibt

- + + - + @@ -46891,12 +47579,13 @@ in den Fällen, die ich mir angeschaut habe, steht dieser String hart codiert in der XXXX_class_init()-Funktion

- + + - + @@ -46906,9 +47595,10 @@ d.h. die angegebenen Abmessungen entsprechen der bounding box

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

- + + @@ -46939,7 +47630,7 @@ - + @@ -46949,7 +47640,8 @@ <offX> <offY> [<blur> [<spread>]] <colour>

- + + @@ -46972,7 +47664,7 @@ - + @@ -46982,7 +47674,8 @@ d.h. wir haben Referenz-Semantik

- + + @@ -46994,7 +47687,7 @@ - + @@ -47010,9 +47703,10 @@ automatisch eine höhere Priorität haben, als das, was sich aus den Path-match ergibt

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

- + + @@ -47056,7 +47751,7 @@ - + @@ -47069,7 +47764,8 @@ context->add_class("ohMy");

- + + @@ -47105,7 +47801,7 @@ - + @@ -47115,9 +47811,10 @@ this->set_name("my-widget")

- + + - + @@ -47172,10 +47869,11 @@   // changed or removed in the future.

- + + - + @@ -47185,7 +47883,8 @@ gtk_widget_class_set_css_name (GTK_WIDGET_GET_CLASS(gobj()), "body");

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

- + + @@ -47255,7 +47955,7 @@ - + @@ -47319,7 +48019,8 @@ apply styles to that specific widget their gtkrc file.

- + + @@ -47335,7 +48036,7 @@ - + @@ -47348,7 +48049,8 @@ mit automatischem Refcounting

- + + @@ -47356,7 +48058,7 @@ - + @@ -47366,7 +48068,8 @@ As a consequence, the style will be regenerated to match the new given path.

- + + @@ -47417,7 +48120,7 @@ - + @@ -47441,7 +48144,8 @@ - + + @@ -47900,7 +48604,7 @@ - + @@ -47913,9 +48617,10 @@ aber macht in etwa die gleichen Operationen

- + + - + @@ -47934,7 +48639,8 @@ Gtk-Main verwendet inzwischen den gleichen Mechanismus

- + + @@ -47947,7 +48653,7 @@ - + @@ -47969,7 +48675,8 @@ Das ist eine subtile Falle.

- + + @@ -47988,7 +48695,7 @@ - + @@ -48011,7 +48718,8 @@ alles das nicht aus dem GUI-Thread heraus geschieht

- + + @@ -48067,7 +48775,7 @@ - + @@ -48077,9 +48785,10 @@ ...ob beim Expand/Collapse das umschließende Widget resized werden soll

- + + - + @@ -48089,12 +48798,13 @@ ob eingeklappt oder ausgeklappt

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

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

- + + @@ -48250,7 +48962,7 @@ - + @@ -48263,7 +48975,8 @@   _release_c_instance();

- + + @@ -48277,9 +48990,9 @@ - - - + + + @@ -48306,7 +49019,7 @@ - + @@ -48319,7 +49032,8 @@ wenn das managende Widget zerstört wird

- + + @@ -48341,7 +49055,7 @@ - + @@ -48354,7 +49068,8 @@ ggfs. neu gemapped und invalidiert wird, woraufhin es neu gezeichnet wird

- + + @@ -48386,7 +49101,7 @@ - + @@ -48399,7 +49114,8 @@ Siehe Beschreibung im Beispiel/Tutorial

- + + @@ -48408,7 +49124,7 @@ - + @@ -48421,7 +49137,8 @@ Im Besonderen kann man sich an Signale anderer Widgets anhängen

- + + @@ -48803,7 +49520,7 @@ - + @@ -48819,7 +49536,8 @@ und auch ein Signal für Parse-Fehler anschließt

- + + @@ -48846,7 +49564,7 @@ - + @@ -48864,7 +49582,8 @@ Beachte: der Text-Cursor (Marker "insert") hat right gravity

- + + @@ -48939,7 +49658,7 @@ - + @@ -48961,7 +49680,8 @@ The grip is implemented as a GdlDockItemGrip

- + + @@ -49042,7 +49762,7 @@

- + @@ -49052,9 +49772,10 @@ kann eines der Templates im Zyklus vorrübergehend als "incomplete" gelten.

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

- + + @@ -49102,7 +49824,7 @@ - + @@ -49130,13 +49852,14 @@ selber aus einem statischen Initialisierungs-Kontext heraus erfolgt.

- + + - + @@ -49332,7 +50055,8 @@   }

- + + @@ -49351,7 +50075,7 @@ - + @@ -49361,7 +50085,8 @@ das sind verschiedene Blickwinkel auf das gleiche Thema

- + + @@ -49370,7 +50095,7 @@ - + @@ -49388,7 +50113,8 @@ - + + @@ -49472,7 +50198,7 @@ - + @@ -49503,7 +50229,8 @@ Allerdinsg nicht auf einer Plattform, die ohnehin sequentiell-konsistent ist. Wie "zum Beispiel" x86/64

- + + @@ -49551,7 +50278,7 @@ - + @@ -49564,7 +50291,8 @@ die shared zone anzufassen!

- + + @@ -49574,7 +50302,7 @@ - + @@ -49599,9 +50327,10 @@ Query<RES>::resolveBy

- + + - + @@ -49636,14 +50365,15 @@ sonst kommt Doxygen durcheinander

- + + - + @@ -49665,7 +50395,8 @@ wird hier kein Link erzeugt

- + + @@ -49681,7 +50412,7 @@ - + @@ -49697,7 +50428,8 @@ Die Icon-Größen ergeben sich aus den Boxes auf 'plate'

- + + @@ -49712,7 +50444,7 @@ - + @@ -49722,7 +50454,8 @@ ...im Besonderen die guten Diagramme für Pulse, ALSA und Jack

- + + @@ -49879,7 +50612,7 @@ - + @@ -49902,10 +50635,11 @@ "-Wl,-rpath-link=target/modules"

- + + - + @@ -49915,14 +50649,15 @@ laufen wieder alle

- + + - + @@ -49932,7 +50667,8 @@ test.sh Zeile 138

- + + @@ -49976,7 +50712,7 @@ - + @@ -49986,12 +50722,13 @@ und wir verbringen unsere Zeit mit contention

- + + - + @@ -50001,7 +50738,8 @@ ist klar, hab ich gebrochen

- + + @@ -50017,7 +50755,7 @@ - + @@ -50030,7 +50768,8 @@ Vorher hatte ich erste Kollisionen nach 25000 Nummern

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

- + + @@ -50139,7 +50879,7 @@ - + @@ -50149,7 +50889,8 @@ bison dejagnu flex gobjc libncurses5-dev libreadline-dev liblzma-dev libbabeltrace-dev libbabeltrace-ctf-dev python3-dev

- + + @@ -50165,7 +50906,7 @@ - + @@ -50199,7 +50940,8 @@ au weia LEUTE!

- + + @@ -50223,7 +50965,7 @@ - + @@ -50239,10 +50981,11 @@ und tatsächlich: das ist daneben, GCC hat Recht!

- + + - + @@ -50252,7 +50995,8 @@ aktualisieren und neu bauen

- + + @@ -50272,7 +51016,7 @@ - + @@ -50282,7 +51026,8 @@ wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird.

- + + @@ -50323,7 +51068,7 @@ - + @@ -50333,14 +51078,15 @@ env.GuiResource(f) for f in env.Glob('stage/*.css')

- + + - + @@ -50350,9 +51096,10 @@ wenn ich doch mal noch komplexere Bäume transportieren muß

- + + - + @@ -50362,7 +51109,8 @@ ich mag code-nahe Resourcen lieber beim Code selber

- + + @@ -50371,7 +51119,7 @@ - + @@ -50392,11 +51140,12 @@ - + + - + @@ -50412,7 +51161,8 @@ Dann

- + + @@ -50420,7 +51170,7 @@ - + @@ -50430,7 +51180,8 @@ nämlich im src/SConscript, wenn es um das GUI geht

- + + @@ -50462,7 +51213,7 @@ - + @@ -50475,9 +51226,10 @@ Ich meine also: zu Beginn vom Build sollte das Buildsystem einmal eine Infozeile ausgeben

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

- + + @@ -50534,7 +51287,7 @@ - + @@ -50544,11 +51297,12 @@ Doku durchkämmen nach Müll

- + + - + @@ -50561,10 +51315,11 @@ WICHTIG: keine vorgreifende Infor publizieren!!!!!

- + + - + @@ -50580,7 +51335,8 @@ insgesamt sorgfältig durchlesen

- + + @@ -50590,7 +51346,7 @@ - + @@ -50600,7 +51356,8 @@ knappe Kennzeichnung des Releases in den Kommentar

- + + @@ -50608,7 +51365,7 @@ - + @@ -50627,7 +51384,8 @@ denn wir wollen keine DEB-Info im Master haben!

- + + @@ -50640,7 +51398,7 @@ - + @@ -50653,7 +51411,8 @@ die unmittelbaren Release-Dokumente durchgehen

- + + @@ -50667,7 +51426,7 @@ - + @@ -50680,7 +51439,8 @@ Sollte konfliktfrei sein

- + + @@ -50703,7 +51463,7 @@ - + @@ -50713,7 +51473,8 @@ ...das heißt bauen und hochladen

- + + @@ -50767,7 +51528,7 @@ - + @@ -50780,9 +51541,10 @@ unter Debian/Jessie wird das ignoriert

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

- + + @@ -50834,7 +51597,7 @@ - + @@ -50844,7 +51607,8 @@ in lib/hash-standard.hpp

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

- + + @@ -50887,7 +51652,7 @@ - + @@ -50897,7 +51662,8 @@ Wichtig: hier nur was wirklich gebaut ist und funktioniert!

- + + @@ -50921,7 +51687,7 @@ - + @@ -50937,7 +51703,8 @@ bestehen, aber irgendwann müssen wir das schon glattziehen

- + + @@ -50975,7 +51742,7 @@ - + @@ -50985,7 +51752,8 @@ seit gcc-4.8 ist kein static_assert mehr in der STDlib

- + + @@ -51074,7 +51842,7 @@ - + @@ -51090,7 +51858,8 @@ !!!!!11!!

- + + @@ -51120,7 +51889,7 @@ - + @@ -51166,10 +51935,11 @@ END

- + + - + @@ -51179,11 +51949,12 @@ for I in `seq 1 50`; do target/test-suite CallQueue_test; done

- + + - + @@ -51199,7 +51970,8 @@ und eine Doxygen-Seite im Browser geladen

- + + @@ -51220,7 +51992,7 @@ - + @@ -51230,7 +52002,8 @@ weil sich die Threads gegenseitig ihre Counter inkrementieren.

- + + @@ -51242,7 +52015,7 @@ - + @@ -51255,7 +52028,8 @@ verwenden globale Variable oder überhaupt keine Objektfelder

- + + @@ -51312,7 +52086,7 @@ - + @@ -51328,7 +52102,8 @@ und dann auf den Deaktiviert-Zustand wartet

- + + @@ -51336,7 +52111,7 @@ - + @@ -51349,7 +52124,8 @@ nachdem einmal ein wait mit Timeout verwendet worden war

- + + @@ -51389,7 +52165,7 @@ - + @@ -51402,7 +52178,8 @@ obwohl noch der Builder läuft

- + +