Reading my work notes from two years ago, the concept can be validated. Clarify the relation of the interfaces involved, and the role foreseen for the upcoming `ZoomWindow` abstraction. This solution approach will lead to multiple-stage indirect calls, which however are deemed not to be overly concerning and will be investigated later, to avoid premature optimisation (see #1254) - `DisplayMetric` is a focused special purpose abstraction - it belongs into the general abstraction of the `DisplayManager` - it is rather linked by use to the other abstraction, the `CanvasHook` - while the `RelativeCanvasHook` is not an interface, but an implementation mix-in - and the actual `DisplayMetric` implementation can likewise be provided as mix-in, since it will typically be implemented in terms of a `ZoomWindow` Using this scheme, it will be possible to avoid some of the indirect cally by making this mix-in visible higher up the call graph -- in case the actual need for optimisation can be confirmed in practice. |
||
|---|---|---|
| .. | ||
| common | ||
| include | ||
| lib | ||
| lumiera | ||
| plugin | ||
| stage | ||
| steam | ||
| tool | ||
| vault | ||
| .gitignore | ||
| DIR_INFO | ||
| doxygen.dox | ||
| SConscript | ||