diff --git a/doc/devel/draw/PlayerArch-1.svg b/doc/devel/draw/PlayerArch-1.svg index a3799f876..14862c94a 100644 --- a/doc/devel/draw/PlayerArch-1.svg +++ b/doc/devel/draw/PlayerArch-1.svg @@ -29,7 +29,7 @@ inkscape:pageshadow="2" inkscape:zoom="2" inkscape:cx="419.63217" - inkscape:cy="331.20952" + inkscape:cy="291.20952" inkscape:document-units="px" inkscape:current-layer="svg2" inkscape:window-width="1668" @@ -38,7 +38,7 @@ inkscape:window-y="0" width="800px" height="600px" - showgrid="true" + showgrid="false" gridspacingx="2px" gridspacingy="2px" gridanglex="30px" @@ -56,6 +56,19 @@ guidetolerance="5" /> + + + + y="100" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="250" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="450" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#6c6c6c;stroke-width:1.5;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> start(...) + style="font-size:8px;font-style:oblique;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;font-family:Bitstream Vera Sans">start( slot ) yields Proc (or Backend?) + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> Displayer (Proxy) + sodipodi:role="line">Display::Sink (functor) PlayerFacade (Proxy) + style="font-size:8px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;font-family:Bitstream Vera Sans" + id="tspan2303">Proxy<Player> + sodipodi:nodetypes="ccc" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="389.93243" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="450" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.99999994;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.99999994;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="490" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> PlayContext + sodipodi:nodetypes="cc" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="190" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + id="path2241" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#4f4f4f;stroke-width:1.5;stroke-linecap:butt;stroke-linejoin:miter;marker-start:url(#TriangleInL);stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow1Mend);stroke-opacity:1" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + sodipodi:nodetypes="cc" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + sodipodi:nodetypes="ccc" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000012;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="250" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> DisplayFacade (Proxy) + sodipodi:role="line">Proxy<Display> + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#4f4f4f;stroke-width:1.5;stroke-linecap:butt;stroke-linejoin:miter;marker-start:url(#TriangleInL);stroke-opacity:1;opacity:1;color:#000000;marker:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#6c6c6c;stroke-width:1.5;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.99999994;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> Displayer + id="tspan2294">DisplayerSlot + y="140.06757" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + y="180.06757" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.99999994;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> Displayer + sodipodi:role="line">DisplayerSlot Displayer + id="tspan2312">DisplayerSlot Displayer + sodipodi:role="line">DisplayerSlot + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow1Mend);stroke-opacity:1" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + transform="translate(529.80198,-99.756098)" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> + sodipodi:nodetypes="ccc" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> yields - ProcessImpl + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow1Mend);stroke-opacity:1" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + sodipodi:nodetypes="ccc" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + sodipodi:nodetypes="ccc" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> periodically + id="path3436" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + style="opacity:1;color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#2d2abd;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> attach_viewer() + style="font-size:8px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;font-family:Bitstream Vera Sans">use_display (slot) + y="70" + inkscape:export-filename="/home/hiv/devel/lumi/wiki/draw/PlayerArch1.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" /> + ProcessImpl + + dispatch toGTK main thread... + play(..) + play(..) + not yet implemented... + diff --git a/doc/devel/uml/class146565.html b/doc/devel/uml/class146565.html new file mode 100644 index 000000000..caadd3954 --- /dev/null +++ b/doc/devel/uml/class146565.html @@ -0,0 +1,21 @@ + + + + + + +Class Facade + + + + + +
Class Facade
+

+ + + + +

Declaration :

  • C++ : class Facade
  • Java : package interface Facade

Directly inherited by : Proxy ServiceImpl

+ + diff --git a/doc/devel/uml/class146693.html b/doc/devel/uml/class146693.html new file mode 100644 index 000000000..1dfd3512e --- /dev/null +++ b/doc/devel/uml/class146693.html @@ -0,0 +1,23 @@ + + + + + + +Class Proxy + + + + + +
Class Proxy
+

+ + + + +

Declaration :

  • C++ : class Proxy : public Facade
+ +
Relation <unidirectional association>

Declaration :

+ + diff --git a/doc/devel/uml/class146821.html b/doc/devel/uml/class146821.html new file mode 100644 index 000000000..af636ece9 --- /dev/null +++ b/doc/devel/uml/class146821.html @@ -0,0 +1,23 @@ + + + + + + +Class ServiceImpl + + + + + +
Class ServiceImpl
+

+ + + + +

Declaration :

  • C++ : class ServiceImpl : public Facade
+ +
Relation <unidirectional association>

Declaration :

+ + diff --git a/doc/devel/uml/class146949.html b/doc/devel/uml/class146949.html new file mode 100644 index 000000000..875ffa2e8 --- /dev/null +++ b/doc/devel/uml/class146949.html @@ -0,0 +1,21 @@ + + + + + + +Class C_Interface + + + + + +
Class C_Interface
+

+ + + + +

Declaration :

  • C++ : class C_Interface

Directly inherited by : C_Instance

+ + diff --git a/doc/devel/uml/class147077.html b/doc/devel/uml/class147077.html new file mode 100644 index 000000000..a17c10f3a --- /dev/null +++ b/doc/devel/uml/class147077.html @@ -0,0 +1,23 @@ + + + + + + +Class C_Instance + + + + + +
Class C_Instance
+

+ + + + +

Declaration :

+ +
Relation <unidirectional association>

Declaration :

