diff --git a/src/stage/model/view-hook.hpp b/src/stage/model/view-hook.hpp index 1344e4350..ba0055270 100644 --- a/src/stage/model/view-hook.hpp +++ b/src/stage/model/view-hook.hpp @@ -160,7 +160,7 @@ namespace model { * constitutes some kind of arrangement in the visual presentation, like * e.g. a stacking order, or by populating some table cells in sequence. * The expected semantics is for this operation to detach each given element, - * and then immediately re-attach it _at the "beginning"_ (whatever this means). + * and then immediately re-attach it _at the "front side"_ (whatever this means). * The element as such, and all associated presentation entities are not destroyed, * but continue to exist with the same identity (and possibly all signal wirings). * Just they now appear as if attached with the new ordering. diff --git a/src/stage/timeline/clip-presenter.cpp b/src/stage/timeline/clip-presenter.cpp index cd4481569..9099bd98a 100644 --- a/src/stage/timeline/clip-presenter.cpp +++ b/src/stage/timeline/clip-presenter.cpp @@ -128,9 +128,10 @@ namespace timeline { }) .constructFrom ([&](GenNode const& spec) -> PEffect { + std::optional timing = spec.retrieveAttribute (string{ATTR_timing}); return make_unique (spec.idi, this->uiBus_ ,getClipContentCanvas() - ,std::nullopt); /////////////////////////TICKET #1213 : is it really such a good idea to pass that here?? Note: nullopt effectively disables any display + ,timing); }) .buildChildMutator ([&](PEffect& target, GenNode::ID const& subID, TreeMutator::Handle buff) -> bool { @@ -151,7 +152,7 @@ namespace timeline { { return make_unique (spec.idi, this->uiBus_ ,getClipContentCanvas() - ,std::nullopt); /////////////////////////TICKET #1213 : how to represent "always" / "the whole track"?? + ,std::nullopt); /////////////////////////TICKET #1213 : time → horizontal extension : how to represent "always" / "the whole track"?? }) .buildChildMutator ([&](PChannel& target, GenNode::ID const& subID, TreeMutator::Handle buff) -> bool { diff --git a/src/stage/timeline/clip-presenter.hpp b/src/stage/timeline/clip-presenter.hpp index 376360b25..520a7bc1f 100644 --- a/src/stage/timeline/clip-presenter.hpp +++ b/src/stage/timeline/clip-presenter.hpp @@ -29,7 +29,7 @@ ** UI elements, their state and immediate feedback to user interactions. The _Presenter_ -- ** as known from the [MVP pattern](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter) -- ** serves as link between both levels. For the global angle of view, it is a model::Tangible and thus - ** plays the role of the _View_, while the _Model_ and _Controler_ roles are mediated through the + ** plays the role of the _View_, while the _Model_ and _Controller_ roles are mediated through the ** stage::UiBus, exchanging command, state and mutation messages. On the other hand, for the local ** angle of view, the _Presenter_ is a structural model element, kind of a _view model_, and corresponds ** to the respective element within the session. In addition, it manages actively the collaborative @@ -40,7 +40,7 @@ ** ** Especially the ClipPresenter plays a crucial role when it comes to deciding which *clip appearance style* ** to use for the actual display. Depending on the zoom level, the ClipPresenter may even decide to hide - ** the individual clip and join it into a combined placeholder for degraded display of a hole strike of + ** the individual clip and join it into a combined placeholder for degraded display of a whole strike of ** clips, just to indicate some content is actually present in this part of the timeline. ** ** @todo WIP-WIP-WIP as of 12/2016 diff --git a/src/stage/timeline/clip-widget.cpp b/src/stage/timeline/clip-widget.cpp index e4066c65b..c3d80e2d9 100644 --- a/src/stage/timeline/clip-widget.cpp +++ b/src/stage/timeline/clip-widget.cpp @@ -29,7 +29,7 @@ ** a clip. Moreover, this clip display can be used both ** within the context of the timeline or as element in a ** media bin in the asset management section. - ** @todo WIP-WIP-WIP as of 12/2016 + ** @todo WIP-WIP-WIP as of 1/2021 ** */ @@ -106,7 +106,7 @@ namespace timeline { } Appearance - changeAppearance (Appearance desired) override + changeAppearance (Appearance) override { return currentAppearance(); } diff --git a/src/stage/timeline/clip-widget.hpp b/src/stage/timeline/clip-widget.hpp index 2b8fe5318..e5df5dfa6 100644 --- a/src/stage/timeline/clip-widget.hpp +++ b/src/stage/timeline/clip-widget.hpp @@ -174,7 +174,7 @@ namespace timeline { /** request to change the clip delegate's appearance style, if possible. * @param manager entity to hold and maintain this specific appearance state. * @param desired the intended style or mode to acquire - * @param displayAnchor (optionally) a different view to hook up the delegate. + * @param newView (optionally) a different view to hook up the delegate. * @return the actual mode the presentation was switched to * @remark switching the appearance style is a state transition; sometimes * this change also implies switching the actual implementation of diff --git a/src/stage/timeline/display-evaluation.cpp b/src/stage/timeline/display-evaluation.cpp index 6228a954e..c47c9ab58 100644 --- a/src/stage/timeline/display-evaluation.cpp +++ b/src/stage/timeline/display-evaluation.cpp @@ -67,7 +67,7 @@ namespace timeline { * and coordinate the overall timeline layout. Within these passes, each element * starts with the (vertical) extension as allocated by GTK; typically these values * need to be increased slightly, in order to align the track headers and the track - * body display, and to accommodate the clips and effect placed into each track. + * body display, and to accommodate the clips and effects placed into each track. * Such local adjustments will typically re-trigger the custom drawing code, and * thus re-invoke this function, until the overall layout is stable. In a similar * vein, the expanding or collapsing of clips and even whole sub-track scopes diff --git a/src/stage/timeline/track-presenter.hpp b/src/stage/timeline/track-presenter.hpp index b94ed2dd5..10dfaa151 100644 --- a/src/stage/timeline/track-presenter.hpp +++ b/src/stage/timeline/track-presenter.hpp @@ -42,7 +42,7 @@ ** ** Each TrackPresenter corresponds to a "sub-Fork" of timeline tracks. Since Lumiera always arranges ** tracks as nested scopes into a tree, there is one root fork, recursively holding several sub forks. - ** - thus each TrackPresenter holds a collection #subFor_ -- possibly empty. + ** - thus each TrackPresenter holds a collection #subFork_ -- possibly empty. ** - moreover, it holds a collection #clips_, which represent the actual content of this track itself, ** as opposed to content on some sub-track. These clips are to be arranged within the _content area_ ** of the track display, in the track body area (at the right side of the timeline). Actually, this diff --git a/tests/library/replaceable-item-test.cpp b/tests/library/replaceable-item-test.cpp index a71424c92..2943f37d7 100644 --- a/tests/library/replaceable-item-test.cpp +++ b/tests/library/replaceable-item-test.cpp @@ -140,6 +140,7 @@ namespace test{ using It = ReplaceableItem; It one{she}, two{he}; + REQUIRE (one != two); CHECK (two == he); CHECK (one == she); CHECK (sizeof(one) == sizeof(X)); diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 8f76c97ec..cd106bbe1 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -4288,7 +4288,7 @@ - + @@ -7193,7 +7193,7 @@ - + @@ -16696,7 +16696,7 @@ - + @@ -16727,7 +16727,7 @@ - + @@ -21135,7 +21135,7 @@

- + @@ -21206,7 +21206,7 @@ - + @@ -21321,7 +21321,10 @@ + + + @@ -21329,16 +21332,46 @@ + + + + + + + + + + + + + + + + + +

+ Das Schöne an diesem Ansatz wäre, daß er für den User komplett natürlich wirkt; solange man gleichartige Clips in einer Timeline liegen hat, würde sich dieses Konzept überaupt nicht auffällig bemerkbar machen; und ein weiterer Vorteil wäre, daß man es als Weiterentwicklung des 1. Lösungsansatzes betrachten kann... +

+ + + + + + + + + + @@ -27314,8 +27347,9 @@ - + + @@ -27590,7 +27624,7 @@ - + @@ -27688,7 +27722,7 @@ - + @@ -27998,6 +28032,25 @@ + + + + + + + + + + +

+ Problem wegen dem Overview-Ruler, d.h. wie berücksichtigt der untere Canvas die Ausdehnung des oberen Canvas? +

+ + + + + + @@ -28023,6 +28076,23 @@ + + + + + + + + + + + + + + + + + @@ -28175,6 +28245,19 @@ + + + + + + +

+ Aufgabe: wie geht man mit einem Anzeigestil um, der den Effkt gar nicht  darstellt +

+ + + + @@ -28246,7 +28329,11 @@ - + + + + + @@ -28318,8 +28405,7 @@ Zoomen, Scrollen, Scroll-Window und View-Path sind reine Gui-Bildungen und werden instantan ohne Round-Trip realisiert

- - + @@ -28332,8 +28418,7 @@ Vorsicht Falle: es reicht nicht, nur die auf Pixel quantisierte Position zu speichern, denn diese wird bei geringem Zoom relativ ungenau. Es wäre leicht möglich, durch Heraus- und wieder Hereinscrollen die sichtbare Position eines Clip massiv zu verschieben.

- - + @@ -29572,7 +29657,7 @@ - + @@ -33571,7 +33656,7 @@ - + @@ -34969,7 +35054,7 @@ - + @@ -36169,7 +36254,7 @@ - + @@ -53728,12 +53813,26 @@ - + + + + + + + + + + + + + + + @@ -53789,7 +53888,7 @@ - +