Project: update and clean-up Doxygen configuration

...in an attempt to clarify why numerous cross links are not generated.
In the end, this attempt was not very successful, yet I could find some breadcrumbs...

- file comments generally seem to have a problem with auto link generation;
  only fully qualified names seem to work reliably

- cross links to entities within a namespace do not work,
  if the corresponding namespace is not documented in Doxygen

- documentation for entities within anonymous namespaces
  must be explicitly enabled. Of course this makes only sense
  for detailed documentation (but we do generate detailed
  documentation here, including implementation notes)

- and the notorious problem: each file needs a valid @file comment

- the hierarchy of Markdown headings must be consistent within each
  documentation section. This entails also to individual documented
  entities. Basically, there must be a level-one heading (prefix "#"),
  otherwise all headings will just disappear...

- sometimes the doc/devel/doxygen-warnings.txt gives further clues

doc/devel/.gitignore

@@ -1,5 +1,5 @@
 ,doxylog
-warnings.txt
+doxygen-warnings.txt
 doxygen_sqlite3.db
 lumiera.tag
 html/*

doc/devel/Doxyfile

@@ -1,4 +1,4 @@
-# Doxyfile 1.8.1.2
+# Doxyfile 1.8.13
 
 #---------------------------------------------------------------------------
 # Project related configuration options
@@ -6,10 +6,11 @@
 DOXYFILE_ENCODING      = UTF-8
 PROJECT_NAME           = Lumiera
 PROJECT_NUMBER         = 0.pre.03
-PROJECT_BRIEF          = »edit your freedom«
+PROJECT_BRIEF          = "»edit your freedom«"
 PROJECT_LOGO           = draw/rendered/LumiLogo-small.png
 OUTPUT_DIRECTORY       =
 CREATE_SUBDIRS         = NO
+ALLOW_UNICODE_NAMES    = NO
 OUTPUT_LANGUAGE        = English
 BRIEF_MEMBER_DESC      = YES
 REPEAT_BRIEF           = YES
@@ -38,24 +39,33 @@ INHERIT_DOCS           = YES
 SEPARATE_MEMBER_PAGES  = NO
 TAB_SIZE               = 4
 ALIASES                =
+OPTIMIZE_OUTPUT_FOR_C  = NO
+OPTIMIZE_OUTPUT_JAVA   = NO
 EXTENSION_MAPPING      =
-AUTOLINK_SUPPORT       = YES
 MARKDOWN_SUPPORT       = YES
+TOC_INCLUDE_HEADINGS   = 2
+AUTOLINK_SUPPORT       = YES
 BUILTIN_STL_SUPPORT    = YES
+CPP_CLI_SUPPORT        = NO
+IDL_PROPERTY_SUPPORT   = NO
 DISTRIBUTE_GROUP_DOC   = NO
+GROUP_NESTED_COMPOUNDS = NO
 SUBGROUPING            = YES
 INLINE_GROUPED_CLASSES = NO
 INLINE_SIMPLE_STRUCTS  = YES
 TYPEDEF_HIDES_STRUCT   = YES
+LOOKUP_CACHE_SIZE      = 2
+
 #---------------------------------------------------------------------------
 # Build related configuration options
 #---------------------------------------------------------------------------
-EXTRACT_ALL            = YES
+EXTRACT_ALL            = NO
 EXTRACT_PRIVATE        = YES
-EXTRACT_PACKAGE        = NO
+EXTRACT_PACKAGE        = YES
 EXTRACT_STATIC         = YES
 EXTRACT_LOCAL_CLASSES  = YES
-EXTRACT_ANON_NSPACES   = NO
+EXTRACT_LOCAL_METHODS  = YES
+EXTRACT_ANON_NSPACES   = YES
 HIDE_UNDOC_MEMBERS     = NO
 HIDE_UNDOC_CLASSES     = NO
 HIDE_FRIEND_COMPOUNDS  = NO
@@ -64,6 +74,7 @@ INTERNAL_DOCS          = YES
 CASE_SENSE_NAMES       = YES
 HIDE_SCOPE_NAMES       = YES
 SHOW_INCLUDE_FILES     = YES
+SHOW_GROUPED_MEMB_INC  = NO
 FORCE_LOCAL_INCLUDES   = YES
 INLINE_INFO            = YES
 SORT_MEMBER_DOCS       = NO
@@ -75,26 +86,30 @@ STRICT_PROTO_MATCHING  = NO
 GENERATE_TODOLIST      = YES
 GENERATE_TESTLIST      = YES
 GENERATE_BUGLIST       = NO
-GENERATE_DEPRECATEDLIST= NO
+GENERATE_DEPRECATEDLIST= YES
 ENABLED_SECTIONS       =
-MAX_INITIALIZER_LINES  = 0
+MAX_INITIALIZER_LINES  = 50
 SHOW_USED_FILES        = YES
 SHOW_FILES             = YES
 SHOW_NAMESPACES        = YES
 FILE_VERSION_FILTER    =
 LAYOUT_FILE            =
+CITE_BIB_FILES         =
+
 #---------------------------------------------------------------------------
-# configuration options related to warning and progress messages
+# Configuration options related to warning and progress messages
 #---------------------------------------------------------------------------
 QUIET                  = NO
 WARNINGS               = YES
 WARN_IF_UNDOCUMENTED   = NO
 WARN_IF_DOC_ERROR      = YES
 WARN_NO_PARAMDOC       = NO
+WARN_AS_ERROR          = NO
 WARN_FORMAT            = "$file:$line: $text"
-WARN_LOGFILE           = html/doxygen-warnings.txt
+WARN_LOGFILE           = doxygen-warnings.txt
+
 #---------------------------------------------------------------------------
-# configuration options related to the input files
+# Configuration options related to the input files
 #---------------------------------------------------------------------------
 INPUT_ENCODING         = UTF-8
 INPUT                  = ../../src/ \
@@ -122,8 +137,10 @@ INPUT_FILTER           =
 FILTER_PATTERNS        =
 FILTER_SOURCE_FILES    = NO
 FILTER_SOURCE_PATTERNS =
+USE_MDFILE_AS_MAINPAGE =
+
 #---------------------------------------------------------------------------
-# configuration options related to source browsing
+# Configuration options related to source browsing
 #---------------------------------------------------------------------------
 SOURCE_BROWSER         = YES
 INLINE_SOURCES         = NO
@@ -131,10 +148,14 @@ STRIP_CODE_COMMENTS    = YES
 REFERENCED_BY_RELATION = YES
 REFERENCES_RELATION    = YES
 REFERENCES_LINK_SOURCE = NO
+SOURCE_TOOLTIPS        = YES
 USE_HTAGS              = NO
 VERBATIM_HEADERS       = YES
+CLANG_ASSISTED_PARSING = NO
+CLANG_OPTIONS          =
+
 #---------------------------------------------------------------------------
-# configuration options related to the alphabetical class index
+# Configuration options related to the alphabetical class index
 #---------------------------------------------------------------------------
 ALPHABETICAL_INDEX     = YES
 COLS_IN_ALPHA_INDEX    = 1
@@ -142,8 +163,9 @@ IGNORE_PREFIX          = lumiera:: \
                          lumiera_ \
                          lumi_ \
                          LUMIERA_
+
 #---------------------------------------------------------------------------
-# configuration options related to the HTML output
+# Configuration options related to the HTML output
 #---------------------------------------------------------------------------
 GENERATE_HTML          = YES
 HTML_OUTPUT            = html
@@ -151,6 +173,7 @@ HTML_FILE_EXTENSION    = .html
 HTML_HEADER            =
 HTML_FOOTER            =
 HTML_STYLESHEET        =
+HTML_EXTRA_STYLESHEET  =
 HTML_EXTRA_FILES       =
 HTML_COLORSTYLE_HUE    = 344
 HTML_COLORSTYLE_SAT    = 68
@@ -158,6 +181,7 @@ HTML_COLORSTYLE_GAMMA  = 80
 HTML_TIMESTAMP         = YES
 HTML_DYNAMIC_SECTIONS  = YES
 HTML_INDEX_NUM_ENTRIES = 100
+GENERATE_DOCSET        = NO
 GENERATE_HTMLHELP      = NO
 GENERATE_ECLIPSEHELP   = NO
 TOC_EXPAND             = YES
@@ -165,12 +189,17 @@ DISABLE_INDEX          = NO
 GENERATE_TREEVIEW      = YES
 TREEVIEW_WIDTH         = 200
 ENUM_VALUES_PER_LINE   = 1
+EXT_LINKS_IN_WINDOW    = NO
 FORMULA_FONTSIZE       = 9
 FORMULA_TRANSPARENT    = YES
+USE_MATHJAX            = NO
 SEARCHENGINE           = YES
 SERVER_BASED_SEARCH    = NO
+EXTERNAL_SEARCH        = NO
+SEARCHENGINE_URL       =
+
 #---------------------------------------------------------------------------
-# configuration options related to the LaTeX output
+# Configuration options related to the LaTeX output
 #---------------------------------------------------------------------------
 GENERATE_LATEX         = NO
 LATEX_OUTPUT           = latex
@@ -181,20 +210,26 @@ PAPER_TYPE             = a4wide
 EXTRA_PACKAGES         =
 LATEX_HEADER           =
 LATEX_FOOTER           =
+LATEX_EXTRA_STYLESHEET =
+LATEX_EXTRA_FILES      =
 PDF_HYPERLINKS         = YES
 USE_PDFLATEX           = YES
 LATEX_BATCHMODE        = YES
 LATEX_HIDE_INDICES     = NO
 LATEX_SOURCE_CODE      = NO
 LATEX_BIB_STYLE        = plain
+LATEX_TIMESTAMP        = NO
+
 #---------------------------------------------------------------------------
-# configuration options related to other output formats
+# Configuration options related to the RTF output
 #---------------------------------------------------------------------------
 GENERATE_RTF           = NO
 GENERATE_MAN           = NO
 GENERATE_XML           = NO
+GENERATE_DOCBOOK       = NO
 GENERATE_AUTOGEN_DEF   = NO
 GENERATE_PERLMOD       = NO
+
 #---------------------------------------------------------------------------
 # Configuration options related to the preprocessor
 #---------------------------------------------------------------------------
@@ -207,21 +242,26 @@ INCLUDE_FILE_PATTERNS  =
 PREDEFINED             = __cplusplus
 EXPAND_AS_DEFINED      =
 SKIP_FUNCTION_MACROS   = YES
+
 #---------------------------------------------------------------------------
-# Configuration::additions related to external references
+# Configuration options related to external references
 #---------------------------------------------------------------------------
 TAGFILES               =
 GENERATE_TAGFILE       = lumiera.tag
 ALLEXTERNALS           = NO
 EXTERNAL_GROUPS        = YES
+EXTERNAL_PAGES         = YES
 PERL_PATH              = /usr/bin/perl
+
 #---------------------------------------------------------------------------
 # Configuration options related to the dot tool
 #---------------------------------------------------------------------------
 CLASS_DIAGRAMS         = YES
 MSCGEN_PATH            =
+DIA_PATH               =
 HIDE_UNDOC_RELATIONS   = YES
 HAVE_DOT               = YES
+DOT_NUM_THREADS        = 0
 DOT_FONTNAME           = FreeSans
 DOT_FONTSIZE           = 8
 DOT_FONTPATH           =
@@ -239,8 +279,12 @@ GRAPHICAL_HIERARCHY    = NO
 DIRECTORY_GRAPH        = YES
 DOT_IMAGE_FORMAT       = svg
 INTERACTIVE_SVG        = YES
+DOT_PATH               =
+DOTFILE_DIRS           =
+MSCFILE_DIRS           =
+DIAFILE_DIRS           =
 DOT_GRAPH_MAX_NODES    = 80
-MAX_DOT_GRAPH_DEPTH    = 1000
+MAX_DOT_GRAPH_DEPTH    = 20
 DOT_TRANSPARENT        = YES
 DOT_MULTI_TARGETS      = YES
 GENERATE_LEGEND        = YES

research/gtk-canvas-experiment.hpp

@@ -85,7 +85,7 @@ namespace demo {
    * Dockable panel to hold timeline widget(s).
    * @todo build the actual implementation, after finishing the investigation
    * 
-   * ## Investigation of gtk::GtkLayout
+   * # Investigation of gtk::GtkLayout
    * As of 10/2016, we start this task with an exploration of GTK behaviour
    * 
    * \par Plan of investigation

research/gtk-style-experiment.cpp

@@ -26,7 +26,7 @@
  ** and use this for custom drawing. Within Lumiera, we use custom drawing for some parts
  ** of the Timeline UI presentation.
  ** 
- ** ## Setup for investigation
+ ** # Setup for investigation
  ** - add a separate dummy Gtk::Frame widget as `testFrame_`
  ** - apply custom styling to that frame, by virtue of a CSS class '.experiment'
  ** - pick up the Gtk::StyleContext of that `testFrame_` to get the CSS path
@@ -34,7 +34,7 @@
  ** - use this style context to draw a custom frame and background onto the canvas
  ** - control extension of that custom drawing through the top margin CSS setting of testFrame_
  ** 
- ** ## Findings
+ ** # Findings
  ** - it works as intended
  ** - however, care must be taken to apply CSS cascading properly (generic vs specific selectors)
  ** - the context_save/restore functionality seems to be broken on a "free standing" style context;

src/common/advice/advice.cpp

@@ -23,6 +23,8 @@
 
 /** @file advice.cpp
  ** Implementation of the AdviceSystem, to support the advice collaboration.
+ ** 
+ ** # Implementation notes
  ** The AdviceSystem is implemented as singleton, but is never accessed directly
  ** by clients participating in an advice collaboration. Rather, they use the
  ** advice::Request and advice::Provision value classes as a frontend. While

src/common/advice/binding.hpp

@@ -21,7 +21,7 @@
 */
 
 
