draft low-level component access
We have several orthogonal identification and access schemes within the UI.
A naively written UI application just attaches the core logic below some widgets and controllers -- not only does this lead to a hard to maintain codebase, this approch is even outright impossible in our case, due to the strict decoupling between core and GUI, which places us into the situation to connect a self contained core with a self contained UI. This is a binding, which, as a sideline, also generates a control structure of its own. We can indeed write code dealing with a generic UI element -- but there needs to be some place where this kind of generic designation is translated into internal structures of the UI toolkit (GTK in our case), to obtain a direct (language) reference to some implementation widget finally.
The purpose of this ticket is to investigate how such a mapping and access service can be constructed. Any actual implementation needs to be left out for now, because we do not know enough about the actual internal strutures to be built within the UI. Yet it seems prudent to draft the access scheme now, so the actual access code can be filled in later ent passant.
Such an access service can be constructed with existing building blocks from our library -- if we accept the limitation to a fixed (hard-coded) selection of base types for any elements accessed this way. We do not need to assume one single base interface. A prototype version of the interface and access mechanism is in place now, with a mocked / faked backend. The access mechanism relies on a
lib::Variantand a variant visitor to pick the right conversion path, which incurs two indirections plus adynamic_castfor any access (double-dispatch). I am not aware of any typesafe and generic solution with lower overhead; moreover this level of safety and overhead seems adequate here: it is a rather unspecific "point and shot" kind of access, to be used from a wide array of different circumstances, and thus there is quite some risk for wrong assumptions on the client side. The access is expected to happen triggered by user interaction, not by repeated ongoing processing.