+ + diff --git a/doc/devel/uml/class147205.html b/doc/devel/uml/class147205.html new file mode 100644 index 000000000..09e455a99 --- /dev/null +++ b/doc/devel/uml/class147205.html @@ -0,0 +1,22 @@ + + + + + + +Class InstanceHandle + + + + + +
Class InstanceHandle
+

+ + + + +

Declaration :

  • C++ : template<class C_Interface, class Facade> class InstanceHandle
+
+ + diff --git a/doc/devel/uml/classdiagrams.html b/doc/devel/uml/classdiagrams.html index f66c12462..8159cb541 100644 --- a/doc/devel/uml/classdiagrams.html +++ b/doc/devel/uml/classdiagrams.html @@ -24,6 +24,7 @@ HierarchyLumiera Exception hierarchy In Memory Database interface components +Layer Separation Interface Media-Asset Relations Proc-Asset Relations Render Entities diff --git a/doc/devel/uml/classes.html b/doc/devel/uml/classes.html index 63214df7b..637ca483e 100644 --- a/doc/devel/uml/classes.html +++ b/doc/devel/uml/classes.html @@ -32,6 +32,8 @@ BuilderFacadeboundaryProvides unified access to the builder functionality. While individual components of the builder subsystem may be called if necessary or suitable, it is usually better to do all extern invocations via the high level methods of this Facade BuilderToolinterfaceUsed according to the visitor pattern: each Tool contains the concrete implementation for one task to be done to the various MObject classes BuildInstruct(Interface) building instructions to be executed by the Builder on the render node network under construction. +C_Instance +C_Interface Caller Categorytree like classification of Assets Clipbookkeeping (asset) view of a media clip. @@ -58,6 +60,7 @@ ExitNodeThe output of the render pipeline. Pulling from such exit nodes actually ivokes the render process ExplicitPlacementinterface External +Facadeinterface Factorya template for generating functor-like Factory objects, used to encapsulate object creation and providing access via smart-pointers only. FeedCache File @@ -75,6 +78,7 @@ FrameReference GLBuf ImplFacade +InstanceHandle InterpolatorProvides the implementation for getting the acutal value of a time varying or automated effect/plugin parameter Invalid Invocation @@ -117,6 +121,7 @@ Project ProjectorSpecial video processing node used to scale and translate image data. Prototype +Proxy PullInput QueryCache QueryHandlerinterface @@ -134,6 +139,7 @@ Seq Sequence Serializeractor +ServiceImpl SessionPrimary Interface for all editing tasks.
The session contains defaults, all the assets being edited, and a set of EDL with the individual MObjects to be manipulated and rendered. SessionImplImplementation class for the Session interface SessManager diff --git a/doc/devel/uml/classes_list.html b/doc/devel/uml/classes_list.html index 96378253b..33f50cb20 100644 --- a/doc/devel/uml/classes_list.html +++ b/doc/devel/uml/classes_list.html @@ -33,6 +33,8 @@ BuilderFacade
BuilderTool
BuildInstruct
+C_Instance
+C_Interface
Caller
Category
Clip
@@ -59,6 +61,7 @@ ExitNode
ExplicitPlacement
External
+Facade
Factory
FeedCache
File
@@ -76,6 +79,7 @@ FrameReference
GLBuf
ImplFacade
+InstanceHandle
Interpolator
Invalid
Invocation
@@ -118,6 +122,7 @@ Project
Projector
Prototype
+Proxy
PullInput
QueryCache
QueryHandler
@@ -135,6 +140,7 @@ Seq
Sequence
Serializer
+ServiceImpl
Session
SessionImpl
SessManager
diff --git a/doc/devel/uml/fig132869.png b/doc/devel/uml/fig132869.png new file mode 100644 index 000000000..5935bc63c Binary files /dev/null and b/doc/devel/uml/fig132869.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index c05d6f597..55bbadb38 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -129,7 +129,7 @@ Documentation
Artifact Lumiera

Depends on common

Depends on gui

Depends on proc

Depends on backend

the main executable to be built

-

executable associated with : glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label

+

executable associated with : controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, mobject, source, frame, placement, sessionimpl, builderfacade

Artifact main

Artifact source

@@ -1180,8 +1180,21 @@ reuse exiting Engine

