ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

TreeExplorer: define behaviour of new "delayed expansion" feature

Browse source 
...we need yet another feature to build the path matching for the Navigator
This commit is contained in:
Fischlurch 2018-01-01 17:43:49 +01:00
parent d5ae52e558
commit d2bbe9c61b
3 changed files with 47 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
tests/library/iter-tree-explorer-test.cpp
View file

@ -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));
}

4
wiki/renderengine.html
View file

@ -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.</pre>
</div>
<div title="UICoord" creator="Ichthyostega" modifier="Ichthyostega" created="201709222300" modified="201712170158" tags="def draft spec Concepts GuiPattern" changecount="21">
<div title="UICoord" creator="Ichthyostega" modifier="Ichthyostega" created="201709222300" modified="201801011613" tags="def draft spec Concepts GuiPattern" changecount="22">
<pre>//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 &quot;place&quot; or &quot;space&quot; 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 &quot;covered&quot; 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 &quot;covered&quot; 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

4
wiki/thinkPad.ichthyo.mm
View file

@ -7165,8 +7165,8 @@
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1514747089115" ID="ID_1696559217" MODIFIED="1514747192393" TEXT="verify_scheduledExpansion">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1514747105248" ID="ID_952786179" MODIFIED="1514747124111" TEXT="setup wie child expansion">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1514747105248" ID="ID_952786179" MODIFIED="1514824954671" TEXT="setup wie child expansion">
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1514747112048" ID="ID_1206186653" MODIFIED="1514747124984" TEXT="wird aber erst bei Iteration vollzogen">
<icon BUILTIN="flag-yellow"/>