Ichthyostega
a683e689f0
This involves some quite tricky changes in the way types are composed to form an iterator-pipeline. Some wrappers are added as adaptors or for additional safety-checks, and to provide a builder-API. Unfortunately, when building a new `IterExplorer` iterator pipeline from an existing pipeline naively, composing all those types will add several unecessary intermediary wrapper-layers. Worse even, the handling of `BaseAdapter` prevents the new tuple-zipping iterator actually to pass-through any `expandChildren()` call. These issues are a consequence of using templated types, instead of fixed types with an interface; we can not just determine if some wrapper is present — unless the wrapper itself ''helps by exposing a tag.'' Even while I must admit that the whole packaging and adaptation machinery of `IterExplorer` looks dangerously complex already, using dedicated type tags for this single purpose seems like a tenable soulution. |
||
|---|---|---|
| .. | ||
| ctrl | ||
| interact | ||
| model | ||
| test | ||
| abstract-tangible-test.cpp | ||
| bus-term-test.cpp | ||
| 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.