diff --git a/src/gui/model/element-access.hpp b/src/gui/model/element-access.hpp index d589a9c14..397728796 100644 --- a/src/gui/model/element-access.hpp +++ b/src/gui/model/element-access.hpp @@ -96,16 +96,15 @@ namespace model { virtual ~ElementAccess () { } ///< this is an interface - template - using Result = lib::Result; - /* == Access by Location == */ template - Result access (UICoord const& destination); + lib::Result access (UICoord const& destination); template - Result access_or_create (UICoord const& destination, size_t limitCreation = LUMIERA_MAX_ORDINAL_NUMBER); + lib::Result access_or_create (UICoord const& destination, size_t limitCreation = LUMIERA_MAX_ORDINAL_NUMBER); + + UICoord allocate (UICoord const& destination, size_t limitCreation = LUMIERA_MAX_ORDINAL_NUMBER); protected: @@ -142,7 +141,7 @@ namespace model { struct ElementAccess::TypeConverter : RawResult::Visitor { - Result result{"not convertible"}; + lib::Result result{"not convertible"}; template // note the "backward" use. We pick that base interface using canUpcast = std::is_convertible; // into which our desired result type can be upcast, because @@ -155,7 +154,7 @@ namespace model { if (pb) result = *dynamic_cast (pb); else - result = Result{"access returns empty answer"}; + result = lib::Result{"access returns empty answer"}; } }; @@ -173,7 +172,7 @@ namespace model { * and convertible to `bool(false)` */ template - inline ElementAccess::Result + inline lib::Result ElementAccess::access (UICoord const& destination) { return access_or_create (destination, 0); @@ -188,7 +187,7 @@ namespace model { * and convertible to `bool(false)` (or raises an exception on attempted access) */ template - inline ElementAccess::Result + inline lib::Result ElementAccess::access_or_create (UICoord const& destination, size_t limitCreation) { TypeConverter converter; diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 9b4f9af9d..052bd25a5 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -9917,7 +9917,7 @@ In addition to querying the interpretation of a given coordinate spec with respe __Navigation mutations:__ //In theory,// it would even be possible to extend the path by creating suitable child components; but actually this would require all "elements" to implement a suitable mutation interface -- which in the case of //generic elements// might be far beyond the common ground. For this reason, we keep mutation of the backing environment outside of a path mutator's scope and rather keep mutation limited to the path itself. -
+
//Cross cutting access to elementary UI structures.//
 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 code base, this approach 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.
 
@@ -9930,6 +9930,9 @@ At the time of this writing, it is not really clear if we need such a facility a
 * so effectively an access request will drill down the real UI topology, following the path of the given UI Coordinates.
 * the result can then be packaged into a {{{lib::Variant}}} and use a //variant visitor// (double dispatch) to invoke the apropriate {{{dynamic_cast}}}
 * together, this mechanism allows us to return direct language references to actual implementation widgets
+
+!Extend UICoord to an opaque concrete {{{UILocation}}} handle?
+This is a possible different turn in the design, considered as an option {{red{as of 6/2018}}}. Such would complement a symbolic coordinate specification with an opaque handle pointing to an actually existing UI widget. Access to this widget requires knowledge about its actual type -- basically a variant record tacked onto the UICoord representation, packaged into a subclass of the latter. The obvious benefit would be to avoid drilling down into the UI widget tree repeatedly, since there is now a way to pass along hidden //insider information// regarding actual UI elements. However, such a design bears a "smell" of being implementation driven, and undercuts the whole idea of a entirely symbolic layer of location specifications. Building such an extension can be considered sensible only under the additional assumption that this kind of //location token// is to be passed over various interfaces and indeed becomes a generic token of exchange and interaction within the UI layer implementation -- which, right now is not a given.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 8ad017457..7673d3e70 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -11474,36 +11474,19 @@ - + + - - - - - - -

- ...wenn ich es irgendwie schaffe, -

-

- doch auch noch UI-Coord als Rückgabewert -

-

- da "hineinzuwürgen"... -

- - - - - + + @@ -11512,6 +11495,130 @@ + + + + + + + + + + + + + + + +

+ als Subklasse von UICoord +

+ + + + + + + + + + + + + +

+ ...denn das eigentliche Problem ist, +

+

+ daß ich noch keinerlei Implementierung schreiben kann. +

+

+ Mithin schiebe ich mir Platzhalter von der linken in die rechte Tasche +

+ + + + + + + + + + +

+ und zwar für die abstrahierte GUI-Location +

+
    +
  • + einmal symbolisch als UI-Koordinaten +
    • +
  • + einmal opaque als eingekapselte Lösung +
    • +
+

+ Und sowas ist verwirrend und verlockt gradezu, die Schachtel aufzumachen +

+

+ und an der Implementierung zu kleben +

+ + + + + + + + + + +

+ ...was bis jetzt nicht gegeben ist! +

+

+ Bis jetzt haben wir einen "Durchlauf-Erhitzer": letztlich will man nur die Referenz +

+

+ auf das GUI-Element haben, und die dazwischenliegende symbolische Schicht +

+

+ dient nur der Konfiguration und Lösungs-Suche. +

+

+ +

+

+ Wenn allerdings später mal diese UILocation == bereits decodierte UI-Koordinaten +

+

+ ein eigenständiges Token wird, welches über mehrere Schnittstellen hinweg geschoben wird, +

+

+ dann und nur dann würde die zusätzliche API-Komplexität Sinn machen. +

+ + + + + + + + + + + + + + +

+ die verfickte Performance wird ignoriert +

+ + + + + +