From cc2ff520ede0d65bf71947a7bbb9abbd91faa05c Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 5 Oct 2018 17:12:23 +0200 Subject: [PATCH] DOC: Plan to rename the three Layers Considering this since some time, since it more and more occurred to me the existing conventional names are a misfit. And they are dull and clumsy. This fall, I mentioned it to Benny, and he seemed to be rather favourable towards that idea, which encourages me just to go ahead. Unfortunately, I am alone on the coding frontier right now, which has several downsides, but at least it gives me the ability to pull off radical moves. --- doc/devel/rfc/LayerNames.txt | 114 +++ doc/devel/rfc_pending/LayerNames.txt | 1 + wiki/thinkPad.ichthyo.mm | 1027 ++++++++++++++++++-------- 3 files changed, 829 insertions(+), 313 deletions(-) create mode 100644 doc/devel/rfc/LayerNames.txt create mode 120000 doc/devel/rfc_pending/LayerNames.txt diff --git a/doc/devel/rfc/LayerNames.txt b/doc/devel/rfc/LayerNames.txt new file mode 100644 index 000000000..2396e7c59 --- /dev/null +++ b/doc/devel/rfc/LayerNames.txt @@ -0,0 +1,114 @@ +LayerNames +========== + +// please don't remove the //word: comments + +[grid="all"] +`------------`----------------------- +*State* _Idea_ +*Date* _Fr 05 Oct 2018 15:05:58 CET_ +*Proposed by* Ichthyostega +------------------------------------- + +******************************************************************************** +.Abstract +Change the names of the three Layers into _Stage, Steam_ and _Vault._ +******************************************************************************** + + +Description +----------- +//description: add a detailed description: +The Lumiera code base is organised into three software layers, which is considered +adequate. However, the names we use for these layers, the way they emerged during +the early days of Lumiera, are not really convincing, given our current understanding +of the architecture. We treat the layers as a conceptual grouping device, yet as such +they are not entities within the architecture -- the actual entities are the subsystems. +Each of the existing layer names is ill-guiding do some degree. + +Gui:: + The graphical user interface seems an obvious pick for a desktop application. + However, there could be a command line interface alongside, and there will be + a script runner. These might even be active simultaneously. And even within + a classical GUI, there is more than just a bunch of widgets: there is some + kind of presentation model, there is presentation state and there is a + binding and communication facility to connect to the lower layers. + So clearly the ``upper layer'' is more than just a GUI, + it involves some kind of _backstage machinery._ + +Proc-Layer:: + The name implies processing; we might conclude the video is rendered here, + while in fact, only metadata is processed and transformed within this layer. + Everything revolves around the tension between two models, a user domain + model, and a technical processing domain model. Overall, this layer is much + akin to a language compiler -- and if you ever encountered the internals + of such a compiler, it always remains _somewhat nebulous_ where and + when the actual magic happened. + +Backend:: + We all know database backends, distributed storage and graph processing backends. + The name implies the backend can be switched, and the application is meant to + be backend technology agnostic. And while certainly true -- Lumiera is not + tied to any media processing framework -- this is rather not what happens + in our Backend layer. Rather, you'll find a very specific processing core + and intricate input/output adaptation pipelines, operating within a highly + conditioned environment, _deep down_ and shielded from the outside world. + +The proposal is thus to abandon those conventional names, and replace them +by some artificial, yet evocative terms: *Stage* -- *Steam* -- *Vault* + + +Tasks +~~~~~ +// List what needs to be done to implement this Proposal: + * find convincing new names ([green]#✔ done#) +// * second step [yellow-background]#WIP# +// * third step [red yellow-background]#TBD# + + +Discussion +~~~~~~~~~~ + +Pros +^^^^ +// add a fact list/enumeration which make this suitable: +// * foo +// * bar ... + + + +Cons +^^^^ +// fact list of the known/considered bad implications: + + + +Alternatives +^^^^^^^^^^^^ +//alternatives: explain alternatives and tell why they are not viable: + + + +Rationale +--------- +//rationale: Give a concise summary why it should be done *this* way: + + + +//Conclusion +//---------- +//conclusion: When approbate (this proposal becomes a Final) +// write some conclusions about its process: + + + + +Comments +-------- +//comments: append below + + +//endof_comments: + +'''' +Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc_pending/LayerNames.txt b/doc/devel/rfc_pending/LayerNames.txt new file mode 120000 index 000000000..610d41e81 --- /dev/null +++ b/doc/devel/rfc_pending/LayerNames.txt @@ -0,0 +1 @@ +../rfc/LayerNames.txt \ No newline at end of file diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index d1482fd3d..3f2a48a80 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -88,7 +88,7 @@ - + @@ -1706,7 +1706,7 @@ - + @@ -5408,8 +5408,7 @@ - - + @@ -5442,8 +5441,7 @@ - - + @@ -5468,8 +5466,7 @@ vorbereitete Grundstrukturen für immer wiederkehrende Setups

- - + @@ -5677,8 +5674,7 @@ Im Zweifelsfall den GTK+ Inspector verwenden!

- - + @@ -5707,8 +5703,7 @@ CSS genügt

- - + @@ -5756,8 +5751,7 @@ }

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

- - + @@ -5864,8 +5857,7 @@ bevor die Notification-Facade geöffnet werden konnte

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

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

- - + @@ -16655,8 +16645,7 @@ und daher auf "inaktiv" geschaltet ist.

- - + @@ -17021,7 +17010,7 @@ - + @@ -17056,8 +17045,7 @@ ...denn das ist das vereinfachte Setup für "einfache" Applikationen

- - + @@ -17443,8 +17431,7 @@ das Diff wird auf den Platzhalter angewendet

- - + @@ -17459,8 +17446,7 @@ dann muß dieses automatisch deregistriert werden

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

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

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

- - + @@ -17825,8 +17808,9 @@ - + + @@ -17840,8 +17824,7 @@ und welchen Teil des Verhaltens überlassen wir GTK

- - + @@ -17871,8 +17854,74 @@ + + + + + + + + + +

+ Standard UI-Mechanik überlassen wir GTK +

+ + + + + + + +

+ ...und das heißt, wir betreiben ggfs sogar erheblichen Aufwand, +

+

+ um Standard-Mechanik auch über die Standard-Mechanismen abzubilden. +

+

+ Aus Gründen der Konsistenz und Zukunftsfähigkeit +

+ + - + + + + + + +

+ unser InteractionControl ist eine Zwischenschicht +

+ + + + + + + +

+ InteractionControl +

+
    +
  • + ist ein eigenständiges Framework in der Obhut des InteractionDirector +
    • +
  • + lauscht und empfängt die Benutzer-Events zweiten Grades (nicht absolut low-level Pixel und Mausbewegung) +
    • +
  • + erzeugt Trigger, auf die die normale UI-Mechanik reagiert (z.B. setzt den Fokus, scrollt) +
    • +
+ + + + + + + @@ -17898,8 +17947,7 @@ Details im  TiddlyWiki....

- - + @@ -17945,8 +17993,9 @@ - - + + + @@ -17962,15 +18011,15 @@ braucht feste Speicher-Addresse

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

- - + @@ -17997,7 +18045,8 @@ - + + @@ -18035,8 +18084,7 @@ - - + @@ -18117,8 +18165,7 @@ ...für die dritte Lösung, die Repräsentation bereits in der Session

- - + @@ -18222,8 +18269,7 @@ Implementiert würde sie vom jeweiligen Widget

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

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

- - + @@ -18299,8 +18343,7 @@ - - + @@ -18388,8 +18431,7 @@ d.h. eine LUID

- - + @@ -18435,8 +18477,7 @@ Irgend eine BareEntryID genügt

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

- - + @@ -18516,8 +18556,7 @@ ...abstraktes Interface

- - + @@ -18539,8 +18578,7 @@ um die Bindung herzustellen

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

- - + @@ -18706,8 +18743,7 @@ und wenn nicht, dann Crash

- - + @@ -18900,8 +18936,7 @@ wenn ich mich überhaupt entscheiden konnte...

- - + @@ -18922,8 +18957,7 @@ - - + @@ -18964,11 +18998,24 @@ - + + + + + + + +

+ Widgets arbeiten stets in Pixeln +

+ + + + @@ -18983,6 +19030,28 @@ + + + + + + + + + + + + + + + + + + + + + + @@ -19030,8 +19099,7 @@ abstrahiert den Zugang zum zugehörigen Widget

- - + @@ -19047,8 +19115,7 @@ sub-Frame wird für unsere Kinder erzeugt

- - + @@ -19061,8 +19128,7 @@ Fazit: DisplayFrame kann sich auf Parent verlassen

- - + @@ -19088,8 +19154,7 @@ - - + @@ -19110,8 +19175,7 @@ - - + @@ -19135,8 +19199,7 @@ - - + @@ -19158,8 +19221,7 @@ STOP. Damit ist die virtuelle Methode nur verschoben

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

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

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

- - + @@ -19333,6 +19392,98 @@ + + + + + + + + + + +

+ ...in dem der Timeline body-canvas nämlich liegt +

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

+ nicht alles wird gezeichnet +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -19362,8 +19513,7 @@ ...sie verwenden dann ein LabelWidget zur Darstellung

- - + @@ -19409,6 +19559,19 @@ + + + + + + +

+ ERR: nexus.hpp:189: worker_3: ~Nexus: Some UI components are still connected to the backbone. +

+ + + + @@ -19487,8 +19650,7 @@ Verwende das als Leitgedanke, um das Layout zu entwickeln

- - + @@ -19631,7 +19793,7 @@ - + @@ -19929,7 +20091,7 @@ - + @@ -19979,7 +20141,7 @@ - + @@ -20863,8 +21025,7 @@ - - + @@ -20882,8 +21043,7 @@ - - + @@ -20922,8 +21082,7 @@ - - + @@ -21026,7 +21185,205 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ a fixed absolute number of tick  units, +

+

+ where 1 tick unit depends on the current zoom level +

+ + + + + + + + + + + + + + + +
    +
  • + real, d.h. in Zeit (Mikroticks) und nicht in Bildschirm-Pixeln +
    • +
  • + relativ, d.h. im Bezug auf die nominelle Zeitskala dieser Timeline;
    entsprechend der Angabe auf dem Time-Ruler +
    • +
+ + + + + + + + + + + + +

+ Beachte: nicht verwechseln mit absoluten Angaben. +

+

+ Diese Skala legt überhaupt nicht fest, wo ihr Nullpunkt liegt +

+

+ im Bezug auf eine globale absolute Zeitskala (denn das macht das betreffende Placement) +

+

+ +

+

+ Theoretisch könnte eine Skala auf einer Seite oder auf beiden Seiten limitiert sein....? +

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

+ nix GTK +

+

+ +

+

+ Liegt in unserem gui::model +

+

+ analog zu gui::model::Tangible +

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

- - + @@ -21101,8 +21457,7 @@ Problem: key nur innerhalb des Objektes eindeutig

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

- - + @@ -21150,8 +21504,7 @@ Der Hash kann genausogut eine Zufallszahl sein

- - + @@ -21170,8 +21523,7 @@ sich über dieses Problem Gedanken zu machen

- - + @@ -21183,8 +21535,7 @@ aber: zufällige ID macht Objekt-builder stateful

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

- - + @@ -21234,8 +21584,7 @@ ...dem man eine EntryID geben kann

- - + @@ -21426,8 +21775,7 @@ erfordert bereits Kenntnis der Innereien

- - + @@ -21762,8 +22110,7 @@ Identität == Bus-ID

- - + @@ -28514,8 +28861,7 @@ Implementierung der real-world-Variante fehlt!

- - + @@ -28535,8 +28881,7 @@ wie Session- und State-Managment, Commands etc.

- - + @@ -33852,8 +34197,7 @@ - - + @@ -36218,14 +36562,104 @@ Visitor ist entweder void, oder bool

- - + + + + + + + + + + +
    +
  • + denke etwa seit einem halben Jahr darüber nach. +
    • +
  • + bisher hatte ich mich nicht getraut... +
    • +
  • + im September mit Benny besprochen (per Mail). Seine Reaktion klang sogar begeistert; das hat mich ermutigt +
    • +
  • + natürlich ist es eine Menge Arbeit, aber jetzt, wo ich allein bin, kann ich sowas einfach durchziehen, ohne daß es zerredet wird +
    • +
+ + + + + + + + + + + + + + + + +

+ bisher "GUI" +

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

+ bisher "Proc-Layer" +

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

+ bisher "Backend" +

+ + + + + + + + + @@ -36288,8 +36722,7 @@ Denn letzteres ist bei uns eine Grundannahme. Es gibt keine ungefähren Diffs!

- - + @@ -39309,8 +39742,7 @@ Ganz prominent fehlt hier also z.B: MIDI

- - + @@ -39330,8 +39762,7 @@ die Aufgrund von Klassifikationen automatisch bereits existieren

- - + @@ -40194,6 +40625,44 @@ + + + + + + + + + + + + + + + + +

+ Widget berechnet adjusted allocation +

+ + + + + + + + + + +

+ ...also abzüglich Dekoration und Margin +

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

- - + @@ -40258,8 +40726,7 @@ context->add_class("ohMy");

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

- - + @@ -40376,7 +40842,7 @@ - + @@ -40400,9 +40866,8 @@ - - - + + @@ -40410,7 +40875,7 @@ - + @@ -40444,9 +40909,9 @@ - - - + + + @@ -40471,15 +40936,14 @@ Alles in ein Framework zwingen. Alternativlos, capisce?

- - + - + @@ -40510,8 +40974,7 @@ welche ggfs C++ - Exceptions fängt

- - + @@ -40543,8 +41006,7 @@ Nur das ist der Grund. Es geht gar nicht um die Event-Loop

- - + @@ -40569,8 +41031,7 @@ - - + @@ -40602,8 +41063,7 @@ - - + @@ -40642,7 +41102,7 @@ - + @@ -40724,8 +41184,7 @@ }

- - + @@ -40806,8 +41265,7 @@ }

- - + @@ -40880,8 +41338,7 @@ aber macht in etwa die gleichen Operationen

- - + @@ -40902,12 +41359,11 @@ Gtk-Main verwendet inzwischen den gleichen Mechanismus

- - + - + @@ -40938,8 +41394,7 @@ Das ist eine subtile Falle.

- - + @@ -40981,8 +41436,7 @@ alles das nicht aus dem GUI-Thread heraus geschieht

- - + @@ -41017,7 +41471,7 @@ - + @@ -41048,8 +41502,7 @@ ...ob beim Expand/Collapse das umschließende Widget resized werden soll

- - + @@ -41061,8 +41514,7 @@ ob eingeklappt oder ausgeklappt

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

- - + @@ -41096,15 +41547,14 @@ Gtk::Grid

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

- - + @@ -41223,12 +41672,15 @@ - + + - + + + @@ -41250,14 +41702,13 @@ Siehe Beschreibung im Beispiel/Tutorial

- - + - + @@ -41273,9 +41724,9 @@ Im Besonderen kann man sich an Signale anderer Widgets anhängen

- - - + + + @@ -41302,7 +41753,8 @@ - + + @@ -41317,8 +41769,7 @@ ....how does the event dispatching deal with partially covered widgets

- - + @@ -41330,8 +41781,7 @@ ...for embedded widgets

- - + @@ -41377,8 +41827,7 @@ i.e. the enclosing parent widget also gets a chance to redraw itself

- - + @@ -41409,8 +41858,7 @@ asked on stackoverflow...

- - + @@ -41429,8 +41877,7 @@ by printing values from the on_draw() callback

- - + @@ -41594,8 +42041,7 @@ Kind-Widgets noch gar nicht festgelegt war (denn das passiert erst beim draw).

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

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

- - + @@ -41793,8 +42237,7 @@ The grip is implemented as a GdlDockItemGrip

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

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

- - + @@ -41965,8 +42406,7 @@ selber aus einem statischen Initialisierungs-Kontext heraus erfolgt.

- - + @@ -42168,8 +42608,7 @@   }

- - + @@ -42436,8 +42875,7 @@ Query<RES>::resolveBy

- - + @@ -42474,8 +42912,7 @@ sonst kommt Doxygen durcheinander

- - + @@ -42504,8 +42941,7 @@ wird hier kein Link erzeugt

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

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

- - + @@ -42712,8 +43146,7 @@ "-Wl,-rpath-link=target/modules"

- - + @@ -42726,8 +43159,7 @@ laufen wieder alle

- - + @@ -42744,8 +43176,7 @@ test.sh Zeile 138

- - + @@ -42799,8 +43230,7 @@ und wir verbringen unsere Zeit mit contention

- - + @@ -42815,8 +43245,7 @@ ist klar, hab ich gebrochen

- - + @@ -42845,8 +43274,7 @@ Vorher hatte ich erste Kollisionen nach 25000 Nummern

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

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

- - + @@ -43017,8 +43443,7 @@ au weia LEUTE!

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

- - + @@ -43072,8 +43496,7 @@ aktualisieren und neu bauen

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

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

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

- - + @@ -43222,8 +43642,7 @@ Doku durchkämmen nach Müll

- - + @@ -43240,8 +43659,7 @@ WICHTIG: keine vorgreifende Infor publizieren!!!!!

- - + @@ -43260,8 +43678,7 @@ insgesamt sorgfältig durchlesen

- - + @@ -43281,8 +43698,7 @@ knappe Kennzeichnung des Releases in den Kommentar

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

- - + @@ -43336,8 +43751,7 @@ die unmittelbaren Release-Dokumente durchgehen

- - + @@ -43364,8 +43778,7 @@ Sollte konfliktfrei sein

- - + @@ -43398,8 +43811,7 @@ ...das heißt bauen und hochladen

- - + @@ -43466,8 +43878,7 @@ unter Debian/Jessie wird das ignoriert

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

- - + @@ -43532,8 +43942,7 @@ in lib/hash-standard.hpp

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

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

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

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

- - + @@ -43766,8 +44171,7 @@ END

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

- - + @@ -43801,8 +44204,7 @@ und eine Doxygen-Seite im Browser geladen

- - + @@ -43833,8 +44235,7 @@ weil sich die Threads gegenseitig ihre Counter inkrementieren.

- - +