a bit of API brainstorming

This commit is contained in:
Fischlurch 2009-05-13 03:46:08 +02:00
parent b32c3f5898
commit 7abada72fd
4 changed files with 40 additions and 6 deletions

View file

@ -335,7 +335,7 @@ namespace asset {
: boost::is_base_of<Asset, A> {};
/** convienient for debugging */
/** convenient for debugging */
inline string str (const PcAsset& a)
{
if (a)

View file

@ -36,13 +36,16 @@
//#include "pre.hpp"
//#include "proc/mobject/session/locatingpin.hpp"
//#include "proc/asset/pipe.hpp"
#include "proc/mobject/placement-ref.hpp"
//#include <tr1/memory>
#include <vector>
namespace mobject {
// using std::tr1::shared_ptr;
using std::vector;
@ -50,8 +53,33 @@ namespace mobject {
*/
class PlacementIndex
{
public:
typedef Placement<MObject> PlacementMO;
typedef PlacementRef PRef;
typedef PRef::ID ID;
PlacementMO& find (ID) const;
template<class MO>
Placement<MO>& find (PRef::IDp<MO>) const;
PlacementMO& getScope (PlacementMO&) const;
PlacementMO& getScope (ID) const;
vector<PRef> getReferrers (ID) const;
/** diagnostic: number of indexed entries */
size_t size() const;
/* == mutating operations == */
ID insert (PlacementMO& newObj, PlacementMO& targetScope);
bool remove (PlacementMO&);
bool remove (ID);
};
////////////////TODO currently just fleshing out the API; probably have to splitt off an impl.class

View file

@ -57,6 +57,11 @@ namespace mobject {
{
};
template<class MO>
class IDp : public ID
{
};
};

View file

@ -1913,12 +1913,13 @@ The general idea is, that each facade interface actually provides access to a sp
* {{{RelativeLocation}}} is used to atach the MObject to some other anchor MObject
* //additional constraints, placement objectives, range restrictions, pattern rules will follow...//</pre>
</div>
<div title="MObject" modifier="Ichthyostega" modified="200710092343" created="200706220312" tags="def classes" changecount="2">
<div title="MObject" modifier="Ichthyostega" modified="200905130114" created="200706220312" tags="def classes" changecount="3">
<pre>All sorts of &quot;things&quot; to be placed and manipulated by the user in the EDL. This interface abstracts the details and just supposes
* the media object has a duration
* it is allways //placed// in some manner, i.e. it is allways accessed via a [[Placement]]
* {{red{and what else?}}}
</pre>
&amp;rarr; overview [[MObject class hierarchy|MObjects]]</pre>
</div>
<div title="MObjectRef" modifier="Ichthyostega" modified="200905090026" created="200904242107" tags="SessionLogic GuiIntegration design draft discuss" changecount="16">
<pre>''The Problem of referring to an [[MObject]]'' stems from the object //as a concept// encompassing a wider scope then just the current implementation instance. If the object was just a runtime entity in memory, we could use a simple (language) reference or pointer. Actually, this isn't sufficient, as the object reference will pass LayerSeparationInterfaces, will be handed over to code not written in the same implementation language, will be included in an ''UNDO'' record for the UndoManager, and thus will need to be serialized and stored permanently within the SessionStorage.
@ -1949,8 +1950,8 @@ Presumably, none of the both models is usable as-is; rather we try to reconstruc
{{red{WIP}}}
</pre>
</div>
<div title="MObjects" modifier="Ichthyostega" modified="200810180118" created="200706190636" tags="overview" changecount="10">
<pre>The ~MObjects Subsystem contains everything related to the [[EDL]] and the various Media Objects placed within. It is complemented by the Asset Management (see &amp;rarr; [[Asset]]). Examples for [[MObjects|MObject]] being:
<div title="MObjects" modifier="Ichthyostega" modified="200905130116" created="200706190636" tags="overview" changecount="15">
<pre>The ~MObjects Subsystem contains everything related to the [[EDL]] and the various Media Objects placed within. It is complemented by the Asset Management (see &amp;rarr; [[Asset]]). Examples for [[MObjects |MObject]](&amp;rarr; def) being:
* audio/video clips
* effects and plugins
* special facilities like mask and projector