Selection :

    Transformation

    GUI is here just a container to hold any entities considered to be User Interface related, which is not in focus for this Design draft

    5 Package CommonLib

    + +

    5.1 Class View InterfaceSystem

    +
    + +

    +

    Layer Separation Interface



    +
    Class Facade
    +
    Class Proxy
    +
    Class ServiceImpl
    +
    Class C_Interface
    +
    Class C_Instance
    +
    Class InstanceHandle
    +
    -

    5.1 Class View StreamType

    +

    5.2 Class View StreamType

    @@ -1193,10 +1206,10 @@ reuse exiting Engine

    Selection :

      Transformation
      Class MediaKind

      -

      5.2 Package ConfigQuery

      +

      5.3 Package ConfigQuery

      -

      5.2.1 Component View Query System overview

      +

      5.3.1 Component View Query System overview

      @@ -1212,7 +1225,7 @@ reuse exiting Engine

      Selection :

        Transformation
        Component DefaultsManager

        -

        5.2.2 Class View query

        +

        5.3.2 Class View query

        @@ -1228,27 +1241,27 @@ reuse exiting Engine

        Selection :

          Transformation
          Class DefaultsRegistry

          -

          5.2.3 Use Case View query use

          +

          5.3.3 Use Case View query use

          when to query



          -

          5.2.3.1 Use Case create specific object

          +

          5.3.3.1 Use Case create specific object

          -

          5.2.3.2 Use Case use "default" object

          +

          5.3.3.2 Use Case use "default" object

          -

          5.2.3.3 Use Case load object from session

          +

          5.3.3.3 Use Case load object from session

          -

          5.2.3.4 Use Case add new object to session

          +

          5.3.3.4 Use Case add new object to session

          Class User
          Class Serializer
          -

          5.2.3.5 Use Case ConfigQuery

          +

          5.3.3.5 Use Case ConfigQuery

          -

          5.2.3.6 Use Case need sub object

          +

          5.3.3.6 Use Case need sub object

          "default" object



          @@ -1256,7 +1269,7 @@ reuse exiting Engine

          Selection :

            Transformation
            Class instance predicate impl

            type :TypeHandler

            -

            5.3 Class View error

            +

            5.4 Class View error

            @@ -1270,7 +1283,7 @@ reuse exiting Engine

            Selection :

              Transformation
              Class std::exception

              -

              5.4 Class View Service Components

              +

              5.5 Class View Service Components

              Class Applicable
              Class Tool
              @@ -1280,7 +1293,7 @@ reuse exiting Engine

              Selection :

                Transformation
                Class Appconfig

                -

                5.5 Class View Posix Threads Abstraction

                +

                5.6 Class View Posix Threads Abstraction

                C++ wrapers for pthreads

                Class Thread
                @@ -1288,7 +1301,7 @@ reuse exiting Engine

                Selection :

                  Transformation
                  Class Mutex

                  -

                  5.6 Class View SmartPointers

                  +

                  5.7 Class View SmartPointers

                  Class SmartPointer
                  diff --git a/doc/devel/uml/index_67.html b/doc/devel/uml/index_67.html index 81d96139c..b906f4d25 100644 --- a/doc/devel/uml/index_67.html +++ b/doc/devel/uml/index_67.html @@ -17,6 +17,8 @@ + + @@ -30,39 +32,39 @@ - + + + + + - - - + - - - - - - - - - - - + + + + + - + + - - - + + + + + + - + diff --git a/doc/devel/uml/index_70.html b/doc/devel/uml/index_70.html index 77ab812da..5f2c83e88 100644 --- a/doc/devel/uml/index_70.html +++ b/doc/devel/uml/index_70.html @@ -17,6 +17,7 @@
                  NameKindDescription
                  C_Instanceclass
                  C_Interfaceclass
                  Cachecomponent
                  Cachecomponent view
                  callDownoperation
                  chainoperationcreate and add another Placement for this media object, thus increasingly constraining the (possible) position of this object.
                  checked_inrelationchecked_in objects are subject of cache aging and must be not in use
                  checked_outrelationthis list keeps all mappings which are in use, and thus prevents them from Cache aging
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  class instanceclass instance
                  clearoperationclear current session contents
                  without resetting overall session config.
                  Afterwards, the session will contain only one
                  empty EDL, while all Assets are retained.
                  client codecomponent
                  Clipclassbookkeeping (asset) view of a media clip.
                  clipartifacta Media Clip
                  clipartifactbookkeeping (asset) view of a media clip.
                  clipartifacta Media Clip
                  Clipclass
                  clipsrelation
                  Codecclassdescription of some media data decoder or encoder facility
                  + diff --git a/doc/devel/uml/index_73.html b/doc/devel/uml/index_73.html index 963294360..7f152ccfe 100644 --- a/doc/devel/uml/index_73.html +++ b/doc/devel/uml/index_73.html @@ -22,13 +22,15 @@ - + + + diff --git a/doc/devel/uml/index_76.html b/doc/devel/uml/index_76.html index 75cbabe50..0689ba659 100644 --- a/doc/devel/uml/index_76.html +++ b/doc/devel/uml/index_76.html @@ -19,6 +19,7 @@ + diff --git a/doc/devel/uml/index_80.html b/doc/devel/uml/index_80.html index 85ccb15d9..d024e3dca 100644 --- a/doc/devel/uml/index_80.html +++ b/doc/devel/uml/index_80.html @@ -71,6 +71,7 @@ +
                  NameKindDescription
                  Facadeclass
                  Factoryclassa template for generating functor-like Factory objects, used to encapsulate object creation and providing access via smart-pointers only.
                  FeedCacheclass
                  fetchoperation
                  In Memory Databaseclass diagram
                  inFixtureactivity action pin
                  inputclass instance
                  inputclass instance
                  inputclass instance
                  inputclass instance
                  instanceoperation
                  InstanceHandleclass
                  instructionsrelation
                  Interfaceclass view
                  interface componentsclass diagram
                  interfacescomponent view
                  InterfaceSystemclass view
                  interpolatorartifactdenotes a facility to get (continuously interpolated) parameter values
                  InterpolatorclassProvides the implementation for getting the acutal value of a time varying or automated effect/plugin parameter
                  Invalidclass
                  NameKindDescription
                  labelartifact
                  Labelclass
                  Layer Separation Interfaceclass diagram
                  lengthattributeTODO: how to represent time intervals?
                  lengthattributeduration (span) of this timeline segment.
                  Linkclass
                  projectorartifactvideo ProcNode for scaling and translating image data
                  Prototypeclass
                  providerrelation
                  Proxyclass
                  pulloperation
                  PullInputclass
                  diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index e92c87510..9c9ebb223 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -32,10 +32,11 @@ Sequenceclass Serializerclass Service Componentsclass view +ServiceImplclass Sessioncomponent sessionartifactInterface: the session edited by the user -sessionpackagesourcecode package

                  Everything concerning the EDL and Session, within the MObject Subsystem Sessionclass view +sessionpackagesourcecode package

                  Everything concerning the EDL and Session, within the MObject Subsystem SessionclassPrimary Interface for all editing tasks.
                  The session contains defaults, all the assets being edited, and a set of EDL with the individual MObjects to be manipulated and rendered. Session structureclass diagram sessionimplartifactholds the complete session data to be edited by the user @@ -49,8 +50,8 @@ SimpleClipclassElementary clip consisting of only one media stream SmartPointerclass SmartPointersclass view -sourcerelationthe media source this clip referes to sourcerelationmedia source of this clip +sourcerelationthe media source this clip referes to SourceclassSource Node: represents a media source to pull data from. sourceartifactRepresentation of a Media source Source Overviewdeployment diagram diff --git a/uml/lumiera/128517 b/uml/lumiera/128517 index 6feb7ce56..6f5c8ce9d 100644 --- a/uml/lumiera/128517 +++ b/uml/lumiera/128517 @@ -1,6 +1,6 @@ format 40 "CommonLib" // CommonLib - revision 13 + revision 14 modified_by 5 "hiv" // class settings //class diagram settings @@ -26,6 +26,184 @@ format 40 package_name_in_tab default show_context default show_opaque_action_definition default auto_label_position default write_flow_label_horizontally default draw_all_relations default shadow default show_infonote default drawing_language default + classview 129541 "InterfaceSystem" + //class diagram settings + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + //collaboration diagram settings + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + //object diagram settings + write_horizontally default package_name_in_tab default show_context default auto_label_position default draw_all_relations default shadow default + //sequence diagram settings + show_full_operations_definition default write_horizontally default class_drawing_mode default drawing_language default draw_all_relations default shadow default + //state diagram settings + package_name_in_tab default show_context default auto_label_position default write_trans_label_horizontally default show_trans_definition default draw_all_relations default shadow default + show_activities default region_horizontally default drawing_language default + //class settings + //activity diagram settings + package_name_in_tab default show_context default show_opaque_action_definition default auto_label_position default write_flow_label_horizontally default draw_all_relations default shadow default + show_infonote default drawing_language default + + classdiagram 132869 "Layer Separation Interface" + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + size A4 + end + + class 146565 "Facade" + visibility package stereotype "interface" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "${comment}${@}${visibility}interface ${name}${extends} { +${members}} +" + idl_decl "${comment}${abstract}${local}interface ${name}${inherit} { +${members}}; +" + explicit_switch_type "" + + end + + class 146693 "Proxy" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 161797 // + relation 157189 -_-|> + a public + cpp default "${type}" + classrelation_ref 161797 // + b multiplicity "" parent class_ref 146565 // Facade + end + + classrelation 162181 // + relation 157573 ---> + stereotype "uses" + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 162181 // + b multiplicity "" parent class_ref 146949 // C_Interface + end + end + + class 146821 "ServiceImpl" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 161925 // + relation 157317 -_-|> + a public + cpp default "${type}" + classrelation_ref 161925 // + b multiplicity "" parent class_ref 146565 // Facade + end + + classrelation 162437 // + relation 157829 ---> + stereotype "has_a" + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 162437 // + b multiplicity "" parent class_ref 147205 // InstanceHandle + end + end + + class 146949 "C_Interface" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + class 147077 "C_Instance" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 162053 // + relation 157445 -_-|> + a public + cpp default "${type}" + classrelation_ref 162053 // + b multiplicity "" parent class_ref 146949 // C_Interface + end + + classrelation 162309 // + relation 157701 ---> + stereotype "calls" + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 162309 // + b multiplicity "" parent class_ref 146821 // ServiceImpl + end + end + + class 147205 "InstanceHandle" + visibility package + nformals 2 + formal name "C_Interface" type "class" explicit_default_value "" + explicit_extends "" + formal name "Facade" type "class" explicit_default_value "" + explicit_extends "" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 162565 // + relation 157957 -_-> + stereotype "opens" + a package + cpp default "#include in source" + classrelation_ref 162565 // + b multiplicity "" parent class_ref 147077 // C_Instance + end + + classrelation 162693 // + relation 158085 -_-> + stereotype "creates" + a package + cpp default "#include in source" + classrelation_ref 162693 // + b multiplicity "" parent class_ref 146693 // Proxy + end + end + end + classview 129285 "StreamType" //class diagram settings draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default @@ -127,7 +305,7 @@ ${inlines} classrelation 158341 // relation 154245 -_-> a default - cpp default "Generated" + cpp default "#include in header" classrelation_ref 158341 // b multiplicity "" parent class_ref 144773 // StreamType end diff --git a/uml/lumiera/129285 b/uml/lumiera/129285 index 4089706c0..96ad397a7 100644 --- a/uml/lumiera/129285 +++ b/uml/lumiera/129285 @@ -1,6 +1,6 @@ format 40 "ProcessingLayer" // ProcessingLayer - revision 24 + revision 25 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/lumiera/132869.diagram b/uml/lumiera/132869.diagram new file mode 100644 index 000000000..654d09664 --- /dev/null +++ b/uml/lumiera/132869.diagram @@ -0,0 +1,75 @@ +format 40 + +classcanvas 128005 class_ref 146565 // Facade + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 66 14 2000 + end +classcanvas 128133 class_ref 146693 // Proxy + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 23 116 2000 + end +classcanvas 128261 class_ref 146821 // ServiceImpl + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 271 198 2000 + end +classcanvas 128389 class_ref 146949 // C_Interface + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 136 117 2000 + end +classcanvas 128517 class_ref 147077 // C_Instance + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 137 197 2000 + end +classcanvas 128645 class_ref 147205 // InstanceHandle + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 171 277 2000 + end +textcanvas 130309 "conceptually equivalent" + xyzwh 165 11 2000 115 18 +relationcanvas 128773 relation_ref 157189 // + geometry VHV + from ref 128133 z 1999 to point 43 95 + line 129157 z 1999 to point 103 95 + line 129285 z 1999 to ref 128005 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 128901 relation_ref 157317 // + geometry VHV unfixed + from ref 128261 z 1999 to point 305 95 + line 129413 z 1999 to point 103 95 + line 129541 z 1999 to ref 128005 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129029 relation_ref 157445 // + from ref 128517 z 1999 to ref 128389 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129669 relation_ref 157573 // + from ref 128133 z 1999 stereotype "<>" xyz 75 135 3000 to ref 128389 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129797 relation_ref 157701 // + from ref 128517 z 1999 stereotype "<>" xyz 213 216 3000 to ref 128261 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 130437 relation_ref 157829 // + geometry HVr + from ref 128261 z 1999 stereotype "<>" xyz 279 305 3000 to point 305 305 + line 130565 z 1999 to ref 128645 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 130693 relation_ref 157957 // + from ref 128645 z 1999 stereotype "<>" xyz 112 281 3000 to point 104 296 + line 130821 z 1999 to point 104 213 + line 130949 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 131077 relation_ref 158085 // + from ref 128645 z 1999 stereotype "<>" xyz 88 306 3000 to point 89 305 + line 131205 z 1999 to ref 128133 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +line 130053 -_-_ + from ref 128005 z 1999 to point 224 27 + line 130181 z 1999 to ref 128389 +end diff --git a/uml/lumiera/5.session b/uml/lumiera/5.session index d04da5e91..83fe86cc6 100644 --- a/uml/lumiera/5.session +++ b/uml/lumiera/5.session @@ -2,8 +2,10 @@ window_sizes 1302 1004 270 1022 854 71 diagrams classdiagram_ref 128133 // Session structure 853 742 100 4 120 0 - active classdiagram_ref 132741 // TimelineSequences + classdiagram_ref 132741 // TimelineSequences 585 732 100 4 0 0 + active classdiagram_ref 132869 // Layer Separation Interface + 373 417 100 4 0 0 end show_stereotypes selected @@ -38,6 +40,7 @@ open class_ref 144517 // Strategy class_ref 144005 // BuffTable class_ref 144261 // Invocation + classview_ref 129541 // InterfaceSystem classview_ref 129285 // StreamType classview_ref 128773 // error class_ref 140165 // Visitable diff --git a/uml/lumiera/lumiera.prj b/uml/lumiera/lumiera.prj index 1017e01e2..212f6ce25 100644 --- a/uml/lumiera/lumiera.prj +++ b/uml/lumiera/lumiera.prj @@ -1,6 +1,6 @@ format 40 "lumiera" - revision 49 + revision 50 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/draw/PlayerArch1.png b/wiki/draw/PlayerArch1.png index 2a8e24e35..5d3b947d4 100644 Binary files a/wiki/draw/PlayerArch1.png and b/wiki/draw/PlayerArch1.png differ diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 68eee94a7..cdc7d9ac7 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -1121,6 +1121,21 @@ The main tool used to implement this separation is the [[Builder Pattern|http:// 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 "internal-multi" 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 EDL in a more uniform manner and gain the possibility to [[place|Placement]] them in various ways.
                  +
                  +
                  LayerSeparationInterface provided by the GUI.
