diff --git a/tests/library/iter-tree-explorer-test.cpp b/tests/library/iter-tree-explorer-test.cpp index 5aa9eabcf..0b5a4d9aa 100644 --- a/tests/library/iter-tree-explorer-test.cpp +++ b/tests/library/iter-tree-explorer-test.cpp @@ -682,7 +682,49 @@ namespace test{ void verify_scheduledExpansion() { - UNIMPLEMENTED ("schedule child expansion to be performed on next iteration"); + auto ii = treeExplore(CountDown{6}) + .expand([](uint j){ return CountDown{j-2}; }) + .expandOnIteration(); + + CHECK (!isnil (ii)); + CHECK (6 == *ii); + ++ii; + CHECK (5 == *ii); + CHECK (ii.depth() == 0); + + ii.expandChildren(); + CHECK (5 == *ii); + CHECK (ii.depth() == 0); + ++ii; + CHECK (3 == *ii); + CHECK (ii.depth() == 1); + + ii.expandChildren(); + ii.expandChildren(); + CHECK (ii.depth() == 1); + CHECK (3 == *ii); + ++ii; + CHECK (1 == *ii); + CHECK (ii.depth() == 2); + ++ii; + CHECK (2 == *ii); + CHECK (ii.depth() == 1); + + ii.expandChildren(); + ++ii; + CHECK (1 == *ii); + CHECK (ii.depth() == 1); + ++ii; + CHECK (4 == *ii); + CHECK (ii.depth() == 0); + ++ii; + CHECK (3 == *ii); + ++ii; + CHECK (2 == *ii); + ++ii; + CHECK (1 == *ii); + ++ii; + CHECK (isnil (ii)); } diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 5fdf0602b..194359f74 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -9744,7 +9744,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                                    
@@ -9792,7 +9792,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, while still providing at least a possible anchor point.
+__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 behind rsp. 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, while still providing at least a 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 2efb7e6a2..5543049a0 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -7165,8 +7165,8 @@
 
 
 
-
-
+
+