-/** @file binding.hpp
+/** @file advice/binding.hpp
  ** A pattern to define and identify a specific attachment to the Advice system.
  ** This pattern is comprised of a predicate list and intended to be matched or unified
  ** against a similar pattern associated with the attachment of a possible collaboration partner.

src/common/config-typed.c

@@ -21,7 +21,7 @@
 * *****************************************************/
 
 
-/** @file config-type.c
+/** @file config-typed.c
  ** Implementation draft for a configuration system (2008).
  ** This file implements high level typed configuration interfaces.
  ** @note unfinished draft from 2008

src/common/subsystem-runner.hpp

@@ -95,7 +95,7 @@ namespace lumiera {
    * correspond to a single component, interface or plugin. It may well be a
    * complete layer of the application (e.g. the GUI).
    * 
-   * ## Protocol of operation
+   * # Protocol of operation
    * The SubsystemRunner is to be configured with a lumiera::Option object first.
    * Then, primary subsystems are \link #maybeRun provided \endlink for eventual
    * startup, which may depend on conditions defined by the subsystem. When

src/include/logging.h

@@ -54,7 +54,11 @@
  ** Any log level can be overridden by an environment variable, for example
  ** `NOBUG_LOG='progress:INFO' ./lumiera`
  **
- ** @todo logging to files? `NOBUG_LOG='progress:INFO@file(name=filename)'` api to set this statically up by the program will follow  --cehteh
+ ** @todo logging to files?
+ ** \verbatim
+ ** `NOBUG_LOG='progress:INFO@file(name=filename)'` api to set this statically up by the program will follow
+ ** \endverbatim
+ **   --cehteh
  */
 
 