+Access point especially for the playback. A render- or playback process uses the DisplayFacade to push media date up to the GUI for display within a viewer widget of full-screen display. This can be thought off as a callback mechanism. In order to use the DisplayFacade, client code needs a DisplayerSlot (handle), which needs to be set up by the UI first and will be provided when starting the render or playback process.
+
                  +
                  +
                  +
                  A service within the GUI to manage output of frames generated by the lower layers of the application.
+*providing the actual implementation of the DisplayFacade
+*creating and maintaining of [[displayer slots|DisplayerSlot]], connected to viewer widgets or similar
+
                  +
                  +
                  +
                  An output port wired up to some display facility or viewer widget within the UI. For the client code, each slot is represented by a handle, which can be used to lock into this slot for an continuous output process. Managed by the DisplayService
+
                  +
                  <<<
 {{red{WARNING: Naming is currently being discussed (11/08)}}}
@@ -1373,15 +1388,24 @@ Thus, the Proc-Layer exposes (one or several) facade interfaces for the GUI to u
 * GuiFacade is implemented by a class //in core// and exposes a notification proxy implementing GuiNotificationFacade, which actually is wired through the InterfaceSystem to forward to the corresponding implementation facade object within the GUI
 * similarly, starting the fundamental subsystems within proc installs Interfaces into the InterfaceSystem and exposes them through proxy objects
 
