WIP: sketch handling placements and mobjects (as test)

This commit is contained in:
Fischlurch 2007-10-12 04:21:36 +02:00
parent 06f2503e62
commit fc1c39dc44
10 changed files with 132 additions and 21 deletions

View file

@ -34,9 +34,8 @@ namespace mobject
/** create an actual (explicit) placement while trying to
* satisfy the network of adjacent objects and placements.
* TODO: need GC!!!!!!!!!!!
*/
ExplicitPlacement&
ExplicitPlacement
Placement::resolve ()
{
}

View file

@ -63,7 +63,7 @@ namespace mobject
/** resolve the network of placement and
* provide the resulting (explicit) placement.
*/
ExplicitPlacement& resolve () ;
ExplicitPlacement resolve () ;
protected:
Placement ();
@ -77,7 +77,7 @@ namespace mobject
/**
* Factory specialized for creating Media Asset objects.
* Factory specialized for creating Placement objects.
*/
class PlacementFactory : public cinelerra::Factory<Placement>
{

View file

@ -0,0 +1,100 @@
/*
PlacementBasic(Test) - basic Placement and MObject handling
Copyright (C) CinelerraCV
2007, Christian Thaeter <ct@pipapo.org>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
#include "common/test/run.hpp"
#include "proc/mobject/session.hpp"
#include "proc/mobject/session/edl.hpp"
#include "proc/mobject/session/testclip.hpp"
#include "proc/mobject/placement.hpp"
#include "common/util.hpp"
//#include <boost/format.hpp>
#include <iostream>
//using boost::format;
using cinelerra::Time;
using util::contains;
using std::string;
using std::cout;
namespace mobject
{
namespace session
{
namespace test
{
/*******************************************************************
* @test basic behaviour of Placements and access to MObjects.
* @see mobject::Placement
* @see mobject::MObject#create
* @see mobject::Placement#addPlacement
* @see mobject::Placement#resolve
*/
class PlacementBasic_test : public Test
{
typedef shared_ptr<asset::Media> PM;
virtual void
run (Arg arg)
{
// create Clip-MObject, which is wrapped into a placement (smart ptr)
PM media = asset::Media::create("test-1", VIDEO);
Placement<Clip> pc = MObject::create(media);
// can use the Clip-MObject interface by dereferencing the placement
PM clip_media = pc->getMedia();
ASSERT (clip_media->ident.category.hasKind (VIDEO));
// using the Placement interface
// TODO: how to handle unterdetermined Placement? Throw?
FixedPlacement & fixpla = pc.addPlacement(Placement::FIXED, Time(1)); // TODO: the track??
ExplicitPlacement expla = pc.resolve();
ASSERT (expla.time == 1);
ASSERT (!expla.isOverdetermined());
ASSERT (*expla == *pc);
ASSERT (*fixpla == *pc);
// now overconstraining with another Placement
pc.addPlacement(Placement::FIXED, Time(2));
expla = pc.resolve();
ASSERT (expla.time == 2); // the latest addition wins
ASSERT (expla.isOverdetermined());
}
};
/** Register this test class... */
LAUNCHER (PlacementBasic_test, "unit session");
} // namespace test
} // namespace session
} // namespace mobject

View file

