LUMIERA.clone/tests/52-gui-control.tests

TESTING "Component Test Suite: GUI Control Facilities" ./test-suite --group=stage


PLANNED "Context bound command invocation" CmdContext_test <<END
return: 0
END


TEST "configuration DSL for view access" ViewSpecDSL_test <<END
return: 0
END


TEST "generic UI coordinates" UICoord_test <<END
return: 0
END


TEST "resolving UI coordinates" UICoordResolver_test <<END
return: 0
END


TEST "solving for UI location" UILocationSolver_test <<END
out-lit: =~	.. UI:?[edit]-viewer
out-lit: 	OR UI:currentWindow[*]-viewer
out-lit: 	OR UI:?-viewer
out-lit: 	OR UI:?[asset]-*.asset
out-lit: 	OR UI:?-asset.asset create!
out-lit: 	OR UI:currentWindow[*]-viewer create!
out-lit: 	OR UI:meta[config]-infobox.inspect create!
return: 0
END
Global-Layer-Renaming: fix remaining textual usages and IDs in the code - most notably the NOBUG logging flags have been renamed now - but for the configuration, I'll stick to "GUI" for now, since "Stage" would be bewildering for an occasional user - in a similar vein, most documentation continues to refer to the GUI 2018-11-16 22:38:29 +01:00			`TESTING "Component Test Suite: GUI Control Facilities" ./test-suite --group=stage`
DockAccess: start implementation draft for the DSL 2017-09-09 23:30:44 +02:00


			`PLANNED "Context bound command invocation" CmdContext_test <<END`
			`return: 0`
			`END`


ViewSpec: integrate the simple View access case (Unit test PASS) This finishes the first round of design drafts in this area. Right now it seems difficult to get any further, since most of the actual view creation and management in the UI is not yet coded. 2018-06-15 18:02:08 +02:00			`TEST "configuration DSL for view access" ViewSpecDSL_test <<END`
DockAccess: start implementation draft for the DSL 2017-09-09 23:30:44 +02:00			`return: 0`
			`END`


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			`TEST "generic UI coordinates" UICoord_test <<END`
			`return: 0`
			`END`


Navigator: finish path matching resolver for UI coordinates (closes #1107) 2018-01-10 04:42:49 +01:00			`TEST "resolving UI coordinates" UICoordResolver_test <<END`
DockAccess: start implementation draft for the DSL 2017-09-09 23:30:44 +02:00			`return: 0`
			`END`
LocationSolver: draft outline of the solving loop 2018-02-08 01:50:11 +01:00

LocationSolver: Documentation and clean-up (#1127) 2018-02-17 03:45:07 +01:00			`TEST "solving for UI location" UILocationSolver_test <<END`
			`out-lit: =~ .. UI:?[edit]-viewer`
			`out-lit: OR UI:currentWindow[*]-viewer`
			`out-lit: OR UI:?-viewer`
			`out-lit: OR UI:?[asset]-*.asset`
			`out-lit: OR UI:?-asset.asset create!`
LocationSolver: automatically inject persp(UIC_ELIDED) (closes #1128) decided to add a very specific preprocessing here, to make the DSL notation more natural. My guess is that most people won't spot the presence of this tiny bit of magic, and it would be way more surprising to have rules like UICoord::currentWindow().panel("viewer").create() fail in most cases, simply because there is a wildcard on the perspective and the panel viewer does not (yet) exist. In such a case, we now turn the perspective into a "existential quantified" wildcard, which is treated as if the actually existing element was written explicitly into the pattern. 2018-02-17 05:11:34 +01:00			`out-lit: OR UI:currentWindow[*]-viewer create!`
LocationSolver: Documentation and clean-up (#1127) 2018-02-17 03:45:07 +01:00			`out-lit: OR UI:meta[config]-infobox.inspect create!`
LocationSolver: draft outline of the solving loop 2018-02-08 01:50:11 +01:00			`return: 0`
			`END`