From df02258547ed92387ebca849cdc4c5ec15e998c7 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 6 Apr 2019 18:21:26 +0200 Subject: [PATCH] Timeline: use a sequence of structure description verbs ...like * ruler * gap * content * open/close sub scope ... --- doc/technical/overview.txt | 9 +-- src/lib/verb-token.hpp | 27 ++++---- src/stage/timeline/body-canvas-widget.cpp | 1 + src/stage/timeline/body-canvas-widget.hpp | 6 +- src/stage/timeline/track-body.hpp | 1 + src/stage/timeline/track-profile.hpp | 75 +++++++++++++++++++++++ wiki/renderengine.html | 18 +++--- wiki/thinkPad.ichthyo.mm | 24 +++++++- 8 files changed, 133 insertions(+), 28 deletions(-) create mode 100644 src/stage/timeline/track-profile.hpp diff --git a/doc/technical/overview.txt b/doc/technical/overview.txt index be7d362a6..e8c798467 100644 --- a/doc/technical/overview.txt +++ b/doc/technical/overview.txt @@ -23,16 +23,17 @@ the source directory structures. This three Layers are: The Stage Layer:: - User interfaces are implemented as plug-ins, most commonly one will see - the default GUI. But also scripting interfaces or specialized GUI's are - possible. + Interaction and presentation. User interfaces are implemented as plug-ins, + and while most commonly one will see the GTK UI, it would be possible to + construct a entirely different user interface, a CLI intereface, or even + operate the application ``headless'', script driven. The Steam Layer:: Keeps the Session, generates the rendering graphs for sequences, arranges what to do when and how. The Vault Layer:: - Manages thread-queues, schedules jobs, does the memory management for the + Manages worker pools, schedules jobs, does the memory management for the heavy multimedia data. Loads and delegates to external libraries for media processing. diff --git a/src/lib/verb-token.hpp b/src/lib/verb-token.hpp index 2328e2f3b..bd8b509a7 100644 --- a/src/lib/verb-token.hpp +++ b/src/lib/verb-token.hpp @@ -38,7 +38,7 @@ ** the concrete receiver, e.g. `VERB_doit (receiver, arg1, arg2)` ** results in the invocation of \c receiver.doit(arg1,arg2) ** - ** @see ...TODO + ** @see [prominent usage: the Diff system](\ref lib::diff::DiffLanguage) ** @see VerbFunctionDispatch_test ** */ @@ -66,6 +66,9 @@ namespace lib { * as defined in the "receiver" interface (parameter \c REC). * The token is typically part of a DSL and can be applied * to a concrete receiver subclass. + * @tparam REC the type receiving the verb invocations + * @tparam SIG signature of the actual verb function, expected + * to exist on the receiver (REC) interface * @remarks while the included ID Literal is mostly for diagnostics, * it also serves as identity for comparisons. Conceptually what * we want is to compare the function "offset", but this leads @@ -101,22 +104,18 @@ namespace lib { , token_(token) { } - VerbToken() : token_("NIL") { } + VerbToken() + : handler_{} + , token_("NIL") + { } /* default copyable */ - - bool - operator== (VerbToken const& o) const ///< @remarks member pointers to virtual functions aren't comparable, for good reason - { - return token_ == o.token_; - } - - bool - operator!= (VerbToken const& o) const - { - return token_ != o.token_; - } + /** equality of VerbToken, based on equality of the #token_ Literal + * @remarks member pointers to virtual functions aren't comparable, for good reason + */ + bool operator== (VerbToken const& o) const { return token_ == o.token_; } + bool operator!= (VerbToken const& o) const { return token_ != o.token_; } }; #define VERB(RECEIVER, FUN) VERB_##FUN (&RECEIVER::FUN, STRINGIFY(FUN)) diff --git a/src/stage/timeline/body-canvas-widget.cpp b/src/stage/timeline/body-canvas-widget.cpp index 2f9fb5b4a..4913fd3a0 100644 --- a/src/stage/timeline/body-canvas-widget.cpp +++ b/src/stage/timeline/body-canvas-widget.cpp @@ -31,6 +31,7 @@ #include "stage/gtk-base.hpp" #include "stage/timeline/body-canvas-widget.hpp" +#include "stage/timeline/track-profile.hpp" #include "stage/timeline/track-body.hpp" //#include "stage/ui-bus.hpp" diff --git a/src/stage/timeline/body-canvas-widget.hpp b/src/stage/timeline/body-canvas-widget.hpp index 95e87ac3c..b8925e51e 100644 --- a/src/stage/timeline/body-canvas-widget.hpp +++ b/src/stage/timeline/body-canvas-widget.hpp @@ -61,7 +61,7 @@ //#include "lib/util.hpp" -//#include +#include //#include @@ -69,14 +69,18 @@ namespace stage { namespace timeline { + class TrackProfile; class TrackBody; class TimelineCanvas : public Gtk::Layout { + using TProfile = std::unique_ptr; + public: TrackBody* rootBody_; + TProfile profile_; TimelineCanvas(); diff --git a/src/stage/timeline/track-body.hpp b/src/stage/timeline/track-body.hpp index dfae724cb..1efa69f2f 100644 --- a/src/stage/timeline/track-body.hpp +++ b/src/stage/timeline/track-body.hpp @@ -41,6 +41,7 @@ #define STAGE_TIMELINE_TRACK_BODY_H #include "stage/gtk-base.hpp" +#include "stage/timeline/track-profile.hpp" #include "stage/timeline/ruler-track.hpp" //#include "lib/util.hpp" diff --git a/src/stage/timeline/track-profile.hpp b/src/stage/timeline/track-profile.hpp new file mode 100644 index 000000000..dca5c322e --- /dev/null +++ b/src/stage/timeline/track-profile.hpp @@ -0,0 +1,75 @@ +/* + TRACK-PROFILE.hpp - building the 3D profile of tracks for timeline presentation + + Copyright (C) Lumiera.org + 2019, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +/** @file track-profile.hpp + ** Abstraction build the layout for the track spaces for 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 + ** rulers, content area and nested child track display. This sequence can then + ** 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 + ** + */ + + +#ifndef STAGE_TIMELINE_TRACK_PROFILE_H +#define STAGE_TIMELINE_TRACK_PROFILE_H + +#include "stage/gtk-base.hpp" +#include "lib/verb-token.hpp" + +//#include "lib/util.hpp" + +//#include +#include + + + +namespace stage { +namespace timeline { + + + /** + * Description of the structure and arrangement of tracks for display in the UI. + * This sequence of verb tokens especially details the _profile_ of a vertical + * cross-section; the nested structure of the track fork is translated into + * a series of steps and insets, running alongside the timeline display. + * To decouple the drawing code -- thus allowing for later customisations -- + * we let the individual TrackBody elements just emit these structure description. + * @todo WIP-WIP as of 4/2019 + */ + class TrackProfile + { + + public: + + + private:/* ===== Internals ===== */ + }; + + +}}// namespace stage::timeline +#endif /*STAGE_TIMELINE_TRACK_PROFILE_H*/ diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 1a35f55ed..4348dec3d 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -3517,7 +3517,7 @@ 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
@@ -3526,16 +3526,18 @@ In accordance with the Lumiera application architecture in general, the UI is no
 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.
 
 Each individual track contributes a similar sequence of structure elements to this overall ''track profile'':
-* a set of rulers, where each ruler may optionally inject a small additional //gap//
+* a set of rulers
+** where each ruler may optionally inject a small additional //gap//
 * a content area
-* the self similar recursive child track fork
+* an inset
+** holding the self similar recursive child track fork
 
 !!!Assembling the track profile
-The actual expression of these elements depends on the content, which is injected via diff message pushed up from the steam layer; additionally, some presentation state like collapsing of elements need to be taken into account. Assembling the complete profile of the track structure thus incurs a tree walk over the nested track body objects, which in turn communicate with the track presenters for layout state. At this point, it is advisable to separate the actual graphics drawing code from the content and state discovery scattered over the nested structure. Thus we produce a ''verb sequence'' as result of the tree walk, which can be stored into a (heap allocated) list for repeated evaluation when handling the actual draw events. Whenever the overall layout has been invalidated, this structure description has to be rebuilt by yet another tree walk. To illustrate this concept, with {{{r(#)}}} ruler, {{{g}}} gap, {{{c(#)}}} content and ''⤵⤴'' direction verbs, the profile above might yield a sequence
-|>|>|>|>|!__Track-1__ |
-| | !__Track-11__ |>|>|!__Track-12__ |
-|>|>| |!__Track-121__ |!__Track-122__ |
-|r(1),r(1),g,''c''(2)|⤵r(1),g,''c''(3)|r(1),g,r(1)|⤵r(1),''c''(2)|r(1),''c''(1)⤴⤴|
+The actual expression of these elements depends on the content, which is injected via diff message pushed up from the steam layer; additionally, some presentation state like collapsing of elements need to be taken into account. Assembling the complete profile of the track structure thus incurs a tree walk over the nested track body objects, which in turn communicate with the track presenters for layout state. At this point, it is advisable to separate the actual graphics drawing code from the content and state discovery scattered over the nested structure. Thus we produce a ''verb sequence'' as result of the tree walk, which can be stored into a (heap allocated) list for repeated evaluation when handling the actual draw events. Whenever the overall layout has been invalidated, this structure description has to be rebuilt by yet another tree walk. To illustrate this concept, with {{{r(#)}}} ruler, {{{g}}} gap, {{{c(#)}}} content and ''⤵⤴'' direction verbs, the profile above might yield the sequence...
+|>|>|>|>|>|>|>|>|!__Track-1__ |
+| | | !__Track-11__ |>|>|>|>|!__Track-12__ | |
+|~|~|>|  | |!__Track-121__ |!__Track-122__ | |~|
+|r(1),r(1),g,''c''(2)|⤵|r(1),g,''c''(3)|r(1),g,r(1)|⤵|r(1),''c''(2)  |r(1),''c''(1)|⤴|⤴|
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index c98bd537e..7bba4b305 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -19674,14 +19674,36 @@ + + + + + + + + + +

+ ...zum Beispiel um einen "Wall" auch expressiv zu schattieren +

+ + + + + + + + - + + +