rearrange GUI Application top-level

[Ichthyostega]

The current setup of the top level classes within the GTK UI works fine, but highlights some tension and mismatches in the overall design

• we support multiple windows, yet from reading the code, you'd rather get the impression we aren't really aware we have multiple top-level windows
• the WindowManager is the core UI manager, which feels like a mix-up in concerns
• the WorkspaceWindow::createUI() does the global UI initialisation. Again, we have multiple workspace windows.
• GtkLumiera::main() creates a Model and a Controller in local function scope, but stores the WindowManager in an object field.
• it seems, for that very reason, GtlLumiera needed to be a singleton, to allow by-name access to "the" WindowManager
• needless to say, this causes a host of problems when shutting down the UI.

Refactoring Plan

Create a new WorkspaceManager class to act as main hub for all central management aspects pertaining to the UI toolkit internals. Pass this as ctor parameter to anyone in need of its services. Strictly use RAII on all top-level UI entities. Get rid of any "initialised" / "not yet ready" state. Then inherit GtkLumiera from Gtk::Application. Which means, GtkLumiera is the Application. It lives solely in the call stack of the GuiRunner and no one else has to talk to GtkLumiera anymore. We have public facades for that

[Ichthyostega]

created gui::workspace::UiManager and factored out part of the WindowManagers existing code....

[Ichthyostega]

meanwhile I've invented another top-level controller to serve as link betweeen the model aspect and the state aspect. As a consequence, we get a quite cohesive top-level context -- and the UiManagerwill basically serve as the maintainer of this context.

[Ichthyostega]

New UI Backbone

After several rounds of refactoring, gradually a new structure for the UI Backbone emerges, which seems more adequate. The lifecycle and dependency problems related to our "UI main" object have been resolved, and the now obsoleted model is mostly retracted (still waiting for removal of the old and defunct timeline widget).

• GtkLumiera is now the GUI-Plugin object itself
• it creates the UI-Bus and the UiManager
• UiManager becomes the new framework backbone object
• it initialises the GTK and GLib framework directly and performs the GTK event loop.
• we try to avoid the framework aspects of GTK as much as possible and use it as mere UI toolkit.
• moreover, there is a rather cohesive top-level UI context, consisting of several mutually dependent service objects for our core concerns (window list, menu and action registration, style manager)
• one of those service objects is the InteractionDirector, which also is a controller and corresponds to the model root element. From here we start into the dynamic UI population by diff messages pushed up from the lower layers. Most notably, it holds the timeline widgets as children.

[Ichthyostega]

Consider this task as basically settled by now...

• Based on this new structure, meanwhile I was able to build the basic framework for a very flexible timeline UI, with the ability to adapt to model changes published from the Session model in Steam layer....
• some further refactoring and design work (dock handling, flexible binding of actions to panels) has been postponed for the time being

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin