ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/gui
History
Ichthyostega f80982b52b gen-node: fix insidious data conssitency problem 
I assumed that, since GenNode is composed of copyable and
assignable types, the standard implementation will do.
But I overlooked the run time type check on the opaque
payload type within lib::Variant. When a type mismatch
is detected, the default implementation has already
assigned and thus altered the IDs.

So we need to roll our own implementation, and to add
insult to injury, we can't use the copy-and-swap idiom either.
2016-02-13 22:55:59 +01:00
..
interact gen-node: fix insidious data conssitency problem 2016-02-13 22:55:59 +01:00
test finialise simple state manager implementation 2016-02-13 22:55:59 +01:00
abstract-tangible-test.cpp state mark handling within the base element: unit test PASS 2016-02-13 22:55:58 +01:00
bus-term-test.cpp finialise simple state manager implementation 2016-02-13 22:55:59 +01:00
README enable special unit-tests to link against the gui 2014-10-18 04:27:07 +02:00
session-structure-mapping-test.cpp mass clean-up: adapt usage of std::cout pretty much everywhere 2016-01-07 20:12:46 +01:00
tangible-update-test.cpp mass clean-up: adapt usage of std::cout pretty much everywhere 2016-01-07 20:12:46 +01:00
test-gui-test.cpp mass clean-up: adapt usage of std::cout pretty much everywhere 2016-01-07 20:12:46 +01:00

README 

GUI backbone tests

The tests in this subtree are a bit special: they cover the generic and
backbone internals of the Lumiera GTK GUI. They are linked against the
complete GUI-module (gui plugin), and thus may use all related ABIs.

Yet these tests are *deliberately* compiled without any GTK, GTKmm or SigC
includes. This effectively rules out the use, even indirectly, of any GTK
widgets and APIs -- forcing the covered GUI backbone entities to stay
clean and generic at API level.

This is a decision done on purpose. The concrete GUI framework technology
shall be treated as an implementation detail. There is no point in writing
tests which click buttons in the GUI -- better delegate any significant
logic or functionality to GUI agnostic components. GUI is meant to be
a presentation layer and must not develop intelligence on its own.