Commit graph

6 commits

Author SHA1 Message Date
ac4f0bc6db ElementAccess: possibly working solution based on lib::variant
With this solution, somewhere deep down within the implementation
the knowledge about the actual result type would be encoded into
the embedded VTable within a lib::variant. At interface level,
ther will be a double dispatch based on that result type
and the desired result type, leading either to a successful
access or an error response.
2018-04-13 02:39:46 +02:00
91b83f5ede ElementAccess: (WIP) unsuccessful attempt to solve the typing problem
the intention was to return disparate result types, just depending on the
actual position in the UI-Coordinates. The client knows what to expect
2018-04-09 01:14:12 +02:00
c245098d45 ElementAccess: (WIP) first draft for internal accessor function
...but can not work this way.
Since void* has not RTTI, no secure access with downcast is possible
2018-04-09 00:51:24 +02:00
ca9abaa9d9 ElementAccess: change wiring in ViewLocator into a dependency
...reduce immediate coupling, since we do not really now what actions ElementAccess
will actually perform, and this is likely to remain this way for some time.
So just let it sit there are an on-demand dependency.

Moreover, create an (empty placeholder) implementation within WindowLocator.
So everything is set now for the actual implementation to be filled in
2018-04-07 02:55:47 +02:00
09359cf92a ElementAccess: initial brainstorming about the interface mechanics 2018-04-07 02:28:29 +02:00
dc97ab5546 ElementAccess: consider helper to encapsulte access to actual GTK structures (#1134) 2018-04-07 01:00:25 +02:00