@ -55,7 +55,8 @@ namespace mobject
*/
class AddClip_test : public Test
{
virtual void run(Arg arg)
virtual void
run (Arg arg)
{
PSess sess = Session::current;
PMO clip = TestClip::create();

View file

@ -56,7 +56,8 @@ namespace mobject
*/
class DeleteClip_test : public Test
{
virtual void run(Arg arg)
virtual void
run (Arg arg)
{
buildTestseesion1();
PSess sess = Session::current;

View file

@ -57,7 +57,8 @@ namespace mobject
*/
class RebuildFixture_test : public Test
{
virtual void run(Arg arg)
virtual void
run (Arg arg)
{
PSess sess = Session::current;
sess.clear();

View file

@ -50,7 +50,8 @@ namespace mobject
*/
class SessionManager_test : public Test
{
virtual void run(Arg arg)
virtual void
run (Arg arg)
{
getCurrentSession ();
clearSession();
@ -66,7 +67,8 @@ namespace mobject
/** @test accessing the current (global) session
*/
void getCurrentSession ()
void
getCurrentSession ()
{
PSess sess = Session::current;
ASSERT (sess->isValid());
@ -77,7 +79,8 @@ namespace mobject
* @todo implement all session content, implement
* mobject and asset deletion operations.
*/
void clearSession ()
void
clearSession ()
{
UNIMPLEMENTED ("clear objects in current session");
Session::current.clear();
@ -87,7 +90,8 @@ namespace mobject
* a pristine default session.
* @todo define the "global session config", implement session default ctor
*/
void resetSession ()
void
resetSession ()
{
UNIMPLEMENTED ("construct a pristine session");
Session::current.reset();
@ -98,7 +102,8 @@ namespace mobject
* objects are wired correctly.
* @todo implement rebuilding session, implement mock session serializer
*/
void loadMockSession ()
void
loadMockSession ()
{
UNIMPLEMENTED ("rebuild session using a mock serializer");
}
@ -108,7 +113,8 @@ namespace mobject
* @param src string with serialized session data
* @todo implement real session serializer
*/
void loadSession (const string& src)
void
loadSession (const string& src)
{
UNIMPLEMENTED ("loding real sesion");
}
@ -117,7 +123,8 @@ namespace mobject
* @param dest string recieving the generated serialized stream
* @todo implement real session serializer
*/
void saveSession (string& dest)
void
saveSession (string& dest)
{
UNIMPLEMENTED ("serialize current session");
}

View file

@ -55,7 +55,8 @@ namespace mobject
*/
class SessionStructure_test : public Test
{
virtual void run(Arg arg)
virtual void
run (Arg arg)
{
PSess sess = Session::current;
ASSERT (0 <= sess->currEDL().size()); // TODO implement

View file

@ -3,19 +3,20 @@ diagrams
classdiagram_ref 130309 // Asset Kinds
860 633 100 4 0 0
active classdiagram_ref 128133 // Session structure
860 633 100 4 47 0
860 633 100 4 89 0
classdiagram_ref 130437 // Media-Asset Relations
860 633 100 4 0 0
classdiagram_ref 128389 // Render Entities
688 506 100 4 120 0
end
show_stereotypes
selected operation_ref 128005 // resolve
selected attribute_ref 128133 // relType
open
package_ref 128005 // design
deploymentview_ref 128773 // gen
classview_ref 128901 // Assets
class_ref 128517 // MObject
class_ref 128645 // Placement
class_ref 129413 // RelativePlacement
classview_ref 129029 // Interface
usecaseview_ref 128133 // usage
end

View file

@ -773,7 +773,7 @@ Cinelerra uses this term in a related manner but with a somewhat shifted focus (
In this usage, the EDL in most cases will be almost synonymous to the [[Session|SessionOverview]], just the latter emphasizes more the state aspect, as it can be thought as the current EDL contents contained in a file or data structure together with additional Option values and settings for the GUI. The Session is what you save and load, while the EDL rather denotes a structured collection of Objects placed in time.
</pre>
</div>
<div title="EditingOperations" modifier="Ichthyostega" modified="200710100119" created="200709251610" tags="design decision" changecount="4">
<div title="EditingOperations" modifier="Ichthyostega" modified="200710111508" created="200709251610" tags="design decision" changecount="5">
<pre>These are the tools provided to any client of the Proc layer for handling and manipulating the entities in the EDL. When defining such operations, //the goal should be to arrive at some uniformity in the way things are done.// Ideally, when writing client code, one should be able to guess how to achieve some desired result.
!guiding principle
@ -794,7 +794,7 @@ While performing any manipulative task, the state of the object is considered in
At the level of fine grained operations on individual entities, there is ''no support for parallelism''. Individual entities don't lock themselves. Tasks perform locking and are to be scheduled. Thus, we need an isolation layer towards all inherently multithreaded parts of the system, like the GUI or the renderengine.
This has some obvious and some subtle consequences. Of course, manipulating //tasks// will be queued and scheduled somewhere. But as we rely on object identity and reference semantics for the entities in the EDL, some value changes are visible to operations going on in parallel threads (e.g. rendering) and each operation on the EDL entities //has to be aware of this.//
Consequently, sometimes there needs to be done a ''self-replacement by copy'' followed by manipulation of the new copy, while ongoing processes use the unaltered original object until they receive some sort of reset.
Consequently, sometimes there needs to be done sort of a ''read-copy-update'', i.e. self-replacement by copy followed by manipulation of the new copy, while ongoing processes use the unaltered original object until they receive some sort of reset.
!!undo
Basically, each elementary operation has to record the informations necessary to be undone. It does so by registering a Memento with some central UndoManager facility. This Memento object contains a functor pre-bound with the needed parameter values. (Besides, the UndoManager is free to implement a second level of security by taking independent state snapshots).