Timeline: implement access mechanism through getter lambda
works, but not really convinced yet...
This commit is contained in:
parent
6b6ed5e0eb
commit
ac3f1d8bef
3 changed files with 44 additions and 23 deletions
|
|
@ -215,14 +215,13 @@ namespace timeline {
|
|||
|
||||
template<class PINT, bool isRuler>
|
||||
auto
|
||||
makeRenderer (DisplayManager& layout, TrackProfile& profile)
|
||||
makeRenderer (DisplayManager& layout, BodyCanvasWidget::ProfileGetter& getProfile)
|
||||
{
|
||||
return [&](CairoC cox)
|
||||
{
|
||||
PINT concreteRenderScheme{cox, layout};
|
||||
/////////////////////////////////////////////////////////////////////////////////TICKET #1039 : find out a way how to select the header/body part of the profile!
|
||||
profile.performWith (concreteRenderScheme);
|
||||
//^^^^^//////////////////////////////////////////////////TODO: need accessor-function here; attach it somehow to establishTrackProfile()
|
||||
getProfile().performWith (concreteRenderScheme);
|
||||
};
|
||||
}
|
||||
|
||||
|
|
@ -246,12 +245,20 @@ namespace timeline {
|
|||
, profile_{}
|
||||
, rootBody_{nullptr}
|
||||
, contentArea_{}
|
||||
, rulerCanvas_{makeRenderer<Grounding, RULER>(layout_,profile_), makeRenderer<Overlay, RULER>(layout_,profile_)}
|
||||
, mainCanvas_ {makeRenderer<Grounding, BODY>(layout_,profile_), makeRenderer<Overlay, BODY>(layout_,profile_)}
|
||||
, rulerCanvas_{makeRenderer<Grounding, RULER>(layout_,getProfile), makeRenderer<Overlay, RULER>(layout_,getProfile)}
|
||||
, mainCanvas_ {makeRenderer<Grounding, BODY>(layout_,getProfile), makeRenderer<Overlay, BODY>(layout_,getProfile)}
|
||||
{
|
||||
// respond to any structure changes of the timeline by recomputing the TrackProfile
|
||||
layout_.signalStructureChange_.connect (sigc::mem_fun (*this, &BodyCanvasWidget::slotStructureChange));
|
||||
|
||||
// access and possible (re)establish the current "profile" of the tracks on demand...
|
||||
getProfile = [this]() -> TrackProfile&
|
||||
{
|
||||
if (rootBody_ and isnil (profile_))
|
||||
rootBody_->establishTrackSpace (profile_);
|
||||
return profile_;
|
||||
};
|
||||
|
||||
this->set_border_width (0);
|
||||
this->property_expand() = true; // dynamically grab any available additional space
|
||||
this->pack_start (rulerCanvas_);
|
||||
|
|
@ -277,7 +284,7 @@ namespace timeline {
|
|||
|
||||
/**
|
||||
* The Lumiera Timeline model does not rely on a list of tracks, as most conventional video editing software does --
|
||||
* rather, each sequence holds a _fork of nested scopes._ This recursively nested structure is reflected in the way
|
||||
* rather, each sequence holds a _fork of nested scopes._ This recursively nested structure is parallelled 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
|
||||
* #mainCanvas_ within the (scrollable) #contentArea_. Thus, adding the first TrackBody to represent the root track
|
||||
|
|
@ -298,21 +305,6 @@ namespace timeline {
|
|||
}
|
||||
|
||||
|
||||
/**
|
||||
*
|
||||
*/
|
||||
TrackProfile&
|
||||
BodyCanvasWidget::establishTrackProfile()
|
||||
{
|
||||
if (rootBody_)
|
||||
{
|
||||
if (isnil (profile_))
|
||||
rootBody_->establishTrackSpace (profile_);
|
||||
}
|
||||
return profile_; //////////////////////////////////////////////////////////////////////////////////////TICKET #1039 : who actually invokes this function? what if not(rootBody_)?
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
TimelineCanvas::TimelineCanvas (_Renderer groundingFac, _Renderer overlayFac)
|
||||
|
|
|
|||
|
|
@ -128,10 +128,13 @@ namespace timeline {
|
|||
return contentArea_.get_vadjustment();
|
||||
}
|
||||
|
||||
/** a way to get and possibly (re)compute the current TrackProfile */
|
||||
using ProfileGetter = std::function<TrackProfile&()>;
|
||||
ProfileGetter getProfile;
|
||||
|
||||
private:/* ===== Internals ===== */
|
||||
|
||||
void slotStructureChange() noexcept;
|
||||
TrackProfile& establishTrackProfile();
|
||||
};
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -20806,7 +20806,33 @@
|
|||
<node CREATED="1561049205709" ID="ID_87098848" MODIFIED="1561049213673" TEXT="bisher direkte Referenz">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1561049214764" ID="ID_1962267741" MODIFIED="1561049222012" TEXT="neue Lösung gesucht">
|
||||
<node COLOR="#338800" CREATED="1561049214764" ID="ID_1962267741" MODIFIED="1561139793452" TEXT="neue Lösung: getter-Funktion">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node CREATED="1561139816451" ID="ID_1820580687" MODIFIED="1561139824487" TEXT="gefällt mir aber noch nicht">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1561139829332" ID="ID_730637336" MODIFIED="1561139839310" TEXT="rein logisch gehört das Profil ja schon hier her"/>
|
||||
<node CREATED="1561139846988" ID="ID_565918975" MODIFIED="1561139974752" TEXT="aber der ganze Update-Mechanismus ist ein in sich abgekapselter Belang">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
und macht sich aber hier im Quellcode über mehrere Funktionen verteilt breit,
|
||||
</p>
|
||||
<p>
|
||||
ohne daß man ihn hier komplett überblicken kann. Dazu kommt, daß die ganze Verdrahterei
|
||||
</p>
|
||||
<p>
|
||||
über zwei Lambdas hinweg auch nicht besonders <i>geradlinig</i> und verständlich ist
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1561139978982" ID="ID_1098160043" MODIFIED="1561139990042" TEXT="doch in den Layout-Manager verschieben?">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue