ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/gui
History
Ichthyostega a9a6aabcbc return to topic: UI element protocol 
next step will be to rig the mock element and set up
and cover the basic / generic element behaviour

This changeset
 - adapts the (planned) unit test to the semantic of
   the EventLog, which is now fully implemented

 - adjusts the function names on the public Tangible interface,
   to be better in line with the naming convention of the
   corrsponding operations on the UI-Bus:

   * "mark" operations are towards the UI element
   * "note" messages are from the UI element towards some
     state manager, which can be reached via the bus
2015-12-16 02:16:53 +01:00
..
test implement log joining in shared heap storage 2015-12-09 01:18:15 +01:00
abstract-tangible-test.cpp return to topic: UI element protocol 2015-12-16 02:16:53 +01:00
bus-term-test.cpp test driven planning 2015-11-26 22:23:43 +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 extended planning to define the operation of UI-Bus and model update 2015-01-17 16:08:56 +01:00
tangible-update-test.cpp extended planning to define the operation of UI-Bus and model update 2015-01-17 16:08:56 +01:00
test-gui-test.cpp enable special unit-tests to link against the gui 2014-10-18 04:27:07 +02: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.