ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/gui/interact/ui-coord-resolver-test.cpp

756 lines
42 KiB
C++
Raw Normal View History

UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
/*
UICoordResolver(Test) - resolve UI coordinates against actual topology
Copyright (C) Lumiera.org
2017, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file ui-coord-resolver-test.cpp
** unit test \ref UICoordResolver_test
*/
#include "lib/test/run.hpp"
#include "lib/test/test-helper.hpp"
#include "gui/interact/ui-coord.hpp"
#include "gui/interact/ui-coord-resolver.hpp"
Navigator: initial draft of a UI coordinate resolver ...which in turn will drive the design of the LoactionQuery API
2017-10-16 02:39:22 +02:00
#include "gui/interact/gen-node-location-query.hpp"
Navigator: analysis indicates to limit mutations ...to limit them to the UI-Coordinates themselves, while declining the possibility to mutate the target environment through the PathResolver. Better handle changes within the target environment by dedicated API calls on the target elements, instead of creating some kind of "universal structure"
2017-10-16 01:28:49 +02:00
#include "lib/diff/gen-node.hpp"
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
#include "lib/format-util.hpp"
#include "lib/util.hpp"
#include <string>
using std::string;
Navigator: analysis indicates to limit mutations ...to limit them to the UI-Coordinates themselves, while declining the possibility to mutate the target environment through the PathResolver. Better handle changes within the target environment by dedicated API calls on the target elements, instead of creating some kind of "universal structure"
2017-10-16 01:28:49 +02:00
using lib::diff::MakeRec;
using lib::diff::Rec;
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
using lib::Symbol;
using util::isnil;
using util::join;
namespace gui {
namespace interact {
namespace test {
Modernise Unknown Exception handler and Exception messages
2018-04-02 01:48:51 +02:00
using lumiera::error::LERR_(INVALID);
using lumiera::error::LERR_(STATE);
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
/******************************************************************************//**
* @test verify query and mutation of UICoord in relation to actual UI topology.
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
* A UI-Coordinate resolver is a special builder, which is initialised by
* the given coordinate spec, and also attached to a "location query API",
* which allows to investigate the current actual UI structure. The builder
* then exposes query and mutation operations, to determine to what extent
* the coordinate spec is "covered" by the real UI, and to match and expand
* any wildcards in the coordinate spec (pattern).
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
*
* @see UICoordResolver
* @see navigator.hpp
* @see ViewLocator
* @see UICoord_test
*/
class UICoordResolver_test : public Test
{
virtual void
run (Arg)
{
Navigator: identify and fix the bug ...which was basically harmless, no fundamental problem, just a simple logical error on my behalf (using the wrong depth level)
2017-12-26 14:04:21 +01:00
verify_simpleUsage();
UI-Coordinates: next steps to cover - allow tab specification to be elided - simple comparisons between UI coordinates - local query predicates
2017-10-02 18:39:18 +02:00
verify_backingQuery();
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
verify_queryAnchor();
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
verify_mutateCoverage();
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
verify_mutateCoverPartially();
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
verify_mutateAnchor();
verify_mutateExtend();
}
Navigator: analysis indicates to limit mutations ...to limit them to the UI-Coordinates themselves, while declining the possibility to mutate the target environment through the PathResolver. Better handle changes within the target environment by dedicated API calls on the target elements, instead of creating some kind of "universal structure"
2017-10-16 01:28:49 +02:00
/** @test introduction to UI coordinate resolution
* - use a backing "real" (dummy) data structure to resolve against
* - establish a suitable implementation of the LocationQuery interface
* - attach a resolver
* - have fun
*/
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
void
UI-Coordinates: next steps to cover - allow tab specification to be elided - simple comparisons between UI coordinates - local query predicates
2017-10-02 18:39:18 +02:00
verify_simpleUsage()
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
{
Navigator: initial draft of a UI coordinate resolver ...which in turn will drive the design of the LoactionQuery API
2017-10-16 02:39:22 +02:00
// a Test dummy placeholder for the real UI structure
LocationQuery: recast syntax for inline structure definitions this fixes a silly mistake: obviously we want named sub-nodes, aka. "Attributes", but we used the anonymous sub-nodes instead, aka. "Children" Incidentally, this renders the definitions also way more readable; in fact the strange post-fix naming notation of the original version was a clear indication of using the system backwards....
2017-10-28 00:06:44 +02:00
Rec dummyUiStructure = MakeRec()
.set("window-1"
, MakeRec()
.type("perspective-A")
)
.set("window-2"
, MakeRec()
.type("perspective-B")
.set("panelX", MakeRec())
.set("panelXX", MakeRec())
);
Navigator: analysis indicates to limit mutations ...to limit them to the UI-Coordinates themselves, while declining the possibility to mutate the target environment through the PathResolver. Better handle changes within the target environment by dedicated API calls on the target elements, instead of creating some kind of "universal structure"
2017-10-16 01:28:49 +02:00
Navigator: initial draft of a UI coordinate resolver ...which in turn will drive the design of the LoactionQuery API
2017-10-16 02:39:22 +02:00
// helper to answer "location queries" backed by this structure
GenNodeLocationQuery locationQuery{dummyUiStructure};
Navigator: decide upon the fine points of meaning anchorage vs. coverage partial vs total possible anchorage possible coverage
2017-10-30 01:47:29 +01:00
UICoord uic{"window-2","*","panelX","someView"};
Navigator: initial draft of a UI coordinate resolver ...which in turn will drive the design of the LoactionQuery API
2017-10-16 02:39:22 +02:00
UICoordResolver resolver{uic, locationQuery};
CHECK (not resolver.isCovered());
Navigator: consider how to approach path resolution obviously, we get a trivial case, when the path is explicit, and we need a tricky full blown resolution with backtracking when forced to interpolate wildcards to cover a given UICoord spec against the actual UI topology. Do we need it? * actually not right now * but already a complete implementation of the ViewSpec concept requires such a resolution
2017-10-21 01:53:13 +02:00
CHECK ( resolver.canCover());
Navigator: initial draft of a UI coordinate resolver ...which in turn will drive the design of the LoactionQuery API
2017-10-16 02:39:22 +02:00
UICoord uic2 = resolver.cover()
.extend("otherView");
CHECK ("UI:window-2[perspective-B]-panelX.otherView" == string(uic2));
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
}
LocationQuery: draft unit test to cover the query API
2017-10-22 00:44:30 +02:00
/** @test verify the command-and-query interface backing the resolver.
* This test actually uses a dummy implementation of the interface, which,
* instead of navigating an actual UI topology, just uses a `Record<GenNode>`
* (a "GenNode tree") to emulate the hierarchical structure of UI components.
* @remarks note some twists how the GenNode tree is used here to represent
* an imaginary UI structure:
* - we use the special _type_ attribute to represent the _perspective_
* within each window; deliberately, we'll use this twisted structure
* here to highlight the fact that the backing structure need not be
* homogeneous; rather, it may require explicit branching
* - we use the _attributes_ within the GenNode "object" representation,
* since these are named nested elements, and the whole notion of an
* UI coordinate path is based on named child components
* - we use the _object builder_ helper to define the whole structure
LocationQuery: recast syntax for inline structure definitions this fixes a silly mistake: obviously we want named sub-nodes, aka. "Attributes", but we used the anonymous sub-nodes instead, aka. "Children" Incidentally, this renders the definitions also way more readable; in fact the strange post-fix naming notation of the original version was a clear indication of using the system backwards....
2017-10-28 00:06:44 +02:00
* as nested inline tree; named nested elements ("attributes") are
* added with the `set(key, val)` builder function, and for each
* nested scope, we start a new nested builder with `MakeRec()`.
LocationQuery: draft unit test to cover the query API
2017-10-22 00:44:30 +02:00
* - there is a special convention _for this test setup solely_ to
* set the `currentWindow` to be the last one in list -- in a real
Navigator: decide how specifically to build on top of TreeExplorer ...this was a difficult piece of consideration and analysis. In the end I've settled down on a compromise solution, with the potential to be extended into the right direction eventually...
2017-12-22 19:35:36 +01:00
* UI this would of course not be a configurable property of the
* LocationQuery, but rather just reflect the transient window
LocationQuery: draft unit test to cover the query API
2017-10-22 00:44:30 +02:00
* state and return the currently activated window
Navigator: LocationQuery interface now finished. Demo implementation unit test PASS (closes #1108) I set out to "discover" what operations we actually need on the LocationQuery interface, in order to build a "coordinate resolver" on top. It seems like this set of operations is clear by now. It comes somewhat as a surprise that this API is so small. This became possible through the idea of a ''child iterator'' with the additional ability to delve down and expand one level of children of the current element. Such can be ''implemented'' by relying on techniques similar to the "Monads" from functional programming. Let's see if this was a good choice. The price to pay is a high level of ''formal precision'' when dealing with the abstraction barrier. We need to stick strictly to the notion of a ''logical path'' into a tree-like topology, and we need to be strong enough never to give in and indulge with "the concrete, tangible". The concrete reality of a tree processing algorithm with memory management plus backtracking is just to complex to be handled mentally. So either stick to the rules or get lost.
2017-12-26 14:56:43 +01:00
* @see IterTreeExplorer_test::verify_IterSource() regarding "child exploration"...
LocationQuery: draft unit test to cover the query API
2017-10-22 00:44:30 +02:00
*/
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
void
UI-Coordinates: next steps to cover - allow tab specification to be elided - simple comparisons between UI coordinates - local query predicates
2017-10-02 18:39:18 +02:00
verify_backingQuery()
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
{
LocationQuery: recast syntax for inline structure definitions this fixes a silly mistake: obviously we want named sub-nodes, aka. "Attributes", but we used the anonymous sub-nodes instead, aka. "Children" Incidentally, this renders the definitions also way more readable; in fact the strange post-fix naming notation of the original version was a clear indication of using the system backwards....
2017-10-28 00:06:44 +02:00
GenNodeLocationQuery queryAPI{MakeRec()
.set("window-1"
, MakeRec()
.type("perspective-A")
.set("panelX"
, MakeRec()
.set("firstView", MakeRec())
.set("secondView", MakeRec())
)
)
.set("window-2"
, MakeRec()
.type("perspective-B")
.set("panelY", MakeRec())
)
.set("window-3"
, MakeRec()
.type("perspective-C")
.set("panelZ"
, MakeRec()
.set("thirdView", MakeRec())
)
.set("panelZZ", MakeRec())
)
};
LocationQuery: draft unit test to cover the query API
2017-10-22 00:44:30 +02:00
// the LocationQuery API works by matching a UICoord spec against the "real" structure
UICoord uic1 = UICoord::window("window-2").persp("perspective-B");
UICoord uic2 = UICoord::window("windows");
UICoord uic3 = UICoord::firstWindow().persp("perspective-A").panel("panelX").view("secondView");
UICoord uic4 = UICoord::currentWindow().persp("perspective-B");
UICoord uic5 = UICoord::currentWindow().persp("perspective-C").panel("panelZ").view("someOtherView");
CHECK ("window-2" == queryAPI.determineAnchor(uic1));
CHECK (Symbol::BOTTOM == queryAPI.determineAnchor(uic2));
CHECK ("window-1" == queryAPI.determineAnchor(uic3));
CHECK ("window-3" == queryAPI.determineAnchor(uic4));
CHECK ("window-3" == queryAPI.determineAnchor(uic5));
CHECK (2 == queryAPI.determineCoverage(uic1));
CHECK (0 == queryAPI.determineCoverage(uic2));
CHECK (4 == queryAPI.determineCoverage(uic3));
CHECK (1 == queryAPI.determineCoverage(uic4));
CHECK (3 == queryAPI.determineCoverage(uic5));
LocationQuery::ChildIter cii = queryAPI.getChildren(uic3, 3);
CHECK (not isnil(cii));
CHECK ("firstView" == *cii);
++cii;
CHECK ("secondView" == *cii);
CHECK (not isnil(cii));
++cii;
CHECK (isnil(cii));
CHECK ("window-1, window-2, window-3" == join (queryAPI.getChildren (uic3, 0)));
CHECK ("perspective-A" == join (queryAPI.getChildren (uic3, 1)));
CHECK ("panelX" == join (queryAPI.getChildren (uic3, 2)));
CHECK ("firstView, secondView" == join (queryAPI.getChildren (uic3, 3)));
CHECK (isnil ( queryAPI.getChildren (uic3, 4))); // "firstView" has no children
CHECK ("window-1, window-2, window-3" == join (queryAPI.getChildren (uic2, 0)));
VERIFY_ERROR (STATE, queryAPI.getChildren (uic2, 1) ); // "windows" at pos==0 is not covered by real UI
CHECK ("window-1, window-2, window-3" == join (queryAPI.getChildren (uic5, 0)));
CHECK ("perspective-C" == join (queryAPI.getChildren (uic5, 1)));
CHECK ("panelZ, panelZZ" == join (queryAPI.getChildren (uic5, 2)));
CHECK ("thirdView" == join (queryAPI.getChildren (uic5, 3)));
VERIFY_ERROR (STATE, queryAPI.getChildren (uic5, 4) ); // "someOtherView" at level 4 does not exist
Navigator: add direct test coverage for child expansion ...et voila, it's broken!! expansion at Perspective level yields "NIL", while it should yield "perspective-A"
2017-12-26 05:07:35 +01:00
Navigator: identify and fix the bug ...which was basically harmless, no fundamental problem, just a simple logical error on my behalf (using the wrong depth level)
2017-12-26 14:04:21 +01:00
// verify "child exploration" via iterator interface
cii = queryAPI.getChildren (uic3, 0); // enter at root level...
CHECK ("window-1" == *cii); // first child of root to appear is "window-1"
CHECK (0 == cii.depth()); // (note depth just happens to coincide with absolute tree depth here)
cii.expandChildren(); // drill down into current element's children
Navigator: add direct test coverage for child expansion ...et voila, it's broken!! expansion at Perspective level yields "NIL", while it should yield "perspective-A"
2017-12-26 05:07:35 +01:00
CHECK (1 == cii.depth());
Navigator: identify and fix the bug ...which was basically harmless, no fundamental problem, just a simple logical error on my behalf (using the wrong depth level)
2017-12-26 14:04:21 +01:00
CHECK ("perspective-A" == *cii); // which is just one, the perspective
cii.expandChildren(); // drill down into the (formal, logical) children of "perspective-A"
Navigator: add direct test coverage for child expansion ...et voila, it's broken!! expansion at Perspective level yields "NIL", while it should yield "perspective-A"
2017-12-26 05:07:35 +01:00
CHECK (2 == cii.depth());
Navigator: identify and fix the bug ...which was basically harmless, no fundamental problem, just a simple logical error on my behalf (using the wrong depth level)
2017-12-26 14:04:21 +01:00
CHECK ("panelX" == *cii); // ..and find the "panelX" at level 2
cii.expandChildren(); // drill down one level further
Navigator: add direct test coverage for child expansion ...et voila, it's broken!! expansion at Perspective level yields "NIL", while it should yield "perspective-A"
2017-12-26 05:07:35 +01:00
CHECK (3 == cii.depth());
Navigator: identify and fix the bug ...which was basically harmless, no fundamental problem, just a simple logical error on my behalf (using the wrong depth level)
2017-12-26 14:04:21 +01:00
CHECK ("firstView" == *cii); // and then just continue iteration, which first explores that scope...
Navigator: LocationQuery interface now finished. Demo implementation unit test PASS (closes #1108) I set out to "discover" what operations we actually need on the LocationQuery interface, in order to build a "coordinate resolver" on top. It seems like this set of operations is clear by now. It comes somewhat as a surprise that this API is so small. This became possible through the idea of a ''child iterator'' with the additional ability to delve down and expand one level of children of the current element. Such can be ''implemented'' by relying on techniques similar to the "Monads" from functional programming. Let's see if this was a good choice. The price to pay is a high level of ''formal precision'' when dealing with the abstraction barrier. We need to stick strictly to the notion of a ''logical path'' into a tree-like topology, and we need to be strong enough never to give in and indulge with "the concrete, tangible". The concrete reality of a tree processing algorithm with memory management plus backtracking is just to complex to be handled mentally. So either stick to the rules or get lost.
2017-12-26 14:56:43 +01:00
CHECK ("firstView, secondView, window-2, window-3" == join (cii)); // ...followed by returning to the enclosing scopes, finally top level.
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
}
Navigator: continue draft of UI coordinate resolver
2017-10-18 03:40:26 +02:00
/** @test query anchorage of given UI coordinates.
* - an anchored UI coordinate spec explicitly rooted within a top level window.
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
* - an explicit UI coordinate spec impossible to anchor within current UI tree
* - a UI coordinate spec with dynamic reference to first/current window
* - an incomplete spec, which needs to be solved (pattern matched) to determine anchor.
Navigator: continue draft of UI coordinate resolver
2017-10-18 03:40:26 +02:00
*/
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
void
verify_queryAnchor()
{
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
GenNodeLocationQuery tree{MakeRec()
LocationQuery: recast syntax for inline structure definitions this fixes a silly mistake: obviously we want named sub-nodes, aka. "Attributes", but we used the anonymous sub-nodes instead, aka. "Children" Incidentally, this renders the definitions also way more readable; in fact the strange post-fix naming notation of the original version was a clear indication of using the system backwards....
2017-10-28 00:06:44 +02:00
.set("window-1"
, MakeRec()
.type("perspective-A")
)
.set("window-2"
, MakeRec()
.type("perspective-B")
.set("panelX"
, MakeRec()
.set("someView", MakeRec())
)
)
};
Navigator: continue draft of UI coordinate resolver
2017-10-18 03:40:26 +02:00
UICoord uic1 = UICoord::window("window-1").persp("perspective-A");
UICoord uic2 = UICoord::window("windows");
UICoord uic3 = UICoord::firstWindow();
UICoord uic4 = UICoord::currentWindow().persp("perspective-B");
UICoord uic5 = UICoord::currentWindow().panel("panelY");
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
UICoord uic6 = UICoord().view("someView");
Navigator: continue draft of UI coordinate resolver
2017-10-18 03:40:26 +02:00
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
UICoordResolver r1{uic1, tree};
UICoordResolver r2{uic2, tree};
UICoordResolver r3{uic3, tree};
UICoordResolver r4{uic4, tree};
UICoordResolver r5{uic5, tree};
UICoordResolver r6{uic6, tree};
Navigator: continue draft of UI coordinate resolver
2017-10-18 03:40:26 +02:00
CHECK ( r1.isAnchored());
CHECK (not r2.isAnchored());
CHECK ( r3.isAnchored());
CHECK ( r4.isAnchored());
Navigator: rework and sharpen the API - the default should be to look for total coverage - the predicates should reflect the actual state of the path only - the 'canXXX' predicates test for possible covering mutation
2018-01-03 02:46:12 +01:00
CHECK ( r5.isAnchored());
Navigator: continue draft of UI coordinate resolver
2017-10-18 03:40:26 +02:00
CHECK (not r6.isAnchored());
CHECK ( r1.canAnchor());
CHECK (not r2.canAnchor());
CHECK ( r3.canAnchor());
CHECK ( r4.canAnchor());
Navigator: rework and sharpen the API - the default should be to look for total coverage - the predicates should reflect the actual state of the path only - the 'canXXX' predicates test for possible covering mutation
2018-01-03 02:46:12 +01:00
CHECK ( r5.canAnchor());
Navigator: continue draft of UI coordinate resolver
2017-10-18 03:40:26 +02:00
CHECK ( r6.canAnchor());
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
}
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
/** @test path matching algorithm to resolve UI coordinates with wildcards against the current UI structure tree.
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
* Since an UI coordinate path with gaps and wildcards could match anywhere, even several times, we need to perform
* an exhaustive search with backtracking over the whole tree. By convention, we use the first maximal solution,
* which can be just a partial solution, leaving an additional uncovered trailing part of the UI coordinate spec.
* Whenever a coordinate spec is _not explicit,_ has wildcards or a leading gap, we need to perform the full
* matching algorithm, even to just answer the question if coverage _is possible_. The result, i.e. the computed
* coverage, is cached internally, and can be used to _mutate_ the UI coordinate spec to match that coverage.
*
* This test verifies various corner cases; especially there is a rule to prevent a partial match based
* on wildcards solely, rather we require at least one explicit match to qualify as partial solution.
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
* - (1) trivial cases not requiring a tree search
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
* ** total coverage
* ** partial coverage, leaving an uncovered suffix
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
* - (2) expand dynamic anchor specifiers
* ** with following content
* ** anchor spec alone
* - (3) wildcard interpolation
* ** interpolate a single gap
* ** interpolate several gaps
* ** interpolate anchor and consecutive wildcards
* ** discriminate by anchor and fill additional gap
* - (4) failure detection
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
* ** trailing wildcards are stripped and ignored
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
* ** reject gap beyond existing real UI tree
* ** reject gap ending at perimeter of real UI tree
* ** reject interpolated gap on immediately following mismatch
* ** reject mismatch immediately behind second gap
* ** mismatch of tree level
* ** contradiction to anchorage
Navigator: cover selection from several possible solutions
2018-01-06 04:36:18 +01:00
* - (5) selection between several possible solutions
* ** the length of the covered trailing suffix decides
* ** when two solutions are equivalent, pick the fist one
* ** best solution will be picked, irrespective of discovery order
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
*/
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
void
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
verify_mutateCoverage()
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
{
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
GenNodeLocationQuery tree{MakeRec()
.set("window-1"
, MakeRec()
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
.type("persp-A")
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
.set("panelX"
, MakeRec()
.set("firstView", MakeRec())
.set("secondView", MakeRec())
)
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
.set("panelZ"
, MakeRec()
.set("thirdView"
, MakeRec()
.set("#1", MakeRec())
.set("#2", MakeRec())
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
.set("tab", MakeRec())
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
)
)
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
)
.set("window-2"
, MakeRec()
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
.type("persp-B")
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
.set("panelY", MakeRec())
)
.set("window-3"
, MakeRec()
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
.type("persp-C")
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
.set("panelZ"
, MakeRec()
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
.set("thirdView"
, MakeRec()
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
.set("tab"
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
, MakeRec()
.set("sub", MakeRec())
)
Navigator: cover selection from several possible solutions
2018-01-06 04:36:18 +01:00
.set("#1", MakeRec())
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
)
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
)
.set("panelZZ", MakeRec())
)
};
/* === trivial cases === */
UICoordResolver r11 {UICoord::window("window-1")
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
.persp("persp-A")
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
.panel("panelX"), tree};
CHECK (r11.isCovered());
CHECK (3 == r11.coverDepth());
UICoordResolver r12 {UICoord::window("window-1")
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
.persp("persp-A")
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
.panel("panelX")
.view("thirdView"), tree};
CHECK (not r12.isCovered());
CHECK ( r12.isCoveredPartially());
CHECK (3 ==r12.coverDepth());
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
CHECK ("UI:window-1[persp-A]-panelX.thirdView" == string(r12));
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
r12.cover();
CHECK (r12.isCovered());
CHECK (r12.isCoveredPartially());
CHECK (3 ==r12.coverDepth());
CHECK ("UI:window-1[persp-A]-panelX" == string(r12));
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === expand anchor === */
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
UICoordResolver r21 {UICoord::firstWindow().persp("persp-A"), tree};
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
CHECK ("UI:firstWindow[persp-A]" == string(r21));
r21.cover();
CHECK ("UI:window-1[persp-A]" == string(r21));
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === expand anchor alone === */
UICoordResolver r22 {UICoord::currentWindow(), tree};
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
CHECK ("UI:window-3" == string(r22.cover()));
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === interpolate a single gap === */
UICoordResolver r31 {UICoord::window("window-1").view("secondView"), tree};
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
CHECK ("UI:window-1[*]-*.secondView" == string(r31));
CHECK (0 ==r31.coverDepth());
CHECK (not r31.isCovered());
CHECK (r31.canCover());
r31.cover();
CHECK (r31.isCovered());
CHECK (4 == r31.coverDepth());
CHECK ("UI:window-1[persp-A]-panelX.secondView" == string(r31));
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === interpolate several gaps === */
UICoordResolver r32 {UICoord().view("thirdView").path("sub"), tree};
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
CHECK ("UI:window-3[persp-C]-panelZ.thirdView.tab/sub" == string(r32.cover()));
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === interpolate anchor and consecutive wildcards === */
UICoordResolver r33 {UICoord::firstWindow().tab(2), tree};
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
CHECK ("UI:window-1[persp-A]-panelZ.thirdView.#2" == string(r33.cover()));
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === discriminate by anchor and fill second gap === */
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
UICoordResolver r34 {UICoord::currentWindow().panel("panelZ").tab("tab"), tree};
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
CHECK ("UI:currentWindow[*]-panelZ.*.tab" == string(r34));
CHECK ("UI:window-3[persp-C]-panelZ.thirdView.tab" == string(r34.cover())); // Note: rest of the path would also match on window-1, but currentWindow == window-3
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
LocationSolver: test coverage for existentially quantified elements (#1128) ...and again spotted some really insidious bugs
2018-02-16 06:37:43 +01:00
UICoordResolver r35 {UICoord::currentWindow().persp(UIC_ELIDED).panel("panelZ").tab("tab"), tree};
CHECK ("UI:currentWindow[.]-panelZ.*.tab" == string(r35));
CHECK ("UI:window-3[persp-C]-panelZ.thirdView.tab" == string(r35.cover())); // elided (existentially quantified) element interpolated similar to a wildcard
UICoordResolver r36 {UICoord::currentWindow().panel(UIC_ELIDED).view("nonexisting"), tree};
CHECK ("UI:currentWindow[*]-..nonexisting" == string(r36));
CHECK ("UI:window-3[persp-C]-panelZ" == string(r36.cover())); // ...but elided counts as existing element and matches arbitrarily (-> contrast this to r44)
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
/* === trailing wildcards stripped automatically === */
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
UICoordResolver r41 {UICoord::window("window-2").append("*/*"), tree};
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
CHECK ("UI:window-2" == string(r41)); // Note: trailing wildcards are already discarded by PathArray / UICoord
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
Navigator: fix covering of an explicit UI-Coordinate ...especially to make the anchorage explicit
2018-01-06 02:54:24 +01:00
r41.extend("*/*"); // if we now attempt to "sneak in" trailing wildcards...
CHECK ("UI:window-2[*]-*" == string(r41));
CHECK (not r41.canCover()); // ...then the algorithm rejects any solution
CHECK ("UI:window-2" == string(r41.cover())); // Note: but cover() will act on the previous coverage and just strip the extraneous suffix
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === reject gap beyond existing real UI tree === */
UICoordResolver r42 {UICoord::window("window-2").append("*/*/*/some/path"), tree};
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
CHECK (not r42.canCover());
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === reject gap ending at real UI tree boundary === */
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
UICoordResolver r43 {UICoord::currentWindow().view("firstView").tab("nonexisting"), tree};
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
CHECK (not r43.canCover());
/* === reject interpolated gap on mismatch right behind === */
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
UICoordResolver r44 {UICoord().view("otherView"), tree}; // Note: will be checked on all four existing views, but never matches
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
CHECK (not r44.canCover());
/* === reject mismatch immediately behind second gap === */
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
UICoordResolver r45 {UICoord().panel("panelZ").tab(3), tree}; // Note: we have two "panelZ", but none has a tab #3
CHECK (not r45.canCover());
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
/* === mismatch of tree level === */
Navigator: explicitly reject solutions that did not bind all wildcards ...this makes most of the remaining test cases pass only a plain anchor is not yet properly interpolated
2018-01-05 03:57:27 +01:00
UICoordResolver r46 {UICoord::currentWindow().append("*/*/panelZ/thirdView"), tree}; // Note: one '*' too much, thus 'panelZ' is matched on view level
Navigator: further unit tests for boundrary cases NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
CHECK (not r46.canCover());
/* === impossible to anchor === */
UICoordResolver r47 {UICoord::firstWindow().tab(3), tree};
CHECK (not r47.canCover());
Navigator: cover selection from several possible solutions
2018-01-06 04:36:18 +01:00
/* === the solution with maximum covered depth wins === */
UICoordResolver r51 {UICoord().tab("tab").path("sub"), tree};
CHECK ("UI:window-3[persp-C]-panelZ.thirdView.tab/sub" == string(r51.cover())); // the second solution found covers to maximum depth
/* === when two solutions are equivalent, pick the fist one === */
UICoordResolver r52 {UICoord().tab("tab"), tree};
CHECK ("UI:window-1[persp-A]-panelZ.thirdView.tab" == string(r52.cover())); // "UI:window-3[persp-C]-panelZ.thirdView.tab" would match too
/* === best solution will be picked, irrespective of discovery order === */
UICoordResolver r531 {UICoord().persp("persp-A").tab(1), tree};
CHECK ("UI:window-1[persp-A]-panelZ.thirdView.#1" == string(r531.cover())); // best solution discovered as first one
UICoordResolver r532 {UICoord().view("thirdView").tab("tab"), tree};
CHECK ("UI:window-1[persp-A]-panelZ.thirdView.tab" == string(r532.cover())); // best solution is 3rd of five possible ones
UICoordResolver r533 {UICoord().persp("persp-C").tab(1), tree};
CHECK ("UI:window-3[persp-C]-panelZ.thirdView.#1" == string(r533.cover())); // best solution is found as last one
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
}
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
/** @test resolve by matching, but retain an extraneous, uncovered extension.
LocationSolver: implement this additional resolving flavour coverPartially() now computes coverage solution and moves that solution into place, while retaining the extraneous, uncovered part
2018-02-09 03:30:45 +01:00
* This is a variation of the UICoordResolver::cover() operation, which likewise resolves
* any wildcards; but here we tolerate _additional elements below_ the covered part, as long
* as those are explicit. The typical use case is when we're about to create a new UI element
* at a specific existing anchor location within the UI. The extraneous uncovered part then
* describes those extra element yet to be created.
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
*/
void
verify_mutateCoverPartially()
{
GenNodeLocationQuery tree{MakeRec()
LocationSolver: implement this additional resolving flavour coverPartially() now computes coverage solution and moves that solution into place, while retaining the extraneous, uncovered part
2018-02-09 03:30:45 +01:00
.set("window-2"
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
, MakeRec()
.type("persp-B")
.set("panelY"
, MakeRec()
.set("someView"
, MakeRec()
.set("#1", MakeRec())
.set("#2", MakeRec())
)
)
)
};
/* === explicitly given spec partially covered === */
LocationSolver: implement this additional resolving flavour coverPartially() now computes coverage solution and moves that solution into place, while retaining the extraneous, uncovered part
2018-02-09 03:30:45 +01:00
UICoordResolver r1 {UICoord{"window-2","persp-B","panelY","otherView","tab"}, tree};
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
CHECK (3 == r1.coverDepth());
r1.coverPartially();
CHECK (not r1.isCovered());
CHECK (3 == r1.coverDepth());
LocationSolver: implement this additional resolving flavour coverPartially() now computes coverage solution and moves that solution into place, while retaining the extraneous, uncovered part
2018-02-09 03:30:45 +01:00
CHECK (r1.isCoveredPartially()); // is covered down to the "panelY"
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
CHECK ("UI:window-2[persp-B]-panelY.otherView.tab" == string(r1));
LocationSolver: implement this additional resolving flavour coverPartially() now computes coverage solution and moves that solution into place, while retaining the extraneous, uncovered part
2018-02-09 03:30:45 +01:00
r1.cover();
CHECK (r1.isCovered()); // cover() retains the covered part only
CHECK ("UI:window-2[persp-B]-panelY" == string(r1));
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
/* === fill wildcard gap but retain uncovered extension === */
UICoordResolver r2 {UICoord::currentWindow().view("someView").tab(3).path("sub"), tree};
CHECK (0 == r2.coverDepth());
r2.coverPartially();
CHECK (not r2.isCovered());
CHECK (4 == r2.coverDepth());
CHECK (r2.isCoveredPartially());
CHECK ("UI:window-2[persp-B]-panelY.someView.#3/sub" == string(r2));
r2.cover();
CHECK ("UI:window-2[persp-B]-panelY.someView" == string(r2));
/* === reject when gap can not be closed unambiguously === */
LocationSolver: implement this additional resolving flavour coverPartially() now computes coverage solution and moves that solution into place, while retaining the extraneous, uncovered part
2018-02-09 03:30:45 +01:00
UICoordResolver r3 {UICoord::currentWindow().view("someView").path("sub"), tree};
CHECK (not r3.canCover()); // NOTE: second gap here, tab info missing
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
r3.coverPartially();
CHECK (isnil (r3));
/* === reject when some wildcards remain after partial coverage === */
UICoordResolver r4 {UICoord::currentWindow().tab(3).path("sub"), tree};
r4.coverPartially();
CHECK (isnil (r4));
LocationSolver: test coverage for existentially quantified elements (#1128) ...and again spotted some really insidious bugs
2018-02-16 06:37:43 +01:00
/* === existentially quantified (elided) element constitutes partial coverage === */
UICoordResolver r5 {UICoord::currentWindow().persp(UIC_ELIDED).panel("fantasy").view("fantomas"), tree};
CHECK ("UI:currentWindow[.]-fantasy.fantomas" == string(r5));
CHECK (1 == r5.coverDepth());
r5.coverPartially();
CHECK (not r5.isCovered());
CHECK (2 == r5.coverDepth()); // Note side-effect of computing the coverage...
CHECK (r5.isCoveredPartially()); // it is known to be covered including "the" perspective
CHECK ("UI:window-2[persp-B]-fantasy.fantomas" == string(r5));
r5.cover();
CHECK ("UI:window-2[persp-B]" == string(r5));
CHECK (2 == r5.coverDepth());
LocationSolver: need yet another flavour of the coordinate resolving mechanism ...this happens when you design a subsystem bottom-up You build five items just to find out that in fact you need only a sixth item....
2018-02-08 03:00:38 +01:00
}
LocationSolver: implement this additional resolving flavour coverPartially() now computes coverage solution and moves that solution into place, while retaining the extraneous, uncovered part
2018-02-09 03:30:45 +01:00
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
/** @test mutate given UI coordinates by anchoring them.
* This operation changes only the window part of the coordinate spec;
* it might use the result of a preceding coverage solution search or even
* trigger such a search, but only to find out about the root window.
Navigator: get the anchor() cases to work as intended
2018-01-07 05:45:21 +01:00
* @note some fine points touched here: to anchor a path is something
* different than to cover it; in fact there are cases where we
* can determine the possible anchor point, but are unable to
* cover the path spec beyond that. And, on the other hand,
* there are cases where you _need to compute a coverage_
* in order to decide upon the anchor point.
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
*/
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
void
verify_mutateAnchor()
{
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
GenNodeLocationQuery tree{MakeRec()
.set("window-1"
, MakeRec()
.type("persp-A")
.set("panelX"
, MakeRec()
.set("firstView", MakeRec())
.set("secondView", MakeRec())
)
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
)
.set("window-2"
, MakeRec()
.type("persp-B")
.set("panelY"
Navigator: fix insidious nesting error in test definition
2018-01-09 01:52:49 +01:00
, MakeRec()
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
.set("thirdView"
, MakeRec()
.set("#1", MakeRec())
.set("#2", MakeRec())
)
Navigator: fix insidious nesting error in test definition
2018-01-09 01:52:49 +01:00
)
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
)
.set("window-3"
, MakeRec()
.type("persp-C")
.set("panelZ"
, MakeRec()
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
.set("thirdView", MakeRec())
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
)
)
};
/* === explicitly given window spec remains unchanged === */
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
UICoordResolver r1 {UICoord{"window-2","persp-B","panelY"}, tree};
CHECK (3 == r1.coverDepth());
r1.anchor();
CHECK ("UI:window-2[persp-B]-panelY" == string(r1));
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
/* === `firstWindow` meta spec is resolved === */
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
UICoordResolver r2 {UICoord::firstWindow().view("blah"), tree};
CHECK (0 == r2.coverDepth());
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
CHECK (r2.isAnchored()); // can obviously be anchored, since there is always a first window
CHECK (not r2.canCover()); // yet this path is impossible to cover in the current UI
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
CHECK ("UI:firstWindow[*]-*.blah" == string(r2));
r2.anchor();
CHECK ("UI:window-1[*]-*.blah" == string(r2));
CHECK (0 == r2.coverDepth());
CHECK (not r2.canCover());
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
/* === `currentWindow` meta spec is resolved === */
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
UICoordResolver r3 {UICoord::currentWindow().view("thirdView"), tree};
CHECK (0 == r3.coverDepth());
CHECK (r3.isAnchored());
CHECK (not r3.isCovered());
CHECK (r3.canCover());
r3.anchor();
CHECK (not r3.isCovered());
CHECK (r3.isCoveredPartially());
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
CHECK (1 == r3.coverDepth()); // anchoring also picks the second of two possible solutions
CHECK ("UI:window-3[*]-*.thirdView" == string(r3)); // thereby covering the "thirdView"
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
/* === coverage solution is calculated on demand === */
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
UICoordResolver r4 {UICoord().view("thirdView").append("#2/sub"), tree};
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
CHECK ("UI:?.thirdView.#2/sub" == string(r4)); // an incomplete path is not automatically resolved
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
CHECK (not r4.isAnchored());
CHECK (0 == r4.coverDepth());
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
r4.anchor(); // but if we anchor, we force search for a coverage solution
Navigator: fix insidious nesting error in test definition
2018-01-09 01:52:49 +01:00
CHECK (1 == r4.coverDepth()); // which is actually found starting from the second window,
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
CHECK (r4.isCoveredPartially()); // and kept in the internal cache for future use,
Navigator: fix insidious nesting error in test definition
2018-01-09 01:52:49 +01:00
CHECK ("UI:window-2[*]-*.thirdView.#2/sub" == string(r4)); // but not made explicit, since we only requested anchorage
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
/* === already calculated coverage solution is used === */
UICoordResolver r5 {UICoord::currentWindow().view("thirdView"), tree};
CHECK (not r5.isCovered());
CHECK (not r5.isCoveredPartially());
CHECK (0 == r5.coverDepth());
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
CHECK (r5.canCover()); // this triggers search for a coverage solution
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
CHECK (1 == r5.coverDepth());
CHECK (not r5.isCovered());
CHECK (r5.isCoveredPartially());
Navigator: get the anchor() cases to work as intended
2018-01-07 05:45:21 +01:00
CHECK ("UI:currentWindow[*]-*.thirdView" == string(r5));
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
r5.anchor(); // and this (cached) solution is also used to make anchorage explicit
Navigator: get the anchor() cases to work as intended
2018-01-07 05:45:21 +01:00
CHECK ("UI:window-3[*]-*.thirdView" == string(r5));
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
CHECK (1 == r5.coverDepth());
CHECK (not r5.isCovered());
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
r5.cover(); // ...now also the coverage solution was made explicit
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
CHECK (r5.isCovered());
CHECK (4 == r5.coverDepth());
Navigator: get the anchor() cases to work as intended
2018-01-07 05:45:21 +01:00
CHECK ("UI:window-3[persp-C]-panelZ.thirdView" == string(r5));
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
Navigator: supply another mutation operation to make anchorage explicit ...basically just a re-use of existing functionality. Needs some test coverage though
2018-01-07 02:24:33 +01:00
/* === impossible to cover and can not be anchored === */
Navigator: cook up some interesting test cases for anchor mutation ...and yes, even writing seemingly superfluous test cases will uncover yet another bug
2018-01-07 03:17:15 +01:00
UICoordResolver r6 {UICoord::window("windows").path("to/hell"), tree};
CHECK (not r6.isAnchored());
CHECK (not r6.canCover());
r6.anchor();
CHECK (not r6.isAnchored());
CHECK (0 == r6.coverDepth());
Navigator: get the anchor() cases to work as intended
2018-01-07 05:45:21 +01:00
CHECK ("UI:windows[*]-*.*.*/to/hell" == string(r6));
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
}
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
/** @test mutate given UI coordinates by uncovered extension.
* Contrary to just appending something to the path (which is a basic path operation
* available on the generic path builder), a _path extension_ is always rooted at the
* end of the actually covered part of the UI coordinates. So extending a path implies
* search for a coverage solution, followed by truncating the path to the covered part.
Navigator: finish path matching resolver for UI coordinates (closes #1107)
2018-01-10 04:42:49 +01:00
* There are two flavours of extending a path:
* - extending with a literal specification, which is just appended behind the coverage
* - extending with an incomplete UI coordinate spec, which allows to place the extension
* at a specific depth (e.g. as a view). This is typically what we want in practice.
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
*/
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
void
verify_mutateExtend()
{
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
GenNodeLocationQuery tree{MakeRec()
.set("window-2"
, MakeRec()
.type("persp-B")
.set("panelY"
Navigator: fix insidious nesting error in test definition
2018-01-09 01:52:49 +01:00
, MakeRec()
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
.set("thirdView"
, MakeRec()
.set("#1", MakeRec())
.set("#2", MakeRec())
)
Navigator: fix insidious nesting error in test definition
2018-01-09 01:52:49 +01:00
)
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
)
};
/* === extend fully covered explicit path === */
UICoordResolver r1 {UICoord{"window-2","persp-B","panelY"}, tree};
Navigator: finish coverage of path extension
2018-01-10 03:21:10 +01:00
CHECK ("UI:window-2[persp-B]-panelY" == string(r1));
CHECK (r1.isCovered());
r1.extend (UICoord().path("gappy").tab(2)); // can extend with partially defined UI coordinates
CHECK ("UI:window-2[persp-B]-panelY.*.#2/gappy" == string(r1)); // ...the resulting UI path is unresolved, yet can be partially covered
r1.extend ("seamless"); // ...and this partial coverage is used as base for further extension
CHECK ("UI:window-2[persp-B]-panelY.thirdView.#2/seamless" ==string(r1));
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
/* === extend partially covered path === */
UICoordResolver r2 {UICoord().view("thirdView").append("some/where"), tree};
Navigator: finish coverage of path extension
2018-01-10 03:21:10 +01:00
CHECK ("UI:?.thirdView.some/where" ==string(r2)); // "thirdView" is covered, "some/where" is not
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
r2.extend ("no/where");
Navigator: finish coverage of path extension
2018-01-10 03:21:10 +01:00
CHECK ("UI:window-2[persp-B]-panelY.thirdView.no/where" ==string(r2)); // ...and thus the extension is attached behind "thirdView"
CHECK (r2.isCoveredPartially());
/* === impossible extensions rejected === */ // since r2 already specifies a perspective ("persp-B")....
VERIFY_ERROR (INVALID, r2.extend(UICoord().persp("fisheye"))); // ...overwriting with another perspective is rejected as extension
CHECK ("UI:window-2[persp-B]-panelY.thirdView.no/where" ==string(r2)); // ...and the existing state is unaffected from this error
VERIFY_ERROR (INVALID, r2.extend(UICoord().view("alternative"))); // Likewise, extending with a conflicting view spec is rejected
r2.extend(UICoord().tab("nada")); // But a tab is not yet covered and thus acceptable as extension
CHECK ("UI:window-2[persp-B]-panelY.thirdView.nada" ==string(r2));
r2.extend(UICoord());
CHECK ("UI:window-2[persp-B]-panelY.thirdView" ==string(r2)); // empty coordinates implicitly attached behind the covered part
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
/* === unsolvable: truncate, extend, recalculate coverage === */
UICoordResolver r3 {UICoord().persp("awesome"), tree};
Navigator: test for path extension now basically working as intended
2018-01-09 02:12:00 +01:00
CHECK (not r3.canCover());
CHECK (0 == r3.coverDepth());
Navigator: finish coverage of path extension
2018-01-10 03:21:10 +01:00
r3.extend (UICoord::currentWindow().tab(1)); // Extension implies covering, which effectively truncates the path
CHECK (1 == r3.coverDepth()); // ...and "currentWindow" can even be covered, thus the coverage increases
CHECK ("UI:currentWindow[*]-*.*.#1" ==string(r3)); // note coverage calculated internally, not made explicit
UI-Coordinates: polish test and consider next steps After completing the self-contained UICoord data elements, the next thing to consider might be how to resolve UI coordinates against an actual window topology. We need to define a suitable command-and-query interface in order to build and verify this intricate resolution process separated from the actual UI code.
2017-10-02 18:11:21 +02:00
}
};
/** Register this test class... */
LAUNCHER (UICoordResolver_test, "unit gui");
}}} // namespace gui::interact::test
Reference in a new issue Copy permalink