#1253 new todo

Timeline: validate and complete structure changes by diff

Reported by: Ichthyostega Owned by:
Priority: lesser Milestone: 0integration
Component: lumieraGui Keywords: GTK design sanity gui timeline
Sub Tickets: #1150, #1206, #1252, #1327 Parent Tickets: #961, #1199

Description

As Lumiera Architect,
I want structure changes from the session model to be propagated automatically into the GUI,
to keep those two deeply complex concerns separated

Implementation and Design validation task

Some years ago, the decision was taken not to rely on a shared global data model for coordination between the parts and layers of the application. Rather, the notion of a common structural scheme was introduced, allowing to communicate differences ("diff messages") between collaborating parts of the application. Especially the Timeline UI can now be populated with content just by pushing diff messages into the UI-Bus.

This architecture decision also leads to the consequence, that changes to the structure of the session will be actively propagated and thus pushed into the UI — instead of just "invalidating" the UI and then pulling data content from the lower layers. However, pushing changes into the UI bears the danger of interfering with internal affairs of the UI layer, leading to either corruption within the UI or tangling of structures between session and UI. Thus we are bound to carry through this design consequently. The interface must be arranged in a way to allow the UI to adapt more or less automatically to changes. To a large extent, this requirement is already settled, insofar all relevant structural elements are self-contained and manage their attachments by "smart-handle". Yet there remains one relevant gap to be closed: the UI has built a complex structure of interconnected widgets, and these are considered implementation detail. Thus, after a structural change, these widgets need to be re-assembled and thus re-constructed in accordance to the changed model structure.

As of 10/2022, it is not clear as to what extent this requirement is already implemented. Prior to the "Covid-19" pandemic, which caused an extended break in Lumiera development, seemingly a thorough design analysis has already been carried out, and some far reaching refactorings in the structure of timeline and track UI has been completed. Moreover, a structure change listener mechanism was created, allowing individual components to be notified when their underlying structure model has been changed by diff. However, it seems that the last step is still open for implementation: the track heads and track body entries need to be retracted and re-hooked to their respective parent attachment points, thereby rearranging existing widgets possibly into a new order.

Thus the task is

  • build a demonstration case for populating and then re-ordering sub-tracks deeply nested into the timeline
  • likewise build a demonstration case for re-ordering clips, thereby also dropping some clips and adding new ones
  • find out to what extent the UI structures will be corrupted by these changes and implement the missing parts.


Acceptance Criteria

given
  • a running Lumiera environment with UI
  • a session structure already published into the Timeline-UI
when
a structure-changing diff is pushed into the UI-Bus
then
  • order and extent of possibly nested tracks is adapted accordingly
  • existing clips are re-arranged as child widgets
  • new clips are added through the regular construction mechanism (adding a ClipPresenter) and properly wired
  • obsoleted clips are properly detached and memory is cleaned up without corruption of existing structures

Change history (2)

comment:1 by Ichthyostega, at 2023-09-13T18:58:35Z

blockedby: 1150, 1206, 12521150, 1206, 1252, 1327

comment:2 by Undercover Agent, at 2025-12-25T00:00:00Z

blockedby: 1150, 1206, 1252, 1327
blocking: 961, 1199
Parent Tickets: 961, 1199
Sub Tickets: 1150, 1206, 1252, 1327
Note: See TracTickets for help on using tickets.