+
                  +
                  +
                  +
                  special LayerSeparationInterface which serves the main purpose to load the GuiStarterPlugin, thus bringing up the Lumiera GTK UI at application start.
 
                  Considering how to interface to and integrate with the GUI Layer. Running the GUI is //optional,// but it requires to be [[started up|GuiStart]], installing the necessary LayerSeparationInterfaces. As an example how to integrate the GUI with the lower layers, in 1/2009 we created an PlayerDummy, which "pulls" dummy frames from the (not yet existing) engine and displays them within an XV viewer widget.
                  -
                  +
                  +
                  LayerSeparationInterface provided by the GUI.
+Access point for the lower layers to push information and state changes (aynchronously) to the GUI. Actually, most operations within Lumiera are initiated by the user through the GUI. In the course of such actions, the GUI uses the services of the lower layer and typically recieves an synchronous response. In some exceptional cases, these operations may cause additional changes to happen asynchronously from the GUI's perspective. For example, an edit operation might trigger a re-build of the low-level model, which then detects an error.
+
                  +
                  +
                  Starting up the GUI is optional and is considered part of the Application start/stop and lifecycle.
-* main and AppState activate the lifecyle methods on the ~GuiSubsysDescriptor
+* main and AppState activate the lifecyle methods on the ~GuiSubsysDescriptor, accessible via the GuiFacade
 * loading a GuiStarterPlugin actually
 ** loads the GUI (shared lib)
 ** creates instances of all the GUI services available through LayerSeparationInterfaces
@@ -1400,6 +1424,10 @@ Note that we retain strict isolation in the other direction: no part of the lowe
 Now, when invoking an operation on some public interface, the code in the lower layers actually executes an implementation of this operation //on the facade proxy,// which in turn forwards the call through the CL interface into the GUI, where it is actually implemented by the corresponding service object instance.
                  +
                  +
                  A specially configured LumieraPlugin, which actually contains or loads the complete code of the (GTK)GUI, and additionally is linked dynamically against the application core lib. During the [[UI startup process|GuiStart]], loading of this Plugin is triggered from {{{main()}}}. Actually this causes spawning of the GTK event thread and execution of the GTK main loop.
+
                  +
                  While the low-level model holds the data used for carrying out the actual media data processing (=rendering), the high-level model is what the user works upon when performing edit operations through the GUI (or script driven in &raquo;headless mode&laquo;). Its building blocks and combination rules determine largely what structures can be created within the [[Session]].
 On the whole, it is a collection of [[media objects|MObjects]] stuck together and arranged by [[placements|Placement]].
@@ -1437,7 +1465,7 @@ Besides routing to a global pipe, wiring plugs can also connect to the source po
 Finally, this example shows an ''automation'' data set controlling some parameter of an effect contained in one of the global pipes. From the effect's POV, the automation is simply a ParamProvider, i.e a function yielding a scalar value over time. The automation data set may be implemented as a bézier curve, or by a mathematical function (e.g. sine or fractal pseudo random) or by some captured and interpolated data values. Interestingly, in this example the automation data set has been placed relatively to the meta clip (albeit on another track), thus it will follow and adjust when the latter is moved.
                  -
                  +
                  This wiki page is the entry point to detail notes covering some technical decisions, details and problems encountered in the course of the implementation of the Lumiera Renderengine, the Builder and the related parts.
 
 * [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
@@ -1458,6 +1486,7 @@ Finally, this example shows an ''automation'' data set controlling some paramete
 * how to classify and [[describe media stream types|StreamType]] and how to [[use them|StreamTypeUse]]
 * the relation of [[Project, Timelines and Sequences|TimelineSequences]]
 * how to [[start the GUI|GuiStart]] and how to [[communicate|GuiCommunication]]
+* build the first LayerSeparationInterfaces
                  @@ -1782,6 +1811,16 @@ config.formatters.push( { } ) //}}}
                  +
                  +
                  An RAII class, used to manage a [[facade interface between layers|LayerSeparationInterface]].
+The InstanceHandle is created by the service implementation and will automatically
+* either register and open a ''C Language Interface'', using Lumiera's InterfaceSystem
+* or load and open a LumieraPlugin, also by using the InterfaceSystem
+* and optionally also create and manage a facade proxy to allow transparent access for client code
+
+&rarr; see [[detailed description here|LayerSeparationInterfaces]]
+
                  +
                  Because we rely on strong decoupling and separation into self contained components, there is not much need for a common quasi-global namespace. Operations needing the cooperation of another subsystem will be delegated or even dispatched, consequently implementation code needs only the service acces points from "direct cooperation partner" subsystems. Hierarchical scopes besides classes are needed only when multiple subsystems share a set of common abstractions. Interface and Implementation use separate namespaces.
 
@@ -1814,18 +1853,41 @@ From experiences with other middle scale projects, I prefer having the test code
 [img[Example: Interfaces/Namespaces of the ~Session-Subsystems|uml/fig130053.png]]
                  -
                  -
                  Lumiera uses a 3-layered architecture. Separation between layers is crucial. Any communication between the layers regarding the normal operation of the application should //at least be initiated// through ''Layer abstraction interfaces''. This is a low-impact version of layering, because, aside from this triggering, direct cooperation of parts within the single Lumiera process is allowed, under the condition that is is implemented using additional abstractions (interfaces with implementation level granularity). We stick to the policy of //disallowing direct coupling of implementations located in different layers.//
+
                  
+
                  A major //business interfaces// &mdash; used by the layers for interfacing to each other; also to be invoked externally by scripts.
+&rarr; [[overfiew and technical details|LayerSeparationInterfaces]]
+
                  
+
                  
+
                  
+
                  Lumiera uses a 3-layered architecture. Separation between layers is crucial. Any communication between the layers regarding the normal operation of the application should //at least be initiated// through ''Layer abstraction interfaces'' (Facade Interfaces). This is a low-impact version of layering, because, aside from this triggering, direct cooperation of parts within the single Lumiera process is allowed, under the condition that is is implemented using additional abstractions (interfaces with implementation level granularity). We stick to the policy of //disallowing direct coupling of implementations located in different layers.//
 
+[>img[Anatomy of a Layer Separation Interface|uml/fig132869.png]]
+The goal is for the interface to remain fairly transparent for the client and to get an automatic lifecycle management. 
 To implement such a structure, each layer separation interface actually is comprised of several parts:
-* an C Language Interface ("CL Interface") to be installed into the InterfaceSystem
-* a facade interface defining the respective abstractions in terms of the implementation language (C or C++)
-* a implementation object on the service proiding side which is directly addressed by the implementation instantiated within the InterfaceSystem
-* a proxy object on the client side, which usually is given inline alongside with the CLI interface definition.
+* an C Language Interface ("''CL Interface''") to be installed into the InterfaceSystem
+* a ''facade interface'' defining the respective abstractions in terms of the client side impl. language (C or C++)
+* a ''service implementation'' directly addressed by the implementation instantiated within the InterfaceSystem
+* a ''facade proxy'' object on the client side, which usually is given inline alongside with the CL interface definition.
 
 !opening and closing
 Handling the lifecycle can be tricky, because client- and service-side need to carry out the opening and closing operations in sync and observing a specific call order to ensure calls get blocked already on the client side unless the whole interface compound is really up and running. To add to this complexity, plugins and built-in interfaces are handled differently regarding the question who is in charge of the lifecycle: interfaces are installed on the service side, whereas the loading of plugins is triggered from client side by requesting the plugin from the loader.
-Anyway, interfaces are resources which best should be managed automatically. At least within the C++ part of the application we can ensure this by using a handle class. This way the handling of plugins and interfaces can be unified; the only remaining difference is on what side (client or service provider side) the handle is instantiated, with the appropriate ctor parameters.
+Anyway, interfaces are resources which best should be managed automatically. At least within the C++ part of the application we can ensure this by using the InstanceHandle template. This way the handling of plugins and interfaces can be unified and the opening and closing of the facade proxy happens automatically.
+
+The general idea is, that each facade interface actually provides access to a specific service; there will always be a single implementation object somewhere, which can be thought of as acting as "the" service. This service-providing object will then contain the mentioned InstanceHandle; thus, its lifecycle becomes identical with the service lifecycle.
+* when the service relies on a [[plugin|LumieraPlugin]], this service providing object (containing the InstanceHandle) needs to sit at the service accessing side (as the plugin may not yet be loaded and someone has to pull it up).
+* otherwise, when the service is just an interface to an already loaded facility, the service providing object (containing the InstanceHandle) will live on the service providing side, not the client side. Then the ctor of the service providing object needs to be able to access an interface instance definition (&rarr; InterfaceSystem); the only difference to the plugin case is to create the InstanceHandle with a different ctor, passing the interface and the implementing instance.
+
+!outline of the major interfaces
+|!Layer|>|!Interface |
+|GUI|GuiFacade|UI lifecycle &rarr; GuiStart|
+|~|GuiNotificationFacade|status/error messages, asynchronous object status change notifications, trigger shutdown|
+|~|DisplayFacade|pushing frames to a display/viewer|
+|Proc|SessionFacade|session lifecycle|
+|~|EditFacade|edit operations, object mutations|
+|~|PlayerDummy|player mockup, maybe move to backend?|
+|//Lumiera's major interfaces//|c
+
+
 
                  
 
                  
 
                  
@@ -2797,25 +2859,29 @@ We need a way of addressing existing [[pipes|Pipe]]. Besides, as the Pipes and T
 <<tasksum end>>
                  -
                  -
                  Joelholdsworth and Ichthyo created this player mockup in 1/2009 to find out about the implementation details regarding integration and colaboration between the layers. There is no working render engine yet, thus we use a ~DummyImageGenerator for creating faked yuv frames to display. Within the GUI, there is a ~PlaybackController hooked up with the transport controls on the timeline pane.
+
                  
+
                  __Joelholdsworth__ and __Ichthyo__ created this player mockup in 1/2009 to find out about the implementation details regarding integration and colaboration between the layers. There is no working render engine yet, thus we use a ~DummyImageGenerator for creating faked yuv frames to display. Within the GUI, there is a ~PlaybackController hooked up with the transport controls on the timeline pane.
 # first everything was contained within ~PlaybackController, which spawns a thread for periodically creating those dummy frames
 # then, a ~PlayerService was factored out, now implemented within Proc-Layer (probably to be relocated into the backend for the final version). A new LayerSeparationInterface called ''~DummyPlayer'' was created and set up as a [[Subsystem]] within main().
 # the next step was to support multiple playback processes going on in parallel. Now, the ~PlaybackController holds an smart-handle to the ~PlayProcess currently generating output for this viewer, and invokes the transport control functions and the pull frame call on this handle.
-# then, also the tick generation (and thus the handling of the thread which pulls the frames) was factored out and pushed down into the mentioned ~PlayProcess. For this to work, the ~PlaybackController now makes a display slot available on the public GUI DisplayFacade interface.
+# then, also the tick generation (and thus the handling of the thread which pulls the frames) was factored out and pushed down into the mentioned ~PlayProcess. For this to work, the ~PlaybackController now makes a display slot available on the public GUI DisplayFacade interface, so the ~PlayProcessImpl can push up the frames for display within the GUI
 [img[Overview to the dummy player operation|draw/PlayerArch1.png]]
 
 !when playing...
-As a prerequisite, a viewer has to be prepared within the GUI. A XV video display widget is wired up to a sigc++ signal slot, using the Glib::Dispatcher to forward calls from the play process thread to the GTK main event loop thread. When doing so, additionally a Displayer slot is created with the DisplayService.
+As a prerequisite, a viewer has to be prepared within the GUI. A XV video display widget is wired up to a sigc++ signal slot, using the Glib::Dispatcher to forward calls from the play process thread to the GTK main event loop thread. All of this wiring actually is encapsulated as a DisplayerSlot, created and registered with the DisplayService.
 
-When starting playback, the slot handle created by these preparations is used to create a ~PlayProcess on the ~DummyPlayer interface. Actually
+When starting playback, the display slot handle created by these preparations is used to create a ~PlayProcess on the ~DummyPlayer interface. Actually
 * a ~PlayProcessImpl object is created down within the player implementation
-* this uses the slot handle to actually allocate the display slot via the Display facade
-* moreover, it aquires an TickService instance, which is still trotteling (not calling the periodic callback)
+* this uses the provided slot handle to actually //allocate// the display slot via the Display facade. Here, //allocating// means registering and preparing it for output by //one single// ~PlayProcess. For the latter, this allocation yields an actually opened display handle.
+* moreover, the ~PlayProcessImpl aquires an TickService instance, which is still trotteling (not calling the periodic callback)
+* probably, a real player at this point would initiate a rendering process, so he can fetch the actual output frames periodically.
 * on the "upper" side of the ~DummyPlayer facade, an lib::Handle object is created to track and manage this ~PlayProcesImpl instance
-The handle is returned to the ~PlaybackController within the GUI, which uses this handle for all further interactions with the Player. The handle is ref counting and has value semantics, so it can be stored away, passed as parameter and so on. All such handles corresponding to one ~PlayProcess form a family; when the last goes out of scope, the ~PlayProcess terminates and deallocates any resources. Conceptually, this corresponds to pushing the "stop" button. Handles can be deliberately disconnected by calling {{{handle.close()}}} &mdash; this has the same effect as deleting a handle (when all are closed or deleted the process ends).
+The mentioned handle is returned to the ~PlaybackController within the GUI, which uses this handle for all further interactions with the Player. The handle is ref counting and has value semantics, so it can be stored away, passed as parameter and so on. All such handles corresponding to one ~PlayProcess form a family; when the last goes out of scope, the ~PlayProcess terminates and deallocates any resources. Conceptually, this corresponds to pushing the "stop" button. Handles can be deliberately disconnected by calling {{{handle.close()}}} &mdash; this has the same effect as deleting a handle (when all are closed or deleted the process ends).
 
-All the other play control operations are simply forwarded via the handle and the ~PlayProcessImpl. For example, "pause" corresponds to setting the tick frequency to 0 (thus temporarily discontinuing the tick callbacks). When allocating the display slot in the course of creating the ~PlayProcessImpl, the latter only accesses the Display facade. It can't access the display or viewer directly, because the GUI lives within an plugin; lower layers can't call directly into GUI functions. Thus, within the Display facade a functor (proxy) is created to represent the output sink. This (proxy) Displayer can be used within the implementation of the perodic callback function. As usual, the implementation of the (proxy) Displayer can be inlined and doesn't create an indirection at runtime. Thus, each frame output call has to pass though two indirections: the function pointer in the Display facade interface, and the Glib::Dispatcher.
+All the other play control operations are simply forwarded via the handle and the ~PlayProcessImpl. For example, "pause" corresponds to setting the tick frequency to 0 (thus temporarily discontinuing the tick callbacks). When allocating the display slot in the course of creating the ~PlayProcessImpl, the latter only accesses the Display facade. It can't access the display or viewer directly, because the GUI lives within an plugin; lower layers aren't allowed to call GUI implementation functions directly. Thus, within the Display facade a functor (proxy) is created to represent the output sink. This (proxy) Displayer can be used within the implementation of the perodic callback function. As usual, the implementation of the (proxy) Displayer can be inlined and doesn't create runtime overhead. Thus, each frame output call has to pass though two indirections: the function pointer in the Display facade interface, and the Glib::Dispatcher.
+
+!rationale
+There can be multiple viewer widgets, to be connected dynamically to multiple play-controllers. (the latter are associated with the timeline(s)). Any playback can require multiple playback processes to work in parallel. The playback controller(s) should not be concerned with managing the play processes, which in turn should neither care for the actual rendering, nor manage the display frequency and synchronisation issues. Moreover, the mentioned parts live in different layers and especially the GUI needs to remain separated from the core. And finally, in case of a problem within one play process, it should be able to unwind automatically, without interfering with other ongoing play processes.
 
                  
 
                  
 
                  
@@ -4823,6 +4889,14 @@ function addKeyDownHandlers(e)
 }
 //}}}
                  +
                  +
                  A service generating //periodic ticks// &mdash; repetedly invoking a callback with a given frequency.
+* defined 1/2009 as part of the PlayerDummy (design sketch)
+* probably to be implemented later on based on Posix timers
+* will probably be later on integrated into a synchronisation framework (display sync, audio sync, MTC master/slave...)
+
+
                  +
                  http://tiddlywiki.com/
                  @@ -5075,6 +5149,9 @@ Wiring requests are small stateful value objects. They will be collected, sorted [[Automation]] is treated as a function over time. Everything beyond this definition is considered an implementation detail of the [[parameter provider|ParamProvider]] used to yield the value. Thus automation is closely tied to the concept of a [[Parameter]], which also plays an important role in the communication with the GUI and while [[setting up and wiring the render nodes|BuildRenderNode]] in the course of the build process (&rarr; see [[tag:Builder|Builder]])
                  +
                  +
                  Definition of commonly used terms and facilities...
                  +