Ichthyostega
42277c5760
the usual drill... once there is one additional non explicit conversion ctor, lots of preferred conversion paths are opened under various conditions. The only remedy is to define all ctors explicitly, instead of letting the compiler infer them (from the imported base class ctors). Because this way we're able to indicate a yet-more-preferred initialisation path and thus prevent the compiler from going the conversion route. In the actual case, the coordinate Builder is the culprit; obviously we need smooth implicit conversion from builder expressions, and obviously we also want to restrict Builder's ctors to be used from UICoord solely. Unfortunately this misleads the compiler to do implement a simple copy construction from non const reference by going through the prohibited Builder ctor, or to instantiate the vararg-ctor inherited from PathArray. Thus better be explicit and noisy... |
||
|---|---|---|
| .. | ||
| ctrl | ||
| interact | ||
| test | ||
| abstract-tangible-test.cpp | ||
| bus-term-test.cpp | ||
| README | ||
| session-structure-mapping-test.cpp | ||
| test-gui-test.cpp | ||
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.