src/lib/depend-inject.hpp

@@ -31,7 +31,7 @@
  ** an explicit configuration, lib::Depend will automatically create and manage a
  ** singleton instance of the type given as type parameter.
  ** 
- ** ## Architecture
+ ** # Architecture
  ** A _dependency_ is understood as something we need to perform the task at hand,
  ** yet a dependency referres beyond that task and relates to concerns outside the
  ** scope and theme of this actual task. The usage site of the dependency is only
@@ -47,9 +47,10 @@
  ** configuration of services is not centralised, and can not be static; it need
  ** to happen prior to any service access (on violation error::Logic is raised)
  ** 
+ ** # Configuration
  ** The public configuration mechanisms offered by DependInject address various concerns:
  ** 
- ** \paragraph Wiring
+ ** ## Wiring
  ** Even when relying on lazy on-demand initialisation, a concrete service implementation
  ** typically needs to connect to further services, and maybe even decide upon the actual
  ** subclass to be instantiated. By invoking the DependInject<SRV>::useSingleton(FUN)
@@ -58,7 +59,7 @@
  ** This function is expected to deliver a heap allocated instance on invocation, which
  ** will be owned and managed by lib::Depend<SRV>::factory (A DependencyFactory<SRV>).
  ** 
- ** \paragraph Service Lifecycle
+ ** ## Lifecycle
  ** Whenever a module or subsystem can be started and stopped, several interconnected
  ** services become operational together, with dependent lifecycle. It is possible to
  ** expose such services through a lib::Depend<SRV> front-end; this way, the actual
@@ -67,7 +68,7 @@
  ** This kind of configuration can be achieved by planting a smart-handle of type
  ** DependInject<SRV>::ServiceInstance<IMP>
  ** 
- ** \paragraph Unit Testing with Mock Services
+ ** ## Unit Testing with Mock Services
  ** Dependencies tend to hamper unit testing, but global variables and actively
  ** linked and collaborating implementations are worse and often prevent test coverage
  ** altogether. Preferably dependencies are limited to an interface and a focused topic,

src/lib/diff/record.hpp

@@ -36,7 +36,7 @@
  ** - a collection of _named attributes_ (key-value data)
  ** - a list of _enclosed children_ (contents within the "scope" of this Record)
  ** 
- ** ## design decisions
+ ** # design decisions
  ** The Record type is shaped from its intended use: It serves to symbolically represent
  ** *objects* in the "external tree description". Here, "objects" means objects _for real_,
  ** i.e. with types, fields and an enclosed scope. Yet the term *external* means that we do not

src/lib/diff/tree-diff-application.hpp

@@ -27,7 +27,7 @@
  ** to receive linearised structural diff descriptions and apply them to
  ** a given target data structure, to effect the corresponding changes.
  ** 
- ** ## Design considerations
+ ** # Design considerations
  ** While -- conceptually -- our tree diff handling can be seen as an extension
  ** and generalisation of list diffing, the decision was \em not to embody this
  ** extension into the implementation technically, for sake of clarity. This would
@@ -37,7 +37,7 @@
  ** needs to embodied into two distinct contexts of implementation. So the list diff
  ** application strategy can be seen as blueprint and demonstration of principles.
  ** 
- ** ### Use cases
+ ** ## Use cases
  ** Initially, we'd have to distinguish two usage situations
  **  - apply a diff to a generic tree representation, based on Record<GenNode>
  **  - apply a diff to some tree shaped implementation data structure.
@@ -49,7 +49,7 @@
  ** goals of our "diff framework", since we want to allow collaboration between
  ** loosely coupled subsystems, without the need of a shared data structure.
  ** 
- ** ### Implementation
+ ** ## Implementation
  ** On the implementation level though, relations are the other way round: the
  ** framework and technique to enable applying a diff onto private implementation data
  ** is used also to apply the diff onto the (likewise private) implementation of our
@@ -66,7 +66,7 @@
  ** - binding especially to a collection of GenNode elements,
  **   which basically covers also the generic tree representation.
  ** 
- ** #### State and nested scopes
+ ** ### State and nested scopes
  ** For performance reasons, the diff is applied _in place_, directly mutating the
  ** target data structure. This makes the diff application _statefull_ -- and in case of
  ** a *diff conflict*, the target *will be corrupted*.
@@ -86,7 +86,7 @@
  ** descent and diff application is implemented with the help of a stack, where a new
  ** TreeMutator is constructed whenever we enter (push) a new nested scope.
  ** 
- ** #### Yet another indirection
+ ** ### Yet another indirection
  ** Unfortunately this leads to yet another indirection layer: Implementing a
  ** language in itself is necessarily a double dispatch (we have to abstract the
  ** verbs and we have to abstract the implementation side). And now we're decoupling
@@ -95,7 +95,7 @@
  ** functors) to translate the _implementation actions_ underlying the language into
  ** _concrete actions_ working on local data.
  ** 
- ** #### Generic and variable parts
+ ** ### Generic and variable parts
  ** So there is a link between generic [»tree diff language«](\ref tree-diff.hpp)
  ** interpretation and the concrete yet undisclosed private data structure, and
  ** most of this implementation is entirely generic, since the specifics are
@@ -105,7 +105,7 @@
  ** figure out a way how to "get" a suitable TreeMutator implementation
  ** for the given concrete target data.
  ** 
- ** ### the TreeMutator DSL
+ ** ## the TreeMutator DSL
  ** In the end, for each target structure, a concrete TreeMutator needs to be built
  ** or provided within the realm of the actual data implementation, so the knowledge
  ** about the actual data layout remains confined there. While this requires some

src/lib/diff/tree-mutator-attribute-binding.hpp

@@ -35,7 +35,7 @@
  ** a building block for one specific kind of layer, used to bind object fields
  ** through "setter" lambdas.
  ** 
- ** ## architecture considerations
+ ** # architecture considerations
  ** Together with the (\ref tree-mutator-collection-binding.hpp), the attribute binding
  ** is the most relevant building block -- yet it is special in several respects. There
  ** is kind of a "impedance mismatch" between the concept of an "attribute", as used in

src/lib/diff/tree-mutator-collection-binding.hpp

@@ -22,7 +22,7 @@
 
 
 /** @file tree-mutator-collection-binding.hpp
- ** Special binding implementation for TreeMutator, allowing to map
+ ** Special binding implementation for lib::diff::TreeMutator, allowing to map
  ** tree diff operations onto a STL collection of native implementation objects.
  ** TreeMutator is a customisable intermediary, which enables otherwise opaque
  ** implementation data structures to receive and respond to generic structural
@@ -38,7 +38,7 @@
  ** As a _special case_, binding to a STL map is supported, while this usage is rather
  ** discouraged, since it contradicts the diff semantics due to intrinsic ordering.
  ** 
- ** ## Internal structure
+ ** # Internal structure
  ** 
  ** The task to set up a binding to a _generic STL collection_ has to face some
  ** technical intricacies, leading to a rather involved implementation, which can
@@ -298,7 +298,7 @@ namespace diff{
     /**
      * Attach to collection: Building block for a concrete `TreeMutator`.
      * This decorator will be outfitted with actual binding and closures
-     * and then layered on top of the (\ref TreeMutaor) base. The resulting
+     * and then layered on top of the (\ref TreeMutator) base. The resulting
      * compound is able to consume tree diff messages and apply the respective
      * changes and mutations to an otherwise opaque implementation data structure.
      * @remarks in practice, this is the most relevant and typical `TreeMutator` setup.

src/lib/diff/tree-mutator.hpp

@@ -36,12 +36,13 @@
  ** representation of types as chained identifiers. (path dependent types).
  ** 
  ** The interface implemented by the TreeMutator is shaped such as to support
- ** the primitives of Lumiera's tree \link diff-language.hpp diff handling language. \endlink
+ ** the primitives of Lumiera's tree [diff handling language](\ref diff-language.hpp).
  ** By default, each of these primitives is implemented as a \c NOP -- but each operation
  ** can be replaced by a binding closure, which allows to invoke arbitrary code in the
  ** context of the given object's implementation internals.
  ** 
- ** ## Builder/Adapter concept
+ ** # Builder/Adapter concept
+ ** 
  ** TreeMutator is both an interface and a set of building blocks.
  ** On concrete usage, the (private, non disclosed) target data structure is assumed
  ** to _build a subclass of TreeMutator._ To this end, the TreeMutator is complemented

src/lib/format-string.hpp

@@ -33,7 +33,7 @@
  ** than the (small) performance gain of directly invoking boost::format (which is
  ** known to be 10 times slower than printf anyway).
  ** 
- ** ## Implementation notes
+ ** # Implementation notes
  ** To perform the formatting, usually a \c _Fmt object is created as an anonymous
  ** temporary, but it may as well be stored into a variable. Copying is not permitted.
  ** Individual parameters are then fed for formatting through the \c '%' operator.
@@ -64,7 +64,7 @@
  ** for all primitive types. In the test showed above, the corresponding object file
  ** had a size of 1300k (with debug information) resp. 290k (stripped).
  ** 
- ** ## Usage
+ ** # Usage
  ** The syntax of the format string is defined by boost::format and closely mimics
  ** the printf formatting directives. The notable difference is that boost::format
  ** uses the C++ stream output framework, and thus avoids the perils of printf.

src/lib/iter-chain-search.hpp

@@ -33,7 +33,7 @@
  ** then lead to a match. Basically we have to try all combinations of all possible local
  ** matches, to find a solution to satisfy the whole chain of conditions.
  ** 
- ** ## Design
+ ** # Design
  ** 
  ** The IterChainSearch component is built as a processing pipeline, based on the
  ** [Tree-Explorer framework](\ref iter-tree-explorer.hpp). This yields several benefits, but
@@ -51,7 +51,7 @@
  ** compilation times and rather large size of the generated code (which in debugging mode
  ** with full type information can even become excessively large).
  ** 
- ** Some caveats
+ ** ## Some caveats
  ** - the resulting pipeline is copyable, and it is typically moved out from a builder
  **   function into the target location. So beware of _lambda captures by reference._
  **   When you capture _anything_ within the pipeline itself, like some `this` pointer,

src/lib/iter-source.hpp

@@ -33,7 +33,7 @@
  **       with the purpose of this adapter. Rather, it should be shaped
  **       similar to IterStateWrapper with three control functions     //////////////////////////////////////TICKET #1125
  ** 
- ** ## Standard Adapters
+ ** # Standard Adapters
  ** As a complement, this header contains a generic implementation
  ** of the IterSource interface by wrapping an existing Lumiera Forward Iterator.
  ** Using this WrappedLumieraIter, the details of this wrapped source iterator

src/lib/iter-tree-explorer.hpp

@@ -1588,7 +1588,7 @@ namespace lib {
    *         TreeExplorer will invalidate that variable (by moving it into the
    *         augmented iterator returned from such builder call).
    * 
-   * ## usage
+   * # usage
    * 
    * This function starts a *Builder* expression. It picks up the given source,
    * which can be something "sequence-like" or "iterable", and will automatically

src/lib/meta/function-closure.hpp

@@ -626,7 +626,7 @@ namespace func{
           return func::Apply<ARG_CNT>::template bind<LeftReducedFunc> (f, params);
         }
       
-      /** do a partial function application, closing the last arguments</br>
+      /** do a partial function application, closing the last arguments<br/>
        *  `f(a,b,c)->res  +  (b,c)`  yields  `f(a)->res`
        *  
        *  @param f   function, function pointer or functor

src/lib/opaque-holder.hpp

@@ -501,7 +501,7 @@ namespace lib {
    * The whole compound is copyable if and only if the contained
    * object is copyable.
    *
-   * ## using OpaqueHolder
+   * # using OpaqueHolder
    * OpaqueHolder instances are copyable value objects. They are created
    * either empty, by copy from an existing OpaqueHolder, or by directly
    * specifying the concrete object to embed. This target object will be

src/lib/scoped-collection.hpp

@@ -29,7 +29,7 @@
  ** The storage holding all those child objects is allocated in one chunk
  ** and never adjusted.
  ** 
- ** ## usage patterns
+ ** # usage patterns
  ** 
  ** The common ground for all usage of this container is to hold some elements
  ** with exclusive ownership; when the enclosing container goes out of scope,

src/lib/symbol-impl.cpp

@@ -20,7 +20,7 @@
 
 * *****************************************************/
 
-/** @file symbol-impl.hpp
+/** @file symbol-impl.cpp
  ** Collection of helpers for working with the lib::Symbol.
  ** 
  ** @todo currently as of 9/09 this is more of a placeholder.

src/lib/sync.hpp

@@ -411,7 +411,7 @@ namespace lib {
    * Lock template, which should be instantiated as an automatic variable
    * within the scope to be protected.
    * 
-   * ## Usage
+   * # Usage
    * - for *locking*, just place an instant of the embedded Lock into the local
    *   scope to be protected. All lock instances within the same object share
    *   the monitor; thus any time, only one of them gets the mutex all other

src/lib/time/control-policy.hpp

@@ -36,7 +36,7 @@
  ** - for \c SRC, the actual type of values to impose _as change_
  ** - for \c TAR, the target time value's type, receiving those changes.
  ** 
- ** ## mutating a time value entity
+ ** # mutating a time value entity
  ** 
  ** Actually imposing a change to the attached time value entity involves several
  ** steps. Each of these steps might be adapted specifically, in accordance to

src/lib/variant.hpp

@@ -42,7 +42,7 @@
  ** handling for _all the possible types._ As an alternative, you might consider the
  ** lib::PolymorphicValue to hold types implementing a common interface.
  ** 
- ** ## implementation notes
+ ** # implementation notes
  ** 
  ** We use a "double capsule" implementation technique similar to lib::OpaqueHolder.
  ** In fact, Variant is almost identical to the latter, just omitting unnecessary flexibility.

src/lib/verb-visitor.hpp

@@ -40,7 +40,7 @@
  ** the separation of actual drawing code from the nested track controller structure.
  ** 
  ** 
- ** ## implementation technique
+ ** # implementation technique
  ** 
  ** The actual foundation is quite simple: we store a [member pointer]. Typically, this embedded
  ** pointer-to-member shall be bound to an abstract virtual function on the _visitor interface._

src/stage/ctrl/state-manager.hpp

@@ -30,7 +30,7 @@
  ** typically expect these choices and traces of usage to remain sticky, persistent
  ** across editing sessions.
  ** 
- ** ## Implementation technique
+ ** # Implementation technique
  ** In Lumiera, handling of persistent presentation state relies on the UI backbone
  ** structure known as [UI-Bus](\ref ui-bus.hpp). Any element of more than local relevance,
  ** as attached to this backbone, will emit *state mark notification* messages, whenever

src/stage/gtk-base.hpp

@@ -32,7 +32,7 @@
  ** Besides, this header defines the basic NLS. Most parts of the GUI rely on this header.
  ** 
  ** 
- ** ## configuration and resource search
+ ** # configuration and resource search
  ** 
  ** The GUI backbone retrieves the necessary configuration values from lumiera::Config,
  ** the config facade in the application core. Currently as of 2/2011 these values are

src/stage/guifacade.hpp

@@ -64,7 +64,7 @@ namespace stage {
    * and wired internally such as to allow transparent access from
    * within the core.
    * 
-   * ## intended usage
+   * # intended usage
    * This is an facade interface to the GUI subsystem, but it's setup
    * is somewhat special, as its sole purpose is to expose the subsystem
    * descriptor, which, when started, loads the GUI as a plugin and

src/stage/interact/elem-access-dir.hpp

@@ -21,7 +21,7 @@
 */
 
 
-/** @file elem-access-directory.hpp
+/** @file elem-access-dir.hpp
  ** A service to discover and access raw UI elements in a cross cutting way.
  ** This is the actual low-level implementation of the model::ElementAccess interface
  ** Tightly coupled to the internals of Lumiera's GTK UI, this implementation embodies

src/stage/interact/ui-location-solver.hpp

@@ -29,7 +29,7 @@
  ** actual event handling code. Rather, the ViewLocator, as a service related to the InteractionDirector,
  ** can be invoked to draw on some default configuration plus the actual UI topology present at this time.
  ** 
- ** ## Pattern matching against the actual UI-tree
+ ** # Pattern matching against the actual UI-tree
  ** 
  ** This Location solver is based on the pattern matching algorithm [embedded](\ref ui-coord-resolver.cpp)
  ** within the UICoordResolver component. This mechanism allows to treat (typically) incomplete coordinate
@@ -39,7 +39,7 @@
  ** (there is no common variable binding); the first clause to produce a successful match is used as
  ** solution -- with any placeholders replaced by the actually matching UI elements.
  ** 
- ** ## Default View location configuration DSL
+ ** # Default View location configuration DSL
  ** 
  ** Whenever a new UI element of a given kind is to be created, we query a standard location configuration
  ** to determine it's actual location within the interface. This standard configuration is known as

src/stage/interact/view-locator.hpp

@@ -33,7 +33,7 @@
  ** - multiplicity (one, one per window, many) depends on the type of view and needs to be managed.
  ** - such a view is not just _created_ -- rather it needs to be _allocated_
  ** 
- ** ## LocationQuery and the View-Spec DSL
+ ** # LocationQuery and the View-Spec DSL
  ** 
  ** Implementation wise, there is a tight connection between the ViewLocator service, the Navigator service
  ** and the configuration how and where to create standard view elements (the "View-Spec DSL"). Several interactions

src/stage/model/expander-revealer.hpp

@@ -32,7 +32,7 @@
  ** - sometimes it is necessary to bring a given widget into sight, be it to show
  **   the effect of some processing, or be it to indicate an error situation.
  ** 
- ** ## Usage in the default implementation
+ ** # Usage in the default implementation
  ** 
  ** The base class of all [tangible UI elements](\ref Tangible) provides a default implementation
  ** for these generic interaction mechanisms: It offers slots to connect UI signals against, and

src/stage/model/tangible.hpp

@@ -26,7 +26,7 @@
  ** This is a generic foundation for any elements of more than local relevance
  ** within the Lumiera UI.<br/> Any such element is connected to the [UI-Bus](\ref ui-bus.hpp).
  ** 
- ** ## rationale
+ ** # rationale
  ** 
  ** Simple user interfaces can be built by wiring up the actions right within the
  ** code processing the trigger of actions. This leads to core functionality littered
@@ -53,7 +53,7 @@
  ** `Tangible::uiBus_`
  ** can be used for interaction with core services.
  ** 
- ** ## the generic interface element API
+ ** # the generic interface element API
  ** 
  ** The _generic interface element_ based on [Tangible](\ref model::Tangible) covers a set of behaviour
  ** common to all elements of the interface. This behaviour is targeted towards the _integration_
@@ -98,7 +98,7 @@
  ** These are sent as notifications just to some relevant top level element, expecting this element
  ** to request a [diff](\ref tree-diff.hpp) and to mutate contents into shape recursively.
  ** 
- ** ## Interactions
+ ** # Interactions
  ** 
  ** - **lifecycle**: connect to an existing term, supply the [EntryID](\ref Tangible::ID) of the new element.
  **   This interaction also implies, that the element automatically detaches itself at end of life.

src/stage/model/zoom-window.hpp

@@ -28,11 +28,11 @@
  ** - it is a place or excerpt within the model topology (e.g. the n-th track in the fork)
  ** - it has a temporal extension within a larger temporal frame (e.g. some seconds within the timeline)
  ** 
- ** ## rationale
+ ** # rationale
  ** 
  ** TBW
  ** 
- ** ## Interactions
+ ** # Interactions
  ** 
  ** - *bla*: connect to blubb
  ** see [sigc-track] for an explanation.

src/stage/panel/timeline-panel.hpp

@@ -24,7 +24,7 @@
 /** @file timeline-panel.hpp
  ** A dockable container to hold a notebook of timeline displays.
  ** 
- ** ## Management of Timeline display
+ ** # Management of Timeline display
  ** Within the Lumiera GTK UI, there is an UI top-level circle of managing entities to handle global
  ** concerns and actions. The ctrl::InteractionDirector incorporates the role of _model root_ and thus
  ** manages a collection of timelines. The timeline panel exposes this collection and allows to view and

src/stage/timeline/body-canvas-widget.hpp

@@ -129,7 +129,7 @@ namespace timeline {
    * the display needs to stay "pinned" on top (the overview rulers), while
    * the majority of the track body area is packaged into a scrolling pane.
    * 
-   * ## Interface
+   * # Interface
    * We have to distinguish two kinds of drawing access to this BodyCanvasWidget:
    * - painting of areas for background, profile and for overlays
    * - relative attachment of widgets onto this canvas

src/stage/timeline/display-evaluation.hpp

@@ -32,7 +32,7 @@
  ** pass; typically additional space requirements are discovered and propagated _as message_ to GTK,
  ** and so the DisplayEvaluation can be expected to be re-triggered soon thereafter.
  ** 
- ** ## Tasks to perform
+ ** # Tasks to perform
  ** 
  ** The basic goal is to establish a coherent vertical space allocation for all tracks within the
  ** timeline (while, to the contrary, the horizontal extension is a fixed requirement and can be
@@ -41,7 +41,7 @@
  ** - buildup of a timeline::TrackProfile to accommodate those requirements and all decorations
  ** - adjustment of the TrackHeadWidget extensions to match the allocated track body space precisely.
  ** 
- ** ## Evaluation structure
+ ** # Evaluation structure
  ** 
  ** This is an intricate collaboration of closely related elements; however, each of the aforementioned
  ** tasks is defined such as to operate in a self-confined way on some part of the timeline. All the
@@ -51,7 +51,7 @@
  ** implies a recursive depth-first invocation proceeding *top-down* and *from left to right*. It is
  ** each LayoutElement's liability to recurse appropriately to make this happen.
  ** 
- ** ## Evaluation state and phases
+ ** # Evaluation state and phases
  ** 
  ** The DisplayEvaluation works by direct (side)effect within the invoked elements, eventually leading
  ** to some of the embedded GTK widgets being resized -- which typically will re-trigger our custom drawing

src/stage/widget/element-box-widget.cpp

@@ -21,7 +21,7 @@
 * *****************************************************/
 
 
-/** @file label-widget.cpp
+/** @file element-box-widget.cpp
  ** Implementation details of the UI building block to display an ID label.
  ** 
  ** @todo WIP-WIP-WIP as of 11/2018   ///////////////////////////////////////////////////////////////////////TICKET #1185

src/stage/widget/error-log-display.hpp

@@ -27,7 +27,7 @@
  ** entries can be added with a severity level, causing the widget to scroll
  ** down to the last line of the content buffer.
  ** 
- ** ## Lifecycle considerations
+ ** # Lifecycle considerations
  ** 
  ** The ErrorLogDisplay is typically managed as child of a container widget.
  ** However, the ctrl::NotificationHub as controller does a lookup and attaches

src/steam/asset/meta.hpp

@@ -34,7 +34,7 @@
  ** from the general Asset interface. To be able to get asset::Meta instances
  ** directly from the AssetManager, we define a specialisation of the Asset ID.
  ** 
- ** ## using meta assets
+ ** # using meta assets
  ** 
  ** The usage pattern of asset::Meta entities differs from the other assets,
  ** insofar they aren't created as individual entries, rather added as part

src/steam/asset/meta/time-grid.hpp

@@ -34,7 +34,7 @@
  ** Time grid specifications are integrated into Lumiera's framework
  ** for meta assets, automation, configuration and similar metadata.
  ** 
- ** ## using time grids
+ ** # using time grids
  ** 
  ** TimeGrid is an interface (ABC), but provides some actual factory
  ** functions, which can be used as a convenience shortcut to fabricate

src/steam/asset/struct.hpp

@@ -37,7 +37,7 @@
  ** - "tracks" are implemented as Fork represented as \c entryID within the asset view.
  ** - ProcPatt is used as a blueprint in the build process, a standard connection pattern
  ** 
- ** ## access and creation
+ ** # access and creation
  ** 
  ** asset::Struct instances are created on demand; the interface is to invoke the
  ** StructFactory with a (typed) Query describing properties or capabilities.

src/steam/control/command-closure.hpp

@@ -35,7 +35,7 @@
  ** actual command operation function), which implements the invocation of the
  ** operation function with the stored argument tuple.
  ** 
- ** ## Command Closure and Lifecycle
+ ** # Command Closure and Lifecycle
  ** When defining a command, Mutation objects are to be created based on a concrete function.
  ** These are stored embedded into a type erasure container, thus disposing the specific type
  ** information of the function and function arguments. Each command needs an Mutation object

src/steam/control/command-registry.hpp

@@ -31,7 +31,7 @@
  **   to the TypedAllocationManager
  ** - maintaining an index to find pre-built command definitions (prototypes)
  ** 
- ** ## Services during command lifecycle
+ ** # Services during command lifecycle
  ** 
  ** Each command starts out as command definition, accessed by client code through CommandDef.
  ** While collecting the necessary parts of such a definition, there is just an empty (pending)

src/steam/engine/dispatcher.hpp

@@ -67,7 +67,7 @@ namespace engine {
    * evaluation and planning of new jobs, which can then be handed over to the Scheduler
    * for time-bound activation.
    * 
-   * ## usage considerations
+   * # usage considerations
    * the asynchronous and ongoing nature of the render process mandates to avoid a central
    * instance for operating this planning process. Instead, together with each chunk of
    * planned jobs we generate a continuation job, which -- on activation -- will pick up

src/steam/engine/job-planning.hpp

@@ -27,7 +27,7 @@
  ** into a sequence of planning steps. The net result is to present a <i>sequence of job planing</i>
  ** to the user, while actually encapsulating a depth-first tree exploration, which proceeds on demand.
  ** 
- ** ## participating elements
+ ** # participating elements
  ** All of these job planning operations are implemented on top of the JobTicket. This is where to look
  ** for "actual" implementation code. Here, within this header, the following entities cooperate to
  ** create a simple sequence out of this implementation level tasks:
@@ -37,7 +37,7 @@
  ** - steam::engine::expandPrerequisites(JobPlanning const&) is the operation to explore further prerequisite Jobs recursively
  ** - PlanningStepGenerator yields the underlying "master beat": a sequence of frame locations to be planned
  ** 
- ** ## how the PlanningState (sequence) is advanced
+ ** # how the PlanningState (sequence) is advanced
  ** PlanningState is an iterator to expose a sequence of JobPlanning elements. On the implementation level,
  ** there is always just a single JobPlanning element, which represents the \em current element; this element
  ** lives as "state core" within the PlanningState object. Advancing to the next JobPlanning element (i.e. to

src/steam/engine/nodeinvocation.hpp

@@ -35,7 +35,7 @@
  ** Invocation object (a sub-interface of StateAdapter) to access the various aspects of the
  ** invocation state.
  ** 
- ** ## composition of the Invocation State
+ ** # composition of the Invocation State
  ** 
  ** For each individual ProcNode#pull() call, the WiringAdapter#callDown() builds an StateAdapter
  ** instance directly on the stack, managing the actual buffer pointers and state references. Using this

src/steam/engine/time-anchor.hpp

@@ -69,7 +69,7 @@ namespace engine {
    * the TimeAnchor closure is the definitive binding between the abstract logical time of the
    * session timeline, and the real wall-clock time forming the deadline for rendering.
    * 
-   * ## internals
+   * # internals
    * The time anchor associates a nominal time, defined on the implicit time grid
    * of some given Timings, with an actual wall clock time. Due to the usage situation,
    * the TimeAnchor takes on the secondary meaning of a breaking point; everything \em before

src/steam/mobject/output-mapping.hpp

@@ -111,7 +111,7 @@ namespace mobject {
    * may be derived by querying the OutputMapping. Here, the kind of
    * the target specification is defined through the type parameter.
    * 
-   * ## definition of specific mapping behaviour
+   * # definition of specific mapping behaviour
    * 
    * This is an generic map-like container, acting as Interface to be used
    * in the signature of API functions either providing or requiring a Mapping.
@@ -356,7 +356,7 @@ namespace mobject {
    *  which then is considered the mapped result and handed over to the `DEF::output`
    *  functor for resolution to a result object to be returned.
    *  
-   *  ## Query for the Nth default instance
+   *  \par Query for the Nth default instance
    *  OutputMapping provides a special behaviour for retrieving "the Nth default pipe".
    *  The rationale being the request for connection to the Nth bus of a given kind, like
    *  e.g. the 3rd audio subgroup or the 2nd video master. This special behaviour is triggered

src/steam/mobject/session/binding.hpp

@@ -21,7 +21,7 @@
 */
 
 
-/** @file binding.hpp
+/** @file session/binding.hpp
  ** MObject in session to represent the top-level binding of a sequence
  ** @todo stalled effort towards a session implementation from 2010
  ** @todo 2016 likely to stay, but expect some extensive rework

src/steam/mobject/session/query-focus-stack.hpp

@@ -54,8 +54,7 @@ namespace session {
    * a boost::intrusive_ptr, which stores the ref-count within
    * the mentioned ScopePath frames located in the stack.
    * 
-   * ## automatic cleanup of unused frames
-   * 
+   * \par automatic cleanup of unused frames
    * The stack is aware of this ref-counting mechanism and will --
    * on each access -- automatically clean up any unused frames starting
    * from stack top, until encountering the first frame still in use.

tests/core/vault/media-access-mock.cpp

@@ -21,7 +21,7 @@
 * *****************************************************/
 
 
