fix **** in doxygen comments

to make them stand out more prominently, some entity comments
where started with a line of starts. Unfortunately, doxygen
(and javadoc) only recogise comments which are started exactly
with /**

This caused quite some comments to be ignored by doxygen.
Credits to Hendrik Boom for spotting this problem!

A workaround is to end the line of stars with *//**

src/backend/engine/scheduler-diagnostics.hpp

@@ -56,7 +56,7 @@ namespace engine {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * Render engine diagnostic facility. Creating an instance
    * will activate additional tracing and diagnostic facilities
    * within the scheduler implementation; results may be investigated

src/backend/enginefacade.hpp

@@ -32,7 +32,7 @@
 namespace backend {
   
   
-  /******************************************************************
+  /**************************************************************//**
    * Interface to the backend layer (render engine subsystem):
    * Global access point for starting the render engine subsystem and
    * for defining the public interface(s) for talking with the engine.

src/backend/media-access-facade.hpp

@@ -42,7 +42,7 @@ namespace backend {
   struct ChanDesc;
   
   
-  /******************************************************************
+  /**************************************************************//**
    * Interface to the backend layer:
    * provides functions for querying (opening) a media file,
    * detecting the channels or streams found within this file etc. 

src/backend/netnodefacade.hpp

@@ -32,7 +32,7 @@
 namespace backend {
   
   
-  /******************************************************************
+  /**************************************************************//**
    * Interface to the backend layer (renderfarm node):
    * Global access point for starting a server listening on a TCP port
    * and accepting render tasks. Possibly such a server could also

src/backend/scriptrunnerfacade.hpp

@@ -32,7 +32,7 @@
 namespace backend {
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * Interface to the backend layer (script runner):
    * Global access point for starting a script within Lumiera application
    * context. 

src/backend/thread-wrapper.hpp

@@ -53,7 +53,7 @@ namespace backend {
   
   
   
-  /****************************************************************************
+  /************************************************************************//**
    * A thin convenience wrapper for dealing with threads,
    * as implemented by the threadpool in the backend (based on pthread).
    * Using this wrapper...

src/common/interface-facade-link.hpp

@@ -65,7 +65,7 @@ namespace facade {
   using lib::Literal;
   
   
-  /************************************************************************
+  /********************************************************************//**
    * simple access-frontend to the implementation of a service (C++ only).
    * Usually, an instance of Accessor is placed as static member right into
    * the facade interface used to access the service. This implementation

src/common/subsystem-runner.hpp

@@ -64,7 +64,7 @@ namespace lumiera {
   }
   
   
-  /*****************************************************************************
+  /*************************************************************************//**
    * Implementation helper for managing execution of a collection of subsystems,
    * which may depend on one another and execute in parallel. Properties of the
    * subsystems are available through Subsys object refs, which act as handle.

src/gui/display-service.hpp

@@ -72,7 +72,7 @@ namespace gui {
   
   
   
-  /********************************************************************
+  /****************************************************************//**
    * Actual implementation of a single displayer slot. Internally,
    * it is connected via the Glib::Dispatcher for outputting frames 
    * to a viewer widget, which executes within the GTK event thread.
@@ -109,7 +109,7 @@ namespace gui {
   
   
   
-  /******************************************************
+  /**************************************************//**
    * Actual implementation of the DisplayService.
    * Creating an instance of this class automatically
    * registers the interface lumieraorg_Display with

src/gui/guifacade.hpp

@@ -51,7 +51,7 @@ namespace gui {
   
   
   
-  /*********************************************************************
+  /*****************************************************************//**
    * Global access point for loading and starting up the Lumiera GTK GUI
    * and for controlling the GUI lifecycle. The implementation part of
    * this class also is responsible for making the "business" interface

src/gui/guistart.cpp

@@ -79,7 +79,7 @@ namespace gui {
   
   namespace { // implementation details
     
-    /******************************************************************************
+    /**************************************************************************//**
      * Implement the necessary steps for actually making the Lumiera Gui available.
      * Open the business interface(s) and start up the GTK GUI main event loop.
      */

src/gui/notification-service.hpp

@@ -49,7 +49,7 @@ namespace gui {
   
   
   
-  /******************************************************
+  /**************************************************//**
    * Actual implementation of the GuiNotification service
    * within the Lumiera GTK GUI. Creating an instance of
    * this class automatically registers the interface

src/include/config-facade.h

@@ -55,7 +55,7 @@ namespace lumiera {
   using std::string;
   
   
-  /*********************************************************************
+  /*****************************************************************//**
    * C++ wrapper for convenient access to the Lumiera config system.
    * 
    * @warning Config system not fully implemented yet. Thus for now

src/include/display-facade.h

@@ -60,7 +60,7 @@
 namespace lumiera {
   
   
-  /******************************************************************
+  /**************************************************************//**
    * Interface for outputting frames to an (already allocated) viewer
    * or display. The viewer is addressed by an "slot" handle, which the 
    * client receives from some other public interface. This reflects

src/include/dummy-player-facade.h

@@ -48,7 +48,7 @@ namespace proc   {
 namespace lumiera {
     
     
-    /******************************************************************
+    /**************************************************************//**
      * Experimental Interface Proc-Layer (or maybe the backend?): 
      * Global access point for starting a dummy playback, generating
      * some test image data for the GUI to display in a viewer window.

src/include/guinotification-facade.h

@@ -49,7 +49,7 @@ namespace gui {
   using std::string;
   
   
-  /*********************************************************************
+  /*****************************************************************//**
    * Global access point to push state update and notification of events
    * from the lower layers into the Lumiera GUI. Typically, this happens
    * asynchronously and triggered by events within the lower layers.

src/include/interfaceproxy.hpp

@@ -89,7 +89,7 @@ namespace facade {
   LUMIERA_ERROR_DECLARE(FACADE_LIFECYCLE);  
 
 
-  /*********************************************************************
+  /*****************************************************************//**
    * access-frontend to the implementation of a service.
    * Usually, an instance of Accessor is placed as static member
    * right into the facade interface used to access the service.

src/include/play-facade.h

@@ -59,7 +59,7 @@ namespace lumiera {
   using std::tr1::weak_ptr;
     
     
-    /******************************************************************
+    /**************************************************************//**
      * Interface to the Player subsystem of Lumiera (Proc-Layer).
      * Global access point for starting playback and render processes,
      * calculating media data by running the render engine.

src/lib/error.hpp

@@ -232,7 +232,7 @@ namespace lumiera {
   
 } // namespace lumiera
 
-/******************************************************
+/**************************************************//**
  * convenience shortcut for a sequence of catch blocks
  * just logging and consuming an error. Typically
  * this sequence will be used within destructors,
@@ -255,7 +255,7 @@ namespace lumiera {
 
 
 
-/******************************************************
+/**************************************************//**
  * if NoBug is used, redefine some macros 
  * to rather throw Lumiera Errors instead of aborting
  */

src/lib/hash-indexed.hpp

@@ -123,7 +123,7 @@ namespace lib {
   
   
   
-  /************************************************************
+  /********************************************************//**
    * A Mixin to add a private ID type to the target class,
    * together with storage to hold an instance of this ID,
    * getter and setter, and a templated version of the ID type

src/lib/meta/function-erasure.hpp

@@ -72,7 +72,7 @@ namespace meta{
   
   
   
-  /******************************************************
+  /**************************************************//**
    * Generic wrapper carrying a function object
    * while hiding the actual function signature
    * - create it using a function ref or pointer

src/lib/singleton-ref.hpp

@@ -51,7 +51,7 @@ namespace lib {
   
   namespace singleton {
   
-    /***************************************
+    /***********************************//**
      * Detail/Policy class specifying
      * how the SingletonRef can be accessed
      */
@@ -96,7 +96,7 @@ namespace lib {
   
   
   
-  /*************************************************************
+  /*********************************************************//**
    * Helper template providing singleton access without managing
    * object creation and lifecycle. Just the access to the
    * implementation instance is handled: on creation, access is

src/lib/sync.hpp

@@ -396,7 +396,7 @@ namespace lib {
   using sync::RecursiveLock_Waitable;
   
   
-  /*************************************************************************
+  /*********************************************************************//**
    * Facility for monitor object based locking.
    * To be attached either on a per class base or per object base.
    * Typically, the client class will inherit from this template (but it

src/proc/asset/category.hpp

@@ -55,7 +55,7 @@ namespace asset {
     , META
     };
   
-  /*************************************
+  /************************************************************************************//**
    * Tree like classification of Assets.
    * By virtue of the Category, Assets can be organised in nested bins (folders).
    * This includes the distinction of different kinds of Assets, like Audio, Video, Effects...

src/proc/engine/calc-stream.hpp

@@ -72,7 +72,7 @@ namespace engine{
   
   
   
-  /*********************************************************
+  /*****************************************************//**
    * A calculation stream groups and abstracts a series of
    * calculation jobs, delivering frames into the configured
    * OutputSlot in a timely fashion. Behind the scenes, this

src/proc/engine/diagnostic-buffer-provider.hpp

@@ -53,7 +53,7 @@ namespace engine {
   class TrackingHeapBlockProvider;
   
   
-  /********************************************************************
+  /****************************************************************//**
    * Helper for unit tests: Buffer provider reference implementation.
    * 
    * @todo write type comment

src/proc/engine/engine-diagnostics.hpp

@@ -68,7 +68,7 @@ namespace engine{
   
   
   
-  /******************************************************
+  /**************************************************//**
    * Render engine diagnostic facility. Creating an instance
    * will activate additional tracing facilities within the
    * render engine; results may be investigated through

src/proc/engine/engine-service-mock.hpp

@@ -76,7 +76,7 @@ namespace engine{
   
   
   
-  /****************************************************************
+  /************************************************************//**
    * Variant of the render engine, reconfigured for mock operation.
    * Especially, this setup leaves out most of the actual Lumiera
    * engine's implementation facilities. There is no scheduler

src/proc/engine/engine-service.hpp

@@ -85,7 +85,7 @@ namespace engine{
   
   
   
-  /******************************************************
+  /**************************************************//**
    * A service to schedule series of calculations,
    * delivering the rendered data into an external output
    * sink in a timely fashion. Actually the CalculationStream
@@ -108,7 +108,7 @@ namespace engine{
       
       
     public:
-      /*************************************************************
+      /*********************************************************//**
        * Quality-of-Service definition for an Render Engine usage.
        * This strategy defines how to decide between conflicting goals like
        * - timely delivery

src/proc/engine/worker/dummy-tick.hpp

@@ -53,7 +53,7 @@ namespace node {
   
   
   
-  /************************************************************
+  /********************************************************//**
    * Tick generating service for a periodic callback,
    * with adjustable frequency. Quick'n dirty implementation!
    */

src/proc/engine/worker/tick-service.hpp

@@ -53,7 +53,7 @@ namespace node {
   
   
   
-  /************************************************************
+  /********************************************************//**
    * Tick generating service for a periodic callback,
    * with adjustable frequency. Quick'n dirty implementation!
    */

src/proc/facade.hpp

@@ -43,7 +43,7 @@
 namespace proc {
   
   
-  /*********************************************************************
+  /*****************************************************************//**
    * Global access point for the services implemented by the Proc-Layer.
    * 
    * @todo this is a dummy placeholder as of 1/2009. Currently, there

src/proc/mobject/session/placement-index.cpp

@@ -102,7 +102,7 @@ namespace session {
   typedef PlacementIndex::ID ID;
   
   
-  /*********************************************************************
+  /*****************************************************************//**
    * Storage and implementation backing the PlacementIndex
    * - #placementTab_ is an hashtable mapping IDs to Placement + Scope
    * - #scopeTab_ is an reverse association serving to keep track of 

src/proc/play/dummy-play-connection.hpp

@@ -210,7 +210,7 @@ namespace play {
   }
 
   
-  /********************************************************************
+  /****************************************************************//**
    * Framework for dummy playback and rendering.
    * A DummyPlayConnection provides a coherent set of placeholders,
    * allowing to start a data producing process while leaving out

src/proc/play/dummy-player-service.hpp

@@ -69,7 +69,7 @@ namespace proc {
     
     
     
-    /********************************************************************
+    /****************************************************************//**
      * Actual implementation of a single (dummy) playback process.
      * The DummyPlayerService (see below) maintains a collection of such
      * actively running playback processes, while the client code gets
@@ -117,7 +117,7 @@ namespace proc {
     
     
     
-    /******************************************************
+    /**************************************************//**
      * Actual implementation of the DummyPlayer service.
      * Creating an instance of this class automatically
      * registers the interface lumieraorg_DummyPlayer with

src/proc/play/output-director.hpp

@@ -64,7 +64,7 @@ namespace play {
   
   
   
-  /******************************************************
+  /**************************************************//**
    * Management of external Output connections.
    * 
    * @todo write Type comment

src/proc/play/output-manager.hpp

@@ -58,7 +58,7 @@ namespace play {
   
   
   
-  /******************************************************
+  /**************************************************//**
    * Management of external Output connections.
    * 
    * @todo need a concrete implementation

src/proc/play/output-slot.hpp

@@ -95,7 +95,7 @@ namespace play {
   
   
   
-  /********************************************************************************
+  /****************************************************************************//**
    * Interface: Generic output sink.
    * An OutputSlot represents the possibility to send data through multiple
    * channels to some kind of external sink (video in GUI window, video full screen,

src/proc/play/play-controller.hpp

@@ -48,7 +48,7 @@ namespace play {
   using std::string;
   
   
-  /********************************************************************
+  /****************************************************************//**
    * TODO do we still need that??????
    * Isn't lumiera::Play::Controller already sufficient?
    */

src/proc/play/play-process.hpp

@@ -111,7 +111,7 @@ namespace play {
   typedef std::vector<Feed>         OutputFeeds;
     
   
-  /******************************************************
+  /**************************************************//**
    * Playback/Render process within the Lumiera Player.
    * This is a top-level implementation entity, created
    * by the PlayService when \em performing a timeline

src/proc/play/play-service.hpp

@@ -83,7 +83,7 @@ namespace play {
   
   
   
-  /******************************************************
+  /**************************************************//**
    * Implementation access point: Player subsystem.
    * The PlayService is the primary way for clients to
    * get into using Lumiera's Play/Output Subsystem.

src/proc/play/timings.hpp

@@ -85,7 +85,7 @@ namespace play {
   
   
   
-  /*****************************************************************************
+  /*************************************************************************//**
    * Generic frame timing specification. Defines the expected delivery interval,
    * optionally also the expected quality-of-service (urgency).
    * 

tests/core/backend/engine/job-hash-test.cpp

@@ -39,7 +39,7 @@ namespace test {
   
   
   
-  /***************************************************************************
+  /**********************************************************************//**
    * @test verify the basic properties of the job and job descriptor struct;
    *       especially verify that job data is passed properly back to the
    *       closure and that a identity can be constructed based on a

tests/core/backend/engine/scheduler-interface-test.cpp

@@ -62,7 +62,7 @@ namespace test {
   typedef SchedulerFrontend::JobTransaction JobTransaction;
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test verify and demonstrate the organisation of the high-level interface
    *       for defining jobs to be invoked by the scheduler.
    *       

tests/core/backend/media-access-mock-test.cpp

@@ -44,7 +44,7 @@ namespace test {
   
   
   
-  /********************************************************************************
+  /****************************************************************************//**
    * @test inject a Mock object replacing the backend_interface::MediaAccessFacade.
    *       Verify if the Mock object behaves as expected when calling the Facade.
    */

tests/core/proc/asset/asset-category-test.cpp

@@ -43,7 +43,7 @@ namespace test {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * @test checking the properties of Asset Category structs.
    *       They are included in the Asset::Ident identification tuple
    *       of Assets and can be used to organize Assets into a tree

tests/core/proc/asset/basicpipetest.cpp

@@ -51,7 +51,7 @@ namespace test  {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * @test basic properties of Pipe (structural) Assets.
    *       <ul><li>created by referral</li>
    *           <li>access existing pipe by referral</li>

tests/core/proc/asset/compoundmediatest.cpp

@@ -42,7 +42,7 @@ namespace test {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * Verifying the special operations available for compound media assets
    * comprised of several elementary media assets.
    */

tests/core/proc/asset/create-asset-test.cpp

@@ -45,7 +45,7 @@ namespace test {
 
 
 
-  /***********************************************************************
+  /*******************************************************************//**
    * @test creating new Assets and registering them with the AssetManager.
    * @see  proc_interface::AssetManager#reg
    */

tests/core/proc/asset/deleteassettest.cpp

@@ -37,7 +37,7 @@ namespace test {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test deleting an Asset includes removing all dependent Assets
    *       and all MObjects relying on these. Especially this means
    *       breaking all links between the involved Objects, so the

tests/core/proc/asset/dependent-assets-test.cpp

@@ -43,7 +43,7 @@ namespace test {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test the handling of Assets dependent on other Assets and the
    *       enabling/disabling of Assets.
    * @see  asset::Asset

tests/core/proc/asset/entry-id-test.cpp

@@ -66,7 +66,7 @@ namespace test {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test proof-of-concept test for a combined symbolic and hash based ID.
    *       - create some symbolic IDs 
    *       - check default assignment works properly

tests/core/proc/asset/identityofassetstest.cpp

@@ -45,7 +45,7 @@ namespace test {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * @test creating several Assets and checking object identity,
    *       detection of duplicates and version handling.
    * @see  proc_interface::AssetManager#reg

tests/core/proc/asset/makecliptest.cpp

@@ -47,7 +47,7 @@ namespace test {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * @test creating a Clip MObject and an associated Clip Asset from 
    *       a given asset::Media.
    * @see  asset::Media#createClip

tests/core/proc/asset/mediastructurequerytest.cpp

@@ -41,7 +41,7 @@ namespace test {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * This test documents the Interface used by MediaFactory when loading
    * media files for querying Lumiera's backend layer for information
    * on how the media file is structured.

tests/core/proc/asset/meta/time-grid-basics-test.cpp

@@ -61,7 +61,7 @@ namespace test {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test build some simple time grids and verify their behaviour
    *       for quantising (grid aligning) time values.
    * 

tests/core/proc/asset/orderingofassetstest.cpp

@@ -44,7 +44,7 @@ namespace test {
   
   
   
-  /******************************************************
+  /**************************************************//**
    * @test validate the equality and order relations of 
    *       Asset::Ident and Asset objects.
    * @note a known problem is that only Asset smart ptrs

tests/core/proc/asset/typed-id-test.cpp

@@ -99,7 +99,7 @@ namespace test {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test outline of an instance registration and accounting service.
    *       The service is self-contained and supports automatic registration
    *       and deregistration. The instance access is configurable on a 

tests/core/proc/control/argument-tuple-accept-test.cpp

@@ -91,7 +91,7 @@ namespace test    {
   
   
   
-  /*************************************************************
+  /*********************************************************//**
    * @test Build a test object, which accepts a bind(...) call
    *       with specifically typed arguments.
    *       

tests/core/proc/control/command-argument-test.cpp

@@ -186,7 +186,7 @@ namespace test    {
   
   typedef lib::ScopedPtrVect<CmdClosure> ArgTuples;
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test Check storage handling of the command parameters and state memento.
    *
    * @see  control::CommandArgumentHolder

tests/core/proc/control/command-basic-test.cpp

@@ -68,7 +68,7 @@ namespace test    {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test basic usage of the Proc-Layer command dispatch system.
    *       Shows how to define a simple command inline and how to
    *       trigger execution and UNDO. Verifies the command action

tests/core/proc/control/command-binding-test.cpp

@@ -42,7 +42,7 @@ namespace test    {
   
   
   
-  /*****************************************************************************
+  /*************************************************************************//**
    * @test coverage for some specific situations when binding command arguments.
    * 
    * @todo add more test cases...

tests/core/proc/control/command-clone-builder-test.cpp

@@ -52,7 +52,7 @@ namespace test    {
   
   
   
-  /********************************************************************************
+  /****************************************************************************//**
    * @test check creation of a command implementation clone from top level,
    *       without disclosing specific type information about the involved closure.
    *       This includes verifying sane allocation management.

tests/core/proc/control/command-equality-test.cpp

@@ -90,7 +90,7 @@ namespace test    {
   
   
   
-  /*****************************************************************************************
+  /*************************************************************************************//**
    * @test cover command equality detection. Two commands are deemed equivalent, if they
    *       - build on the same Mutation functors
    *       - are either both incomplete or

tests/core/proc/control/command-mutation-test.cpp

@@ -69,7 +69,7 @@ namespace test    {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * Verify the behaviour of the type erased closure, which is used
    * by Proc-Layer commands to implement the capturing and later
    * re-invocation of a function.

tests/core/proc/control/command-registry-test.cpp

@@ -51,7 +51,7 @@ namespace test    {
   
   
   
-  /*******************************************************************************
+  /***************************************************************************//**
    * @test verify sane behaviour of the relevant operations on the CommandRegistry
    *       interface. Add/remove a command instance to the index, allocate an
    *       CommandImpl frame and verify it is removed properly on ref count zero.

tests/core/proc/control/command-use1-test.cpp

@@ -49,7 +49,7 @@ namespace test    {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test command usage aspects I: defining commands in various ways,
    *       then re-accessing those definitions, create instances,
    *       invoke them and undo the effect. Clean up finally.

tests/core/proc/control/command-use2-test.cpp

@@ -71,7 +71,7 @@ namespace test    {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test command usage aspects II: patterns of invoking commands.
    * 
    * @todo this test is still on hold, as the non-trivial patterns aren't implemented as of 10/09

tests/core/proc/control/command-use3-test.cpp

@@ -60,7 +60,7 @@ namespace test    {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test command usage aspects III: elaborate handling patterns, like e.g.
    *       asynchronous or repeated invocation and command sequence bundles.
    *

tests/core/proc/control/handling-pattern-basics-test.cpp

@@ -55,7 +55,7 @@ namespace test    {
   
   
   
-  /**********************************************************************************
+  /******************************************************************************//**
    * @test operate and verify a simple dummy command handling pattern.
    * @note this test covers mainly the behaviour of a handling pattern as a concept,
    *       not so much the behaviour of the (standard) handling pattern implementations.

tests/core/proc/control/handling-pattern-standard-impl-test.cpp

@@ -83,7 +83,7 @@ namespace test    {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * @test verify correct behaviour of all the command handling patterns
    *       provided by the default configuration of a lumiera session.
    *       - executing quasi synchronous

tests/core/proc/control/memento-tie-test.cpp

@@ -65,7 +65,7 @@ namespace test    {
   
   
   
-  /*****************************************************************************************
+  /*************************************************************************************//**
    * @test Verify the state capturing mechanism (memento), which is used to implement
    * the Undo() functionality for Proc-Layer commands. Bind an undo function and a state
    * capturing function and wire up both to store and retrieve a memento value. 

tests/core/proc/engine/buff-table-test.cpp

@@ -122,7 +122,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test create a random pattern of recursive invocations, each
    *       allocating a chunk out of a global buffer table storage.
    *       After returning, each allocation should be cleanly

tests/core/proc/engine/buffer-metadata-key-test.cpp

@@ -155,7 +155,7 @@ namespace test  {
   
   
   
-  /***********************************************************************
+  /*******************************************************************//**
    * @test verify calculation and relations of Buffer metadata type keys.
    *       These are used internally within the standard implementation
    *       of BufferProvider to keep track of various kinds of buffers,

tests/core/proc/engine/buffer-metadata-test.cpp

@@ -74,7 +74,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test verify the properties of the BufferMetadata records used
    *       internally within BufferProvider to attach additional
    *       organisational data to the exposed buffers.

tests/core/proc/engine/buffer-provider-protocol-test.cpp

@@ -61,7 +61,7 @@ namespace test  {
   }
   
   
-  /******************************************************************************
+  /**************************************************************************//**
    * @test verify and demonstrate the usage cycle of data buffers for the engine
    *       based on the BufferProvider interface. This is kind of a "dry run"
    *       for documentation purposes, because the BufferProvider implementation

tests/core/proc/engine/calc-stream-test.cpp

@@ -45,7 +45,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test detailed coverage of the various CalcStream flavours
    *       supported by the render engine interface.
    * 

tests/core/proc/engine/dispatcher-interface-test.cpp

@@ -143,7 +143,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test document and verify the engine::Dispatcher interface, used
    *       to translate a CalcStream into individual node jobs.
    *       This test covers the definition of the interface itself,

tests/core/proc/engine/engine-interface-test.cpp

@@ -63,7 +63,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test cover the basic service exposed at the engine interface:
    *       create a calculation stream and verify the translation
    *       into individual jobs.

tests/core/proc/engine/node-basic-test.cpp

@@ -71,7 +71,7 @@ namespace test  {
   }
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test basic render node properties and behaviour.
    */
   class NodeBasic_test : public Test

tests/core/proc/engine/node-fabrication-test.cpp

@@ -39,7 +39,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test creating and wiring various kinds of render nodes.
    */
   class NodeFabrication_test : public Test

tests/core/proc/engine/node-operation-test.cpp

@@ -39,7 +39,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test check render node operation modes and collaboration.
    */
   class NodeOperation_test : public Test

tests/core/proc/engine/node-source-test.cpp

@@ -39,7 +39,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test the source reading render node.
    */
   class NodeSource_test : public Test

tests/core/proc/engine/testframe-test.cpp

@@ -56,7 +56,7 @@ namespace test  {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test verify test helper for engine tests: a dummy data frame.
    *       TestFrame instances can be created right away, without any
    *       external library dependencies. A test frame is automatically

tests/core/proc/engine/tracking-heap-block-provider-test.cpp

@@ -66,7 +66,7 @@ namespace test  {
   }
   
   
-  /**********************************************************************
+  /******************************************************************//**
    * @test verify a test support facility, used to write mock components
    *       to test the lumiera engine. The TrackingHeapBlockProvider is a
    *       braindead implementation of the BufferProvider interface: it just

tests/core/proc/mobject/builder/buildertooltest.cpp

@@ -94,7 +94,7 @@ namespace test    {
       
       
       
-      /*************************************************************************************
+      /*********************************************************************************//**
        * @test the generic visitor pattern specialised for treating MObjects in the builder.
        * Besides using existing MObject types (at the moment session::Clip),
        * we create a yet-unknown new MObject subclass. When passing such to any

tests/core/proc/mobject/builder/buildsegmenttest.cpp

@@ -40,7 +40,7 @@ namespace test {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test the builder core functionality: create a render pipeline
    *       for a given segment of the Session/Timeline.
    */

tests/core/proc/mobject/builder/fixture-change-detector-test.cpp

@@ -82,7 +82,7 @@ namespace test  {
   
   
   
-  /*********************************************************************************
+  /*****************************************************************************//**
    * @test TODO blubb
    *       
    * @see  mobject::builder::FixtureChangeDetector

tests/core/proc/mobject/builder/model-port-registry-test.cpp

@@ -90,7 +90,7 @@ namespace test  {
   
   
   
-  /*********************************************************************************
+  /*****************************************************************************//**
    * @test create a standalone model port registry to verify the behaviour of
    *       model ports, accessed through reference handles. This test provides an
    *       example setup detached from the real usage situation within the builder.

tests/core/proc/mobject/builder/segmentation-datastructure-test.cpp

@@ -82,7 +82,7 @@ namespace test  {
   
   
   
-  /*********************************************************************************
+  /*****************************************************************************//**
    * @test TODO blubb
    *       
    * @see  mobject::builder::FixtureChangeDetector

tests/core/proc/mobject/controller/rendersegmenttest.cpp

@@ -40,7 +40,7 @@ namespace test {
   
   
   
-  /********************************************************************
+  /****************************************************************//**
    * @test create a render process from a given segment of the Session.
    *       Basically this includes cooperation of all parts of the
    *       Lumiera Proc Layer. For a prepared test-Session we invoke the

tests/core/proc/mobject/mobject-interface-test.cpp

@@ -68,7 +68,7 @@ namespace test    {
   typedef TestPlacement<DummyMO> PDummy;
   
   
-  /*********************************************************************************
+  /*****************************************************************************//**
    * @test cover the common behaviour of all MObjects. 
    * @note the MObject interface is still very preliminary (as of 10/10).
    *       It is expected to support some kind of metadata and object serialisation

tests/core/proc/mobject/mobject-ref-test.cpp

@@ -84,7 +84,7 @@ namespace test    {
   
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test properties and behaviour of the external reference-mechanism for
    *       MObjects placed into the session. We create a simple, simulated
    *       "session" (no real session datastructure) and a mock PlacementIndex.

tests/core/proc/mobject/output-mapping-test.cpp

@@ -45,7 +45,7 @@ namespace test {
   typedef asset::ID<Pipe> PID;
   
   
-  /*********************************************************************************
+  /*****************************************************************************//**
    * @test create a synthetic / example mapping to verify generic mapping behaviour.
    *       We're creating a custom mapping type here, for this test only: The
    *       struct DummyDef provides a "definition context" for this custom mapping

tests/core/proc/mobject/placement-basic-test.cpp

@@ -48,7 +48,7 @@ namespace test    {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test basic behaviour of Placements and access to MObjects.
    * @see  mobject::Placement
    * @see  mobject::MObject#create

tests/core/proc/mobject/placement-hierarchy-test.cpp

@@ -55,7 +55,7 @@ namespace test    {
   using lumiera::error::LUMIERA_ERROR_ASSERTION;
   
   
-  /***************************************************************************************
+  /***********************************************************************************//**
    * @test creating placements specifically typed, forming an hierarchy of placement types
    *       which loosely mirrors the hierarchy of the pointee types. Assignments between
    *       placement of differing type, while still sharing ownership.

tests/core/proc/mobject/placement-object-identity-test.cpp

@@ -52,7 +52,7 @@ namespace test    {
   
 
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test verify correct handling of object identity. Create test objects,
    *       add placements to a dummy index/session, then create PlacementRef
    *       and MObjectRef handles. Finally do cross comparisons.

tests/core/proc/mobject/placement-ref-test.cpp

@@ -51,7 +51,7 @@ namespace test    {
   typedef PlacementMO::ID P_ID;
   
   
-  /***************************************************************************
+  /***********************************************************************//**
    * @test properties and behaviour of the reference-mechanism for Placements.
    *       We create an mock placement index and install it to be used
    *       by all PlacementRef instances while conducting this test.

tests/core/proc/mobject/session/addcliptest.cpp

@@ -44,7 +44,7 @@ namespace test {
   
   
   
-  /*******************************************************************
+  /***************************************************************//**
    * @test adding an test clip to the Model/Session.
    * @see  mobject::session::Clip
    * @see  mobject::Session

tests/core/proc/mobject/session/defs-manager-impl-test.cpp

@@ -81,7 +81,7 @@ namespace test    {
   
   
   
-  /************************************************************************
+  /********************************************************************//**
    * @test verify some general assumptions regarding implementation details
    *       of the the defaults manager.
    * @see  DefsManager_test for the "big picture"