TreeExplorer: finished and unit test PASS
several extensions and convenience features are conceivable, but I'll postpone all of them for later, when actual need arises Note especially there is one recurring design challenge, when creating such a demand-driven tree evaluation: more often than not it turns out that "downstream" will need some information about the nested tree structure, even while, on the surfice, it looks as if the evaluation could be working completely "linearised". Often, such a need arises from diagnostic features, and sometimes we want to invoke another API, which in turn could benefit from knowing something about the original tree structure, even if just abstracted. I have no real solution for this problem, but implementing this pipeline builder leads to a pragmatic workaround: since the iterator already exposes a expandChildren(), it may as well expose a depth() call, even while keeping anything beyond that opaque. This is not the clean solution you'd like, but it comes without any overhead and does not really break the abstraction.
This commit is contained in:
parent
7ed1948a89
commit
1fdeb08f19
5 changed files with 106 additions and 122 deletions
|
|
@ -118,7 +118,6 @@
|
|||
#include "lib/iter-source.hpp" /////////////TICKET #493 : only using the IterSource base feature / interface here. Should really split the iter-source.hpp
|
||||
#include "lib/iter-stack.hpp"
|
||||
#include "lib/util.hpp"
|
||||
#include "lib/test/test-helper.hpp"///////////TODO Bug-o
|
||||
|
||||
#include <functional>
|
||||
#include <utility>
|
||||
|
|
@ -547,11 +546,11 @@ namespace lib {
|
|||
|
||||
ResIter expanded{ hasChildren()? expandChildren_(*expansions_)
|
||||
: expandChildren_(*this)};
|
||||
incrementCurrent(); // consume current head element
|
||||
incrementCurrent(); // consume current head element (but don't clean-up)
|
||||
if (not isnil(expanded))
|
||||
expansions_.push (move(expanded));
|
||||
else
|
||||
dropExhaustedChildren();
|
||||
dropExhaustedChildren(); // clean-up only here to preserve the logical depth
|
||||
|
||||
ENSURE (invariant());
|
||||
}
|
||||
|
|
@ -629,7 +628,7 @@ namespace lib {
|
|||
* be several flavours of child expansion. Unfortunately, most of these conceivable extensions would
|
||||
* require a flexibilisation of Expander's internals and thus increase the complexity of the code.
|
||||
* Thus, if ever encounter the need of anything beyond the basic expansion pattern, we should
|
||||
* rework the design of Expander and introduce building blocks to define the evaluation strategy.
|
||||
* rework the design of Expander and introduce building blocks to define the evaluation strategy.
|
||||
*/
|
||||
template<class SRC>
|
||||
class AutoExpander
|
||||
|
|
@ -820,8 +819,10 @@ namespace lib {
|
|||
|
||||
|
||||
/**
|
||||
* Interface to indicate the ability for _child expansion_.
|
||||
* Interface to indicate and expose the ability for _child expansion_.
|
||||
* This interface is used when packaging a TreeExplorer pipeline opaquely into IterSource.
|
||||
* @remark the depth() call indicates the depth of the child expansion tree. This information
|
||||
* can be used by a "downstream" consumer to react according to a nested scope structure.
|
||||
* @todo expandChildren() should not return the value pointer.
|
||||
* This is just a workaround to cope with the design mismatch in IterSource;
|
||||
* the fact that latter just passes around a pointer into the implementation is
|
||||
|
|
|
|||
|
|
@ -252,7 +252,10 @@ return: 0
|
|||
END
|
||||
|
||||
|
||||
PLANNED "Iterator monad variations (2nd draft)" IterTreeExplorer_test <<END
|
||||
TEST: "Iterator monad variations (2nd draft)" IterTreeExplorer_test <<END
|
||||
out-lit: 4-3-2-1
|
||||
out: Search in random tree: toFind = .....
|
||||
out: Protocol of the search: .+\-.+\-.+\-.+\-.+
|
||||
return: 0
|
||||
END
|
||||
|
||||
|
|
|
|||
|
|
@ -152,15 +152,10 @@ namespace test{
|
|||
size_t cnt_;
|
||||
char letter_;
|
||||
|
||||
// static
|
||||
char
|
||||
static char
|
||||
rndLetter()
|
||||
{
|
||||
static _Fmt fmt{"rLet(%0d < %0d) → %s"};
|
||||
char ll = 'A' + rand() % 26;
|
||||
cout << fmt % cnt_ % lim_ % ll <<endl;
|
||||
return ll;
|
||||
// return 'A' + rand() % 26;
|
||||
return 'A' + rand() % 26;
|
||||
}
|
||||
|
||||
public:
|
||||
|
|
@ -914,6 +909,18 @@ namespace test{
|
|||
* into a limited random sub sequence, down to arbitrary depth. We just assume
|
||||
* that the search has good chances to find its target sequence eventually and
|
||||
* thus only ever visits a small fraction of the endless search space.
|
||||
* - on top of this (opaque) tree navigation we build a secondary search pipeline
|
||||
* based on a state tuple, which holds onto the underlying data source
|
||||
* - the actual decision logic to guide the search lives within the filter predicate
|
||||
* to pull for the first acceptable solution, i.e. a path down from root where
|
||||
* each node matches the next element from the search string. It is from here
|
||||
* that the `expandChildren()` function is actually triggered, whenever we've
|
||||
* found a valid match on the current level. The (random) data source was chosen
|
||||
* such as to make it very likely to find a match eventually, but also to produce
|
||||
* some partial matches followed by backtracking
|
||||
* - note how the "downstream" processing accesses the `depth()` information exposed
|
||||
* on the opaque data source to react on navigation into nested scopes: here, we use
|
||||
* this feature to create a protocol of the search to indicate the actual "winning path"
|
||||
*/
|
||||
void
|
||||
demonstrate_LayeredEvaluation()
|
||||
|
|
@ -921,7 +928,7 @@ namespace test{
|
|||
// Layer-1: the search space with "hidden" implementation
|
||||
using DataSrc = IterExploreSource<char>;
|
||||
DataSrc searchSpace = treeExplore(RandomSeq{-1})
|
||||
.expand([](char){ return RandomSeq{4}; })
|
||||
.expand([](char){ return RandomSeq{15}; })
|
||||
.asIterSource();
|
||||
|
||||
// Layer-2: State for search algorithm
|
||||
|
|
@ -982,20 +989,9 @@ namespace test{
|
|||
{
|
||||
while (it->src.depth() < it->toFind.size() - 1
|
||||
and it->isMatch())
|
||||
{
|
||||
cout <<"|!| expand "<<materialise(it->protocol)<<endl;
|
||||
it->expandChildren();
|
||||
cout <<"|.| "<<*(it->src)<<" -->> "<<materialise(it->protocol)<<endl;
|
||||
}
|
||||
|
||||
// return it->isMatch();
|
||||
if (it->isMatch())
|
||||
return true;
|
||||
else {
|
||||
cout << "|↯| "<<*(it->src)<< " ... " <<materialise(it->protocol)<<endl;
|
||||
return false;
|
||||
}
|
||||
|
||||
return it->isMatch();
|
||||
});
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4260,7 +4260,7 @@ The UI-Bus offers a dedicated API to direct ~MutationMessages towards {{{Tangibl
|
|||
|
||||
In the case at hand, the basic building block of the Lumiera UI, the {{{Tangible}}} offers this interface and thus the ability to construct a concrete TreeMutator, which in turn is bound to the internals of the actual UI-Element in question. Together this allows for a generic implementation of MutationMessage handling, where the designated UI-Element is reshaped by applying a concrete diff sequence embedded in the message with the help of a {{{DiffApplicator<DiffMutable>}}}, based on the TreeMutator exposed.</pre>
|
||||
</div>
|
||||
<div title="Navigator" creator="Ichthyostega" modifier="Ichthyostega" created="201710132354" modified="201712101920" tags="spec decision draft GuiPattern" changecount="19">
|
||||
<div title="Navigator" creator="Ichthyostega" modifier="Ichthyostega" created="201710132354" modified="201712170155" tags="spec decision draft GuiPattern" changecount="21">
|
||||
<pre>//Service to navigate through the UI as generic structure.//
|
||||
The Navigator is a component maintained by the InteractionDirector, and the actual implementation is backed by several facilities of the GuiTopLevel. It serves as foundation to treat the UI as a topological network of abstracted locations, represented as [[UI-Coordinates|UICoord]]. This design, together with the UI-Bus helps to reduce coupling within the UI implementation, since it enables to //get somewhere// and reach //some place// -- without the necessity to rely on concrete widget implementation structure.
|
||||
|
||||
|
|
@ -4287,36 +4287,7 @@ In the current situation ({{red{10/2017}}}), before engaging into the actual imp
|
|||
|
||||
!!!Requirements clarified
|
||||
From these use cases we conclude that the actual requirements for a Navigator component are less than one might expect.
|
||||
In fact it is sufficient to keep //the actual element// entirely opaque, so the Navigator works on UI coordinates solely. The result -- some other UI coordinates -- can then be used to accomplish some tasks implemented elsewhere, like allocating a new view or actually moving [[the Spot|Spot]] (&rarr; InteractionControl)
|
||||
|
||||
!Challenges of the implementation
|
||||
Some tricky problems remain to be solved, though: since the Navigator works on UI coordinates, the fundamental problem remains how to acquire the initial coordinates to start navigation. This is a problem of //reverse lookup:// given a concrete element of the UI, find it's UI coordinates. While we should note that it might not be necessary to "discover" coordinates, because in fact we may know them already -- either the element has to store them (on creation), or some lookup index table could be maintained to serve the same purpose//Service to navigate through the UI as generic structure.//
|
||||
The Navigator is a component maintained by the InteractionDirector, and the actual implementation is backed by several facilities of the GuiTopLevel. It serves as foundation to treat the UI as a topological network of abstracted locations, represented as [[UI-Coordinates|UICoord]]. This design, together with the UI-Bus helps to reduce coupling within the UI implementation, since it enables to //get somewhere// and reach //some place// -- without the necessity to rely on concrete widget implementation structure.
|
||||
|
||||
!The problem of abstraction
|
||||
This goal initially poses some challenge, since it aims beyond the conventional notion of UI programming, where it is sufficient just to wire some widgets and manipulate the receiver of an event notification. The usual UI widgets are just not meant to be treated in a more systematic, generic way -- and indeed, in most cases and for most purposes it is not a good idea to approach UI programming in a to much schematic way. User interfaces need to be tangible, something concrete, with lots of specifics and local traits. Yet this very nature of UI programming tends to turn some //cross-cutting concerns// into serious liabilities. So the deliberate ''decision to introduce a Navigator'' in avoidance of these future burdens and liabilities is a decision of priorities when it comes to shaping the Lumiera UI.
|
||||
|
||||
Which leaves us with the quest of mapping a generic location scheme onto a load of implementation defined structures not exposing any kind of genericness, and to accomplish this within an environment lacking meta information and support for self discovery beyond the most basic abstraction level. As a first step towards bridging this gap, we'll have to identify the actual //command-and-query operations// required to treat UI elements as a topological structure.
|
||||
|
||||
!!!Analysis of expected functionality
|
||||
In order to build a navigation facility, we need to...
|
||||
* follow a path
|
||||
** which means to constitute a location
|
||||
** and to discover child nodes at that location
|
||||
* and we might want to extend (maybe also prune) the collection of children
|
||||
|
||||
!!!Use cases
|
||||
In the current situation ({{red{10/2017}}}), before engaging into the actual implementation, we're able to identify two distinct use cases
|
||||
;View [[specification|GuiComponentView]]
|
||||
:locate a view based on a preconfigured placement
|
||||
:* either to allocate a new view instance
|
||||
:* or to get //just some instance// of a view identified by type
|
||||
;WorkSite navication
|
||||
:move the Spot to some other place in the UI known by its [[UI-Coordinates|UICoord]]
|
||||
|
||||
!!!Requirements clarified
|
||||
From these use cases we conclude that the actual requirements for a Navigator component are less than one might expect.
|
||||
In fact it is sufficient to keep //the actual element// entirely opaque, so the Navigator works on UI coordinates solely. The result -- some other UI coordinates -- can then be used to accomplish some tasks implemented elsewhere, like allocating a new view or actually moving [[the Spot|Spot]] (&rarr; InteractionControl)
|
||||
In fact it is sufficient to keep //the actual element// entirely opaque, so the Navigator works on [[UI coordinates|UICoord]] solely. The result -- some other UI coordinates -- can then be used to accomplish some tasks implemented elsewhere, like allocating a new view or actually moving [[the Spot|Spot]] (&rarr; InteractionControl)
|
||||
|
||||
!Challenges of the implementation
|
||||
Some tricky problems remain to be solved, though: since the Navigator works on UI coordinates, the fundamental problem remains how to acquire the initial coordinates to start navigation. This is a problem of //reverse lookup:// given a concrete element of the UI, find it's UI coordinates. While we should note that it might not be necessary to "discover" coordinates, because in fact we may know them already -- either the element has to store them (on creation), or some lookup index table could be maintained to serve the same purpose
|
||||
|
|
@ -9773,7 +9744,7 @@ The dispatch of //diff messages// is directly integrated into the UI-Bus -- whic
|
|||
|
||||
The Graphical User interface, the upper layer in this hierarchy, embodies everything of tangible relevance to the user working with the application. The interplay with Proc-Layer, the middle layer below the UI, is organised along the distinction between two realms of equal importance: on one side, there is the immediate //mechanics of the interface,// which is implemented directly within the ~UI-Layer, based on the Graphical User Interface Toolkit. And, on the other side, there are those //core concerns of working with media,// which are cast into the HighLevelModel at the heart of the middle layer.</pre>
|
||||
</div>
|
||||
<div title="UICoord" creator="Ichthyostega" modifier="Ichthyostega" created="201709222300" modified="201712101758" tags="def draft spec Concepts GuiPattern" changecount="15">
|
||||
<div title="UICoord" creator="Ichthyostega" modifier="Ichthyostega" created="201709222300" modified="201712170158" tags="def draft spec Concepts GuiPattern" changecount="21">
|
||||
<pre>//A topological addressing scheme to designate structural locations within the UI.//
|
||||
Contrary to conventional screen pixel coordinates, here we aim at a topological description of the UI structure. Such a framework of structural reference allows us
|
||||
* to refer to some "place" or "space" within the interface
|
||||
|
|
@ -9789,12 +9760,12 @@ As starting point for the design of such a framework, we'll pick the notion of a
|
|||
* plus a locally defined access path further down to the actual UI element
|
||||
|
||||
!Properties
|
||||
UI coordinates are a symbolic specification, and as such, their representation is immutable value-like. Essentially, a coordinate specification designates a pathway, and thus is comprised of a sequence of symbols. The individual path component symbol can be addressed by its depth index, starting with the top level window as rooting point. The meaning of first steps of each path is thus always fixed (window, perspective, panel, view), followed by an essentially open sequence of local component names. Yet a given index position need not necessarily be actually defined. A coordinate spec can be indeterminate (nil), but in all other cases a minimal consecutive sequence of symbols is guaranteed to exist.
|
||||
UI coordinates are a symbolic specification, and as such, their representation is immutable value-like. Essentially, a coordinate specification designates a pathway, and thus is comprised of a sequence of symbols. The individual path component symbol can be addressed by its depth index, starting with the top level window as rooting point. The meaning of first steps within each path is thus always fixed (top-level window, perspective, panel, view), followed by an essentially open sequence of local component names. Yet a given index position need not necessarily be actually defined. A coordinate spec can be indeterminate (NIL), but in all other cases a minimal consecutive sequence of symbols is guaranteed to exist.
|
||||
|
||||
!!!flavours of meaning
|
||||
A given coordinate spec needs to be //interpreted// with the help of a resolver, which supplies additional knowledge regarding the actual window and UI configuration backing those interpretations. Such an interpretation allows to query for some typical predications, and it allows for //mutating operations,// which actually build a new coordinate spec from the given one. The general assumption is for all those coordinate interpretations to happen not within an excessively performance critical zone, where a little bit of iteration and repeated recomputation is deemed less costly than extended caching of evaluation state.
|
||||
|
||||
The first distinction to draw is the ''anchor point'' of a given coordinate spec. After anchoring, the designated path is explicitly rooted within a top level window. Obviously, the act of anchoring can be obvious(trivial), it can be //covered by wildcard,// or it can be a free interpolation or match against the existing environment. Starting from the anchor, the next predication to consider is the ''coverage'': the extent to which a given coordinate spec is actually covered by real UI structures. The test for coverage starts at the anchor point and descends following the coordinate spec in question. Backed by this evaluation process of interpretation and matching, we may judge a coordinate spec with respect to several predications
|
||||
The first distinction to draw is the ''anchor point'' of a given coordinate spec. After anchoring, the designated path is explicitly rooted within a top level window. The act of anchoring can thus be obvious(trivial), it can be //covered by wildcard,// or it can be a free interpolation or match against the existing environment. Starting from the anchor, the next predication to consider is the ''coverage'': the extent to which a given coordinate spec is actually covered by real UI structures. The test for coverage starts at the anchor point and descends following the coordinate spec in question. Backed by this evaluation process of interpretation and matching, we may judge a coordinate spec with respect to several predications
|
||||
* the coordinate spec may be totally ''explicit'' -- or it might contain wildcards
|
||||
* one specific path component of the coordinate spec may be known(present) or unknown
|
||||
* regarding the coverage, we may distinguish
|
||||
|
|
@ -9803,7 +9774,7 @@ The first distinction to draw is the ''anchor point'' of a given coordinate spec
|
|||
** a coordinate spec impossible to cover
|
||||
|
||||
!UI coordinate path evaluation
|
||||
As indicated above, evaluation of UI coordinates requires a resolver, and this evaluation process is //stateless.// Evaluation state is confined within the individual query or mutation call. Evaluation is accomplished by first constituting an anchoring, followed by traversal of the coordinate spec and matching against a navigation path within the actual UI window configuration. This process might involve interpretation of some meta-symbols and interpolation of wildcards.
|
||||
As indicated above, evaluation of UI coordinates requires a ''resolver'', and this evaluation process is //stateless.// Evaluation state is confined within the individual query or mutation call. Evaluation is accomplished by first constituting an anchoring, followed by traversal of the coordinate spec and matching against a navigation path within the actual UI window configuration. This process might involve interpretation of some meta-symbols and interpolation of wildcards.
|
||||
|
||||
Internally the coordinate resolver in turn relies on a context query interface, to find out about existing windows, panels, views and tabs and to navigate the real UI structure. The actual implementation of this context query interface is backed by the [[Navigator]] component exposed through the InteractionDirector.
|
||||
!!!Query operations
|
||||
|
|
@ -9821,7 +9792,7 @@ In addition to the //locally decidable properties// of a coordinate spec, which
|
|||
:* it is //partially covered// with an remaining, uncovered extension part
|
||||
:* it is //possible to cover completely//
|
||||
:* it is //impossible to cover//
|
||||
__Some fine points to note__: Anchorage and coverage are not the same thing, but coverage implies anchorage. Only when a path is complete (starts with the window spec) and explicit (has no wildcards), then anchorage implies also partial coverage (namely at least to depth 1). To determine the possible coverage means to perform a resolution with backtracking to pick the maximal solution. Moreover, since "covered" means that the path specification //is at least partially supported by the real UI,// we establish an additional constraint to ensure this resolution did not just match some arbitrary wildcards. Rather we demand that beind / below the last wildcard there is at least one further explicit component in the path spec, which is supported by the real UI. As a consequence, the coverage resolution may fail altogether, will still providing at least an possible anchor point.
|
||||
__Some fine points to note__: Anchorage and coverage are not the same thing, but coverage implies anchorage. Only when a path is complete (starts with the window spec) and explicit (has no wildcards), then anchorage implies also partial coverage (namely at least to depth 1). To determine the possible coverage means to perform a resolution with backtracking to pick the maximal solution. Moreover, since "covered" means that the path specification //is at least partially supported by the real UI,// we establish an additional constraint to ensure this resolution did not just match some arbitrary wildcards. Rather we demand that beind / below the last wildcard there is at least one further explicit component in the path spec, which is supported by the real UI. As a consequence, the coverage resolution may fail altogether, while still providing at least a possible anchor point.
|
||||
!!!Mutations
|
||||
In addition to querying the interpretation of a given coordinate spec with respect to the current UI environment, it is also possible to rewrite or extend the spec based on this environment
|
||||
;anchoring
|
||||
|
|
|
|||
|
|
@ -4739,7 +4739,7 @@
|
|||
<node CREATED="1510341163528" ID="ID_1640768302" MODIFIED="1510341167036" TEXT="fischt nach Lösungen"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1510341362957" ID="ID_1499495468" MODIFIED="1512927071452" TEXT="wirklich monadisch?">
|
||||
<node CREATED="1510341362957" FOLDED="true" ID="ID_1499495468" MODIFIED="1513473668875" TEXT="wirklich monadisch?">
|
||||
<linktarget COLOR="#80c6b3" DESTINATION="ID_1499495468" ENDARROW="Default" ENDINCLINATION="-1812;12745;" ID="Arrow_ID_673178727" SOURCE="ID_1502143527" STARTARROW="None" STARTINCLINATION="4133;-10665;"/>
|
||||
<node CREATED="1510341374332" ID="ID_483481416" MODIFIED="1511572072346" TEXT="naja...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -4963,7 +4963,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510540265979" HGAP="17" ID="ID_1160853986" MODIFIED="1512927037815" VSHIFT="26">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510540265979" HGAP="17" ID="ID_1160853986" MODIFIED="1513473715007" VSHIFT="26">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
|
|
@ -4977,7 +4977,8 @@
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<arrowlink COLOR="#406878" DESTINATION="ID_845080696" ENDARROW="Default" ENDINCLINATION="-88;-61;" ID="Arrow_ID_409690433" STARTARROW="None" STARTINCLINATION="-374;6;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510540282280" ID="ID_304955672" MODIFIED="1512927037832" STYLE="fork" TEXT="Baum-Explorer">
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1510540409159" ID="ID_1790409069" MODIFIED="1512797263191" TEXT="wiederverwendbarer Baustein"/>
|
||||
|
|
@ -5082,12 +5083,15 @@
|
|||
</node>
|
||||
<node CREATED="1510540399304" ID="ID_300971395" MODIFIED="1512927037831" TEXT="Filter">
|
||||
<node CREATED="1510541335201" ID="ID_1717169058" MODIFIED="1510541339780" TEXT="fischt nach Lösungen"/>
|
||||
<node CREATED="1513473625110" ID="ID_267118379" MODIFIED="1513473632137" TEXT="kann die Auswertung treiben">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510941382478" ID="ID_667413818" MODIFIED="1510941391581" TEXT="generische Lösung">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1510941382478" ID="ID_667413818" MODIFIED="1513473609732" TEXT="generische Lösung">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1510941425200" ID="ID_1773303405" MODIFIED="1512927037799" TEXT="Vorgabe">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1510941397907" ID="ID_993148577" MODIFIED="1512955809672" TEXT="zunächst als abstrakter Baustein">
|
||||
|
|
@ -5111,8 +5115,7 @@
|
|||
<i>ich </i>brauche ihn nicht
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1512955707636" ID="ID_398975798" MODIFIED="1512955789085" TEXT="aber bestehendes Verhalten ist gefährlich">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -5133,8 +5136,7 @@
|
|||
Lösung wäre, das Iterator-API erst nach einem expliziten terminalen Aufruf freizuschalten
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1512955715434" ID="ID_1973548871" MODIFIED="1512955720444" TEXT="also: spätermal">
|
||||
|
|
@ -5147,9 +5149,10 @@
|
|||
<node CREATED="1512278456672" ID="ID_488770369" MODIFIED="1512278462388" TEXT="wird in jedem Schritt gestrippt"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1510941463562" ID="ID_845080696" MODIFIED="1512952040864" TEXT="TreeExplorer">
|
||||
<node COLOR="#338800" CREATED="1510941463562" ID="ID_845080696" MODIFIED="1513473715008" TEXT="TreeExplorer">
|
||||
<linktarget COLOR="#585e9d" DESTINATION="ID_845080696" ENDARROW="Default" ENDINCLINATION="-101;761;" ID="Arrow_ID_402051988" SOURCE="ID_1359727169" STARTARROW="None" STARTINCLINATION="208;5;"/>
|
||||
<linktarget COLOR="#83dfc7" DESTINATION="ID_845080696" ENDARROW="Default" ENDINCLINATION="-1109;3887;" ID="Arrow_ID_1645152965" SOURCE="ID_30857289" STARTARROW="None" STARTINCLINATION="2051;-176;"/>
|
||||
<linktarget COLOR="#406878" DESTINATION="ID_845080696" ENDARROW="Default" ENDINCLINATION="-88;-61;" ID="Arrow_ID_409690433" SOURCE="ID_1160853986" STARTARROW="None" STARTINCLINATION="-374;6;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1511571446467" FOLDED="true" ID="ID_1778455053" MODIFIED="1513447893872" TEXT="expand-Operation">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
|
|
@ -5889,7 +5892,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1512363286920" ID="ID_1420123769" MODIFIED="1513293456202" TEXT="Zusammenspiel">
|
||||
<node COLOR="#338800" CREATED="1512363286920" FOLDED="true" ID="ID_1420123769" MODIFIED="1513473558354" TEXT="Zusammenspiel">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1512844805995" ID="ID_927486947" MODIFIED="1512927037825" TEXT="single-val">
|
||||
<icon BUILTIN="help"/>
|
||||
|
|
@ -5900,7 +5903,7 @@
|
|||
<icon BUILTIN="stop-sign"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1512363297486" ID="ID_531127457" MODIFIED="1512927037825" TEXT="re-evaluate">
|
||||
<node COLOR="#338800" CREATED="1512363297486" FOLDED="true" ID="ID_531127457" MODIFIED="1513473550578" TEXT="re-evaluate">
|
||||
<linktarget COLOR="#5a92a2" DESTINATION="ID_531127457" ENDARROW="Default" ENDINCLINATION="385;167;" ID="Arrow_ID_556443427" SOURCE="ID_579206895" STARTARROW="None" STARTINCLINATION="844;55;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
|
|
@ -6206,7 +6209,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513293471929" ID="ID_1115016372" MODIFIED="1513395858395" TEXT="chained expansion">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513293471929" FOLDED="true" ID="ID_1115016372" MODIFIED="1513473546013" TEXT="chained expansion">
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513293488863" ID="ID_263549307" MODIFIED="1513294184112" TEXT="logisches Problem mit layered expansion">
|
||||
<linktarget COLOR="#9c5265" DESTINATION="ID_263549307" ENDARROW="Default" ENDINCLINATION="189;145;" ID="Arrow_ID_1920033917" SOURCE="ID_1013175212" STARTARROW="None" STARTINCLINATION="1219;0;"/>
|
||||
|
|
@ -6243,8 +6246,7 @@
|
|||
an einen bestehenden Iterator angeschlossen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#5f7b87" DESTINATION="ID_618831184" ENDARROW="Default" ENDINCLINATION="0;-100;" ID="Arrow_ID_1648666133" STARTARROW="None" STARTINCLINATION="-110;0;"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -6301,8 +6303,7 @@
|
|||
Das Ergebnis ist eben nicht rein linear.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1513395931727" ID="ID_1852380231" MODIFIED="1513395937842" TEXT="erst mal Erfahrungen sammeln"/>
|
||||
<node CREATED="1513395939502" ID="ID_1752199055" MODIFIED="1513401371843" TEXT="und direkt die Baum-Tiefe durchgeben">
|
||||
|
|
@ -6318,8 +6319,7 @@
|
|||
...das ist nämlich der triviale Workaround
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1513396299238" ID="ID_1740583889" MODIFIED="1513396343855" TEXT="noch besser: diese auf das ChildExpandableSource-Interface legen!">
|
||||
<icon BUILTIN="idea"/>
|
||||
|
|
@ -6354,8 +6354,7 @@
|
|||
noch bevor wir dazu kommen, die Kinder zu pushen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1513448002247" ID="ID_804459643" MODIFIED="1513448144858" TEXT="Lösung">
|
||||
<linktarget COLOR="#63b5aa" DESTINATION="ID_804459643" ENDARROW="Default" ENDINCLINATION="456;372;" ID="Arrow_ID_1606709369" SOURCE="ID_1181955496" STARTARROW="None" STARTINCLINATION="1446;0;"/>
|
||||
|
|
@ -6366,7 +6365,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1511837384749" ID="ID_274979743" MODIFIED="1513395614706" TEXT="asIterSource">
|
||||
<node COLOR="#338800" CREATED="1511837384749" FOLDED="true" ID="ID_274979743" MODIFIED="1513473563423" TEXT="asIterSource">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1512621242778" ID="ID_695969017" MODIFIED="1512927037824" TEXT="Eigenschaften">
|
||||
<icon BUILTIN="info"/>
|
||||
|
|
@ -6374,7 +6373,7 @@
|
|||
<node CREATED="1511837401738" ID="ID_289320579" MODIFIED="1511837414204" TEXT="verpackt hinter OO-Interface mit virtuellen Funktionen"/>
|
||||
<node CREATED="1511837421967" ID="ID_906113750" MODIFIED="1511837433914" TEXT="automatische Heap-Storage"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1512621260992" ID="ID_611871784" MODIFIED="1512927037824" TEXT="erweitertes Interface">
|
||||
<node COLOR="#338800" CREATED="1512621260992" FOLDED="true" ID="ID_611871784" MODIFIED="1513473535917" TEXT="erweitertes Interface">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#990000" CREATED="1512621268527" ID="ID_1388034155" MODIFIED="1512927037843" TEXT="wie bauen?">
|
||||
<icon BUILTIN="help"/>
|
||||
|
|
@ -6667,8 +6666,8 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1512358595283" ID="ID_1526405052" MODIFIED="1512927037810" TEXT="piggyback?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1512358595283" FOLDED="true" ID="ID_1526405052" MODIFIED="1513473590357" TEXT="piggyback?">
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
<node CREATED="1512358616584" ID="ID_1041373923" MODIFIED="1512358662699" TEXT=""könnte mal praktisch sein"">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="12"/>
|
||||
</node>
|
||||
|
|
@ -6728,13 +6727,17 @@
|
|||
</node>
|
||||
</node>
|
||||
<node CREATED="1512358632486" ID="ID_1795551304" MODIFIED="1512358640785" TEXT="aber keine konkrete Anwendung"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1512358649900" ID="ID_1625666992" MODIFIED="1512955563447" TEXT="wäre hier billig zu haben">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1512358649900" ID="ID_1625666992" MODIFIED="1513473577494" TEXT="wäre hier billig zu haben">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="12"/>
|
||||
<node CREATED="1513473578677" ID="ID_834217894" MODIFIED="1513473581168" TEXT="ja..."/>
|
||||
<node CREATED="1513473581876" ID="ID_1304656331" MODIFIED="1513473586811" TEXT="bei Bedarf">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510941467586" ID="ID_381928532" MODIFIED="1512927037797" TEXT="TreeExplorer_test">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1510941467586" ID="ID_381928532" MODIFIED="1513473335441" TEXT="TreeExplorer_test">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1510969031378" ID="ID_1678287752" MODIFIED="1512927037810" TEXT="verify_wrappedIterator();">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1511054727547" ID="ID_328168347" MODIFIED="1511054858441" TEXT="Problem: muß Iterator-Arten unterscheiden">
|
||||
|
|
@ -7127,8 +7130,8 @@
|
|||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510969031379" ID="ID_842384656" MODIFIED="1513216994004" TEXT="demonstrate_LayeredEvaluation();">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1510969031379" ID="ID_842384656" MODIFIED="1513473315193" TEXT="demonstrate_LayeredEvaluation();">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1513035990902" ID="ID_1647713519" MODIFIED="1513036279025" TEXT="Zweck">
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1513035997493" ID="ID_1010963261" MODIFIED="1513036010287" TEXT="vorbereitender Fingerübung für UI-Coord-Matching"/>
|
||||
|
|
@ -7141,7 +7144,7 @@
|
|||
<node CREATED="1513036109158" ID="ID_142686199" MODIFIED="1513036128095" TEXT="es wird tatsächlich etwas Baum-artig gesucht"/>
|
||||
<node CREATED="1513036128988" ID="ID_1461134959" MODIFIED="1513036135063" TEXT="das Ergebnis ist verifizierbar"/>
|
||||
</node>
|
||||
<node CREATED="1513036196163" ID="ID_994330749" MODIFIED="1513128367098" TEXT="Idee-1">
|
||||
<node CREATED="1513036196163" FOLDED="true" ID="ID_994330749" MODIFIED="1513473349080" TEXT="Idee-1">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1513036205114" ID="ID_792801416" MODIFIED="1513036214764" TEXT="zufällige Zahlenfolge wiederfinden"/>
|
||||
<node CREATED="1513036215559" ID="ID_971330002" MODIFIED="1513036250591" TEXT="...indem man in N Permutationen hintereinander sucht"/>
|
||||
|
|
@ -7159,8 +7162,7 @@
|
|||
siehe <font color="#4423e3"><b>std::shuffle</b></font>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1513036568505" ID="ID_1862649545" MODIFIED="1513036572456" TEXT="Kritik">
|
||||
|
|
@ -7170,7 +7172,7 @@
|
|||
<node CREATED="1513202756258" ID="ID_397395434" MODIFIED="1513202760717" TEXT="kein Backtracking"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1513128368566" ID="ID_405602924" MODIFIED="1513128375301" TEXT="Idee-2">
|
||||
<node CREATED="1513128368566" FOLDED="true" ID="ID_405602924" MODIFIED="1513473350640" TEXT="Idee-2">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1513128409745" ID="ID_784629005" MODIFIED="1513128419748" TEXT="naive Primfaktor-Zerlegung"/>
|
||||
<node CREATED="1513129988151" ID="ID_1967188076" MODIFIED="1513129995231" TEXT="brauche...">
|
||||
|
|
@ -7184,7 +7186,8 @@
|
|||
<node CREATED="1513131272956" ID="ID_1394088821" MODIFIED="1513131285590" TEXT="kein Grund, expandChildren() von außen aufzurufen"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1513206569503" ID="ID_729219891" MODIFIED="1513206581186" TEXT="Idee-3">
|
||||
<node CREATED="1513206569503" FOLDED="true" ID="ID_729219891" MODIFIED="1513473378563" TEXT="Idee-3">
|
||||
<arrowlink COLOR="#374d84" DESTINATION="ID_570463763" ENDARROW="Default" ENDINCLINATION="2;-39;" ID="Arrow_ID_1149883114" STARTARROW="None" STARTINCLINATION="0;47;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1513206594428" ID="ID_678047423" MODIFIED="1513206615387">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
|
|
@ -7196,8 +7199,7 @@
|
|||
vorgegebene Zahlenfolge<br />in untendlichem Zufalls-Baum finden
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1513206650964" ID="ID_973791239" MODIFIED="1513206660094" TEXT="brauche...">
|
||||
<icon BUILTIN="forward"/>
|
||||
|
|
@ -7212,17 +7214,18 @@
|
|||
<node CREATED="1513207165088" ID="ID_529012246" MODIFIED="1513207191511" TEXT="Nichtdeterminismus, aber 99.9999% Erfolgs-Chancen"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513218546828" HGAP="-37" ID="ID_570463763" MODIFIED="1513218608169" TEXT="konkret..." VSHIFT="37">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513218561938" ID="ID_1431731183" MODIFIED="1513218616291" TEXT="randomTree bauen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1513218546828" HGAP="-37" ID="ID_570463763" MODIFIED="1513473371054" TEXT="konkret..." VSHIFT="37">
|
||||
<linktarget COLOR="#374d84" DESTINATION="ID_570463763" ENDARROW="Default" ENDINCLINATION="2;-39;" ID="Arrow_ID_1149883114" SOURCE="ID_729219891" STARTARROW="None" STARTINCLINATION="0;47;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1513218561938" ID="ID_1431731183" MODIFIED="1513473294567" TEXT="randomTree bauen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513218569000" ID="ID_973922179" MODIFIED="1513218617435" TEXT="Zustands-Typ bauen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1513218569000" ID="ID_973922179" MODIFIED="1513473296220" TEXT="Zustands-Typ bauen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node CREATED="1513218582175" ID="ID_1963772553" MODIFIED="1513218620609" TEXT="Probleme">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node COLOR="#338800" CREATED="1513218627121" ID="ID_1077327965" MODIFIED="1513284086498" TEXT="Bottom-Error">
|
||||
<node COLOR="#338800" CREATED="1513218627121" FOLDED="true" ID="ID_1077327965" MODIFIED="1513473496041" TEXT="Bottom-Error">
|
||||
<arrowlink COLOR="#179a76" DESTINATION="ID_474013760" ENDARROW="Default" ENDINCLINATION="513;33;" ID="Arrow_ID_1289625747" STARTARROW="None" STARTINCLINATION="426;-150;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1513218635200" ID="ID_418877787" MODIFIED="1513218650010" TEXT="beim Materialisieren der Random-Target-Sequenz"/>
|
||||
|
|
@ -7241,8 +7244,8 @@
|
|||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513219035419" ID="ID_1033553745" MODIFIED="1513219047433" TEXT="prüfen: default constructible state core">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1513219035419" FOLDED="true" ID="ID_1033553745" MODIFIED="1513473487443" TEXT="prüfen: default constructible state core">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1513219271307" ID="ID_474013760" MODIFIED="1513284051101" TEXT="hier liegt der Hund begraben">
|
||||
<linktarget COLOR="#179a76" DESTINATION="ID_474013760" ENDARROW="Default" ENDINCLINATION="513;33;" ID="Arrow_ID_1289625747" SOURCE="ID_1077327965" STARTARROW="None" STARTINCLINATION="426;-150;"/>
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
|
|
@ -7251,9 +7254,15 @@
|
|||
<font NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node CREATED="1513473427921" ID="ID_530629075" MODIFIED="1513473441747" TEXT="Algo-State ist nicht default-constructible">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1513473445287" ID="ID_482215181" MODIFIED="1513473460312" TEXT="aber man man kommt damit über die Runden"/>
|
||||
<node CREATED="1513473461140" ID="ID_9651434" MODIFIED="1513473477134" TEXT="solange man den resultierenden Iterator nicht default-konstruiert"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513283787640" ID="ID_1300399860" MODIFIED="1513283802591" TEXT="Protokoll-pop funktioniert nicht">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513283787640" ID="ID_1300399860" MODIFIED="1513473274042" TEXT="Protokoll-pop funktioniert nicht">
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
<node CREATED="1513283807613" ID="ID_711568006" MODIFIED="1513283821335" TEXT="erschöpfter Kind-Iter wird nicht weggeräumt"/>
|
||||
<node CREATED="1513283822323" ID="ID_1993626666" MODIFIED="1513283848220" TEXT="Folge: es wird auf dem letzten Element weitergezählt"/>
|
||||
<node CREATED="1513283849472" ID="ID_1522104923" MODIFIED="1513283980027" TEXT="Aber der Basis-Iter (Datenquelle) funktioniert korrekt">
|
||||
|
|
@ -7276,24 +7285,25 @@
|
|||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513286396525" ID="ID_1013175212" MODIFIED="1513294184112" TEXT="Logisches Problem mit layered expand">
|
||||
<node CREATED="1513286396525" ID="ID_1013175212" MODIFIED="1513473250590" TEXT="Logisches Problem mit layered expand">
|
||||
<arrowlink COLOR="#9c5265" DESTINATION="ID_263549307" ENDARROW="Default" ENDINCLINATION="189;145;" ID="Arrow_ID_1920033917" STARTARROW="None" STARTINCLINATION="1219;0;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
<node CREATED="1513286420386" ID="ID_32133695" MODIFIED="1513286442066" TEXT="oberer Layer bekommt Ende der Quell-Folge nicht mit"/>
|
||||
<node CREATED="1513286442822" ID="ID_1310607126" MODIFIED="1513286465873" TEXT="...und macht daher endlos mit den Kindern weiter">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513396403408" ID="ID_1034289731" MODIFIED="1513401133757" TEXT="pragmatischer Workaround">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1513396403408" ID="ID_1034289731" MODIFIED="1513473286115" TEXT="pragmatischer Workaround">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1513396411416" ID="ID_1466307579" MODIFIED="1513401380676" TEXT="Tiefe über ChildExpandableSource durchgeben">
|
||||
<arrowlink COLOR="#75c4c1" DESTINATION="ID_1752199055" ENDARROW="Default" ENDINCLINATION="653;643;" ID="Arrow_ID_1536391130" STARTARROW="None" STARTINCLINATION="1299;33;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1513401151507" ID="ID_1181955496" MODIFIED="1513448292560" TEXT="Protokoll aber immer noch nicht korrekt implementiert">
|
||||
<node COLOR="#338800" CREATED="1513401151507" ID="ID_1181955496" MODIFIED="1513473186627" TEXT="Protokoll aber immer noch nicht korrekt implementiert">
|
||||
<arrowlink COLOR="#63b5aa" DESTINATION="ID_804459643" ENDARROW="Default" ENDINCLINATION="456;372;" ID="Arrow_ID_1606709369" STARTARROW="None" STARTINCLINATION="1446;0;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1513401162242" ID="ID_147162782" MODIFIED="1513401173005" TEXT="push am Ende"/>
|
||||
<node CREATED="1513401192358" ID="ID_91552039" MODIFIED="1513401294410" TEXT="Beispiel "FAVSU"">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -7422,10 +7432,14 @@
|
|||
|↯| X ... 40882
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1513401185198" ID="ID_933999759" MODIFIED="1513473212036" TEXT="Zähler läuft weiter">
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
<node CREATED="1513473196754" ID="ID_570569140" MODIFIED="1513473207824" TEXT="Lösung: depth()-Infromation nutzen">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1513401185198" ID="ID_933999759" MODIFIED="1513401189850" TEXT="Zähler läuft weiter"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1513447822247" ID="ID_1725576262" MODIFIED="1513448159466" TEXT="jetzt scheint's zu funktionieren...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -7524,8 +7538,7 @@
|
|||
Protocol of the search: 77944-1-0-3-1
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue