Ichthyostega
0178e11e65
The old implementation relied on two layered APIs: one for the client and one for the implementer of the Allocation state. This is logically sound, yet clumsy in terms of design, since the internal API turns out to be void of actual meaning. It seems possible to eliminate this confusing structure by a clear separation of ''implementation realms'' * the ''mechanics'' of connection state management * the actual implementation of the connection The first can be provided as generic template subclass, while the latter should be confined entirely into the implementation of the `Connection` interface. Doing so requires to keep each part of the implementation strictly focused onto its purpose — something I obviously was not able to see at the time when writing this old implementation, notably because I was completely guided and driven by the test/dummy implementation without considering how an actual implementation of low-level data output would work. |
||
|---|---|---|
| .. | ||
| ctrl | ||
| interact | ||
| model | ||
| test | ||
| abstract-tangible-test.cpp | ||
| bus-term-test.cpp | ||
| DIR_INFO | ||
| gen-node-location-query.hpp | ||
| 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.