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

rearrange the query functions to suit the changed ScopePath internals

Browse source
This commit is contained in:
Fischlurch 2010-10-02 18:01:59 +02:00
parent 1fe76e33a2
commit 58757281b0
4 changed files with 43 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
src/proc/mobject/session/query-focus.cpp
View file

@ -22,6 +22,7 @@
#include "proc/mobject/session/query-focus.hpp"
#include "proc/mobject/mobject.hpp"
namespace mobject {

40
src/proc/mobject/session/scope-locator.hpp
View file

@ -78,6 +78,10 @@ namespace session {
typename ScopeQuery<MO>::iterator
locate (Scope scope);
ScopeQuery<MObject>::iterator
getRawPath (Scope);
~ScopeLocator();
protected:
@ -113,20 +117,42 @@ namespace session {
return ScopeQuery<MO> (scope.getTop(), CONTENTS).resolveBy (theResolver());
}
/** use the contents-resolving facility exposed by the session
* to discover the path up from the given scope to model root
* @todo this seems to be the prime candidate to add the support for virtual paths,
* as required to implement meta-clips ///////////////////////////////////////////TICKET #663
* only used by the ScopePath implementation thus far
/** navigate the \em current QueryFocus scope location. The resulting
* access path to the new location is chosen such as to be most closely related
* to the original location; this includes picking a timeline or meta-clip
* attachment most similar to the one used in the original path. So effectively
* you'll see things through the same "scoping perspective" as given by the
* original path, if possible to the new location
* given as parameter. use the contents-resolving facility exposed by the session
* @note changes the \em current QueryFocus as a sideeffect
* @param scope the new target location to navigate
* @return an iterator yielding the nested scopes from the new location
* up to root, in a way likely to be similar to the original location
*/
template<typename MO>
inline typename ScopeQuery<MO>::iterator
ScopeLocator::locate (Scope scope)
{
return ScopeQuery<MO> (scope.getTop(), PATH).resolveBy (theResolver());
UNIMPLEMENTED ("virtual navigation");
}
/** use the contents-resolving facility exposed by the session
* to discover the path up from the given scope to model root.
* @note this yields the \em raw path (basic containment hierarchy),
* as opposed to an effective or virtual path, which should reflect
* the attachment of Sequences to Timelines or meta-clips. That is,
* you'll always get the top-level track of any sequence as direct
* child of the root node and timelines (BindingMO) just appear
* to be "dead ends"
*/
inline ScopeQuery<MObject>::iterator
ScopeLocator::getRawPath (Scope scope)
{
return ScopeQuery<MObject> (scope.getTop(), PATH).resolveBy (theResolver());
}
}} // namespace mobject::session
#endif

6
src/proc/mobject/session/scope-path.cpp
View file

@ -54,12 +54,12 @@ namespace session {
namespace { // Helpers and shortcuts....
/** issue a query to discover the path to root,
/** issue a query to discover the (raw) path to root,
* starting with the given scope */
inline ScopeQuery<MObject>::iterator
discoverScopePath (Scope const& leaf)
{
return ScopeLocator::instance().locate<MObject> (leaf); /////////////////////////////TICKET #663 create a single extension point to add meta-clip support later
return ScopeLocator::instance().getRawPath (leaf);
}
@ -279,7 +279,7 @@ namespace session {
this->path_ = otherPath; // TODO really relate the two paths, including a treatment for meta-clips
// - if both are in the same sequence (same head element): just attach the tail of the other
// - if the other path points into a sequence which is attached as meta-clip to the current sequence,
// then attach the other path below that meta-clip
// then attach the other path below that meta-clip (problem: resolve multiple attachments)
// - otherwise use the first timeline, to which the other path's sequence is attached
// - otherwise, if all else fails, use the raw otherPath
}

11
wiki/renderengine.html
View file

@ -1045,7 +1045,7 @@ Meanwhile I've settled down on implementing the [[top-level entities|Timeline]]
On the implementation side, we use a special kind of MObject, acting as an anchor and providing an unique identity. Like any ~MObject, actually a placement establishes the connection and the scope, and typically constitutes a nested scope (e.g. the scope of all objects //within// the sequence to be bound into a timeline)
</pre>
</div>
<div title="BindingScopeProblem" modifier="Ichthyostega" modified="201010011556" created="200910181435" tags="SessionLogic spec" changecount="19">
<div title="BindingScopeProblem" modifier="Ichthyostega" modified="201010021417" created="200910181435" tags="SessionLogic spec" changecount="20">
<pre>There is some flexibility in the HighLevelModel, allowing to attach the same [[Sequence]] onto multiple [[timelines|Timeline]] or even into a [[meta-clip|VirtualClip]]. Thus, while there is always an containment relation which can be used to define the current PlacementScope, we can't always establish an unique path from any given location up to the model root. In the most general case, we have to deal with a DAG, not a tree.
!solution idea
@ -1078,10 +1078,11 @@ As the current query focus stack top always holds a ScopePath, the ''navigating
!!{{red{WIP 9/10}}}Deficiencies
To buy us some time, analysing and implementing the gory details of scope path navigation and meta-clips was skipped for now.
Please note the shortcomings and logical contradictions in the solution currently in code:
* it is assumed that the translation basic tree &amp;rarr; logical position happens &quot;somehow&quot; in the discovery query; but this query is implemented by the standard query resolver, which is the PlacementIndex. Thus, the facility providing the basic view should also be in charge for providing the logical view &amp;mdash; not a very clever move
* QueryFocus, with the help of ScopeLocator exposes the query services of the PlacementIndex. This yields the basic containment tree, while actually the logical view should be exposed. Thus we need an augmenting and translating layer on top
* the {{{ScopePath::navigate()}}}-function actually creates a new path on-the-fly, just to get this translation. Rather, //exactly this function//&amp;nbsp; should be the sole location to //provide//&amp;nbsp; this service.
* so we need a way to share the implementation logic, so the query/discovery functions can participate
* the {{{ScopePath::navigate()}}}-function was chosen as the location to implement the translation logic. //But actually this translation logic is missing.//
* so basically we're just using the raw paths of the basic containment tree; more specifically, the BindingMO (=Timeline) isn't part of the derived ScopePath
* this will result in problems even way before we implement meta-clips (because the Timeline is assumed to provide output routing information) to the Placements
* QueryFocus, with the help of ScopeLocator exposes the query services of the PlacementIndex. So actually it's up to the client code to pick the right functions. This might get confusing
* The current design rather places the implementation according to the roles of the involved entities, which causes some ping-pong on the implementation level. Especially the ScopeLocator singleton can be accessed multiple times. This is the usual clarity vs. performance tradeoff. Scope resolution is assumed rather to be //not performance critical.//
</pre>
</div>
<div title="BuildProcess" modifier="Ichthyostega" modified="200906071813" created="200706190658" tags="Builder operational img" changecount="30">