Commit graph

38 commits

Author SHA1 Message Date
5f6854621e Command-Cycle: remove the separate 'bang!' message
as it turns out, we can always trigger commands right away,
the moment all arguments are known. Thus it is sufficient to
send a single argument binding message, which allows us to
get rid of a lot or ugly complexities (payload visitor).
2017-04-14 23:45:35 +02:00
05aaa74422 MERGE Doxygen clean-up done during the last months 2017-04-01 23:59:00 +02:00
155bf95ce5 Doxygen: magically insert a reference to the test class
this bit of Sed magic relies on the fact that we happen to write
the almost correct class name of a test into the header comment.

HOWTO:
for F in $(find tests -type f \( -name '*.cpp' \)  -exec egrep -q '§§TODO§§' {} \; -print);
  do sed -r -i -e'
    2          {h;x;s/\s+(.+)\(Test\).*$/\\ref \1_test/;x};
    /§§TODO§§/ {s/§§TODO§§//;G;s/\n//}'
    $F;
done
2017-02-22 03:17:18 +01:00
24b3bec4be Doxygen: prepare all unit tests for inclusion in the documentation
Doxygen will only process files with a @file documentation comment.
Up to now, none of our test code has such a comment, preventing the
cross-links to unit tests from working.

This is unfortunate, since unit tests, and even the code comments there,
can be considered as the most useful form of technical documentation.
Thus I'll start an initiative to fill in those missing comments automatically
2017-02-22 01:54:20 +01:00
60adaa5639 UI-top-level: simplify name and namespace
the (Presentation)StateManager interface and implementation
seems to fit in more into the ctrl package
2017-02-19 04:27:09 +01:00
48e9b7594a Doxygen: identify all files lacking a @file comment
reason is, only files with a @file comment will be processed
with further documentation commands. For this reason, our Doxygen
documentation is lacking a lot of entries.

HOWTO:
find src -type f \( -name '*.cpp' -or -name '*.hpp' \) -not -exec egrep -q '\*.+@file' {} \; -print -exec sed -i -r -e'\_\*/_,$ { 1,+0 a\
\
\
/** @file §§§\
 ** TODO §§§\
 */
}' {} \;
2016-11-03 18:20:10 +01:00
d7d90bf491 Element protocol: broadcast of state reset messages unit test PASS
This basically finishes definition of the fundamental
UI-Element and Bus protocol -- with one notable exception:
how to mutate elements by diff.

This will be the next topic to address
2016-02-14 05:03:08 +01:00
18b6a388a0 implement state reset handlers / mock handlers 2016-02-14 03:42:10 +01:00
afeedfc288 draft state reset behaviour (test)
indeed building on the new broadcast functionality now.
Probably this implies we'll get some broadcast-with-filter eventually
2016-02-14 02:42:14 +01:00
44bb044eee message broadcast implementation unit test PASS
...was indeed dead easy to implement
2016-02-14 02:20:51 +01:00
b5b62f101f WIP: draft a message broadcasting function
not really sure about its usefullness, but it seems
low hanging fruit for me right now (while I am still
aware of all details how the UI-Bus works).

This might possibly be helpful to broadcast "reset" messages....
2016-02-14 01:47:21 +01:00
1b9e4a7310 test to cover call sequence of message dispatch in UI-Bus 2016-02-14 01:34:58 +01:00
0be12aaa79 PresentationStateManager unit test PASS
basic state capturing, storage and replay now works as intended
More elaborate state management will be implemented later,
when we know more about perspectives and work sites!
2016-02-13 23:53:09 +01:00
4da75dd4d3 bus protocol change: special handling for reset state marks
- suppres sending redundant stat mark messages from MockElm
- emit a "reset" state mark when an actual reset happens
- let the PresentationStateManager discard recorded special state
  when receiving a "reset" mark for a given element
