Commit graph

6 commits

Author SHA1 Message Date
cbb35d7161 TreeExplorer: add shortcut to adapt STL container automatically
...selecting the iterator or const iterator as apropriate
2017-11-19 17:35:00 +01:00
fd3d6fb60e TreeExplorer: first testcase, build either from Lumiera-Iterator or use StateCore
TODO: also wrap any suitable STL iterable.
we need a one-shot solution here
2017-11-19 02:28:48 +01:00
2345d76138 Research: how to detect that a type in question exposes a free function extension point
The key trick is to form an expression with the free function, using a declval of the type to probe.
What is somewhat tricky is the fact that functions can be void, so we need just to pick up
the type and use it in another type expression
2017-11-19 00:35:38 +01:00
a7bdc05091 WIP: draft first testcase
...just wrapping various kinds of iterators
2017-11-18 18:40:30 +01:00
c3b04af76f TreeExplorer: decide upon the steps towards implementation
Here, the tricky question remains, how to relate this evalutaion scheme
to the well known monadic handling of collections and iterators.

It seems, we can not yet decide upon that question, rather we should
first try to build a concrete implementation of the envisioned algorithm
and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
782b4f949f TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117)
This can be seen as a side track, but the hope is
by relying on some kind of monadic evaluation pattern, we'll be
able to to reconcile the IterExplorer draft from 2012 with the requirement
to keep the implementation of "tree position" entirely opaque.

The latter is mandatory in the use case here, since we must not intermingle
the algorithm to resolve UI-coordinates in any way with the code actually
navigating and accessing GTK widgets. Thus, we're forced to build some kind
of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00