GUI content connector

[Ichthyostega]

Define and draft the mechanism for the UI to be populated with actual content.

The UI-Layer must not perform this on its own behalf -- rather, the UI top-level need to issue some kind of request and/or install a listener somehow into the session. Which in turn then causes the session to cast a population diff upwards into the UI. The task for this ticket is to establish the framework and mechanisms to make establishing such a connection possible.

[Ichthyostega]

from #1145 it is clear that -- while our start-up sequence for the UI is basically sane -- we're lacking a proper trigger point. The reason is, content population has to start after the event loop is running and the UI frame is shown. Incidentally, at that poin we also know that the session subsystem is already completely booted and ready (command processing is open and running). The ordering of subsystem dependencies ensures this ordering. Yet this doesn't mean that actual session (content) is already loaded. It could be present (if the session to load was given as commandline argument), or alternatively, a placeholder session is constructed and populated with some default content.

[Ichthyostega]

The general plan to trigger content population boils down to

• have someone^(TM) inject the population trigger into the GTK event loop
• the trigger itself issues a command towards the session
• execution of aforementioned command activates sending of population / diff messages
• on shutdown of the top-level, send the corresponding deactivation command

[Ichthyostega]

Over the course of the last years, while reworking the backbone of the UI-Layer, the envisioned new solution to this tricky problem has been clarified, implemented and validated to great extent

• after starting the GTK Event-Loop, an action is scheduled into this event loop, which in turn queries the Steam-Layer for the actual model contents
• the response arrives asynchronously, and is dispatched into the GTK-Thread over the UI-Bus
• the model content is described in the form of a »Population Diff« — thereby avoiding the use of a common shared model implementation.
• all relevant entities in the GUI (which represent some part of the model) do implement a Diff Mutator and can thus be addressed through the UI-Bus to bring up the necessary widgets and structures in conformance to the diff description of the model.
• based alone on this setup, it was possible to establish all the wiring and scaffolding to build a fully functional UI, including the handling of dragging-gestures

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin