From 28331f9f8aa03a85e3f92f92cde257caf10f95e0 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 18 Mar 2023 00:58:55 +0100 Subject: [PATCH] Timeline: complete the rework of UI backbone and Timeline (closes: #1014) check private notes and mindmap and fix some remaining minor inconsistencies, notably the calculations in the overlay renderer in the `BodyCanvasWidget`. --- src/stage/timeline/body-canvas-widget.cpp | 94 ++- src/stage/timeline/body-canvas-widget.hpp | 7 +- src/stage/timeline/timeline-layout.cpp | 3 - src/stage/timeline/track-body.cpp | 2 - src/stage/timeline/track-body.hpp | 2 +- src/stage/timeline/track-head-widget.hpp | 2 +- src/stage/timeline/track-presenter.hpp | 2 +- wiki/thinkPad.ichthyo.mm | 903 ++++++++++++++-------- 8 files changed, 669 insertions(+), 346 deletions(-) diff --git a/src/stage/timeline/body-canvas-widget.cpp b/src/stage/timeline/body-canvas-widget.cpp index cd4b695ed..330048c75 100644 --- a/src/stage/timeline/body-canvas-widget.cpp +++ b/src/stage/timeline/body-canvas-widget.cpp @@ -36,10 +36,12 @@ ** timeline::TrackBody::establishTrackSpace(), based on specifications drawn from the real ** CSS layout definitions. Here, within this translation unit, we define the corresponding ** timeline::ProfileInterpreter implementations; these are the concrete visitors and are - ** invoked repeatedly to carry out the actual drawing requests. - ** - ** @todo WIP-WIP-WIP as of 6/2019 + ** invoked repeatedly to carry out the actual drawing requests. ** + ** @todo as of 3/2023 the foundation of this rewritten, highly flexible drawing code established, + ** and the layout seemingly behaves reasonably stable and visually as expected, yet with + ** some minor glitches. Any kind of dynamic adjustment in response to expanding/collapsing + ** or the content representation of clips is *not yet implemented* */ @@ -50,34 +52,22 @@ #include "stage/timeline/track-body.hpp" #include "stage/style-scheme.hpp" -//#include "stage/ui-bus.hpp" -//#include "lib/format-string.hpp" #include "lib/format-cout.hpp"//////////////TODO - #include "common/advice.hpp" #include "lib/util.hpp" -//#include -//#include #include - -//using util::_Fmt; using lib::time::Time; using util::max; using util::isnil; -//using util::contains; -//using Gtk::Widget; using Gdk::Rectangle; -//using sigc::mem_fun; -//using sigc::ptr_fun; -//using std::cout; -//using std::endl; using std::string; using std::move; + namespace stage { namespace timeline { @@ -147,7 +137,7 @@ namespace timeline { styleBody->add_class (slopeClassName(depth)); TrackBody::decoration.borders[depth] = styleBody->get_border().get_bottom(); - TrackBody::decoration.borders[0] = styleBody->get_border().get_top(); // Note: we use a common size for all opening borders + TrackBody::decoration.borders[0] = styleBody->get_border().get_top(); // Note: we use a common size for all opening borders styleBody->remove_class (slopeClassName(depth)); // styleBody->context_restore(); // <<<---does not work... @@ -167,15 +157,17 @@ namespace timeline { * mechanism to invoke a set of (virtual) drawing primitives, the * actual drawing code is in the two following subclasses, * separate for the background and for drawing overlays. + * @note the *invariant* is: after processing a _verb_ from the profile, + * all drawing including the current "water level" #line_ is complete. */ class AbstractTrackRenderer : public ProfileInterpreter { protected: CairoC cox_; - StyleC style_; - StyleC styleR_; - PixSpan visible_; + StyleC style_; // CSS style for the main track body + StyleC styleR_; // CSS style for the an overview ruler + PixSpan visible_; // vertical extension of the timeline /** the current painting "water level". * To be updated while drawing top-down */ @@ -195,10 +187,18 @@ namespace timeline { public: AbstractTrackRenderer (CairoC currentDrawContext, DisplayManager& layout) : cox_{currentDrawContext} - , style_{trackBodyStyle.getAdvice()} // storing a const& to the advice is potentially dangerous, but safe here, since it is not long-lived + , style_{trackBodyStyle.getAdvice()} , styleR_{trackRulerStyle.getAdvice()} , visible_{layout.getPixSpan()} { } + /* + * Note: we store a const& to the advice in the member fields. + * This is potentially dangerous, but seems adequate here, since + * the renderer instance does not outlive the BodyCanvasWidget, + * and the style context accessed through the advice is created + * once, at application startup. Please take into account that + * this drawing code is invoked very frequently from GUI thread. + */ }; @@ -299,14 +299,18 @@ namespace timeline { } /** paint closing slope to finish nested sub tracks - * @param n number of nested levels to close */ + * @param n number of nested levels to close + * @note to get drawing of the border corners right, + * we "set back" by the border width and draw some spurious + * vertical part, hidden outside of the visible canvas area. + */ void close (uint n) override { // style_->context_save(); // <<<---does not work. Asked on SO: https://stackoverflow.com/q/57342478 style_->add_class (slopeClassName(n)); int slopeWidth = style_->get_border().get_bottom(); - line_ -= slopeWidth; // set back to create room for the (invisible) top side of the frame + line_ -= slopeWidth; // set back to create room for the (invisible) top side of the frame style_->render_frame_gap(cox_ ,visible_.b +30 ////////////////////////////////////////TODO: visual debugging @@ -351,35 +355,60 @@ namespace timeline { } /** draw overlays on top of overview/ruler track - * @param h ruler track height */ + * @param contentHeight ruler track height */ void - ruler (uint h) override + ruler (uint contentHeight) override { - line_ += h; + int marTop = styleR_->get_margin().get_top(); + int marBot = styleR_->get_margin().get_bottom(); + int padTop = styleR_->get_padding().get_top(); + int padBot = styleR_->get_padding().get_bottom(); + int frameT = styleR_->get_border().get_top(); + int frameB = styleR_->get_border().get_bottom(); + + int heightWithFrame = contentHeight + padTop+padBot + frameT+frameB; + + /* nothing to paint */ + line_ += marTop + + heightWithFrame + + marBot; } /** render overlays on top of padding/gap */ void gap (uint h) override { - UNIMPLEMENTED ("overlays for gap"); + /* nothing to paint */ + line_ += h; } /** place overlays on top of of track content area, * @remark anything to show semi-transparent * on top of the content clips */ void - content (uint h) override + content (uint contentHeight) override { + int marTop = style_->get_margin().get_top(); + int marBot = style_->get_margin().get_bottom(); + int padTop = style_->get_padding().get_top(); + int padBot = style_->get_padding().get_bottom(); + int heightWithPadding = contentHeight + padTop+padBot; + /* nothing to paint */ - line_ += h; + line_ += marTop + + heightWithPadding + + marBot; } /** render overlays covering the opening slope towards nested tracks */ void open() override { +// style_->context_save(); // <<<---does not work. Asked on SO: https://stackoverflow.com/q/57342478 + style_->add_class (slopeClassName (1)); int slopeWidth = style_->get_border().get_top(); +// style_->context_restore(); // <<<---does not work... + style_->remove_class (slopeClassName(1)); line_ += slopeWidth; } @@ -387,11 +416,12 @@ namespace timeline { void close (uint n) override { - style_->context_save(); - style_->add_class(slopeClassName(n)); +// style_->context_save(); // <<<---does not work. Asked on SO: https://stackoverflow.com/q/57342478 + style_->add_class (slopeClassName(n)); int slopeWidth = style_->get_border().get_bottom(); +// style_->context_restore(); // <<<---does not work... + style_->remove_class (slopeClassName(n)); line_ += slopeWidth; - style_->context_restore(); } public: diff --git a/src/stage/timeline/body-canvas-widget.hpp b/src/stage/timeline/body-canvas-widget.hpp index 9157c2be3..72d9cba66 100644 --- a/src/stage/timeline/body-canvas-widget.hpp +++ b/src/stage/timeline/body-canvas-widget.hpp @@ -27,7 +27,7 @@ ** implemented with automatic layout by the UI toolkit set. Rather, we need to ** control a precise temporal display grid, and we need to limit the actual widgets ** added for display, since a given timeline may easily hold several hundred up to - ** thousands of elements. To ease such tasks, a _canvas control_ -- here implemented + ** thousands of elements. To ease such tasks, a _canvas control_ — here implemented ** on top of Gtk::Layout, allows to combine _custom drawing_ with the placement of ** embedded child widgets, where the latter's layout is again managed automatically ** by the toolkit set. This approach allows us to circumvent some of the perils of @@ -51,7 +51,7 @@ ** ** ## Coordinate systems ** When drawing onto a canvas, we need to define the coordinate system. This task is - ** complicated here, since -- on implementation level -- we end up with several `Gtk::Layout` + ** complicated here, since — on implementation level — we end up with several `Gtk::Layout` ** elements (the actual canvas widget). This is necessary to accommodate for the display ** "mechanics": part of the timeline has to stay "pinned" on top, including the time ** overview ruler and possible further marker displays. Based on practical considerations @@ -66,8 +66,6 @@ ** So effectively, from the view point of (sub)widget management, we thus get virtual ** canvas coordinates per (sub)track. ** - ** @todo WIP-WIP-WIP as of 6/2019 - ** */ @@ -137,7 +135,6 @@ namespace timeline { * On the other hand, for attachment of sub-widgets onto the canvas (Clips, Effects, Markers) * we use the Interface model::CanvasHook, which allows us to break down the access hierarchically. * Each sub-Track can be outfitted with its own "virtual canvas", exposed as delegating CanvasHook. - * @todo WIP-WIP as of 6/2019 */ class BodyCanvasWidget : public Gtk::Box diff --git a/src/stage/timeline/timeline-layout.cpp b/src/stage/timeline/timeline-layout.cpp index 3b9d0d853..d445e6dbd 100644 --- a/src/stage/timeline/timeline-layout.cpp +++ b/src/stage/timeline/timeline-layout.cpp @@ -24,9 +24,6 @@ /** @file timeline-layout.cpp ** Implementation details of global timeline layout management. ** - ** @todo as of 10/2018 timeline display in the UI is rebuilt to match the architecture - ** @todo WIP-WIP-WIP as of 12/2019 - ** ** @see track-body.cpp for mapping individual tracks onto the common canvas ** @see body-canvas-widget.cpp for painting track background and overlays ** diff --git a/src/stage/timeline/track-body.cpp b/src/stage/timeline/track-body.cpp index b8f7820a8..2efc2834f 100644 --- a/src/stage/timeline/track-body.cpp +++ b/src/stage/timeline/track-body.cpp @@ -30,8 +30,6 @@ ** @see TrackBody::establishTrackSpace (TrackProfile&) ** @see BodyCanvasWidget::maybeRebuildLayout() invocation ** - ** @todo WIP-WIP-WIP as of 6/2019 - ** */ diff --git a/src/stage/timeline/track-body.hpp b/src/stage/timeline/track-body.hpp index e554050f5..1b4fc46bd 100644 --- a/src/stage/timeline/track-body.hpp +++ b/src/stage/timeline/track-body.hpp @@ -32,7 +32,7 @@ ** in the [header pane](\ref timeline::HeaderPaneWidget) and the display of the ** timeline body; the latter is actually a canvas for custom drawing. ** - ** @todo WIP-WIP-WIP as of 12/2016 + ** @todo as of 3/2023 the reworked Timeline-UI is basically complete ** */ diff --git a/src/stage/timeline/track-head-widget.hpp b/src/stage/timeline/track-head-widget.hpp index d0b942d0b..9814790b1 100644 --- a/src/stage/timeline/track-head-widget.hpp +++ b/src/stage/timeline/track-head-widget.hpp @@ -38,7 +38,7 @@ ** which serves to control such aspects relevant for all content contained within the scope ** of this track, including the sub-tracks nested therein. ** - ** @todo WIP-WIP-WIP as of 10/2018 + ** @todo as of 3/2023 the reworked Timeline-UI is basically complete ** */ diff --git a/src/stage/timeline/track-presenter.hpp b/src/stage/timeline/track-presenter.hpp index 1598786cc..4858694b9 100644 --- a/src/stage/timeline/track-presenter.hpp +++ b/src/stage/timeline/track-presenter.hpp @@ -88,7 +88,7 @@ ** investigated when there is a sufficiently complete implementation available -- see #1254 ** ** @todo as of 10/2018 timeline display in the UI is rebuilt to match the architecture - ** @todo still WIP as of 3/2020 -- yet the basic structure is settled by now. + ** @todo as of 3/2023, the basic structure is settled and the design validated ** */ diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index d6a4e2c67..729be05a1 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -17,7 +17,7 @@ - + @@ -36,7 +36,9 @@ - + + + @@ -94,11 +96,19 @@ - - + + + - + + + + + + + + @@ -107,22 +117,24 @@ - - - + + + + + - + - + - + @@ -209,7 +221,7 @@ - + @@ -253,16 +265,16 @@ - + - + - + @@ -378,12 +390,12 @@ - + - + @@ -759,9 +771,10 @@ - + - + + @@ -1034,19 +1047,19 @@ - + - + - + - + @@ -1112,7 +1125,7 @@ - + @@ -1139,7 +1152,9 @@ - + + + @@ -1387,7 +1402,7 @@ - + @@ -1457,7 +1472,7 @@ - + @@ -1646,7 +1661,7 @@ - + @@ -3995,7 +4010,7 @@ - + @@ -4091,7 +4106,7 @@ - + @@ -4122,7 +4137,7 @@ - + @@ -4138,7 +4153,7 @@ - + @@ -4293,7 +4308,7 @@ - + @@ -4319,7 +4334,8 @@ - + + @@ -4360,7 +4376,7 @@ - + @@ -5121,7 +5137,7 @@ - + @@ -5245,7 +5261,7 @@ - + @@ -5294,7 +5310,7 @@ - + @@ -5305,7 +5321,8 @@

- + + @@ -5438,16 +5455,19 @@ - + - + - + + - + + + @@ -5468,11 +5488,11 @@ - + - - - + + + @@ -5488,38 +5508,39 @@ - + - + - + - - + - - - + + + + - + - + - - - - + + + + - + - + - + - + + @@ -5995,7 +6016,7 @@ - + @@ -6171,7 +6192,7 @@

- + @@ -6417,8 +6438,8 @@ - - + + @@ -6724,7 +6745,17 @@ - + + + + + + +

+ das ist ein gaaaanz großes Strategisches Thema; vor 2023 hatte ich schon mehrfach versucht, es zu fassen — das ist mir aber bisher nicht gelungen, und deshalb wartet es.... ⌛ +

+ + @@ -6885,7 +6916,7 @@ - + @@ -6958,7 +6989,7 @@ - + @@ -7025,7 +7056,8 @@ - + + @@ -7219,12 +7251,26 @@ - + - + + + + + + + +

+ ...das können wir erst dann sinnvoll angehen, wenn die Application-Core weiter ausgereift ist +

+ + + + + @@ -15519,7 +15565,7 @@ - + @@ -16107,7 +16153,7 @@ - + @@ -17194,10 +17240,10 @@ - + - + @@ -18067,7 +18113,7 @@ - + @@ -18151,7 +18197,7 @@ - + @@ -18257,7 +18303,7 @@ - + @@ -19080,8 +19126,9 @@ - - + + + @@ -19111,8 +19158,9 @@ - + + @@ -19140,7 +19188,8 @@ - + + @@ -20457,6 +20506,7 @@ + @@ -21601,8 +21651,9 @@ - + + @@ -23539,8 +23590,9 @@ - - + + + @@ -23586,7 +23638,7 @@ - + @@ -23716,7 +23768,7 @@ - + @@ -23740,7 +23792,7 @@ - + @@ -24911,6 +24963,7 @@ + @@ -25078,7 +25131,7 @@ - + @@ -25229,10 +25282,11 @@ - + - - + + + @@ -25369,13 +25423,23 @@ - - + + - - + + + + + + +

+ ...bis jetzt genügt es, das TrackProfile selbst als "dirty-flag" zu misbrauchen. Aber ich vermute, längerfristig bekommen wir irgendwo im GUI noch weiteren "dirty-state" ⟹ und dann bleibt die Frage, wo siedeln wir den an... +

+ + + @@ -25386,7 +25450,8 @@ - + + @@ -25400,7 +25465,8 @@ - + + @@ -25451,7 +25517,8 @@ - + + @@ -25525,12 +25592,12 @@ - + - + @@ -25658,7 +25725,8 @@ - + + @@ -25747,7 +25815,8 @@ - + + @@ -25803,7 +25872,7 @@

- + @@ -25811,9 +25880,10 @@ - + + - + @@ -25849,7 +25919,7 @@ - + @@ -25863,7 +25933,7 @@ - + @@ -25883,8 +25953,8 @@ - - + + @@ -25903,9 +25973,9 @@ - + - + @@ -25917,7 +25987,7 @@ - + @@ -25950,7 +26020,7 @@ - + @@ -26039,7 +26109,7 @@ - + @@ -26105,7 +26175,7 @@ - + @@ -26146,10 +26216,12 @@ - - - - + + + + + + @@ -26166,11 +26238,11 @@ - + - + @@ -26192,7 +26264,8 @@ - + + @@ -26250,7 +26323,7 @@ - + @@ -26592,7 +26665,7 @@ - + @@ -26623,7 +26696,7 @@ - + @@ -26632,7 +26705,7 @@ - + @@ -26721,7 +26794,7 @@ - + @@ -26765,10 +26838,10 @@ - + - + @@ -27603,7 +27676,7 @@ - + @@ -27612,7 +27685,7 @@ - + @@ -27766,7 +27839,7 @@ - + @@ -28146,7 +28219,8 @@ - + + @@ -28211,10 +28285,8 @@ - - - - + + @@ -29816,13 +29888,40 @@ - + + + + + + + + +

+ Mehrere Aspekte sind hier offen (2023: Abschluß der GUI-Neugründung und vor Playback-Vertical-Slice): +

+
    +
  • + die Track-Head-Abschnitte beginnen nicht exakt korrekt bündig mit dem zugehörigen Bereich im Body; möglicherweise ein "run-away" um ein paar Pixel +
    • +
  • + die Scopes reagieren noch nicht dynamisch auf den Inhalt (und es fehlt die aktive Abstimmung) +
    • +
  • + die Scopes sollten auch eine dynamische Status-Anzeige unterstützen +
    • +
+ + + + + + @@ -32474,7 +32573,7 @@ - + @@ -32500,9 +32599,10 @@ - + - + + @@ -32759,13 +32859,14 @@ - + + - + @@ -32808,7 +32909,7 @@ - + @@ -33313,8 +33414,9 @@ - - + + + @@ -33349,7 +33451,8 @@ - + + @@ -33362,6 +33465,7 @@ + @@ -33372,7 +33476,8 @@ - + + @@ -33390,10 +33495,12 @@ - + + + @@ -33453,9 +33560,9 @@ - + - + @@ -33563,8 +33670,8 @@ - - + + @@ -33639,8 +33746,11 @@ + + - + + @@ -33690,7 +33800,7 @@ - + @@ -33720,7 +33830,7 @@ - + @@ -33730,20 +33840,7 @@ - - - - - - -

- Wir erzeugen künstlich einen widget-Path und verankern ihn sinngemäß an der logisch richtigen Stelle (wobei aber die im Pfad aufgeführten Widgets gar nicht existieren, sondern logische Platzhalter sind). Über diesen Widget-Path greifen wir in einen CSS-Scope hinein, der typischerweise alle seine Styles von umschließenden Scopes erbt; indirekt ist damit aber auch die Möglichkeit geschaffen, diesen speziellen Scope gezielt mit CSS-Regeln zu addressieren — wodurch der Designer direkt auf das Erscheinungbild von Lumiera Einfluß nehmen kann -

- - - - - + @@ -33756,10 +33853,22 @@ TiddlyWiki + doc/technical/stage/style/Timeline.txt

- - + + + + + + + +

+ Wir erzeugen künstlich einen widget-Path und verankern ihn sinngemäß an der logisch richtigen Stelle (wobei aber die im Pfad aufgeführten Widgets gar nicht existieren, sondern logische Platzhalter sind). Über diesen Widget-Path greifen wir in einen CSS-Scope hinein, der typischerweise alle seine Styles von umschließenden Scopes erbt; indirekt ist damit aber auch die Möglichkeit geschaffen, diesen speziellen Scope gezielt mit CSS-Regeln zu addressieren — wodurch der Designer direkt auf das Erscheinungbild von Lumiera Einfluß nehmen kann +

+ + + + @@ -33790,7 +33899,8 @@ - + + @@ -33804,8 +33914,9 @@ - - + + + @@ -34147,7 +34258,8 @@ - + + @@ -34188,7 +34300,8 @@ - + + @@ -34476,18 +34589,18 @@ - + - - - - + + + + - + @@ -34514,34 +34627,28 @@ - - - - - - - + + - - + - - + + - - + + - + - + - + @@ -34558,7 +34665,7 @@ - + @@ -34568,35 +34675,6 @@ - - - - - - - - - - -

- ...darüber bin ich auch beim Zeichnen der Connector im StaveBracket gestolpert -

- - - - - - - - - -

- sichtbar an der Höhe der Sub-Scope-Verbindungen auf den StaveBrackets -

- - - - @@ -34604,14 +34682,33 @@ - - + + + + - - - - - + + + + + + + + + +

+ ...aber das wird sich ganz gewiß ändern ⟶ Stichwort Bereichsmarkierungen +

+ + + + + + + + + + @@ -34659,7 +34756,7 @@ - + @@ -34825,13 +34922,52 @@ - - + + - + + + + + + + +

+ sollte theoretisch funktionieren.... +

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

+ ClipPresenter::determineRequiredVerticalExtension() +

+ + + + + + + + + + + + + + + - + @@ -35157,10 +35293,11 @@ - - - - + + + + + @@ -35249,13 +35386,40 @@ - - - + + + + + + + + + + + + + +
    +
  • + Feature-Definition der »Ruler« noch nicht gegeben +
    • +
  • + viele Details zum »Content« in den Tracks sind noch nicht klar +
    • +
  • + vertikale Positionierung von Content innerhalb der Tracks ist noch nicht gelöst +
    • +
+ + + + + - - + + + @@ -35266,19 +35430,43 @@ - - - - - + + + + + + + + + + + + + - - + + + + + + + + + + + + + + + + + + @@ -35335,6 +35523,39 @@ + + + + + + + + + + + + + +

+ ...darüber bin ich auch beim Zeichnen der Connector im StaveBracket gestolpert +

+ + + + + + + + + +

+ sichtbar an der Höhe der Sub-Scope-Verbindungen auf den StaveBrackets +

+ + + + + @@ -36461,9 +36682,13 @@ + + + + - + @@ -36488,7 +36713,25 @@ - + + + + + + + + + +

+ Und zwar geht es hier um eine sehr grundsätzliche Layout / + Design-Entscheidung, die auch sehr starken Einfluß auf den Workflow und + die »Mechanik« der Clips haben wird; im aktuellen Stand + (2023) der Entwicklung habe ich nicht den Boden, um diese Enstscheidung + treffen zu können �� +

+ + + @@ -37308,7 +37551,7 @@ - + @@ -37371,8 +37614,10 @@ - + + + @@ -47138,9 +47383,9 @@ - + - + @@ -49906,7 +50151,7 @@ - + @@ -49969,7 +50214,7 @@ - + @@ -51758,7 +52003,7 @@ - + @@ -55192,7 +55437,7 @@ - + @@ -69649,7 +69894,7 @@ - + @@ -73099,6 +73344,7 @@ + @@ -73128,7 +73374,8 @@ - + + @@ -73137,21 +73384,30 @@ - + - - - - - + + + + + + + +

+ auf diese Stellen konzentrierte sich für längere Zeit die Aktivität, und keines dieser Themen konnte ich wirklich abschließen, denn es sind noch zu viele strategische Fragen ungeklärt — mit 2022 ist immerhin jedes dieser Themen auf einen längerfristig tragfähigen Grund gestellt +

+ + + + + + - - + + - - - + @@ -73172,6 +73428,10 @@ + + + + @@ -73203,10 +73463,30 @@ + + + + + - + + + + + + + + + +

+ das ViewHook / CanvasHook-Konzept hat sich hervorragend bewährt, und durch das zoom-metric-Mix-in gibt es auch bereits eine sehr elaborierte und robuste Implementierung für alle Belange der temporalen Ausdehnung (horizontal). Allerdings funktionieren alle diese Basis-Implementierungen bisher nur für den eigentlichen Content in der Timeline — ganz einfach weil ich noch nicht so recht weiß, was es mit den »Rulern« so auf sich hat ....  ⌛ +

+ + + + @@ -73229,8 +73509,21 @@

....dieses Thema sollte generisch gelöst werden, und dann weiter entwickelt in Richtung »Interaction Design« — also mit einem aktuellen Fokus verbunden, und mit jeweils eigener Historie pro Fokus, so daß man in die verschiedenen Fokus-Zonen über gut etablierte "Leitern" wieder einsteigen könnte. Leider muß ich (Stand 9/2022) das GUI nun wieder verlassen, und es ist ganz und gar ungeklärt, unter welchen Umständen dieses zentrale Thema wieder aufgenommen werden kann...

+ + + + + + + + + +

- ~ WaitingDesign um den Display-Frame im Timeline-Layout  + Es gibt immer noch Zweifel ob gewisser Race-Conditions.... +

+

+ Diese hängen jedoch eng mit dem Design des Subsystem-Runners zusammen, welches zwar grundsätzlich in Ordnung ist, aber alles in allem „etwas zu knapp gehalten“: man sollte hier explizit und fein differenziert die Lebenszyklus-Phasen ausformulieren, denn dann ist man nicht mehr von Subtilitäten der Implementierungs-Reihenfolge abhängig

@@ -73250,14 +73543,18 @@ - + + + - + + + - + @@ -73377,10 +73674,10 @@ - - + + - + @@ -73394,7 +73691,7 @@

- + @@ -73457,8 +73754,9 @@ - + + @@ -73468,13 +73766,13 @@ - + - + - + @@ -73487,13 +73785,16 @@ - - - + + + + + +