ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/stage
History
Ichthyostega a90b9e5f16 Library: uniform definition scheme for error-IDs 
In the Lumiera code base, we use C-String constants as unique error-IDs.
Basically this allows to create new unique error IDs anywhere in the code.

However, definition of such IDs in arbitrary namespaces tends to create
slight confusion and ambiguities, while maintaining the proper use statements
requires some manual work.

Thus I introduce a new **standard scheme**
 * Error-IDs for widespread use shall be defined _exclusively_ into `namespace lumiera::error`
 * The shorthand-Macro `LERR_()` can now be used to simplify inclusion and referral
 * (for local or single-usage errors, a local or even hidden definition is OK)
2024-03-21 19:57:34 +01:00
..
ctrl Global-Layer-Renaming: fix remaining textual usages and IDs in the code 2018-12-10 00:09:56 +01:00
interact Library: uniform definition scheme for error-IDs 2024-03-21 19:57:34 +01:00
model the new design takes the old name 2023-06-22 20:23:55 +02:00
test Scheduler-test: fix out-of-bound access 2023-12-21 20:25:43 +01:00
abstract-tangible-test.cpp Library: uniform definition scheme for error-IDs 2024-03-21 19:57:34 +01:00
bus-term-test.cpp Library: uniform definition scheme for error-IDs 2024-03-21 19:57:34 +01:00
gen-node-location-query.hpp the new design takes the old name 2023-06-22 20:23:55 +02:00
README Global-Layer-Renaming: rearrange directories 2018-11-15 23:28:03 +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.