ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/gui
History
Ichthyostega b3f0605b9b SessionCommand-facade: consider how to expose command invocation 
after reading some related code, I am leaning towards a design
to mirror the way command messages are sent over the UI-Bus.

Unfortunately this pretty much abandons the possibility to
invoke these operations from a client written in C or any
other hand made language binding. Which pretty much confirms
my initial reservation towards such an excessively open
and generic interface system.
2016-12-23 07:26:00 +01:00
..
interact implement deleting of individual property state data 2016-02-14 04:29:40 +01:00
test Finish AbstractTangible_test and the basic UI-Element protocol 2016-10-04 03:50:44 +02:00
abstract-tangible-test.cpp SessionCommand-facade: consider how to expose command invocation 2016-12-23 07:26:00 +01:00
bus-term-test.cpp Element protocol: broadcast of state reset messages unit test PASS 2016-02-14 05:03:08 +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.