2016-02-13 23:48:34 +01:00
94576af4df finialise simple state manager implementation
...and rearrange storage interface to suit
2016-02-13 22:55:59 +01:00
071f49027f change presentation state manager API
...based on elementIDs rather, to avoid any
tangling and trickery with reconstructing IDs
2016-02-13 22:55:58 +01:00
f58b2af228 stub new parts 2016-02-13 22:55:58 +01:00
1e5c1059d3 WIP: draft basics of state manager interface 2016-02-13 22:55:58 +01:00
44785859ea convenience shortcut to simplify command invocation via Bus 2016-02-13 22:55:57 +01:00
41c8c948e3 explicit size check to generate a meaningful error message
the values.child() call would also do a bounds check,
but only to rise a error::Invalid "index out of bounds".
So now we generate a clear message to indicate that
actually a runtime-checked type mismatch caused this problem
2016-02-13 22:55:57 +01:00
a7cd8996aa immutable-arguments(#989): proof-of concept
seems to work as assumed; we'll just have to construct
a new holder tuple in place when binding arguments.
Doesn't look too bad for me
2016-02-06 19:42:41 +01:00
dfc28ca2a0 UI-Bus command handling protocol unit test PASS
still TODO: the ability to use immutable types
within the command framework. In theory, this
shouldn't be had to implement, since we're creating
a new opaque value holder within the command registry
anyway, so it should be sufficient to refrain from
re-assigning a new value tuple. This is relevant,
since e.g. our time framework is built on immutable
value types.
2016-02-06 01:28:39 +01:00
743a30c1ed command binding via UI-Bus implemented and covered in mock setup 2016-02-05 17:07:42 +01:00
3f22150ab3 back to topic: get all the arguments of command binding logged
...when the Test-Nexus processes a command binding message.
In the real system of course we do not want to log every bind message.

The challenge here is the fact that command binding as such
is opaque, and the types of the data within the bind message
are opaque as well. Finally I settled on the compromise
to log them as strings, but only the DataCap part;
most value types applicable within GenNode
have a string representation to match.
2016-02-05 15:55:22 +01:00
3fef76e1d7 command-binding(#990): add new GenNode based argument binding
based on the new generic tuple builder, we're now able to
add a new binding function into the command implementation
machinery, alongside the existing one. As it stands, the
latter will be used rather by unit tests, while the new
access path is what will be actually taken within
the application, when receiving argument binding
messages dispatched via the UI-Bus.
2016-01-29 00:59:34 +01:00
1dc9642ec4 draft implementation of diagnostic command handler 2016-01-22 19:44:17 +01:00
eaa12499f3 back to UI command invocation: basically implement a placeholder command
based on the previous experiments, this adds a fake operation
and a definition frame to hook this operation as pseudo Proc-Layer command

WIP: the invocation itself is not yet implemented.
     We need to build a custom invocation pattern for that,
     in order to be able to capture the instance-ID of the command
     on invocation

NOTE: also, because of #989, we can not bind a time value for this test
2016-01-22 12:19:25 +01:00
627b11dcb7 stub the new functions 2016-01-15 04:57:49 +01:00
b2e0c8fa63 WIP: draft a test to verify the bus side of UI command invocation
basically this comes down to provide some convenience fixture
within the test::Nexus, which automatically generates and wires
mock commands.

Not sure if this is even possible to the extent envisioned here
2016-01-15 04:30:43 +01:00
0b21eeae2f extend unit test verification on UI command invocation 2016-01-15 02:29:33 +01:00
2c20d407fc mass clean-up: adapt usage of std::cout pretty much everywhere
- remove unnecessary includes
- expunge all remaining usages of boost::format
- able to leave out the expliti string(elm) in output
- drop various operator<<, since we're now picking up
  custom string conversions automatically
- delete diagnostics headers, which are now largely superfluous
- use newer helper functions occasionally

I didn't blindly change any usage of <iostream> though;
sometimes, just using the output streams right away
seems adequate.
2016-01-07 20:12:46 +01:00
96ba1fc2d0 basic BusTerm lifecycle unit test PASS 2016-01-03 05:32:05 +01:00
c9ea9de54d cover basic up-link and down-link communication in BusTerm_test 2016-01-03 03:37:52 +01:00
540151b56b provide a mock handler for commands and state marks
in the real system, this will be the task of the CoreService,
while here, in test mode, we allow to install handling closures
from the unit-test-code
2016-01-03 03:23:39 +01:00
2e4d74747e implement logging overrides in the Test-Nexus implementation
the actual functionality is forwareded to the base class,
which is the regular Nexus Hub
2016-01-02 19:16:37 +01:00
3230660d86 implement, cover and use the log clearing function 2016-01-02 02:00:07 +01:00
d27d9f79c2 define first test case to cover the UI-Bus side of basic element interactions
this test is intended as counterpart to
AbstractTangible_test::verify_mockManipulation()

It creates a mock element and verifies bidirectional
connnectivity to the UI-Bus
2016-01-02 01:23:09 +01:00
42c2569bb8 test driven planning
next steps will be to invent a mock UI element
and then to wire and operat this mock through the UI-Bus
2015-11-26 22:23:43 +01:00