From 5530bbede8775e0a343afd0ea4aace13e1d00ce3 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 30 Oct 2017 01:47:29 +0100 Subject: [PATCH] Navigator: decide upon the fine points of meaning anchorage vs. coverage partial vs total possible anchorage possible coverage --- src/gui/interact/ui-coord-resolver.hpp | 44 +++++-- src/gui/interact/ui-coord.hpp | 2 +- tests/gui/interact/ui-coord-resolver-test.cpp | 4 +- wiki/renderengine.html | 3 +- wiki/thinkPad.ichthyo.mm | 117 ++++++++++++++++-- 5 files changed, 147 insertions(+), 23 deletions(-) diff --git a/src/gui/interact/ui-coord-resolver.hpp b/src/gui/interact/ui-coord-resolver.hpp index 3ec89c2e0..5cced524b 100644 --- a/src/gui/interact/ui-coord-resolver.hpp +++ b/src/gui/interact/ui-coord-resolver.hpp @@ -176,32 +176,60 @@ namespace interact { /* === query functions === */ - /** */ + /** is this path explicitly anchored at an existing window? + * @remarks this also implies the path is complete and explicit (no wildcards). + */ bool isAnchored() const { - UNIMPLEMENTED ("path anchorage check"); + return res_.isResolved + and res_.anchor and res_.anchor != Symbol::BOTTOM; } - /** */ + /** determine if a mutation is possible to anchor the path explicitly + * @remarks basically this either means the path isAnchored(), or we're able + * to calculate a path resolution, interpolating any wildcards. + * And while the path resolution as such might fail, it was at least + * successful to determine an anchor point. The existence of such an + * anchor point implies the path is not totally in contradiction to the + * existing UI*/ bool canAnchor() const { - UNIMPLEMENTED ("determine if a mutation is possible to anchor the path explicitly"); + return isAnchored() + or (res_.isResolved and res_.covfefe) + or pathResolution() + or isAnchored(); // resolution failed, but computed at least an anchor } - /** */ + /** is this path at least _partially_ covered? + * A covered path describes an access path through widgets actually existing in the UI. + * @remarks this also implies the path is anchored, complete and explicit. + * @note this predicate tests for _partial_ coverage, which means, there might + * be some extraneous suffix in this path descending beyond existing UI + */ bool isCovered() const { - UNIMPLEMENTED ("path coverage check"); + return res_.isResolved + and res_.depth > 0; } - /** */ + /** determine if a mutation is possible to get the path (partially) covered. + * @remarks in order to be successful, a path resolution must interpolate any gaps in the + * path spec _and_ reach a point behind / below the gap (wildcards), where an existing + * explicitly stated component in the path can be confirmed (covered) by the existing UI. + * The idea behind this definition is that we do not want just some interpolated wildcards, + * rather we really want to _confirm_ the essence of the path specification. Yet we accept + * an extraneous suffix _in the explicitly given part_ of the path spec to extend beyond or + * below what exists currently within the UI. + */ bool canCover() const { - UNIMPLEMENTED ("determine if a mutation is possible to get the path covered"); + return isCovered() + or (res_.isResolved and res_.covfefe) + or pathResolution(); } diff --git a/src/gui/interact/ui-coord.hpp b/src/gui/interact/ui-coord.hpp index 75145fae7..b4ddfbfd5 100644 --- a/src/gui/interact/ui-coord.hpp +++ b/src/gui/interact/ui-coord.hpp @@ -194,7 +194,7 @@ namespace interact { /** - * @remark an _explicit_ coordinate spec does nut use wildcards + * @remark an _explicit_ coordinate spec does not use wildcards * and is anchored in a window spec */ bool diff --git a/tests/gui/interact/ui-coord-resolver-test.cpp b/tests/gui/interact/ui-coord-resolver-test.cpp index 45e84c4be..4f5e295a4 100644 --- a/tests/gui/interact/ui-coord-resolver-test.cpp +++ b/tests/gui/interact/ui-coord-resolver-test.cpp @@ -79,7 +79,7 @@ namespace test { virtual void run (Arg) { -// verify_simpleUsage(); + verify_simpleUsage(); verify_backingQuery(); verify_queryAnchor(); verify_queryCoverage(); @@ -114,7 +114,7 @@ namespace test { // helper to answer "location queries" backed by this structure GenNodeLocationQuery locationQuery{dummyUiStructure}; - UICoord uic{"window-1","*","panelX","someView"}; + UICoord uic{"window-2","*","panelX","someView"}; UICoordResolver resolver{uic, locationQuery}; CHECK (not resolver.isCovered()); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index c8fae4c2d..49a3ab013 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -9648,7 +9648,7 @@ The dispatch of //diff messages// is directly integrated into the UI-Bus -- whic The Graphical User interface, the upper layer in this hierarchy, embodies everything of tangible relevance to the user working with the application. The interplay with Proc-Layer, the middle layer below the UI, is organised along the distinction between two realms of equal importance: on one side, there is the immediate //mechanics of the interface,// which is implemented directly within the ~UI-Layer, based on the Graphical User Interface Toolkit. And, on the other side, there are those //core concerns of working with media,// which are cast into the HighLevelModel at the heart of the middle layer. -
+
//A topological addressing scheme to designate structural locations within the UI.//
 Contrary to conventional screen pixel coordinates, here we aim at a topological description of the UI structure. Such a framework of structural reference allows us                                                                     
 * to refer to some "place" or "space" within the interface                                    
@@ -9696,6 +9696,7 @@ In addition to the //locally decidable properties// of a coordinate spec, which
 :* it is //partially covered// with an remaining, uncovered extension part
 :* it is //possible to cover completely//
 :* it is //impossible to cover//
+__Some fine points to note__: Anchorage and coverage are not the same thing, but coverage implies anchorage. Only when a path is complete (starts with the window spec) and explicit (has no wildcards), then anchorage implies also partial coverage (namely at least to depth 1). To determine the possible coverage means to perform a resolution with backtracking to pick the maximal solution. Moreover, since "covered" means that the path specification //is at least partially supported by the real UI,// we establish an additional constraint to ensure this resolution did not just match some arbitrary wildcards. Rather we demand that beind / below the last wildcard there is at least one further explicit component in the path spec, which is supported by the real UI. As a consequence, the coverage resolution may fail altogether, will still providing at least an possible anchor point.
 !!!Mutations
 In addition to querying the interpretation of a given coordinate spec with respect to the current UI environment, it is also possible to rewrite or extend the spec based on this environment
 ;anchoring
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 9c3d516bf..f9e218a2a 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -4266,6 +4266,86 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+    
+  
+  
+    

+      ...denn wir verlangen, daß wir nach dem Interpolieren über eine Lücke
+    

+    

+      immer noch mindestens ein explizt gegebenes Element im Pfad haben,
+    

+    

+      welches auch von der UI-Topologie bestätigt wird.
+    

+    

+      Grund: wir wollen vermeiden, abschließende Wildcards bloß irgendwie zu binden
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      nämlich wenn der Pfad mit einem explizit gegebenen Präfix anfängt,
+    

+    

+      dann aber Wildcards enthält, die nicht nach den verschärften Bedingungen gecovert werden können.
+    

+  
+
+
+
+
+
+  
+    
+  
+  
+    

+      beispielsweise
+    

+    
    
+      
  • 
+        wenn schon das Präfix nicht paßt
+      
    • 
+      
  • 
+        wenn das erste Element nach dem Gap nirgends im realen UI in der tiefe existiert
+      
    • 
+      
  • 
+        wenn mehr Wildcards da sind, als restliche Tiefe zum Matchen
+      
    • 
+    

+  
+
+
+
+
+
+
 
 
 
@@ -4373,7 +4453,7 @@
 
 
 
-
+
 
   
     
@@ -4383,7 +4463,7 @@
       Tiefensuche über die reale UI-Topologie
     

     

-      Ziel ist den Pfad bestmöglich zu covern
+      Ziel ist, den Pfad bestmöglich zu covern
     

     

       Es gilt die erste maximal abdeckende Lösung
@@ -4468,8 +4548,8 @@
 
 
 
-
-
+
+
 
 
   
@@ -4503,18 +4583,33 @@
 
 
 
-
-
+
+
 
 
 
-
-
+
+
 
-
-
+
 
 
+
+
+  
+    
+  
+  
+    

+      ...verwendet einen GenNode-Tree
+    

+    

+      als Repräsentation des real-existierenden UI
+    

+  
+
+
+
 
 
 
@@ -4617,7 +4712,7 @@
 
 
 
-
+