LUMIERA.clone

History

Ichthyostega 09e7e1f8f5 WIP: pondering diff representation variants Actually I arried at the conclusion, that the receiving of a diff representation is actually a typical double-dispatch situation. This leads to the attempt to come up with a specialised visitor as standard pattern to handle and apply a diff. Obviously, we do not want the classical GoF-Visitor, but (yes, we had that discussion allready) -- well in terms of runtime cost, we have to deal with at least two indirections anyway; so now I'm exploring the idea to implement one of these indirections through a functor object, which at the same time acts as "Tag" in the diff representation language (instead of using an enum as tag)		2014-11-10 04:00:39 +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	WIP: pondering diff representation variants	2014-11-10 04:00:39 +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.