Commit graph

17 commits

Author SHA1 Message Date
4de2ea2abe ViewSpec: get rid of all the lambdas and global vars. LocationQuery is a service now
Harvesting the fruits of the DependencyFactory rework....
2018-04-04 03:48:53 +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
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
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
98cab32a08 LocationSolver: several rule match test cases 2018-02-14 03:02:44 +01:00
92bf317d29 LocationSolver: long explicit path test cases
...and here a bug was hiding. gotcha
2018-02-13 02:46:43 +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
a1ee7574ef LocationSolver: reorganise and complete the decision logic (#1127) 2018-02-09 23:49:36 +01:00
f8dd3a7030 LocationSolver: draft the success cases for a location solution 2018-02-09 04:10:53 +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
6022a8afb1 LocationSolver: draft outline of the solving loop 2018-02-08 02:50:48 +01:00
bf314482da LocationSolver: draft the simple usage scenario (unit test) (#1127) 2018-02-08 00:37:02 +01:00
1238d416fc LocationSolver: draft the DSL syntax for sequential alternatives (#1126)
turns out to be somewhat tricky.
The easy shot would be to use the comma operator,
but I don't like that idea, since in logic programming, comma means "and then".

So I prefer an || operator, similar to short-circuit evaluation of boolean OR

Unfortunately, OR binds stronger than assignment, so we need to trick our way
into a smooth DSL syntax by wrapping into intermediary marker types, and accept
rvalue references only, as additional safeguard to enforce the intended inline
definition syntax typical for DSL usage.
2018-02-07 04:24:33 +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