From 603f9e2b7d320ddae47b5cb018a566a1f231e344 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 27 Dec 2015 03:16:49 +0100 Subject: [PATCH] DOC: fix some Doxygen link syntax I worked under the erroneous assumption, that Doxygen will use its internal entity-IDs as the link-IDs when generating mardown-links. Yes, this seemed logical and this would be the way I'd implement it.... But seemingly, Doxygen is not so consistent when it comes to questions of syntax. The same holds true for markdown, which lacking a coherent definition anyway. Another problem is that Doxygen's auto-link generation frequently fails, for reasons not yet clear to me. Sometimes it seems to be necessary to give it a nudge by including the \ref command. While I'm not willing to go into focussed invstigation of Doxygen syntax right now, at least I've done a search-and-replace to remove the malformed links I've written the last days --- src/gui/ctrl/bus-controller.cpp | 12 ++++----- src/gui/ctrl/bus-controller.hpp | 10 +++---- src/gui/ctrl/bus-term.hpp | 6 ++--- src/gui/ctrl/nexus.hpp | 6 ++--- src/gui/model/tangible.cpp | 4 +-- src/gui/model/tangible.hpp | 39 ++++++++++++++-------------- src/gui/ui-bus.hpp | 16 ++++++------ src/lib/iter-cursor.hpp | 8 +++--- src/lib/test/event-log.hpp | 12 ++++----- src/lib/test/test-helper.hpp | 2 +- tests/gui/abstract-tangible-test.cpp | 12 ++++----- tests/gui/test/mock-elm.hpp | 6 ++--- tests/gui/test/test-nexus.cpp | 6 ++--- tests/gui/test/test-nexus.hpp | 8 +++--- tests/library/iter-cursor-test.cpp | 2 +- tests/library/iter-explorer-test.cpp | 10 +++---- 16 files changed, 80 insertions(+), 79 deletions(-) diff --git a/src/gui/ctrl/bus-controller.cpp b/src/gui/ctrl/bus-controller.cpp index 2398eb131..db569704c 100644 --- a/src/gui/ctrl/bus-controller.cpp +++ b/src/gui/ctrl/bus-controller.cpp @@ -24,9 +24,9 @@ /** @file bus-controller.cpp ** Implementation of the UI backbone service for messaging. ** Any globally relevant widget or controller within the Lumiera UI - ** is connected to the [UI-Bus][ui-bus.hpp], which is largely implemented - ** within this compilation unit. [Clients][gui::model::Tangible] typically - ** use the [BusTerm-Interface][bus-term.hpp] to route generic actions and + ** is connected to the [UI-Bus](ui-bus.hpp), which is largely implemented + ** within this compilation unit. [Clients](\ref gui::model::Tangible) typically + ** use the [BusTerm-Interface](bus-term.hpp) to route generic actions and ** receive notifications, state changes and mutations. ** ** @note as of 11/2015 this is complete WIP_WIP @@ -119,7 +119,7 @@ namespace ctrl { /** capture and record a "state mark" for later replay for restoring UI state. - * @param subject the [endpoint-ID][BusTerm::endpointID_] of the emitting element + * @param subject the [endpoint-ID](BusTerm::endpointID_) of the emitting element * @param mark the actual state update or notification message to be remembered * @remarks relevant changes to presentation state, which are to be recalled and * restored later, are emitted from the place they occur, packaged as @@ -138,11 +138,11 @@ namespace ctrl { /** route a state update or notification to the given subject. - * @param subject the [endpoint-ID][BusTerm::endpointID_] of the element to address + * @param subject the [endpoint-ID](BusTerm::endpointID_) of the element to address * @param mark the actual state update or notification message to be delivered * @remarks each "subject" to be addressed is a gui::model::Tangible, and as such * holds a BusTerm of its own, which in turn ensures a registration and - * connection from the [central routing hub][gui::ctrl::Nexus] down to + * connection from the [central routing hub](gui::ctrl::Nexus) down to * the element. Thus, the default implementation is just to pass the * given state mark "up", assuming that it will reach the hub * eventually, which in turn knows hot to reach the element. diff --git a/src/gui/ctrl/bus-controller.hpp b/src/gui/ctrl/bus-controller.hpp index b3754a6ea..9a9d79d4b 100644 --- a/src/gui/ctrl/bus-controller.hpp +++ b/src/gui/ctrl/bus-controller.hpp @@ -22,10 +22,10 @@ /** @file bus-controller.hpp - ** The service actually operating the [UI-Bus][ui-bus.hpp]. + ** The service actually operating the [UI-Bus](ui-bus.hpp). ** This service includes state management for the bus operations - ** as a whole, it includes the setup of a [routing table][ctrl::Nexus] - ** and it includes the management of connection to the [core service][core-service.hpp] + ** as a whole, it includes the setup of a [routing table](\ref ctrl::Nexus) + ** and it includes the management of connection to the [core service](core-service.hpp) ** Service for bus-controller. ** This header defines the basics of... ** @@ -37,8 +37,8 @@ ** @todo WIP ///////////////////////TICKET #959 ** ** @see ////TODO_test usage example - ** @see [implementation][bus-controller.cpp] - ** @see [front-end and lifecycle][UiBus] + ** @see [implementation](bus-controller.cpp) + ** @see [front-end and lifecycle](UiBus) ** */ diff --git a/src/gui/ctrl/bus-term.hpp b/src/gui/ctrl/bus-term.hpp index 639dc1ac8..821deb306 100644 --- a/src/gui/ctrl/bus-term.hpp +++ b/src/gui/ctrl/bus-term.hpp @@ -32,9 +32,9 @@ ** \par Lifecycle and identity ** An BusTerm is always created starting from another BusTerm, to ** which it will be wired. Moreover, each BusTerm bears a distinct - ** [identity][::endpointID_], which is used as _implicit subject_ + ** [identity](\ref ::endpointID_), which is used as _implicit subject_ ** for emanating messages, or as explicit destination for routing. - ** The whole [UI-Bus][BusController] is built to perform within the + ** The whole [UI-Bus](\ref BusController) is built to perform within the ** UI event thread and thus is _not threadsafe_. For that reason, ** the automatic detachment built into each BusTerm's dtor is ** sufficient to ensure sane connectivity. @@ -77,7 +77,7 @@ namespace ctrl{ /** * connection point at the UI-Bus. * The UI-Bus is a star shaped network of terminal points, - * where each \link Tangible tangible UI element \endlink + * where each \ref model::Tangible "tangible UI element" * holds a BusTerm serving access point. The BusTerm interface * exposes the basic "verbs" available for communication within * the UI diff --git a/src/gui/ctrl/nexus.hpp b/src/gui/ctrl/nexus.hpp index 2890b63dc..c0e1108f2 100644 --- a/src/gui/ctrl/nexus.hpp +++ b/src/gui/ctrl/nexus.hpp @@ -23,8 +23,8 @@ /** @file nexus.hpp ** Core hub and routing table of the UI-Bus. - ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus][ui-bus.hpp] - ** through some [bus terminal][bus-term.hpp]. Actually, there is one special BustTerm + ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus](ui-bus.hpp) + ** through some [bus terminal](bus-term.hpp). Actually, there is one special BustTerm ** implementation, which acts as router and messaging hub. ** ** @todo initial draft and WIP-WIP-WIP as of 11/2015 @@ -100,7 +100,7 @@ namespace ctrl{ } /** add a new down-link connection to the routing table - * @param identity the [endpoint-ID][BusTerm::endpointID_] used + * @param identity the [endpoint-ID](\ref BusTerm::endpointID_) used * to address the new element to be connected to the bus. * @return backlink for the new Tangible's BusTerm to * attach itself to the Nexus. diff --git a/src/gui/model/tangible.cpp b/src/gui/model/tangible.cpp index a710bfff9..9e792cc30 100644 --- a/src/gui/model/tangible.cpp +++ b/src/gui/model/tangible.cpp @@ -25,7 +25,7 @@ ** Common base implementation of all tangible and connected interface elements. ** ** @see abstract-tangible-test.cpp - ** @see [explanation of the fundamental interactions][tangible.hpp] + ** @see [explanation of the fundamental interactions](tangible.hpp) ** */ @@ -60,7 +60,7 @@ namespace model { /** * Prepare a command or action for actual invocation, once the execution context * has been established. The action is not executed right away, but it is now ready - * and bound to the concrete arguments supplied with the [record][lib::diff::Rec]. + * and bound to the concrete arguments supplied with the [record](\ref lib::diff::Rec). * @param prototype handle to a command instantiation, to be readied for invocation * @param arguments suitable tuple of values, to be used to outfit the prototype */ diff --git a/src/gui/model/tangible.hpp b/src/gui/model/tangible.hpp index cf3f59acb..c629e4601 100644 --- a/src/gui/model/tangible.hpp +++ b/src/gui/model/tangible.hpp @@ -24,7 +24,7 @@ /** @file tangible.hpp ** Abstraction: a tangible element of the User Interface. ** This is a generic foundation for any elements of more than local relevance - ** within the Lumiera UI. Any such element is connected to the [UI-Bus][ui-bus.hpp]. + ** within the Lumiera UI.
Any such element is connected to the [UI-Bus](ui-bus.hpp). ** ** \par rationale ** Simple user interfaces can be built by wiring up the actions right within the @@ -34,9 +34,7 @@ ** in turn. This approach works, but is repetitive and thus lures the lazy programmer ** into taking shortcuts. Since we can foresee the Lumiera UI to become quite challenging ** in itself, we prefer to introduce a **mediating backbone**, impersonating the role - ** of the _Model_ and the _Controler_ in the - ** [MVC-Pattern][http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller] - ** in common UI architecture. + ** of the _Model_ and the _Controler_ in the [MVC-Pattern] in common UI architecture. ** ** The MVC-Pattern as such is fine, and probably the best we know for construction of ** user interfaces. But it doesn't scale well towards the integration into a larger and @@ -50,14 +48,15 @@ ** generic concerns of interaction control and command binding. The immediately tangible ** "mechanics" of the UI shall be implemented in a conventional way, right within the ** concrete widget (or controller) code. But, since any widget concerned with more than - ** local behaviour will inherit from [Tangible], the embedded [UI-Bus terminal][Tangible::uiBus_] + ** local behaviour will inherit from \ref Tangible, the embedded [UI-Bus terminal](\ref ctrl::BusTerm) + ** `Tangible::uiBus_` ** can be used for interaction with core services. ** ** \par the generic interface element API - ** The _generic interface element_ based on [Tangible] covers a set of behaviour common to - ** all elements of the interface. This behaviour is targeted towards the _integration_ with the - ** core application. Beyond that, there are still several concerns regarding presentation, like - ** a common styling. These are addressed the conventional way, through a common [WindowManager]. + ** 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_ + ** with the core application. Beyond that, there are still several concerns regarding presentation, + ** like a common styling. These are addressed the conventional way, through a common \ref WindowManager. ** The following discussion focuses on the aspects of integration with the core. ** ** For one reason ore another, any element in the UI can appear and go away. @@ -80,7 +79,7 @@ ** expanding and collapsing, moving by focus or manipulation of a similar presentation control. ** These manipulations in itself do not constitute an action. But there typically is some widget ** or controller, which is responsible for the touched presentation state. If this entity judges - ** the state change to be relevant and persistent, it may [send][BusTerm::note()] a **state mark** + ** the state change to be relevant and persistent, it may [send](\ref BusTerm::note()) a **state mark** ** into the UI-Bus -- expecting this marked state to be remembered. ** In turn this means the bus terminal might feed a state mark back into the tangible element, ** expecting this state to be restored. @@ -94,14 +93,14 @@ ** ** And finally, there are the _essential updates_ -- any changes in the model _for real._ ** These are sent as notifications just to some relevant top level element, expecting this element - ** to request a [diff][tree-diff.hpp] and to mutate contents into shape recursively. + ** to request a [diff](tree-diff.hpp) and to mutate contents into shape recursively. ** ** \par Interactions - ** - **lifecycle**: connect to an existing term, supply the [EntryID][Tangible::ID] of the new element. + ** - **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. - ** - **act**: send a [GenNode] representing the action + ** - **act**: send a \ref GenNode representing the action ** - **note**: _send_ a GenNode representing the _state mark_ - ** - **mark**: _receive_ a [GenNode] representing the _feedback_ or a replayed _state mark_ + ** - **mark**: _receive_ a GenNode representing the _feedback_ or a replayed _state mark_ ** - **diff**: ask to retrieve a diff, which ** - either is an incremental status update ** - or is a from-scratch reconfiguration @@ -112,11 +111,13 @@ ** - slotReveal() prompts the element to bring the indicated child into sight. ** Typically, this request will "bubble up" recursively. ** These slots are defined to be `sigc::trackable` for automated disconnection - ** see [Ticket #940][http://issues.lumiera.org/ticket/940#comment:3] for an explanation. + ** see [sigc-track] for an explanation. ** + ** [MVC-Pattern]: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller + ** [sigc-track]: http://issues.lumiera.org/ticket/940#comment:3 "Ticket #940" ** - ** @see [AbstractTangible_test] - ** @see [BusTerm_test] + ** @see \ref AbstractTangible_test + ** @see \ref BusTerm_test ** */ @@ -145,9 +146,9 @@ namespace model { * Interface common to all UI elements of relevance for the Lumiera application. * Any non-local and tangible interface interaction will at some point pass through * this foundation element, which forms the joint and attachment to the UI backbone, - * which is the [UI-Bus][ui-bus.hpp]. Any tangible element acquires a distinct identity + * which is the [UI-Bus](ui-bus.hpp). Any tangible element acquires a distinct identity * and has to be formed starting from an already existing bus nexus. - * @see [explanation of the basic interactions][tangible.hpp] + * @see [explanation of the basic interactions](tangible.hpp) */ class Tangible : public sigc::trackable diff --git a/src/gui/ui-bus.hpp b/src/gui/ui-bus.hpp index 1d0bed798..89e38edf7 100644 --- a/src/gui/ui-bus.hpp +++ b/src/gui/ui-bus.hpp @@ -27,7 +27,7 @@ ** This is a messaging system and taps into any widget of more than local relevance. ** To that end, any globally relevant (custom) widget, and all secondary controllers ** inherit from the gui::model::Tangible base. The top-level gui::UiBus element is - ** a front-end and framework component managed by the [GTK-main][GtkLumiera::main]. + ** a front-end and framework component managed by the [GTK-main](\ref GtkLumiera::main). ** ** @warning as of 12/2015, this is still totally a mess. This \em will remain ** the one-and-only master controller of the UI, but I am determined @@ -38,9 +38,7 @@ ** ** \par rationale ** The UI-Bus acts as a **mediating backbone**, impersonating the role - ** of the _Model_ and the _Controler_ in the - ** [MVC-Pattern][http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller] - ** in common UI architecture. + ** of the _Model_ and the _Controler_ in the [MVC-Pattern]in common UI architecture. ** ** The MVC-Pattern as such is fine, and probably the best we know for construction of ** user interfaces. But it doesn't scale well towards the integration into a larger and @@ -59,19 +57,19 @@ ** these core services will receive the messages, act on them and _respond asynchronously_. ** ** \par Bus interactions - ** The UI-Bus has a star shaped topology, with a central "bus master" hub, the ["Nexus"][Nexus], + ** The UI-Bus has a star shaped topology, with a central "bus master" hub, the ["Nexus"](\ref Nexus), ** which maintains a routing table. Attachment and detachment of elements can be managed automatically, ** since all of the UI-Bus operations _perform within the UI event thread._ ** ** We distinguish between _up-link messages,_ directed towards some central service ** (presentation state management or command invocation) and _down-link messages,_ ** directed towards individual elements. The interactions at the bus are closely interrelated - ** with the [elementary UI-Element operations][tangible.hpp]. + ** with the [elementary UI-Element operations](tangible.hpp). ** ** - **act**: send a [GenNode] representing the action - ** - in a first step, a command prototype is [outfitted][InvocationTrail::bind()] with actual + ** - in a first step, a command prototype is [outfitted](\ref InvocationTrail::bind()) with actual ** parameter values. -> see [InvocationTrail] - ** - the actual command invocation is triggered by a ["bang" message][InvocationTrail::bang()] + ** - the actual command invocation is triggered by a ["bang" message](\ref InvocationTrail::bang()) ** - **note**: send a [GenNode] representing the _state mark;_ ** some (abstracted) presentation state manager is expected to listen to these messages, ** possibly recording state to be restored later. The contents of the _state mark_ message @@ -88,6 +86,8 @@ ** @see ctrl/nexus.hpp ** @see ctrl/core-service.hpp ** + ** [MVC-Pattern]: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller + ** ** @todo as of 1/2015, this header needs to be reshaped ////////////////////TICKET #959 ** */ diff --git a/src/lib/iter-cursor.hpp b/src/lib/iter-cursor.hpp index 1e4ffa2b8..5abcb5d2f 100644 --- a/src/lib/iter-cursor.hpp +++ b/src/lib/iter-cursor.hpp @@ -26,12 +26,12 @@ ** This wrapper relies on the ability of typical STL container iterators ** to work in both directions, similar to std::reverse_iterator. ** Yet it is a single, self-contained element and in compliance to the - ** ["Lumiera Forward Iterator"][iter-adapter.hpp] concept. But it has - ** the additional ability to [switch the working direction][IterCursor::switchDir]. + ** ["Lumiera Forward Iterator"](iter-adapter.hpp) concept. But it has + ** the additional ability to [switch the working direction](\ref IterCursor::switchDir). ** ** @see IterCursor_test ** @see iter-adapter.hpp - ** @see [usage example][event-log.hpp] + ** @see [usage example](event-log.hpp) ** */ @@ -156,7 +156,7 @@ namespace lib { * It can be built on top of any bidirectional STL iterator or similar entity, * which has an `--` operator. Initially, IterCursor will operate in forward * direction; irrespective of the current direction, it always fulfils the - * ["Lumiera Forward Iterator"][iter-adapter.hpp] concept, i.e. it can be + * ["Lumiera Forward Iterator"](iter-adapter.hpp) concept, i.e. it can be * iterated until exhaustion, in which case it will evaluate to bool(false). * @note IterCursor instances can be equality compared, also taking the * current direction into account. As a special case, all diff --git a/src/lib/test/event-log.hpp b/src/lib/test/event-log.hpp index 17e07c88b..a58e6b0e9 100644 --- a/src/lib/test/event-log.hpp +++ b/src/lib/test/event-log.hpp @@ -34,7 +34,7 @@ ** to deliver a precise indication what part of the condition failed. ** ** @see TestEventLog_test - ** @see [usage example][AbstractTangible_test] + ** @see [usage example](\ref AbstractTangible_test) ** */ @@ -357,7 +357,7 @@ namespace test{ /** find a match for an "event" _after_ the current point of reference * @remarks the term "event" designates several types of entries, which * typically capture something happening within the observed entity. - * Especially, the following [record types][lib::Record::getType()] + * Especially, the following [record types](\ref lib::Record::getType()) * qualify as event: * - `event` * - `error` @@ -552,7 +552,7 @@ namespace test{ /****************************************************************//** * Helper to log and verify the occurrence of events. * The EventLog object is a front-end handle, logging flexible - * [information records][lib::Record] into a possibly shared (vector) + * [information records](\ref lib::Record) into a possibly shared (vector) * buffer in heap storage. An extended query DSL allows to write * assertions to cover the occurrence of events in unit tests. * @see TestEventLog_test @@ -744,7 +744,7 @@ namespace test{ /** Log the creation of an object. - * Such an entry can be [matched as event][::verifyEvent] */ + * Such an entry can be [matched as event](\ref ::verifyEvent) */ EventLog& create (string text) { @@ -790,7 +790,7 @@ namespace test{ /** start a query to match for some substring. * The resulting matcher object will qualify on any log entry * containing the given string. By adding subsequent further - * query expressions on the returned [matcher object][EventMatch], + * query expressions on the returned [matcher object](\ref EventMatch), * the query can be refined. Refining a query might induce backtracking. * The final result can be retrieved by `bool` conversion */ @@ -819,7 +819,7 @@ namespace test{ /** start a query to match for some event. * @remarks only a subset of all log entries is treated as "event", * any other log entry will not be considered for this query. - * Besides the regular [events][::event()], also errors, + * Besides the regular [events](\ref ::event()), also errors, * creation and destruction of objects count as "event". * @param match text to (substring)match against the argument logged as event */ diff --git a/src/lib/test/test-helper.hpp b/src/lib/test/test-helper.hpp index 8fc012c5d..babe35c1e 100644 --- a/src/lib/test/test-helper.hpp +++ b/src/lib/test/test-helper.hpp @@ -27,7 +27,7 @@ ** for types. Some of these support meta programming to figure out the \em actual ** reference kind (value, lvalue, rvalue) of a template parameter instantiation. ** For GNU compatible compilers, we define here also an interface to the internal - ** ABI for [demangling type names][demangleCxx]. + ** ABI for [demangling type names](\ref demangleCxx). ** ** @note this header is included into a large number of tests. ** @see TestHelper_test diff --git a/tests/gui/abstract-tangible-test.cpp b/tests/gui/abstract-tangible-test.cpp index c71aece07..c9e106608 100644 --- a/tests/gui/abstract-tangible-test.cpp +++ b/tests/gui/abstract-tangible-test.cpp @@ -24,8 +24,8 @@ /** @file abstract-tangible-test.cpp ** Verify the common base shared by all interface elements of relevance. ** This test is not so much a test, than a test of the test support for testing - ** [primary elements][gui::model::Tangible] of the Lumiera GTK UI. Any such element - ** is connected to the [UI-Bus][gui::UiBus] and responds to some generic actions and + ** [primary elements](\ref gui::model::Tangible) of the Lumiera GTK UI. Any such element + ** is connected to the [UI-Bus](\ref gui::UiBus) and responds to some generic actions and ** interaction patterns. This is the foundation of any presentation state recording ** and restoration, and it serves to invoke any persistent action on the ** [Session] through a single channel and access point. @@ -114,17 +114,17 @@ namespace test { * a [MockElm] with a suitable name / ID, we're able to operate this element * programmatically and to send messages and responses from the core "up" * to this mocked interface. And since this mock element embodies an - * [event log][EventLog], the unit test code can verify the occurrence + * [event log](\ref EventLog), the unit test code can verify the occurrence * of expected events, invocations and responses. * * \par connectivity - * Any mock element will automatically connect against the [Test-Nexus][test/test-nexus.hpp], + * Any mock element will automatically connect against the [Test-Nexus](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 * retrieved or verified from the test code. Since lifecycle and robustness in * "post mortem" situations tend to be tricky for UI code, we provide a dedicated - * ["zombification"][gui::test::TestNexus::zombificate()] feature: a [MockElm] can be turned - * into an _almost dead_ state, while still hanging around. It will be detached from the + * ["zombification"](\ref gui::test::TestNexus::zombificate()) feature: a \ref MockElm can be + * turned into an _almost dead_ state, while still hanging around. It will be detached from the * "living" Test-Nexus and re-wired to some special, hidden "Zombie Nexus", causing any * further messaging activity to be logged and ignored. */ diff --git a/tests/gui/test/mock-elm.hpp b/tests/gui/test/mock-elm.hpp index a84b3e6cd..32d814349 100644 --- a/tests/gui/test/mock-elm.hpp +++ b/tests/gui/test/mock-elm.hpp @@ -48,7 +48,7 @@ ** built with a distinct core, the UI should not contain anything not tangible enough ** as just to be verified by watching it in action. The push of a button should just ** invoke an action, and the action itself should be self contained enough to be - ** tested in isolation. The UI-Bus and the [generic widget base][gui::model::Tangible] + ** tested in isolation. The UI-Bus and the [generic widget base](\ref gui::model::Tangible) ** was built to serve as a foundation to achieve that goal. ** ** @see abstract-tangible-test.cpp @@ -92,9 +92,9 @@ namespace test{ * Mock UI element or controller. * Within Lumiera, all interface components of relevance are based * on the [Tangible] interface, which we mock here for unit testing. - * This special implementation is instrumented to [log][lib::test::EventLog] + * This special implementation is instrumented to [log](\ref lib::test::EventLog) * any invocation and any messages sent or received through the UI Backbone, - * which is formed by the [UI-Bus][ui-bus.hpp]. + * which is formed by the [UI-Bus](ui-bus.hpp). * * @todo some usage details * @see abstract-tangible-test.cpp diff --git a/tests/gui/test/test-nexus.cpp b/tests/gui/test/test-nexus.cpp index ba4d12a47..f60d7feb9 100644 --- a/tests/gui/test/test-nexus.cpp +++ b/tests/gui/test/test-nexus.cpp @@ -25,8 +25,8 @@ ** Implementation of a fake UI backbone for testing. ** This compilation unit provides the actual setup for running a faked ** user interface from unit tests. Test code is assumed to access those - ** features through the [front-end][gui::test::TestNexus], while the - ** actual implementation instances are placed [as singletons][depend.hpp] + ** features through the [front-end](\ref gui::test::TestNexus), while the + ** actual implementation instances are placed [as singletons](depend.hpp) ** ** @todo initial draft and WIP-WIP-WIP as of 11/2015 ** @@ -69,7 +69,7 @@ namespace test{ * @internal fake interface backbone and unit test rig * for simulated command and presentation state handling. * This implementation embodies the routing functionality - * as found in the [real nexus][gui::ctrl::Nexus], and additionally + * as found in the [real nexus](\ref gui::ctrl::Nexus), and additionally * also implements the handler functions of the [gui::ctrl::CoreService]. * The latter allows us to intercept command invocations and presentation * state messages diff --git a/tests/gui/test/test-nexus.hpp b/tests/gui/test/test-nexus.hpp index 558c118a6..da84128c6 100644 --- a/tests/gui/test/test-nexus.hpp +++ b/tests/gui/test/test-nexus.hpp @@ -23,9 +23,9 @@ /** @file test/test-nexus.hpp ** A fake UI backbone for investigations and unit testing. - ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus][ui-bus.hpp] + ** Any relevant element within the Lumiera GTK UI is connected to the [UI-Bus](ui-bus.hpp) ** So for testing and investigation we need a white room setup to provide an instrumented - ** backbone to run any test probes against. The test::Nexus allows to [hook up][testUI()] + ** backbone to run any test probes against. The test::Nexus allows to [hook up](\ref testUI()) ** a generic interface element, to participate in a simulated interface interaction. ** ** This class test::Nexus acts as front-end for unit tests, while the actual implementation @@ -59,8 +59,8 @@ namespace test{ /** * Mock UI backbone for unit testing. - * In the absence of a real UI, this simulated [UI-Bus][ui-bus.hpp] - * can be used to wire a [test probe][MockElm] and address it in unit testing. + * In the absence of a real UI, this simulated [UI-Bus](ui-bus.hpp) + * can be used to wire a [test probe](\ref MockElm) and address it in unit testing. * * @note behind the scenes, this is a singleton. Use the provided * attachment point testUI() in order to wire and hook up new diff --git a/tests/library/iter-cursor-test.cpp b/tests/library/iter-cursor-test.cpp index f4ea5eee4..28f3e5b85 100644 --- a/tests/library/iter-cursor-test.cpp +++ b/tests/library/iter-cursor-test.cpp @@ -74,7 +74,7 @@ namespace test{ * * @see iter-cursor.hpp * @see iter-adapter.hpp - * @see [usage example][event-log.hpp] + * @see [usage example](event-log.hpp) */ class IterCursor_test : public Test { diff --git a/tests/library/iter-explorer-test.cpp b/tests/library/iter-explorer-test.cpp index 66733c260..fecaae6c9 100644 --- a/tests/library/iter-explorer-test.cpp +++ b/tests/library/iter-explorer-test.cpp @@ -192,12 +192,12 @@ namespace test{ * @test use a simple source iterator yielding numbers * to build various functional evaluation structures, * based on the IterExplorer template. - * - the [state adapter][verifyStateAdapter] iterator + * - the [state adapter](\ref verifyStateAdapter) iterator * construction pattern - * - helper to [chain iterators][verifyChainedIterators] - * - building [tree exploring structures][verifyDepthFirstExploration] - * - the [monadic nature][verifyMonadOperator] of IterExplorer - * - a [recursively self-integrating][verifyRecrusiveSelfIntegration] + * - helper to [chain iterators](\ref verifyChainedIterators) + * - building [tree exploring structures](\ref verifyDepthFirstExploration) + * - the [monadic nature](\ref verifyMonadOperator) of IterExplorer + * - a [recursively self-integrating](\ref verifyRecrusiveSelfIntegration) * evaluation pattern * * \par Explanation