Ichthyostega
bada8ecffd
unintentionally we used copy construction in the builder expression, wenn passing in the CollectionBinding to the ChildCollectionMutator. The problem is that CollectionBinding owns a shaddow buffer, where the contents of the target collection are moved temporarily while applying the diff. The standard implementation of copy construction would cause a copy of that shaddow buffer, which boils down to a copy of the storage of the target collection. If we want to support move-only types in the collection, most notably std::unique_ptr, we can thus only use the move constructor. Beyond that there is no problem, since we're only ever moving elements, and new elements will be move constructed via emplace() or emplace_back() |
||
|---|---|---|
| .. | ||
| interact | ||
| test | ||
| abstract-tangible-test.cpp | ||
| bus-term-test.cpp | ||
| README | ||
| session-structure-mapping-test.cpp | ||
| tangible-update-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.