define Player / Output subsystem stub

This commit is contained in:
Fischlurch 2011-05-24 03:48:49 +02:00
parent 20f95ca26f
commit c091b8e260
4 changed files with 69 additions and 4 deletions

View file

@ -37,15 +37,15 @@
using lib::Cmdline;
using lumiera::Subsys;
using lumiera::AppState;
using lumiera::ON_GLOBAL_INIT;
namespace {
Subsys& engine = backend::EngineFacade::getDescriptor();
Subsys& netNode = backend::NetNodeFacade::getDescriptor();
Subsys& script = backend::ScriptRunnerFacade::getDescriptor();
Subsys& player = lumiera::DummyPlayer::getDescriptor();
Subsys& player = lumiera::DummyPlayer::getDescriptor(); ///////TODO: just a dummy, until we're able to render
Subsys& builder = proc::Facade::getBuilderDescriptor();
Subsys& session = proc::Facade::getSessionDescriptor();
Subsys& playOut = proc::Facade::getPlayOutDescriptor();
Subsys& lumigui = gui::GuiFacade::getDescriptor();
}
@ -66,13 +66,17 @@ main (int argc, const char* argv[])
session.depends (builder);
netNode.depends (session);
netNode.depends (engine);
playOut.depends (engine);
playOut.depends (session);
// lumigui.depends (session); //////TODO commented out in order to be able to start up a dummy GuiStarterPlugin
// lumigui.depends (engine);
player.depends (playOut); //////TODO dummy player, until we're able to render
lumigui.depends (player);
script.depends (session);
script.depends (engine);
application.maybeStart (session);
application.maybeStart (playOut);
application.maybeStart (netNode);
application.maybeStart (lumigui);
application.maybeStart (script);

View file

@ -103,9 +103,53 @@ namespace proc {
}
};
class PlayOutSubsysDescriptor
: public Subsys
{
operator string () const { return "PlayOut"; }
/** determine, if any output system is required to start up explicitly.
* Moreover, extract configuration variations for specific kinds of output
* @return true if any output system is required to start stand-alone.
* otherwise, the player and a default configured output connection
* is pulled up only when required by another subsystem (e.g. GUI)
* @todo actually define cmdline options and parse/decide here!
*/
bool
shouldStart (lumiera::Option&)
{
TODO ("extract options about specific output systems to be brought up");
return false;
}
bool
start (lumiera::Option&, Subsys::SigTerm termination)
{
UNIMPLEMENTED ("bring up and configure the output connections and the player");
return false;
}
void
triggerShutdown () throw()
{
UNIMPLEMENTED ("initiate playback/render halt and disconnect output");
}
bool
checkRunningState () throw()
{
//Lock guard (*this);
TODO ("implement detecting running state");
return false;
}
};
namespace {
lib::Singleton<BuilderSubsysDescriptor> theBuilderDescriptor;
lib::Singleton<SessionSubsysDescriptor> theSessionDescriptor;
lib::Singleton<PlayOutSubsysDescriptor> thePlayOutDescriptor;
}
@ -125,6 +169,14 @@ namespace proc {
{
return theSessionDescriptor();
}
/** @internal intended for use by main(). */
Subsys&
Facade::getPlayOutDescriptor()
{
return thePlayOutDescriptor();
}

View file

@ -44,6 +44,8 @@ namespace proc {
* @todo this is a dummy placeholder as of 1/2009. Currently, there
* is only implementation-level code within the Proc-Layer and
* the interfaces need to be worked out.
* @note at least the Play/Output subsystem slowly turns into
* something real, as of 6/2011
*
*/
struct Facade
@ -60,6 +62,13 @@ namespace proc {
static lumiera::Subsys& getSessionDescriptor();
/** provide a descriptor for lumiera::AppState,
* wired accordingly to allow main to bring up
* the render, playback coordination and
* output management subsystem. */
static lumiera::Subsys& getPlayOutDescriptor();
//////////////////TODO: define the global access interfaces for the Proc-Layer
//////////////////TODO: provide a function for accessing this interface
//////////////////TODO: register similar proxy/facade interfaces for the GUI

View file

@ -7269,10 +7269,10 @@ Establishing a ~ViewConnection is prerequisite for creating or attaching an Play
View connections are part of the model and thus persistent. They can be created explicitly, or just derived by //allocating a viewer.// And a new view connection can push aside (and thus &quot;break&quot;) an existing one from another timeline or model element. When a view connection is //broken,// any associated PlayProcess needs to be terminated (this is a blocking operation). Thus, at any time, there can be only one active view connection to a given viewer; here &quot;active&quot; means, that a PlayController has been hooked up, and the connection is ready for playback or rendering. But on the other hand, nothing prevents a timeline (or similar model object) to maintain multiple view connections -- consequently the actual playback position behaves as if associated with the view connection.
</pre>
</div>
<div title="ViewerAsset" modifier="Ichthyostega" created="201105230116" tags="Model spec" changecount="1">
<div title="ViewerAsset" modifier="Ichthyostega" modified="201105232228" created="201105230116" tags="Model spec" changecount="2">
<pre>A [[structural Asset|StructAsset]] corresponding to a Viewer element in the GUI.
These Viewer (or Monitor) elements play an enabling role for any output generation. In order to [[initiate playback|PlayService]], we need a fulle resolved OutputDesignation, which typcially can be achieved by creating a ViewConnection, i.e. connecting a timeline or similarily suitable model element to such a viewer. Actually, this connection is modelled by attaching to a BindingMO which is linked to a ViewerAsset. This way, the model tracks and persists the available viewer windows and the current connection situation.
These Viewer (or Monitor) elements play an enabling role for any output generation. In order to [[initiate playback|PlayService]], we need a fully resolved OutputDesignation, which typcially can be achieved by creating a ViewConnection, i.e. connecting a timeline or similarily suitable model element to such a viewer. Actually, this connection is modelled by attaching to a BindingMO which is linked to a ViewerAsset. This way, the model tracks and persists the available viewer windows and the current connection situation.
When the GUI is outfitted, based on the current Session or HighLevelModel, it is expected to retrieve the viewer assets and for each of them, after installing the necessary widgetes, registers an OutputSlot with the global OutputManager.</pre>
</div>