91b83f5ede
ElementAccess: (WIP) unsuccessful attempt to solve the typing problem
...
the intention was to return disparate result types, just depending on the
actual position in the UI-Coordinates. The client knows what to expect
2018-04-09 01:14:12 +02:00
c245098d45
ElementAccess: (WIP) first draft for internal accessor function
...
...but can not work this way.
Since void* has not RTTI, no secure access with downcast is possible
2018-04-09 00:51:24 +02:00
20ecc3f0d0
DI: allow to trigger the lazy instantiation of a mock service instance directly
...
Basically the mocking mechanism just switches the configuration
and then waits for the service to be accessed in order to cause acutual
instantiation of the mock service implementation. But sometimes we want
to prepare and rig the mock instance prior to the first invocation;
in such cases it can be handy just to trigger the lazy creating process
2018-04-08 18:43:27 +02:00
e99ad7a3e6
ElementAccess: draft simple lookup interface
2018-04-08 18:43:27 +02:00
09359cf92a
ElementAccess: initial brainstorming about the interface mechanics
2018-04-07 02:28:29 +02:00
dc97ab5546
ElementAccess: consider helper to encapsulte access to actual GTK structures ( #1134 )
2018-04-07 01:00:25 +02:00
2f899a921c
ViewSpec: draft next steps to address
...
...should implement the generic invocation in ViewLocator,
without actually implementing the backing UI element allocation logic
2018-04-05 19:43:10 +02:00
18a552002d
ViewSpec: use mocked LocationSolver to verify operation of the DSL
2018-04-05 01:09:13 +02:00
71bb2b48b6
ViewSpec: pick up with dependency-injection into the DSL tokens ( #1126 )
...
Attempt to find my way back to the point
where the digression regarding dependency-injection started.
As it turns out, this was a valuable digression, since we can rid ourselves
from lots of ad-hoc functionality, which basically does in a shitty way
what DependencyFactory now provides as standard solution
FIRST STEP is to expose the Navigator as generic "LocationQuery" service
through lib::Depend<LocationQuery>
2018-04-04 03:29:26 +02:00
89d93a13e4
Modernise Unknown Exception handler and Exception messages
2018-04-02 01:48:51 +02:00
685a9b84ee
Library: replace boost::noncopyable by our own library solution
...
Benefits
- get rid of yet another pervasive Boost dependency
- define additional more fine grained policies (move only, clonable)
2018-03-24 05:35:13 +01:00
41b8d12b66
ViewSpec: reconsider how to build and structure the DSL ( #1126 )
...
...in the light of all the foundation components and frameworks created meanwhile
2018-02-23 05:07:39 +01:00
b6360b2e9c
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
0f26f1e0f4
LocationSolver: Documentation and clean-up ( #1127 )
2018-02-17 03:45:07 +01:00
da8fd6a031
LocationSolver: use the "elided" marker for realistic create rules
...
...actually just more test coverage,
the feature is already implemented.
What *could* be done though is to inject that UIC_ELIDED marker
on missing perspective specs in create clauses automatically...
2018-02-16 07:34:48 +01:00
983c490644
LocationSolver: test coverage for existentially quantified elements ( #1128 )
...
...and again spotted some really insidious bugs
2018-02-16 06:37:43 +01:00
6665fb68d6
LocationSolver: decide not to implement match based on context ( #1130 )
...
This looks like YAGNI, and it would be non trivial to implement.
But since the feature looks important for slick UI behaviour,
I've made a new ticket and leave it for now
2018-02-16 03:24:37 +01:00
f3791297d6
LocationSolver: cover most standard usage situations
...
with the exception of some special situations,
which require additional features from the engine,
especially binding-on-context
Not sure though if I'll implement these or say YAGNI
2018-02-16 01:59:51 +01:00
60d40a6a6e
LocationSolver: concept for standard usage situation test coverage
...
...using a fixed set of rules this time,
while injecting a different (simulated) UI tree for each testcase
2018-02-14 04:42:19 +01:00
98cab32a08
LocationSolver: several rule match test cases
2018-02-14 03:02:44 +01:00
9249c513a9
LocationSolver: wildcard match test cases
2018-02-13 03:13:53 +01:00
92bf317d29
LocationSolver: long explicit path test cases
...
...and here a bug was hiding. gotcha
2018-02-13 02:46:43 +01:00
9fe314ad04
LocationSolver: testcases regarding perspective
...
TODO support for existentially quantified perspective to match against
"just the" perspectice, disregarding the actual value
2018-02-13 02:26:03 +01:00
c11e557b45
LocationSolver: smallest possible query test cases
...
querying on window level (=root level)
2018-02-11 04:36:11 +01:00
e04f61fe0d
LocationSolver: length discriminating test cases
2018-02-11 04:16:58 +01:00
820abe2bef
LocationSolver: provide DSL notation to write "create clauses"
2018-02-11 04:00:59 +01:00
7a167c4c3a
LocationSolver: draft pattern for writing those test cases
...
...which shows: we also need a DSL mechanism for writing "create clauses"
2018-02-11 02:34:56 +01:00
65a86bc426
LocationSolver: define extensive test coverage to be written ( #1127 )
2018-02-10 02:03:09 +01:00
6d0e8a35a6
LocationSolver: simple unit test PASS
2018-02-10 00:34:24 +01:00
66bbf146a6
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
c88a68a2a0
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
bf314482da
LocationSolver: draft the simple usage scenario (unit test) ( #1127 )
2018-02-08 00:37:02 +01:00
10d2cafba9
LocationSolver: draft entities involved in location solving ( #1127 )
...
basically this will be built on top of the path matching / resolving mechanism coded thus far.
but we'll need some additional flags and some DSL magic
2018-02-07 04:03:39 +01:00
136e78d023
DockAccess: decide on next steps towards integration ( #1126 )
2018-02-01 23:08:43 +01:00
22e823fad5
DockAccess: finish setup of allocation specifications within the DSL
2018-01-15 03:56:23 +01:00
ef74527f6b
DOC: eliminate spurious mentions of tr1::
2018-01-12 03:03:25 +01:00
7dd69003b5
Navigator: finish path matching resolver for UI coordinates ( closes #1107 )
2018-01-10 04:42:49 +01:00
722c49e5ff
Navigator: finish coverage of path extension
2018-01-10 04:21:42 +01:00
2d66293c32
Navigator: test for path extension now basically working as intended
2018-01-09 02:12:00 +01:00
f10263c469
Navigator: fix insidious nesting error in test definition
2018-01-09 01:52:49 +01:00
55c196e5a2
Navigator: define test cases for path extension after coverage
2018-01-08 23:49:24 +01:00
d5209bfe1d
Navigator: get the anchor() cases to work as intended
2018-01-07 07:20:41 +01:00
837aa81fc5
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
2665ad5bf3
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
c88747dc99
Navigator: cover selection from several possible solutions
2018-01-06 04:36:18 +01:00
e7ce82d17e
Navigator: fix covering of an explicit UI-Coordinate
...
...especially to make the anchorage explicit
2018-01-06 03:32:42 +01:00
0ea5583b62
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
d9db5f3917
Navigator: further unit tests for boundrary cases
...
NOTE not working yet; trailing wildcards not rejected
2018-01-05 02:14:22 +01:00
f4648c393f
Navigator: unit test simple cases of coverage
2018-01-04 04:52:09 +01:00
f23b916f03
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
