ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

define creation and control structure of TimelineWidget

Browse source
This commit is contained in:
Fischlurch 2016-12-03 05:42:34 +01:00
parent 14588dbc19
commit f995dd51e2
13 changed files with 314 additions and 36 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
src/gui/ctrl/nexus.hpp
View file

@ -27,6 +27,8 @@
** through some [bus terminal](bus-term.hpp). Actually, there is one special BustTerm
** implementation, which acts as router and messaging hub.
**
** @note messages to unknown target elements are silently dropped.
**
** @todo initial draft and WIP-WIP-WIP as of 11/2015
**
** @see TODO_abstract-tangible-test.cpp

1
src/gui/model/controller.hpp
View file

@ -38,6 +38,7 @@
#include "lib/error.hpp"
#include "gui/model/tangible.hpp"
//#include "lib/symbol.hpp"
//#include "lib/util.hpp"

4
src/gui/timeline/timeline-controller.cpp
View file

@ -45,6 +45,7 @@
//using util::_Fmt;
using lib::diff::TreeMutator;
//using std::shared_ptr;
//using std::weak_ptr;
//using util::contains;
@ -65,7 +66,8 @@ namespace timeline {
TimelineController::TimelineController ()
TimelineController::TimelineController (ID identity, ctrl::BusTerm& nexus)
: Controller{identity, nexus}
{
}

22
src/gui/timeline/timeline-controller.hpp
View file

@ -54,6 +54,7 @@
#define GUI_TIMELINE_TIMELINE_CONTROLLER_H
#include "gui/gtk-base.hpp"
#include "gui/model/controller.hpp"
#include "lib/time/timevalue.hpp"
@ -67,19 +68,23 @@ namespace timeline {
/**
* Core timeline display (custom widget).
* Controller to supervise the timeline display.
* As a [tangible element](model::Tangible), it is attached to the UI-Bus.
* @todo WIP-WIP-rewrite as of 12/2016
* @remarks At top level, this widget is split into a header pane (left)
* and a scrollable timeline body (right). The layout of both parts is aligned.
* @remarks a Timeline always has an attached Sequence, which in turn has
* a single mandatory root track. This in turn might hold further child tracks,
* thus forming a fork of nested scopes.
*/
class TimelineController
: public model::Controller
{
public:
/**
* @param source_state state to be used used as the
* data source (model) for this timeline widget.
* @param identity used to refer to a corresponding timeline element in the Session
* @param nexus some established connection to the UI-Bus, used for registration.
*/
TimelineController();
TimelineController (ID identity, ctrl::BusTerm& nexus);
~TimelineController();
@ -91,7 +96,10 @@ namespace timeline {
private:/* ===== Events ===== */
private:/* ===== Internals ===== */
/** set up a binding to respond to mutation messages via UiBus */
virtual void buildMutator (lib::diff::TreeMutator::Handle) override;
};

5
src/gui/timeline/timeline-widget.cpp
View file

@ -65,9 +65,12 @@ namespace timeline {
TimelineWidget::TimelineWidget ()
TimelineWidget::TimelineWidget (TimelineID identity, ctrl::BusTerm& nexus)
: Gtk::Paned{Gtk::ORIENTATION_VERTICAL}
, control_{new TimelineController{identity, nexus}}
, layout_{new LayoutManager}
{
UNIMPLEMENTED ("build the timeline UI");
}

52
src/gui/timeline/timeline-widget.hpp
View file

@ -33,6 +33,20 @@
** to a single session::Timeline, known by its ID. The widget creates a TimelineController
** right away, which takes initiative to populate the display with that Timeline's contents.
**
** #Lifecycle
** The assumption is that any element creation and deletion is triggered through messages over
** the [UI-Bus](\ref ui-bus.hpp). So there will be a _parent element,_ corresponding to the
** ["model root"](\ref session::Root), and this parent, in response to some mutation message,
** will create a TimelineWidget, add it into the appropriate GTK display setup and manage it
** as child element; the [construction parameters](TimelineWidget::TimelineWidget] ensure
** it gets connected to the bus as well. Incidentally, this assumption also implies that
** this parent element has set up a _binding for diff mutation,_ typically by implementing
** model::Tangible::buildMutator. And further on this means that the parent will also
** destroy the TimelineWidget, prompted by a message to that end. All deregistration
** and unwinding happens automatically. Widgets, and also our model::Controller
** is `sigc::trackable`, which means after destruction any further signals
** will be silently ignored.
**
** @todo as of 12/2016 a complete rework of the timeline display is underway
**
*/
@ -42,18 +56,28 @@
#define GUI_TIMELINE_TIMELINE_WIDGET_H
#include "gui/gtk-base.hpp"
#include "gui/timeline/timeline-controller.hpp"
#include "gui/timeline/timeline-controller.hpp" /////TODO possible to push that into the implementation?
#include "gui/timeline/layout-manager.hpp"
#include "gui/ctrl/bus-term.hpp"
#include "lib/time/timevalue.hpp"
#include "lib/diff/diff-mutable.hpp"
#include "lib/idi/entry-id.hpp"
//#include <memory>
//#include <vector>
namespace proc {
namespace asset{
class Timeline;
}}
namespace gui {
namespace timeline {
using TimelineID = lib::idi::EntryID<proc::asset::Timeline>;
/**
* Core timeline display (custom widget).
@ -65,12 +89,30 @@ namespace timeline {
class TimelineWidget
: public Gtk::Paned
{
std::unique_ptr<TimelineController> control_;
std::unique_ptr<LayoutManager> layout_;
public:
/**
* @param source_state state to be used used as the
* data source (model) for this timeline widget.
/** build a new timeline display and attach it to the UI-Bus.
* @param identity used to refer to a corresponding element in the Session
* @param nexus some established connection to the UI-Bus, will be used
* to register the embedded TimelineController as communication
* partner to respond under the given ID.
* @remarks after creation, the widget can just be hooked up and wired like
* any ordinary GTK element; it becomes passive and just responds to
* signals. The active role is played by the controller, which also
* responds to mutation messages; this is the only way to populate
* the timeline display. Likewise, a timeline shall be deleted by
* sending an respective mutation message to its _parent element,_
* the one that created it, typically also in response to a message.
* Non the less it is possible just to delete a TimelineWidget, since
* it is a Gtk::Widget, and the controller is also `sigc::trackable`
* and additionally, as a gui::model::Tangible, it will deregister
* automatically from the UI-Bus. After that, any further messages
* towards this element will be dropped silently.
*/
TimelineWidget ();
TimelineWidget (TimelineID identity, ctrl::BusTerm& nexus);
~TimelineWidget();

8
src/gui/ui-bus.hpp
View file

@ -29,14 +29,14 @@
** inherit from the gui::model::Tangible base. The top-level gui::UiBus element is
** a front-end and framework component managed by the [GTK-main](\ref GtkLumiera::main).
**
** @warning as of 12/2015, this is still totally a mess. This \em will remain
** @warning as of 12/2016, this is still totally a mess. This \em will remain
** the one-and-only master controller of the UI, but I am determined
** to change the architecture and implementation technique altogether.
** For the time being, we keep the controller::Controller in place, as
** written by Joel Holdsworth, while building the new UI-Bus frontend
** to take on this central role eventually.
**
** \par rationale
** # Rationale
** The UI-Bus acts as a **mediating backbone**, impersonating the role
** of the _Model_ and the _Controler_ in the [MVC-Pattern]in common UI architecture.
**
@ -54,9 +54,9 @@
** feedback and reactions to operating some interface controls. Any actual operations and
** actions relevant to the application as a whole, are to be sent as messages into the
** UI-Bus. The interface code can assume some "core services" to be available _somewhere;_
** these core services will receive the messages, act on them and _respond asynchronously_.
** these core services will receive the messages, act on them and _respond asynchronously._
**
** \par Bus interactions
** # Bus interactions
** The UI-Bus has a star shaped topology, with a central "bus master" hub, the ["Nexus"](\ref Nexus),
** which maintains a routing table. Attachment and detachment of elements can be managed automatically,
** since all of the UI-Bus operations _perform within the UI event thread._

1
src/lib/ref-array.hpp
View file

@ -35,6 +35,7 @@ namespace lib {
* Typically the return type is an interface,
* and the Implementation wraps some datastructure
* holding subclasses.
* @todo ouch -- a collection that isn't iterable... ///////////////////////TICKET #1040
*/
template<class T>
struct RefArray : boost::noncopyable

14
src/proc/asset/timeline.hpp
View file

@ -38,10 +38,15 @@
** Like every structural asset, the creation of timelines happens automatically
** on referral; Timelines can be queried from the StructFactory, providing additional
** requested capabilities. Commonly clients will retrieve a given timeline by query
** on the name-ID of the timeline: \c Struct::retrieve(Query<Timeline>("id(theName)."))
** on the name-ID of the timeline: `Struct::retrieve (Query<Timeline>("id(theName)."))`
** Additionally, the binding to a specific sequence may be established alongside:
** \c "timeline(theTimelineName),bindSequence(theTimelineName,sequenceID)."
** `"timeline(theTimelineName), bindSequence(theTimelineName,sequenceID)."`
**
** @todo around 2010, the concept of Timeline and Session binding was defined,
** together with a rough preliminary implementation. Up to 2017, there
** was no opportunity to set this system really into motion; this is
** not necessarily a bad thing, since meanwhile we understand way
** better in which way the Session will actually be accessed...
** @see Session
** @see Sequence
** @see StructFactory
@ -84,7 +89,10 @@ namespace asset {
/**
* TODO type comment
* @todo this new Timeline API was invented about 2010
* and remained in half finished state ever since.
* @todo 2016 can confirm that we still want to go that route
* @todo we need some actual interface, beyond just creating timelines!
*/
class Timeline
: public Struct

2
src/proc/mobject/session.hpp
View file

@ -24,7 +24,7 @@
/** @file session.hpp
** @ingroup session
** Primary Interface to the current Session.
** The session interface can be used to discover session's contents.
** The session interface can be used to discover session contents.
** Mostly, these objects within the session are MObject subclasses, but they
** are attached into the session by a Placement. Usually, you'd want to use
** the discovered objects to invoke operations on them; in most cases,

8
tests/gui/abstract-tangible-test.cpp
View file

@ -177,7 +177,7 @@ namespace test {
* - error state indication
* - structural changes by diff message
*
* This test documents a generic interaction protocoll supported by all
* This test documents a generic interaction protocol supported by all
* "tangible" elements of the Lumiera GTK UI. This works by connecting any
* such element to a messaging backbone, the *UI-Bus*. By sending messages
* according to this protocol, typical state changes can be detected and
@ -187,7 +187,7 @@ namespace test {
* @note the actions in this test are verified with the help of an EventLog
* built into the mock UI element and the mock UI-Bus counterpart.
* Additionally, each test case dumps those log contents to STDOUT,
* which hopefully helps to undrstand the interactions in detail.
* which hopefully helps to understand the interactions in detail.
*
* @see BusTerm_test
* @see DiffTreeApplication_test
@ -211,7 +211,7 @@ namespace test {
/** @test verify the UI widget unit test support framework.
* The generic backbone of the Lumiera UI offers a mock UI element,
* with the ability to stand-in for actual elements present in the real GUI.
* This allows us to rig a emulated test user interface to cover interactions
* This allows us to rig an emulated test user interface to cover interactions
* involving some communication from or to interface elements. After setting up
* a [mock UI-element](\ref MockElm) with a suitable name / ID, we're able to
* operate this element programmatically and to send messages and responses
@ -338,7 +338,7 @@ namespace test {
MARK_TEST_FUN
EventLog nexusLog = gui::test::Nexus::startNewLog();
// Setup test stage: define an command/action "in Proc"
// Setup test stage: define a command/action "in Proc"
CommandDef (DUMMY_CMD_ID)
.operation (operate)
.captureUndo (capture)

12
wiki/renderengine.html
View file

@ -3517,8 +3517,8 @@ For each meta asset instance, initially a //builder// is created for setting up
<div title="Model" modifier="Ichthyostega" created="201003210020" modified="201003210021" tags="overview">
<pre>Lumiera's Proc-Layer is built around //two interconnected models,// mediated by the [[Builder]]. Basically, the &amp;rarr;[[Session]] is an external interface to the HighLevelModel, while the &amp;rarr;RenderEngine operates the structures of the LowLevelModel.</pre>
</div>
<div title="ModelDependencies" modifier="Ichthyostega" created="201003020150" modified="201505310112" tags="SessionLogic Model operational spec draft img" changecount="1">
<pre>Our design of the models (both [[high-level|HighLevelModel]] and [[low-level|LowLevelModel]]) relies partially on dependent objects being kept consitently in sync. Currently (2/2010), __ichthyo__'s assessment is to consider this topic not important and pervasive enough to justify building a dedicated solution, like e.g. a central tracking and registration service. An important point to consider with this assesment is the fact that the session implementation is beeing kept mostly single-threaded. Thus, lacking one central place to handle this issue, care has to be taken to capture and treat all the relevant individual dependencies properly at the implementation level.
<div title="ModelDependencies" modifier="Ichthyostega" created="201003020150" modified="201612030206" tags="SessionLogic Model operational spec draft img" changecount="4">
<pre>Our design of the models (both [[high-level|HighLevelModel]] and [[low-level|LowLevelModel]]) relies partially on dependent objects being kept consitently in sync. Currently (2/2010), __ichthyo__'s assessment is to consider this topic not important and pervasive enough to justify building a dedicated solution, like e.g. a central tracking and registration service. An important point to consider with this assessment is the fact that the session implementation is deliberately kept single-threaded. While this simplifies reasoning, we also lack one central place to handle this issue, ans so care has to be taken to capture and treat all the relevant individual dependencies properly at the implementation level.
!known interdependencies
[&gt;img[Fundamental object relations used in the session|uml/fig136453.png]]
@ -3527,7 +3527,7 @@ For each meta asset instance, initially a //builder// is created for setting up
* currently as of 2/2010 the exact dependency of the automation calculation during the render process onto the automation definitions within the HighLevelModel remains to be specified.
!!Timelines and Sequences
While implemented as StructAsset, additionally we need to assure every instance gets linked to the relevant parts of the model and registered with the session. Contrast this with other kinds of assets, which may just remain enlisted, but never actually used.
While implemented as StructAsset, additionally we need to ensure every instance gets linked to the relevant parts of the model and registered with the session. Contrast this with other kinds of assets, which may just remain enlisted, but never actually used.
;the Session
:...is linked 1:1 with timelines and sequences. Registration and deregistration is directly tied to creation and destruction.
@ -3539,7 +3539,7 @@ While implemented as StructAsset, additionally we need to assure every instance
: __created__ &amp;rArr; create a dedicated new binding, either useing an existing sequence, or a newly created empty sequence
: __destroy__ &amp;rArr; remove binding, while the previously bound sequence remains in model.
;root-placed Binding
:while generally a Binding can exist in the model, when attached to root, a Timeline will be created
:while generally a Binding can just exist somewhere in the model, when attached to root, a Timeline will be created
: __created__ &amp;rArr; an existing sequence might be given on creation, otherwhise a default configured sequence is created
: __destroy__ &amp;rArr; implemented by detaching from root (see below) prior to purging from the model.
: __attached__ to root &amp;rArr; invoke Timeline creation
@ -8144,14 +8144,14 @@ Currently (1/11), the strategy is implemented according to (1) and (4) above, le
Implementation of this strategy is still broken: it doesn't work properly when actually the change passing over the zero point happens by propagation from lower digits. Because then -- given the way the mutators are implemented -- the //new value of the wrapping digit hasn't been stored.// It seems the only sensible solution is to change the definition of the functors, so that any value will be changed by side-effect {{red{Question 4/11 -- isn't this done and fixed by now??}}}
</pre>
</div>
<div title="Timeline" modifier="Ichthyostega" created="200706250721" modified="201505310138" tags="def" changecount="3">
<div title="Timeline" modifier="Ichthyostega" created="200706250721" modified="201612030116" tags="def" changecount="4">
<pre>Timeline is the top level element within the [[Session (Project)|Session]]. It is visible within a [[timeline view in the GUI|GuiTimelineView]] and represents the effective (resulting) arrangement of media objects, to be rendered for output or viewed in a Monitor (viewer window). A timeline is comprised of:
* a time axis in abolute time ({{red{WIP 1/10}}}: not clear if this is an entity or just a conceptual definition)
* a list of [[global Pipes|GlobalPipe]] representing the possible outputs (master busses)
* //exactly one// top-level [[Sequence]], which in turn may contain further nested Sequences.
* when used for Playback, a ViewConnection is necessary, allowing to get or connect to a PlayController
Please note especially that following this design //a timeline doesn't define tracks.// [[Tracks form a Tree|Fork]] and are part of the individual sequences, together with the media objects placed to these tracks. Thus sequences are independent entities which may exist stand-alone within the model, while a timeline is //always bound to hold a sequence.// &amp;rarr; see ModelDependencies
Please note especially that following this design //a timeline doesn't define tracks.// [[Tracks form a Tree|Fork]] and are part of the individual sequences, together with the media objects placed to this //track fork.// Thus sequences are independent entities which may exist stand-alone within the model, while a timeline is //always bound to hold a sequence.// &amp;rarr; see ModelDependencies
[&gt;img[Fundamental object relations used in the session|uml/fig136453.png]]
Within the Project, there may be ''multiple timelines'', to be viewed and rendered independently. But, being the top-level entities, multiple timelines may not be combined further. You can always just render (or view) one specific timeline. A given sequence may be referred directly or indirectly from multiple timelines though. A given timeline is represented within the GUI according to [[distinct principles and conventions|GuiTimelineView]]

219
wiki/thinkPad.ichthyo.mm
View file

@ -176,6 +176,141 @@
<node CREATED="1479678723576" ID="ID_666987913" MODIFIED="1479678758128" TEXT="Layout Grundmuster: zweigeteilt"/>
<node CREATED="1479678736655" ID="ID_1313901406" MODIFIED="1479678745545" TEXT="globaler Layout-Manager"/>
</node>
<node CREATED="1480723110777" HGAP="24" ID="ID_1197860604" MODIFIED="1480725393020" TEXT="Kontrollstruktur" VSHIFT="7">
<icon BUILTIN="pencil"/>
<node CREATED="1480723136861" ID="ID_839909208" MODIFIED="1480723143433" TEXT="Einstiegspunkt">
<node CREATED="1480723144188" ID="ID_420419439" MODIFIED="1480723148072" TEXT="TimelineWidget"/>
<node CREATED="1480723148572" ID="ID_1331974915" MODIFIED="1480723151671" TEXT="wirklich">
<icon BUILTIN="help"/>
</node>
</node>
<node CREATED="1480723200765" ID="ID_1498754065" MODIFIED="1480723203209" TEXT="aktiv">
<node CREATED="1480723223938" ID="ID_1057816659" MODIFIED="1480723229172" TEXT="UI-Mechanik">
<node CREATED="1480723246207" ID="ID_988556037" MODIFIED="1480723268808" TEXT="Scrollen"/>
<node CREATED="1480723270492" ID="ID_1057899601" MODIFIED="1480723272959" TEXT="Zoomen"/>
<node CREATED="1480723288521" ID="ID_238022948" MODIFIED="1480723290941" TEXT="Navigieren">
<node CREATED="1480723291697" ID="ID_486282572" MODIFIED="1480723294564" TEXT="delegiert"/>
<node CREATED="1480723296128" ID="ID_681787776" MODIFIED="1480723317025" TEXT="timeline::NavigatorWidget"/>
</node>
<node CREATED="1480723797453" ID="ID_451406554" MODIFIED="1480723801984" TEXT="Benachrichtigungen"/>
</node>
<node CREATED="1480723989315" ID="ID_1314277524" MODIFIED="1480723991902" TEXT="zentral">
<node CREATED="1480724166868" ID="ID_1338884424" MODIFIED="1480724170734" TEXT="Struktur&#xe4;nderung">
<node CREATED="1480724385214" ID="ID_1913904871" MODIFIED="1480724400259" TEXT="DiffMutable bieten">
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1480724171371" ID="ID_410013238" MODIFIED="1480724177718" TEXT="Struktur&#xe4;nderung vorbereiten">
<node CREATED="1480724215437" ID="ID_1953691654" MODIFIED="1480724219873" TEXT="Kontextmen&#xfc;"/>
<node CREATED="1480724317120" ID="ID_1898649980" MODIFIED="1480724328098" TEXT="Fokus + Befehl / Taste"/>
<node CREATED="1480724346548" ID="ID_200646693" MODIFIED="1480724360777" TEXT="markieren + Kommando schicken">
<icon BUILTIN="forward"/>
</node>
</node>
</node>
</node>
<node CREATED="1480724417722" HGAP="55" ID="ID_940232384" MODIFIED="1480724427486" TEXT="drei M&#xf6;glichkeiten" VSHIFT="5">
<node CREATED="1480724450958" ID="ID_493402962" MODIFIED="1480725131286" TEXT="Widget is Tangible">
<icon BUILTIN="button_cancel"/>
<node CREATED="1480724706739" ID="ID_1043502336" MODIFIED="1480724721717" TEXT="kann dann direkt Notifications implementieren"/>
<node CREATED="1480724724585" ID="ID_576219568" MODIFIED="1480724737691" TEXT="mu&#xdf; f&#xfc;r alle Struktur&#xe4;nderungen delegieren"/>
<node CREATED="1480724738583" ID="ID_403933116" MODIFIED="1480724756546" TEXT="Achtung: Tangible is noncopyable">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1480724761876" ID="ID_335451126" MODIFIED="1480724779581" TEXT="wegen BusTerm">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
braucht feste Speicher-Addresse
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1480724781801" ID="ID_198046255" MODIFIED="1480724795442" TEXT="folglich: nicht in STL-Container">
<icon BUILTIN="stop-sign"/>
</node>
</node>
</node>
<node CREATED="1480724461860" ID="ID_865875607" MODIFIED="1480725128760" TEXT="Controller is Tangible">
<icon BUILTIN="button_ok"/>
<node CREATED="1480724851312" ID="ID_1653680733" MODIFIED="1480724896364" TEXT="erzeugt R&#xfc;ckbezug f&#xfc;r Notifications">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
..d.h. der Controller mu&#223; wieder auf das Widget zugreifen
</p>
<p>
und sei es auch blo&#223; &#252;ber ein Interface!
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1480724910096" ID="ID_874781354" MODIFIED="1480724920595" TEXT="kann direkt das View-Modell manipulieren"/>
<node CREATED="1480724927814" ID="ID_1912287440" MODIFIED="1480724956251" TEXT="ist nicht direkt erreichbar">
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1480724935397" ID="ID_1279073903" MODIFIED="1480725166588" TEXT="Modell-Vater mu&#xdf; DiffMutable sehen">
<arrowlink COLOR="#2817aa" DESTINATION="ID_550796340" ENDARROW="Default" ENDINCLINATION="129;0;" ID="Arrow_ID_1199115828" STARTARROW="None" STARTINCLINATION="129;0;"/>
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1480724468283" ID="ID_1683703083" MODIFIED="1480725137591" TEXT="expose DiffMutable">
<icon BUILTIN="idea"/>
<node CREATED="1480724983774" ID="ID_845297603" MODIFIED="1480724994016" TEXT="hei&#xdf;t: Manipulation au&#xdf;erhalb des Diff-Systems"/>
<node CREATED="1480725000029" ID="ID_1586514211" MODIFIED="1480725010294" TEXT="wir steigen stets auf Ebene einer Timeline ein"/>
<node CREATED="1480725012731" ID="ID_9332776" MODIFIED="1480725101873">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
<i>aber:</i>&#160;Binding im Diff-System durchaus m&#246;glich
</p>
</body>
</html>
</richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...denn:
</p>
<p>
das Diff-System verlangt nicht, da&#223; Kinder in der Collection auch Tangible sind.
</p>
<p>
Es verlangt nur
</p>
<ul>
<li>
da&#223; wir wissen, wie wir Kinder machen
</li>
<li>
da&#223; wir f&#252;r ein gegebenes Kind ein DiffMutable beschaffen k&#246;nnen
</li>
</ul>
</body>
</html>
</richcontent>
<icon BUILTIN="idea"/>
</node>
<node CREATED="1480725106478" ID="ID_550796340" MODIFIED="1480725166588" TEXT="effektiv auch die L&#xf6;sung f&#xfc;r Alternative-2">
<linktarget COLOR="#2817aa" DESTINATION="ID_550796340" ENDARROW="Default" ENDINCLINATION="129;0;" ID="Arrow_ID_1199115828" SOURCE="ID_1279073903" STARTARROW="None" STARTINCLINATION="129;0;"/>
<icon BUILTIN="yes"/>
</node>
</node>
</node>
</node>
<node CREATED="1479688613990" ID="ID_1537299376" MODIFIED="1479688617705" TEXT="Struktur&#xe4;nderung">
<node CREATED="1479688621637" ID="ID_71591229" MODIFIED="1479688631881" TEXT="notwendig: strukturelles Modell">
<icon BUILTIN="messagebox_warning"/>
@ -184,7 +319,7 @@
<node CREATED="1479688653913" ID="ID_1435784278" MODIFIED="1479688666394" TEXT="dieser wiederum mu&#xdf; f&#xfc;r jede Erweiterung konsultiert werden"/>
</node>
</node>
<node CREATED="1479774700668" HGAP="36" ID="ID_1407821684" MODIFIED="1480606879554" TEXT="Mutation" VSHIFT="7">
<node CREATED="1479774700668" HGAP="47" ID="ID_1407821684" MODIFIED="1480725485721" TEXT="Mutation" VSHIFT="13">
<node CREATED="1479774705839" ID="ID_301222108" MODIFIED="1479774729887" TEXT="Problem">
<icon BUILTIN="messagebox_warning"/>
<node COLOR="#d30f0f" CREATED="1479774731141" ID="ID_1523088286" MODIFIED="1479774739456" TEXT="Element != Widget"/>
@ -219,6 +354,10 @@
</html></richcontent>
</node>
<node CREATED="1480120359191" ID="ID_1039094699" MODIFIED="1480120390087" TEXT="Widget-Container hat keine &#xc4;nderungs-Schnittstelle"/>
<node COLOR="#338800" CREATED="1480725417748" HGAP="28" ID="ID_1996114890" MODIFIED="1480725470323" TEXT="...war dann doch kein so schlimmes Problem" VSHIFT="7">
<arrowlink COLOR="#69ee12" DESTINATION="ID_1964453367" ENDARROW="Default" ENDINCLINATION="-55;-87;" ID="Arrow_ID_636465261" STARTARROW="None" STARTINCLINATION="-116;69;"/>
<icon BUILTIN="button_ok"/>
</node>
</node>
</node>
<node CREATED="1480120516442" ID="ID_880374813" MODIFIED="1480120518812" TEXT="Ans&#xe4;tze">
@ -325,7 +464,8 @@
<icon BUILTIN="forward"/>
</node>
</node>
<node CREATED="1480121177145" ID="ID_1964453367" MODIFIED="1480123456994" TEXT="Widget is delegate/slave">
<node CREATED="1480121177145" ID="ID_1964453367" MODIFIED="1480725470323" TEXT="Widget is delegate/slave">
<linktarget COLOR="#69ee12" DESTINATION="ID_1964453367" ENDARROW="Default" ENDINCLINATION="-55;-87;" ID="Arrow_ID_636465261" SOURCE="ID_1996114890" STARTARROW="None" STARTINCLINATION="-116;69;"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1480121209277" ID="ID_834494092" MODIFIED="1480123869816" TEXT="Hinzuf&#xfc;gungen erzeugen neue Widgets">
<icon BUILTIN="idea"/>
@ -431,10 +571,81 @@
<node CREATED="1480639429307" ID="ID_1922498247" MODIFIED="1480639431270" TEXT="Canvas"/>
</node>
</node>
<node CREATED="1480606954115" ID="ID_1178000371" MODIFIED="1480606960326" TEXT="Struktur-Modell"/>
<node CREATED="1480606954115" ID="ID_1178000371" MODIFIED="1480606960326" TEXT="Struktur-Modell">
<node CREATED="1480725215087" ID="ID_212845679" MODIFIED="1480725217771" TEXT="erzeugen">
<node CREATED="1480725218783" ID="ID_192239117" MODIFIED="1480725230986" TEXT="Controller ist Tangible">
<icon BUILTIN="yes"/>
</node>
<node CREATED="1480725247115" ID="ID_1533101483" MODIFIED="1480725266740" TEXT="Konstruktion erfordert...">
<node CREATED="1480725267632" ID="ID_335184137" MODIFIED="1480725357016" TEXT="EntryID&lt;Timeline&gt;">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
eigentlich...
</p>
<p>
w&#252;rde eine BareEntryID gen&#252;gen.
</p>
<p>
Aber die strengere Typisierung erscheint mir ein
</p>
<p>
hilfreicher Wink f&#252;r den User
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1480725273775" ID="ID_1495656573" MODIFIED="1480725279987" TEXT="Bus-Term-Referenz"/>
</node>
</node>
<node CREATED="1480725377994" ID="ID_172881069" MODIFIED="1480725379629" TEXT="verwalten"/>
</node>
<node CREATED="1480694550601" ID="ID_391329400" MODIFIED="1480694554372" TEXT="TimelineController">
<node CREATED="1480694557112" ID="ID_786517324" MODIFIED="1480694570434" TEXT="Widget ist Startpunkt"/>
<node CREATED="1480694571310" ID="ID_1188786444" MODIFIED="1480694576714" TEXT="aber Controller wird Chef"/>
<node CREATED="1480725633399" ID="ID_1475661668" MODIFIED="1480725663683" TEXT="mu&#xdf; erst mal Controller implementieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...abstraktes Interface
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="smily_bad"/>
<node CREATED="1480725680713" ID="ID_448125852" MODIFIED="1480725692188" TEXT="Delegate for Notification">
<icon BUILTIN="help"/>
</node>
<node CREATED="1480725704142" ID="ID_992732373" MODIFIED="1480725707913" TEXT="was bleibt abstrakt">
<node CREATED="1480725715916" ID="ID_890987188" MODIFIED="1480725754663" TEXT="buildMutator">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
lat&#252;rnich
</p>
<p>
...den <i>mu&#223;</i>&#160;jeder individuell implementieren,
</p>
<p>
um die Bindung herzustellen
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="ksmiletris"/>
</node>
</node>
</node>
</node>
<node CREATED="1480606985087" ID="ID_885244508" MODIFIED="1480639465600" TEXT="Layout-Manager">
<node CREATED="1480639469981" ID="ID_983391388" MODIFIED="1480639472833" TEXT="Abstraktionen"/>
@ -6347,7 +6558,7 @@
<icon BUILTIN="help"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1475342135193" FOLDED="true" HGAP="31" ID="ID_336806935" MODIFIED="1475449459631" TEXT="Problem: Diff-Nachricht" VSHIFT="7">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1475342135193" FOLDED="true" HGAP="31" ID="ID_336806935" MODIFIED="1480725582488" TEXT="Problem: Diff-Nachricht" VSHIFT="7">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1475342157302" ID="ID_1383404259" MODIFIED="1475342166025" TEXT="&quot;Diff&quot; ist kein Typ"/>
<node CREATED="1475342185707" ID="ID_787925049" MODIFIED="1475342190662" TEXT="Lumiera-Iteratoren sind generisch"/>