ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Library: allow for an explicitly random EntryID

Browse source 
same pattern as the existing EntryID, i.e. a human readable symbol plus a hash
but the hash is just random, instead of deriving it from the symbol text.

Use case is when we explicitly need a distinct identity, even when the
human readable symbolic name is the same. Actual example: the fork root in the timeline
This commit is contained in:
Fischlurch 2018-11-10 01:01:59 +01:00
parent 8432420726
commit a4c37ed99c
10 changed files with 71 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
src/gui/timeline/timeline-controller.cpp
View file

@ -84,7 +84,7 @@ namespace timeline {
TimelineController::TimelineController (ID identity, ID trackID, ctrl::BusTerm& nexus, TimelineLayout& layoutManager)
: Controller{identity, nexus}
, name_{identity.getSym()} // fallback initialise name from human-readable ID symbol
, name_{identity.getSym()} // fallback initialise name from human-readable ID symbol
, markers_{}
, fork_{new TrackPresenter{trackID, nexus, [&](TrackHeadWidget& head,TrackBody& body)
{

2
src/gui/timeline/track-body.cpp
View file

@ -64,7 +64,7 @@ namespace timeline {
TrackBody::TrackBody (ID identity)
TrackBody::TrackBody (cuString trackName)
: overviewHeight_{DEFAULT_OVERVIEW_HEIGHT_px}
, contentHeight_{DEFAULT_OVERVIEW_HEIGHT_px}
, subTracks_{}

2
src/gui/timeline/track-body.hpp
View file

@ -78,7 +78,7 @@ namespace timeline {
SubTracks subTracks_;
public:
TrackBody (ID identity);
TrackBody (cuString trackName);
~TrackBody();
uint calcHeight();

6
src/gui/timeline/track-head-widget.cpp
View file

@ -62,10 +62,10 @@ namespace timeline {
TrackHeadWidget::TrackHeadWidget (ID identity)
TrackHeadWidget::TrackHeadWidget (cuString& trackName)
: Gtk::Grid{}
, nameTODO_{identity.getSym()}
, treeTODO_{"X"}
, nameTODO_{trackName}
, treeTODO_{"↳"}
{
this->attach (nameTODO_, 0,0, 2,1);
this->attach (treeTODO_, 0,1, 1,1);

2
src/gui/timeline/track-head-widget.hpp
View file

@ -74,7 +74,7 @@ namespace timeline {
Gtk::Label treeTODO_;
public:
TrackHeadWidget (ID identity);
TrackHeadWidget (cuString& trackName);
~TrackHeadWidget();
/** Integrate the control area for a nested sub track fork. */

10
src/gui/timeline/track-presenter.cpp
View file

@ -66,9 +66,7 @@ namespace timeline {
TrackPresenter::~TrackPresenter()
{
}
TrackPresenter::~TrackPresenter() { }
@ -151,7 +149,11 @@ namespace timeline {
if (ID{*target} != subID) return false;
target->buildMutator (buff);
return true;
})));
}))
.change(ATTR_name, [&](string val)
{ // »Attribute Setter« : receive a new value for the track name field
name_ = val;
}));
}

10
src/gui/timeline/track-presenter.hpp
View file

@ -80,9 +80,9 @@ namespace timeline {
TrackBody body;
template<class FUN>
DisplayFrame (ID id, FUN anchorDisplay)
: head{id}
, body{id}
DisplayFrame (cuString& name, FUN anchorDisplay)
: head{name}
, body{name}
{
anchorDisplay (head, body);
}
@ -106,6 +106,7 @@ namespace timeline {
class TrackPresenter
: public model::Controller
{
string name_;
DisplayFrame display_;
vector<unique_ptr<TrackPresenter>> subFork_;
@ -123,7 +124,8 @@ namespace timeline {
template<class FUN>
TrackPresenter (ID id, ctrl::BusTerm& nexus, FUN anchorDisplay)
: Controller{id, nexus}
, display_{id, anchorDisplay}
, name_{id.getSym()} // fallback initialise track-name from human-readable ID symbol
, display_{name_, anchorDisplay}
, subFork_{}
, markers_{}
, clips_{}

38
src/lib/idi/entry-id.hpp
View file

@ -32,6 +32,13 @@
** @note as of 3/2010 this is an experimental setup and exists somewhat in parallel
** to the assets. We're still in the process of finding out what's really required
** to keep track of all the various kinds of objects. ///////////////////TICKET #739
** @todo as of 11/2018 the basic design seems adequate, but the actual solution looks fishy.
** Even more so, since we now use subclasses of BareEntryID
** - as identity tag within lib::diff::GenNode
** - as identity tag for all [tangible UI elements](\ref gui::model::Tangible)
** There are various quirks and hacks to make all of this happen, and especially
** the hashed-in type information feels gratuitous at places, when all we actually
** need is a distinct identity plus a human readable symbol.
**
** @see asset::Asset::Ident
** @see entry-id-test.cpp
@ -101,7 +108,7 @@ namespace idi {
* which would require both to yield the same hash values....
* @warning there is a weakness in boost::hash for strings of running numbers,
* causing collisions already for a small set with less than 100000 entries.
* To ameliorate the problem, we hash in the trailing digits, and
* To mitigate the problem, we hash in the trailing digits, and
* spread them by the #KNUTH_MAGIC /////////TICKET #865
* @warning this code isn't portable and breaks if sizeof(size_t) < sizeof(void*)
* @see HashGenerator_test#verify_Knuth_workaround
@ -146,11 +153,18 @@ namespace idi {
* encoded into a hash seed. Thus even the same symbolicID
* generates differing hash-IDs for different type parameters
*/
BareEntryID (string const& symbolID, HashVal seed =0)
BareEntryID (string const& symbolID, HashVal seed)
: symbol_(symbolID)
, hash_(buildHash (symbol_, seed))
{ }
/** store the symbol but use a random hash part */
explicit
BareEntryID (string const& symbolID)
: symbol_(symbolID)
, hash_{} // random
{ }
public:
/* default copyable and assignable */
@ -281,6 +295,26 @@ namespace idi {
/**
* Entry-ID with a symbolic tag but just a plain random hash part.
* @remarks use this flavour when it is _not relevant_ to tag with
* some type information nor to reproduce the hash value.
*/
struct RandID
: BareEntryID
{
RandID (string const& symbolID)
: BareEntryID{util::sanitise (symbolID)}
{ }
RandID (const char* symbolID)
: BareEntryID{util::sanitise (symbolID)}
{ }
RandID (Symbol const& internalSymbol)
: BareEntryID{string{internalSymbol}}
{ }
};
/** try to upcast this BareEntryID to a fully typed EntryID.
* Effectively, this is the attempt to reverse a type erasure;
* thus the caller needs to know the type information (as provided

14
wiki/renderengine.html
View file

@ -2025,18 +2025,18 @@ Deliberately there is an limitaion on the flexibility of what can be added to th
A strong emphaisis is placed on ''Separation of Concerns'' and especially on ''Open Closed'' design. We resist the temptation to build an //universal model.// Rather, we understand our whole unterdaking a ''transformation of metadata'' -- which, as a whole, remains conceptual and is only ever implemented partially within context. A [[language of diff exchanges|TreeDiffFundamentals]] serves as integrating backbone. It works against a rather symbolic representation of strucutred matters, conceived as an ExternalTreeDescription. In fact, this desctiption is only materialised in parts, if at all.
</pre>
</div>
<div title="DesignGoals" modifier="Ichthyostega" created="200706210557" modified="200805300046" tags="design">
<pre>This __proc-Layer__ and ~Render-Engine implementation started out as a design-draft by [[Ichthyo|mailto:Ichthyostega@web.de]] in summer 2007. The key idea of this design-draft is to use the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]] for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, which is done by the Builder.
<div title="DesignGoals" modifier="Ichthyostega" created="200706210557" modified="201811092250" tags="design" changecount="3">
<pre>This ~Proc-Layer and ~Render-Engine implementation started out as a design-draft by [[Ichthyo|mailto:Ichthyostega@web.de]] in summer 2007. The key idea of this design-draft is to use the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]] for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, which is done by the Builder.
!Why doesn't the current Cinelerra-2 Design succeed?
The design of Cinelerra-2 basically follows a similar design, but __fails because of two reasons__
# too much differentiation is put into the class hierarchy instead of configuring Instances differently.&lt;br&gt;This causes overly heavy use of virtual functions and -- in order to ameliorate this -- falling back to hard wired branching
The design of Cinelerra-2 basically follows a similar design, but [[fails because of two reasons...|https://lumiera.org/project/background/history/CinelerraWoes.html]]
# too much differentiation is put into the class hierarchy instead of configuring Instances differently.&lt;br/&gt;This causes overly heavy use of virtual functions, intricate implementation dependencies, and -- in order to mitigate this -- falling back to hard wired branching in the end.
# far too much coupling and back-coupling to the internals of the »EDL«, forcing a overly rigid structure on the latter
!Try to learn from the Problems of the current Cinelerra-2 codebase
* build up an [[Node Abstraction|ProcNode]] powerful enough to express //all necessary Operations// without the need to recure on the actual object type
* build up an [[Node Abstraction|ProcNode]] powerful enough to express //all necessary Operations// without the need to recur on the actual object type
* need to redesign the internals of the Session in a far more open manner. Everything is an [[M-Object|MObjects]] which is [[placed|Placement]] in some manner
* strive at a StrongSeparation between Session and Render Engine, encapsulate and allways implement against interfaces
* strive at a StrongSeparation between Session and Render Engine, encapsulate and always implement against interfaces
!Design Goals
@ -2044,7 +2044,7 @@ As always, the main goal is //to cut down complexity// by the usual approach to
To achieve this, here we try to separate ''Configuration'' from ''Processing''. Further, in Configuration we try to separate the ''high level view'' (users view when editing) from the ''low level view'' (the actual configuration effective for the calculations). Finally, we try to factor out and encapsulate ''State'' in order to make State explicit.
The main tool used to implement this separation is the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]. Here especially we move all decisions and parametrization into the BuildProcess. The Nodes in the render pipeline should process Video/Audio and do nothing else. All decisions, tests and conditional operations are factored out of the render process and handled as configuration of the pipeline, which is done by the Builder. The actual color model and number of ports is configured in by a pre-built wiring descriptor. All Nodes are of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. OpenGL and renderfarm support can be configured in as an alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering. We introduce separate control data connections for the [[automation data|Automation]], separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or the case of two nodes using the same automation data).
The main tool used to implement this separation is the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]. Here especially we move all decisions and parametrization into the BuildProcess. The Nodes in the render pipeline should process Video/Audio and do nothing else. All decisions, tests and conditional operations are factored out of the render process and handled as configuration of the pipeline, which is done by the Builder. The actual colour model and number of ports is configured in by a pre-built wiring descriptor. All Nodes are of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. OpenGL and renderfarm support can be configured in as an alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering. We introduce separate control data connections for the [[automation data|Automation]], separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or the case of two nodes using the same automation data).
Another pertinent theme is to make the basic building blocks simpler, while on the other hand gaining much more flexibility for combining these building blocks. For example we try to unfold any &quot;internal-multi&quot; effects into separate instances (e.g. the possibility of having an arbitrary number of single masks at any point of the pipeline instead of having one special masking facility encompassing multiple sub-masks. Similarly, we treat the Objects in the Session in a more uniform manner and gain the possibility to [[place|Placement]] them in various ways.
</pre>

12
wiki/thinkPad.ichthyo.mm
View file

@ -17603,7 +17603,7 @@
<node CREATED="1480639279591" ID="ID_887618627" MODIFIED="1518487921078" TEXT="Timecode"/>
<node CREATED="1480639276064" ID="ID_1418536459" MODIFIED="1518487921078" TEXT="Fader"/>
<node CREATED="1480639258169" ID="ID_1876553930" MODIFIED="1518487921078" TEXT="Label">
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1541089187808" ID="ID_368245484" MODIFIED="1541096032389" TEXT="ElementBoxWidget">
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1541089187808" ID="ID_368245484" MODIFIED="1541801476783" TEXT="ElementBoxWidget">
<linktarget COLOR="#f6cca4" DESTINATION="ID_368245484" ENDARROW="Default" ENDINCLINATION="-599;39;" ID="Arrow_ID_703893400" SOURCE="ID_1437927701" STARTARROW="None" STARTINCLINATION="42;-316;"/>
<linktarget COLOR="#f6cca4" DESTINATION="ID_368245484" ENDARROW="Default" ENDINCLINATION="-599;39;" ID="Arrow_ID_1199047781" SOURCE="ID_1032237384" STARTARROW="None" STARTINCLINATION="-698;-271;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
@ -19374,7 +19374,7 @@
<node CREATED="1538940692545" ID="ID_1827979765" MODIFIED="1538940694085" TEXT="expanded"/>
</node>
<node CREATED="1541095848871" ID="ID_1480696061" MODIFIED="1541095854691" TEXT="Anzeige-Modi">
<node CREATED="1541095855984" ID="ID_1437927701" MODIFIED="1541096004448" TEXT="verwendet ElementBoxWidget">
<node CREATED="1541095855984" ID="ID_1437927701" MODIFIED="1541801476782" TEXT="verwendet ElementBoxWidget">
<arrowlink COLOR="#f6cca4" DESTINATION="ID_368245484" ENDARROW="Default" ENDINCLINATION="-599;39;" ID="Arrow_ID_703893400" STARTARROW="None" STARTINCLINATION="42;-316;"/>
<icon BUILTIN="idea"/>
</node>
@ -20984,6 +20984,12 @@
<node CREATED="1541547600640" ID="ID_787025622" MODIFIED="1541547663157" TEXT="Element-IDs m&#xfc;ssen eindeutig sein">
<arrowlink COLOR="#c9876a" DESTINATION="ID_1850412206" ENDARROW="Default" ENDINCLINATION="49;-155;" ID="Arrow_ID_1571993328" STARTARROW="None" STARTINCLINATION="-11;173;"/>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1541807934354" ID="ID_306409593" MODIFIED="1541807964448" TEXT="jedesmal explizit einen zuf&#xe4;lligen Hash verwenden">
<icon BUILTIN="yes"/>
</node>
<node CREATED="1541807922861" ID="ID_811005250" MODIFIED="1541807960058" TEXT="idi::RandID">
<icon BUILTIN="forward"/>
</node>
</node>
</node>
</node>
@ -21049,7 +21055,7 @@
<node CREATED="1541545696185" ID="ID_1907010009" MODIFIED="1541545798109" TEXT="Grund: UI-Bus - Routing">
<icon BUILTIN="info"/>
</node>
<node COLOR="#435e98" CREATED="1541545933006" ID="ID_1850412206" MODIFIED="1541800215407" TEXT="t&#xfc;ckisches Problem">
<node COLOR="#435e98" CREATED="1541545933006" FOLDED="true" ID="ID_1850412206" MODIFIED="1541801398040" TEXT="t&#xfc;ckisches Problem">
<linktarget COLOR="#c9876a" DESTINATION="ID_1850412206" ENDARROW="Default" ENDINCLINATION="49;-155;" ID="Arrow_ID_1571993328" SOURCE="ID_787025622" STARTARROW="None" STARTINCLINATION="-11;173;"/>
<linktarget COLOR="#c9876a" DESTINATION="ID_1850412206" ENDARROW="Default" ENDINCLINATION="369;179;" ID="Arrow_ID_1229280605" SOURCE="ID_659707505" STARTARROW="None" STARTINCLINATION="586;-203;"/>
<icon BUILTIN="messagebox_warning"/>