diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index c9074b028..3651974d2 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -18461,7 +18461,7 @@ - + @@ -18484,7 +18484,7 @@ - + @@ -18507,48 +18507,35 @@ + + + + + + - - - - - - + + + + +

- "the children of your friends ain't necessarily your friends" + Dies wäre dann das Rückgrat in der View-Behandlung in der Timeline

+ - - - - - - -

- ...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.... -

- - - - - - - - - - - - - - + + + + @@ -18556,7 +18543,7 @@ - + @@ -18579,8 +18566,7 @@ Jeder neue TrackPresenter bekommt zur Erzeugung einen Funktor, mit dem sich der von ihm gehaltene DisplayFrame in einen Vater-Kontext "einhäkeln" kann...

- - + @@ -18618,8 +18604,7 @@ ...wohl ehr nicht, aber sie sind nicht allgemeingültig, das ist das Problem

- - + @@ -18627,8 +18612,8 @@ - - + + @@ -18682,8 +18667,7 @@ alternativ kann man eine konkrete Template-Funktion deklarieren

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

- - + @@ -18766,8 +18749,7 @@ man muß nicht eine explizite Spezialisierung des ganzen Interfaces schreiben

- - + @@ -18779,8 +18761,7 @@ man schreibt die konkrete Implementierung direkt bei der Implementierung des Zieltyps mit

- - + @@ -18797,8 +18778,8 @@ - - + + @@ -18810,8 +18791,7 @@ wir könnten zwar Widgets aufbauen, diese aber dann später nicht umordnen oder zerstören

- - + @@ -18841,8 +18821,7 @@ durch die Lösung mit dem "Einhäkeln" via temporär durchgereichtem Lambda!

- - + @@ -18859,8 +18838,7 @@ um zu dokumentieren, daß wir in diesem Visitor-Mischfall am Konzept vorbei implementieren

- - + @@ -18875,8 +18853,7 @@ ...und nicht hierarchisch! Letzten Endes geht es nur darum, Widgets an einen gemeinsamen Canvas zu heften

- - + @@ -18892,14 +18869,13 @@ nämlich der Vater-TrackBody

- - + - + @@ -18923,8 +18899,7 @@ will sagen: es gibt keinen Zugriff, der vom Canvas ausgeht, durch die TrackBodies durchsteigt, und dann indirekt in den Cavas zurück greift. Denn -- zumindest im Moment -- handelt es sich um zwei klar geschiedene Belange: einmal das Rendern der Track-Struktur, und andererseits das platzieren von Clips auf dem Canvas

- - + @@ -18937,8 +18912,7 @@ ...denn diese wird von der Auswertung der Track-Struktur (vor dem Zeichnen) etabliert, und andererseits beim Platzieren eines Clip genutzt.

- - + @@ -18956,8 +18930,7 @@ und diese Info ist komplett redundant

- - + @@ -18969,8 +18942,7 @@ alle anderen Daten in TrackBody sind nicht redundant

- - + @@ -18999,8 +18971,7 @@ denn der Display/Manager bzw Canvas ist zwar "quasi global", aber eben nicht wirklich, denn er ist für eine Timeline zuständig. Also genau die Art Relation, für die man typischerweise DI macht

- - + @@ -19013,8 +18984,7 @@ weil nach hier etablierter Policy diesen erlaubt wäre, "von oben" in den trackPresenter.displayFrame.trackBody reinzugreifen für die startLine_

- - + @@ -19044,8 +19014,7 @@ ...sondern zur Timeline gehört

- - + @@ -19056,7 +19025,7 @@ - + @@ -19103,11 +19072,11 @@ ViewHooked wird nun zum eigentlichen Front-End

- - + - + + @@ -19117,7 +19086,8 @@ - + + @@ -19129,25 +19099,174 @@ + + + + + + + +

+ wie ich's auch drehe und wende, daran führt kein Weg vorbei. Weil die Referenz eben nicht wirklich global ist, sondern einen root-Kontext darstellt (nämlich die umschließende Timeline). +

+ + + + + + + + + +

+ ...also wenn wir das ViewHookable für einen anderen Kinder-Typ brauchen +

+ + + + + + + + + +

+ fragt sich von wem wir dieses Hookable für einen andern Typ bekommen +

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

+ denn wenn alle Methoden auf dem TrackBody liegen, kann man diese auch von außen direkt aufrufen +

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

+ es sei denn, man packt dann das ViewHookable in eine eigene Sub-Komponente +

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

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

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

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

- - + @@ -19321,10 +19436,62 @@ + + + + + + + + + + + + + + + + + + + +

+ "the children of your friends ain't necessarily your friends" +

+ + + + + + + + + + +

+ ...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.... +

+ + + + + + + + + + + + + + + + + @@ -19413,6 +19580,14 @@ + + + + + + + + @@ -21118,7 +21293,7 @@ - + @@ -21170,7 +21345,7 @@ - + @@ -21182,6 +21357,7 @@ + @@ -21270,7 +21446,8 @@ - + + @@ -21444,6 +21621,21 @@ + + + + + + + + + + + + + + + @@ -21462,8 +21654,9 @@ - + + @@ -22934,7 +23127,7 @@ - + @@ -39450,8 +39643,9 @@ - + +