From 1a8917e60a86fee9cba9a73db8cafd27a3abf14f Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 10 Jun 2019 16:08:31 +0200 Subject: [PATCH] Timeline: after a long break... reconsider how to integrate the new VerbPack ...into the draft skeleton of timeline drawing --- src/stage/timeline/body-canvas-widget.cpp | 18 ++-- src/stage/timeline/body-canvas-widget.hpp | 14 +-- src/stage/timeline/ruler-track.cpp | 2 +- src/stage/timeline/ruler-track.hpp | 6 +- src/stage/timeline/timeline-layout.cpp | 2 +- src/stage/timeline/timeline-layout.hpp | 2 +- src/stage/timeline/timeline-widget.hpp | 2 +- src/stage/timeline/track-body.cpp | 2 +- src/stage/timeline/track-body.hpp | 2 +- src/stage/timeline/track-profile.hpp | 9 +- wiki/renderengine.html | 4 +- wiki/thinkPad.ichthyo.mm | 121 ++++++++++++++++------ 12 files changed, 121 insertions(+), 63 deletions(-) diff --git a/src/stage/timeline/body-canvas-widget.cpp b/src/stage/timeline/body-canvas-widget.cpp index 126617f68..ee919ed21 100644 --- a/src/stage/timeline/body-canvas-widget.cpp +++ b/src/stage/timeline/body-canvas-widget.cpp @@ -24,7 +24,7 @@ /** @file body-canvas-widget.cpp ** Implementation details of timeline custom drawing. ** - ** @todo WIP-WIP-WIP as of 12/2016 + ** @todo WIP-WIP-WIP as of 6/2019 ** */ @@ -77,8 +77,8 @@ namespace timeline { /** paint the top of the track body area - @param f number of consecutive track elements - to keep pinned (always visible) at top */ + * @param f number of consecutive track elements + * to keep pinned (always visible) at top */ void prelude (uint f) override { @@ -86,7 +86,7 @@ namespace timeline { } /** finish painting the track body area - @param pad additional padding to add at bottom */ + * @param pad additional padding to add at bottom */ void coda (uint pad) override { @@ -94,7 +94,7 @@ namespace timeline { } /** draw grounding of a overview/ruler track - with the given height */ + * with the given height */ void ruler (uint h) override { @@ -109,7 +109,7 @@ namespace timeline { } /** fill background of track content area - with the given vertical extension */ + * with the given vertical extension */ void content (uint h) override { @@ -117,7 +117,7 @@ namespace timeline { } /** paint opening slope to enter nested sub tracks - @note we only ever open one level deep a time */ + * @note we only ever open one level deep a time */ void open (uint n) override { @@ -125,7 +125,7 @@ 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 */ void close (uint n) override { @@ -194,7 +194,7 @@ namespace timeline { * rather, each sequence holds a _fork of nested scopes._ This recursively nested structure is reflected in the way * we organise and draw the timeline representation onto the TimelineCanvas: we use an intermediary entity, the TrackBody * as an organisational grouping device, even while we draw _all of the timeline representation_ onto a single global - * ::canvas_ within the (scrollable) BodyCanvasWidget. Thus, adding the first TrackBody to represent the root track + * #mainCanvas_ within the (scrollable) #contentArea_. Thus, adding the first TrackBody to represent the root track * of a Timeline, will also prepare the grounding for any other nested entities to be drawn on top. */ void diff --git a/src/stage/timeline/body-canvas-widget.hpp b/src/stage/timeline/body-canvas-widget.hpp index 3baecd2d6..6c457c82a 100644 --- a/src/stage/timeline/body-canvas-widget.hpp +++ b/src/stage/timeline/body-canvas-widget.hpp @@ -49,7 +49,7 @@ ** As result, some new widgets may be injected, existing widgets might be removed or ** hidden, and other widgets may be relocated to different virtual canvas coordinates. ** - ** @todo WIP-WIP-WIP as of 12/2016 + ** @todo WIP-WIP-WIP as of 6/2019 ** */ @@ -98,18 +98,18 @@ namespace timeline { TimelineCanvas (_RenderFactory groundingFac, _RenderFactory overlayFac); private: - virtual bool on_draw (Cairo::RefPtr const&) override; + virtual bool on_draw (CairoC) override; - void openCanvas (Cairo::RefPtr const&); - void closeCanvas (Cairo::RefPtr const&); + void openCanvas (CairoC); + void closeCanvas (CairoC); - void drawGrounding (Cairo::RefPtr const&); - void drawOverlays (Cairo::RefPtr const&); + void drawGrounding (CairoC); + void drawOverlays (CairoC); }; /** - * @todo WIP-WIP as of 12/2016 + * @todo WIP-WIP as of 6/2019 */ class BodyCanvasWidget : public Gtk::Box diff --git a/src/stage/timeline/ruler-track.cpp b/src/stage/timeline/ruler-track.cpp index b75dd0048..b45e92afa 100644 --- a/src/stage/timeline/ruler-track.cpp +++ b/src/stage/timeline/ruler-track.cpp @@ -25,7 +25,7 @@ ** Implementation details regarding custom drawing of track overview ** and time code ticks and markers onto the TimelineCanvas. ** - ** @todo WIP-WIP-WIP as of 12/2018 + ** @todo WIP-WIP-WIP as of 6/2019 ** @todo this is more or less preliminary/placeholder code as of 4/2019 ** */ diff --git a/src/stage/timeline/ruler-track.hpp b/src/stage/timeline/ruler-track.hpp index cbc7305fb..5281545c8 100644 --- a/src/stage/timeline/ruler-track.hpp +++ b/src/stage/timeline/ruler-track.hpp @@ -28,13 +28,15 @@ ** this track content area we build a horizontal ruler to show the timecode or ** frame count references plus any markers, ranges and locators. In case of ** group tracks or collapsed tracks, a synopsis of the content may be rendered - ** into this overview bar. Since any of these display elements need to be aligned + ** into this overview bar. However, similar ruler tracks can also be used _within_ + ** the actual fork of tracks, to represent a sub-scope or a similar kind of overview + ** or summarising display. Since any of these display elements need to be aligned ** precisely with the content, we employ custom drawing for the rulers as well. ** The RulerTrack -- like any parts of the coordinated TimelineLayout, will be ** referred to from and used by the BodyCanvasWidget for offloading specific ** parts of the drawing routines. ** - ** @todo WIP-WIP-WIP as of 12/2018 + ** @todo WIP-WIP-WIP as of 6/2019 ** */ diff --git a/src/stage/timeline/timeline-layout.cpp b/src/stage/timeline/timeline-layout.cpp index d80e44613..c83aec8c9 100644 --- a/src/stage/timeline/timeline-layout.cpp +++ b/src/stage/timeline/timeline-layout.cpp @@ -64,7 +64,7 @@ namespace timeline { TimelineLayout::TimelineLayout (Gtk::Paned& topLevelContainer) : paneSplitPosition_{topLevelContainer.property_position()} , bodyCanvas_{*this} // inject (as interface DisplayManager) - , headerPane_{bodyCanvas_.get_vadjustment()} // wire the header pane (Gtk::Viewport) to follow the body vertical scroll movement + , headerPane_{bodyCanvas_.get_vadjustment()} // wire the patchbay (Gtk::Viewport) to follow the body vertical scroll movement { topLevelContainer.add1 (headerPane_); topLevelContainer.add2 (bodyCanvas_); diff --git a/src/stage/timeline/timeline-layout.hpp b/src/stage/timeline/timeline-layout.hpp index 2b6a5e484..068c57d9f 100644 --- a/src/stage/timeline/timeline-layout.hpp +++ b/src/stage/timeline/timeline-layout.hpp @@ -69,7 +69,7 @@ ** ** For this to work, the _element_ can not be the actual widget, since the result of this whole ** process might be to create or retract an actual GTK widget. For this reason, the timeline - ** layout management relies on a _Presenter_ entity, which in turn controls a mostly passive + ** layout management relies on _Presenter_ entities, which in turn control a mostly passive ** view -- our solution in fact relies on some flavour of the ** [MVP pattern](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter) here. ** diff --git a/src/stage/timeline/timeline-widget.hpp b/src/stage/timeline/timeline-widget.hpp index 6777be5f3..5cfa4d379 100644 --- a/src/stage/timeline/timeline-widget.hpp +++ b/src/stage/timeline/timeline-widget.hpp @@ -118,7 +118,7 @@ namespace timeline { * @param trackID the mandatory root track used in the associated Sequence * @param nexus some established connection to the UI-Bus, will be used * to register the embedded TimelineController as communication - * partner to respond under the given ID. + * partner to respond under the given timeline ID. * @remarks after creation, the widget can just be hooked up and wired like * any ordinary GTK element; it becomes passive and just responds to * signals. The active role is played by the controller, which also diff --git a/src/stage/timeline/track-body.cpp b/src/stage/timeline/track-body.cpp index 286a5bf0b..6aa60d6e6 100644 --- a/src/stage/timeline/track-body.cpp +++ b/src/stage/timeline/track-body.cpp @@ -25,7 +25,7 @@ ** Implementation details regarding display management of the ** track body area within the timeline display canvas. ** - ** @todo WIP-WIP-WIP as of 12/2016 + ** @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 c588b1670..c503563f9 100644 --- a/src/stage/timeline/track-body.hpp +++ b/src/stage/timeline/track-body.hpp @@ -67,7 +67,7 @@ namespace timeline { * task of a TrackBody is to find out about its own overall height, including the * overall height required by all its nested children. Moreover, the height of * the content area needs to be negotiated with the actual content elements. - * @todo WIP-WIP as of 10/2018 + * @todo WIP-WIP as of 6/2019 */ class TrackBody { diff --git a/src/stage/timeline/track-profile.hpp b/src/stage/timeline/track-profile.hpp index 072670b4d..1a8c9a0d2 100644 --- a/src/stage/timeline/track-profile.hpp +++ b/src/stage/timeline/track-profile.hpp @@ -22,7 +22,7 @@ /** @file track-profile.hpp - ** Abstraction build the layout for the track spaces for timeline display. + ** Abstraction to build the layout for the track spaces within timeline display. ** In Lumiera, tracks are arranged into a fork of nested shapes, which structure ** is parallelled into nested structure of TrackBody elements. A tree walk over ** this structure yields a sequence of adjacent timeline elements, like overview @@ -30,7 +30,7 @@ ** be transformed into suitable drawing instructions to create a 3D shaded ** display, clearly highlighting the complex structure of the track arrangement. ** - ** @todo WIP-WIP-WIP as of 4/2019 + ** @todo WIP-WIP-WIP as of 6/2019 ** */ @@ -53,11 +53,12 @@ namespace stage { namespace timeline { using lib::Literal; + using util::isnil; class ProfileInterpreter { public: - ~ProfileInterpreter() { } ///< this is an interface + virtual ~ProfileInterpreter() { } ///< this is an interface virtual void ruler(uint h) =0; ///< represent a overview/ruler track with the given height virtual void gap(uint h) =0; ///< represent a gap to structure the display @@ -90,7 +91,7 @@ namespace timeline { explicit operator bool() const { - return not util::isnil (elements); + return not isnil (elements); } void diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 4348dec3d..f26618e22 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -3517,11 +3517,11 @@ In accordance with the Lumiera application architecture in general, the UI is no 
A specially configured LumieraPlugin, which actually contains or loads the complete code of the (GTK)GUI, and additionally is linked dynamically against the application core lib. During the [[UI startup process|GuiStart]], loading of this Plugin is triggered from {{{main()}}}. Actually this causes spawning of the GTK event thread and execution of the GTK main loop.
-
+
The presentation of the track body area relies on the [[Gtk::Layout "canvas widget"|GtkLayoutWidget]], thus allowing for a mixture of custom drawing with embedded custom Gtk widgets. The actual drawing routine is activated in response to the {{{on_draw}}} signal -- and invoking the inherited handler function will initiate the standard drawing for the embedded child widgets. This partitions the additional, specific drawing activities into a pre-widget drawing phase to prepare the background and framework structure of the track area, and a post-widget drawing phase to show all kinds of overlays, markers cursors and similar UI indicators. A nested structure of {{{TrackBody}}} objects serves as organisational device to structure these custom drawing activities in accordance with the nested structure of the track fork.
 
 !Building a nested 3D structure
-[>img[3D structure of track drawing|draw/UI-TimelineTrackProfile-1.png]]A proficient UI design often relies on subtle cues to guide the user intuitively -- which includes shading of boundary areas to structure the interface space. Both the space and the means to give such unambiguous visual clues are limited, and it would be unwise to forgo such possibilities to follow some stylish fad. Rather, we strive at some degree of internal coherency within the application of these stylistic means.
+[>img[3D structure of track drawing|draw/UI-TimelineTrackProfile-1.png]]A proficient UI design often relies on subtle cues to guide the user intuitively -- which includes shading of boundary areas to structure the interface space. Both the space and the means to give such unambiguous visual clues are limited, and it would be unwise to forgo such possibilities to follow some stylish fad. Rather, we strive at achieving some degree of internal coherency within the application of these stylistic means.
 
 In Lumiera, the //tracks// represent an organisational device, a nested set of //scopes,//  which -- for the UI representation -- is paralleled by nested insets holding the media content. One or several //rulers// as guiding devices run alongside the top of each scope, either representing the scope as a whole, or introducing the working area of this scope similar to a side walk running alongside a channel. A system of increasingly deeper nested scopes thus becomes a cadence of insets in the way of a lateral staircase.
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 19de35eb6..6f2b73d63 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -19667,7 +19667,7 @@
 
 
 
-
+
 
 
 
@@ -19881,8 +19881,7 @@
       d.h er funktioniert nur, wenn man das std::get<idx> (tuple) unmittelbar an den jeweiligen Ziel-Parameter bindet
     

   
-
-
+
 
 
 
@@ -19897,8 +19896,7 @@
       und einen, der einen RValue entgegennimmt
     

   
-
-
+
 
 
 
@@ -19916,8 +19914,7 @@
       steht in keinem Verhältnis zum Zweck
     

   
-
-
+
 
 
 
@@ -20011,8 +20008,7 @@
       Also ist das sogar das korrekte Verhalten.
     

   
-
-
+
 
 
 
@@ -20025,8 +20021,7 @@
       d.h. wenn zufällig das Interface auch eine Methode CloneInto() enthält, aber mit einer unpassenden Signatur
     

   
-
-
+
 
 
 
@@ -20050,8 +20045,7 @@
       das ist auch gut so, zu viel Flexibilität schadet (besonders, wenn man sie dann gar nicht unterstützt)
     

   
-
-
+
 
 
 
@@ -20071,8 +20065,7 @@
       Leider haben wir dann zweimal die gleiche Basisklasse in beiden Zweigen der multiple inheritance...
     

   
-
-
+
 
 
 
@@ -20087,8 +20080,7 @@
       (was ich bisher in der Praxis so noch nie gemacht habe)
     

   
-
-
+
 
 
 
@@ -20103,8 +20095,7 @@
       hab das ganz explizit ausgeknobelt, es fehlt hier genau dieser eine zusätzliche "Slot"
     

   
-
-
+
 
 
 
@@ -20119,8 +20110,8 @@
 
 
 
-
 
+
 
 
 
@@ -20220,8 +20211,7 @@
       wo wir die konkreten Argumente in den vorbereiteten Argument-Tupel im Holder schieben
     

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

   
-
-
+
 
 
 
@@ -20321,7 +20309,60 @@
 
 
 
+
+
 
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      sondern die Argumente sind in einem Tuple eingewickelt,
+    

+    

+      und befinden sich tief vergraben in der Implementierungsklasse,
+    

+    

+      innerhalb eines PolymorphicValue.
+    

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

+      Verhältnis zum Inteface Renderer klären
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -20421,6 +20462,15 @@
 
 
 
+
+
+
+
+
+
+
+
+
 
 
 
@@ -20464,7 +20514,7 @@
 
 
 
-
+
 
 
 
@@ -22667,7 +22717,7 @@
 
 
 
-
+
 
 
 
@@ -22879,10 +22929,13 @@
 
 
 
-
+
+
+
 
 
-
+
+
 
 
 
@@ -22895,7 +22948,8 @@
 
 
 
-
+
+
 
 
 
@@ -22912,8 +22966,9 @@
 
 
 
-
+
 
+
 
 
 
@@ -41262,7 +41317,7 @@
 
 
 
-
+