Ichthyostega
289f92da7e
...in a similar vein as done for the product calculation. In this case, we need to check the dimensions carefully and pick the best calculation path, but as long as the overall result can be represented, it should be possible to carry out the calculation with fractional values, albeit introducing a small error. As a follow-up, I have now also refactored the re-quantisation functions, to be usable for general requantisation to another grid, and I used these to replace the *naive* implementation of the conversion FSecs -> µ-Grid, which caused a lot of integer-wrap-around However, while the test now works basically without glitch or wrap, the window position is still numerically of by 1e-6, which becomes quite noticeably here due to the large overall span used for the test. |
||
|---|---|---|
| .. | ||
| ctrl | ||
| interact | ||
| model | ||
| test | ||
| abstract-tangible-test.cpp | ||
| bus-term-test.cpp | ||
| gen-node-location-query.hpp | ||
| 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.