-/** @file media-acess-mock.cpp
+/** @file media-access-mock.cpp
  ** Mock implementation of the Interface normally used to query media file
  ** information from the data backend. The Mock implementation instead holds
  ** a map of fixed response which will be delivered when querying some magic

tests/library/iter-explorer-test.cpp

@@ -223,7 +223,7 @@ namespace test{
    *       - a [recursively self-integrating](\ref verifyRecrusiveSelfIntegration())
    *         evaluation pattern
    * 
-   * ## Explanation
+   * # Explanation
    * 
    * Both this test and the IterExplorer template might be bewildering
    * and cryptic, unless you know the *Monad design pattern*. Monads are
@@ -420,7 +420,7 @@ namespace test{
       /** @test a depth-first visiting and exploration scheme of a tree like system,
        *        built on top of the IterExplorer monad.
        * 
-       * ## Test data structure
+       * # Test data structure
        * We build a functional datastructure here, on the fly, while exploring it.
        * The `exploreChildren(m)` function generates this tree like datastructure:
        * For a given number, it tries to divide by 5, 3 and 2 respectively, possibly
@@ -435,7 +435,7 @@ namespace test{
        * \endcode
        * This tree has no meaning in itself, beyond being an easy testbed for tree exploration schemes.
        * 
-       * ## How the exploration works
+       * # How the exploration works
        * We use a pre defined Template \ref DepthFirstExplorer, which is built on top of IterExplorer.
        * It contains the depth-first exploration strategy in a hardwired fashion. Actually this effect is
        * achieved by defining a specific way how to _combine the results of an exploration_ -- the latter

tests/library/iter-tree-explorer-test.cpp

@@ -236,7 +236,7 @@ namespace test{
    *         an extension (sub interface) to allow for "tree exploration" without
    *         any knowledge regarding the concrete implementation of the data source.
    * 
-   * ## Explanation
+   * # Explanation
    * 
    * These tests build a evaluation pipeline by _wrapping_ some kind of data source
    * and then layering some evaluation stages on top. There are two motivations why

tests/stage/abstract-tangible-test.cpp

@@ -196,7 +196,7 @@ namespace test {
        * embodies an [event log](\ref EventLog), the unit test code can verify
        * the occurrence of expected events, invocations and responses.
        * 
-       * ### connectivity
+       * \par connectivity
        * Any mock element will automatically connect against the [Test-Nexus](\ref test/test-nexus.hpp),
        * so to be suitably rigged for unit testing. This means, there is no _live connection_
        * to the session, but any command- or other messages will be captured and can be

wiki/thinkPad.ichthyo.mm

@@ -43184,8 +43184,7 @@
       erwarte eine Funktion <b>getID()</b>
     </p>
   </body>
-</html>
-</richcontent>
+</html></richcontent>
 </node>
 <node CREATED="1611402182252" ID="ID_12989992" MODIFIED="1611402197061" TEXT="und deren Resultat mu&#xdf; per == vergleichbar sein"/>
 <node CREATED="1611402199145" ID="ID_317509193" MODIFIED="1611402204788" TEXT="...mit einer GenNode::ID"/>
@@ -43204,8 +43203,7 @@
       ...d.h. man mu&#223; dann halt doch noch den Matcher explizit in der DSL konfigurieren
     </p>
   </body>
-</html>
-</richcontent>
+</html></richcontent>
 <icon BUILTIN="yes"/>
 </node>
 </node>
@@ -53898,6 +53896,18 @@
   </body>
 </html></richcontent>
 </node>
+<node CREATED="1611414331032" ID="ID_772377087" MODIFIED="1611414385896" TEXT="Dokumentations-Kommentar mu&#xdf; mit &quot;/**&quot; beginnen (exakt zwei Sterne!)">
+<richcontent TYPE="NOTE"><html>
+  <head>
+    
+  </head>
+  <body>
+    <p>
+      also keine &quot;Banner&quot; aus Sternen.<br />Abhilfe: /*********************//**
+    </p>
+  </body>
+</html></richcontent>
+</node>
 </node>
 <node CREATED="1491098382888" ID="ID_1568153886" MODIFIED="1557498707240" TEXT="Probleme">
 <node CREATED="1491098385823" ID="ID_801230289" MODIFIED="1557498707240" TEXT="Auto-Links">
@@ -53927,12 +53937,33 @@
   </body>
 </html></richcontent>
 </node>
+<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1611412636691" ID="ID_972826576" MODIFIED="1611412651452" TEXT="Fehlersuche">
+<icon BUILTIN="back"/>
+<node CREATED="1611412673543" ID="ID_1658996929" MODIFIED="1611412691750" TEXT="versuchshalber explizit einen Link per \ref erzweingen"/>
+<node CREATED="1611412652657" ID="ID_1149640138" MODIFIED="1611412667586" TEXT="doxygen-warning.txt durchsuchen"/>
+<node CREATED="1611412694100" ID="ID_1782021607" MODIFIED="1611412711705" TEXT="sicherstellen da&#xdf;...">
+<node CREATED="1611412712385" ID="ID_1286698190" LINK="https://stackoverflow.com/a/46895346" MODIFIED="1611416096145" TEXT="der umschlie&#xdf;ende Namespace dokumentiert ist">
+<icon BUILTIN="messagebox_warning"/>
 </node>
-<node CREATED="1491098487889" ID="ID_1401713015" MODIFIED="1557498707240" TEXT="Sqlite-Support">
+<node CREATED="1611412720896" ID="ID_1416946834" MODIFIED="1611412732531" TEXT="das definierende File einen @file-Kommentar hat"/>
+</node>
+</node>
+</node>
+<node CREATED="1611414193640" ID="ID_1495280173" MODIFIED="1611414203972" TEXT="Markdown">
+<node CREATED="1611414205207" ID="ID_1304449575" MODIFIED="1611414215413" TEXT="funktioniert generell recht zuverl&#xe4;ssig"/>
+<node CREATED="1611414215893" ID="ID_1250665044" MODIFIED="1611414235234" TEXT="Header-Hierarchie mu&#xdf; konsistent sein">
+<icon BUILTIN="clanbomber"/>
+<node CREATED="1611414254368" ID="ID_1103685826" MODIFIED="1611414275946" TEXT="d.h. die erste Zwischen&#xfc;berschrift auf Level-1 (Pr&#xe4;fix &quot;#&quot;)"/>
+<node CREATED="1611414236218" ID="ID_1711467407" MODIFIED="1611414253828" TEXT="sonst werden die btrf. &#xdc;berschriften komplett unterdr&#xfc;ckt"/>
+</node>
+</node>
+<node CREATED="1491098487889" ID="ID_1401713015" MODIFIED="1611412586548" TEXT="Sqlite-Support">
+<icon BUILTIN="button_cancel"/>
 <node CREATED="1491098494497" ID="ID_1565133197" MODIFIED="1557498707241" TEXT="ist wohl noch sehr vorl&#xe4;ufig"/>
 <node CREATED="1491098499712" ID="ID_1643743799" MODIFIED="1557498707241" TEXT="wenn eine Sqlite-DB gefunden wird...."/>
 <node CREATED="1491098515845" ID="ID_1313255620" MODIFIED="1557498707241" TEXT="produziert er jede Menge Constraint-Verletzungen"/>
 <node CREATED="1491098525396" ID="ID_1962242264" MODIFIED="1557498707241" TEXT="Tip: Sqlite-DB wegl&#xf6;schen!!!"/>
+<node CREATED="1611412589929" ID="ID_1865414656" MODIFIED="1611412626461" TEXT="Doxygen 1.8.13 generiert jetzt per default kein Sqlite mehr"/>
 </node>
 </node>
 </node>