Ichthyostega
a835a796b2
The detailed analysis of corner cases indicated a lot of hidden dangers when stretching the `IterExplorer` design beyond its limits. By deliberate choice, this design was kept open so that advanced cohesive implementation structures can be built. It is even possible ''and tolerated'' to rely on ''references'' to some degree -- assuming however that the referred memory location remains stable. As it turned out, these basic assumptions can be broken by a combination of read-ahead processing (as is necessary for grouping and filtering), together with adaptor objects embedded as value, especially when the resulting pipeline object is then moved or copied during evaluation. While my general attitude towards such extremely clever implementation constructs is "don't shoot yourself into your foot unless you need to" -- it seems prudent to clean-up some crappy code from the first attempts towards an iterator pipeline -- notably some of the »Itertools«. |
||
|---|---|---|
| .. | ||
| 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.