solution for Timeline slave

[Ichthyostega]

There are various reasons why we might want to offer multiple equivalent UI representations of the same Timeline

• the user might want to see several remote parts of the same timeline simultaneously, in focussed display
• we allow several indeptendent top-level windows (think several desktops), so it might just happen that the same timeline is selected in several windows
• we might want to introduce a focussed view on a nested sequence or virtual clip

Now, since we build our UI on the notion of mapping session contents via a messaging system onto suitable presenters in the UI, we get a conceptual mismatch. Basically we need to cut at some point and duplicate some connections. Either we need the ability within a timeline presentation entity to serve several sets of slave widgets, or we need the ability for those presentation entities to collaborate, where one of them becomes the leader and automatically forwards all notifications to the other members of the cluster. Or, alternatively, we could think of pushing that duplication down into the session, in which case we get a TimelineClone entity, and the Builder then needs to be aware of this situation and generate duplicated responses to be sent to the UI.

In any case, this is an advanced topic, and nowhere near trivial.
It seems reasonable to reject opening duplicate timeline presentations as a first step, and then address this topic way later, when we've gained sufficient knowledge regarding all the subtleties of timeline presentation and editing.

[Ichthyostega]

while now working (for real) on #1016, I stumbled across that problem again, and it looks like I am leaning towards the most systematic option, which is to represent this duplication already within the session as TimelineClone. Rationale

• splitting this way is likely to produce the least accidental complexity -- at that point we are forced to cross-cut only a small number of other concerns. Were we to cut and duplicate within the UI, we'd be forced to carry care for slave entities into a huge number of entirely unrelated UI concerns, like layout management or media display feedback.
• in the case of a focussed view on a nested sequence we are even forced to go that route, since doing otherwise would carry over core session responsibilities into the presentation layer. Consequently, any other solution scheme causes duplicating of functionality.
• however -- if we implement slave timelines already within the session, we still need to make the UI counterpart basically aware of the situation. Thus the TimelineControler needs the ability to delegate some behaviour to another primary controller.

That being said -- I still confirm the decision to postpone that topic altogether...

[Ichthyostega]

...should also look for a better term than »slave«; however, such a term must also transport the meaning well — »drone« for example is not quite precise enough

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin