draft timeline display building

[Ichthyostega]

As Lumiera Architect,
I want a Timeline UI accommodated to a dynamic model structure,
to allow for later evolution of the core independent from pre-established limitations of presentation.

Call for Design Draft

Need to draft mechanics how to build a proper layout from flexible building blocks, thereby choosing the clip display appearance style dynamically. Key point to watch is the fact we build the timeline presentation from a flexible nested set of elements to show — while the core is able to choose from a wide array of possible arrangements. Which means, we must not manipulate and arrange UI elements from a central »display manager«, rather we need a collaborative evaluation pass. Otherwise, excessive complexity will hamper further evolution of the timeline display, and jeopardise essential objectives of the whole project: Lumiera aims at building better editing software, not just to reproduce existing software or to mimic the old style of editing film with celluloid and scissors...

Acceptance Criteria

• Design for UI model and supporting structures has been established
• Timeline can be populated with content
  • within limits of a generic tree structure
  • without assuming specific fixed arrangement of tracks and contents
• Widgets for presentation are dynamically built, wired and attached to follow suit

[Ichthyostega]

a rough concept is complete in my mind....
Intention is to turn this into code right away, even while we're in fact far from being able to get this into operative state. Should be sufficient to get it to compile for now; hopefully I'll be able to use at least the ClipWidget built here in my GtkLayout evaluation/demo

[Ichthyostega]

back to that point now, after finishing several other parts, which are involved in this task here.
Now we have a "test control" dialog, which sends some diagnostic/instrumentation commands to the core, which then responds by pushing a hard wired, fabricated Diff up into the UI. The application of this Diff works automatically, and so we can start to fill in the actual widgets, attached to the backbone of the timeline display

• the TimelineWidget is the top-level container
• it houses the TimelineController, which from a model viewpoint represents "the timeline"
• alongside, it also houses the TimelineLayout, which acts as service to coordinate the overall usage of screen space
• starting with the root track, the fork root, a TrackPresenter is attached as child to the TimelineController
• and so on... TrackPresenter has a child collection of ClipPresenter entries, plus a nested collection of TrackPresenters

All these entities are built and wired in response to the UI, and we have already a two part pane for the track head and track body display; which brings us to the immediate next step: we need to custom draw the track structure onto the canvas in the TrackBody widget.

[Ichthyostega]

Meanwhile the custom drawing is mostly in place; especially the problem is solved, how to integrate custom darwing with a CSS provided by the user. The immediate next blocking problem is how to attach a display or drawing context relative to some other, existing context. Which means, more specifically, how to do that not in a naive way (which would tangle both involved implementations); we do not want some drawing code to reach into the innards of some other drawing code; and we do not want a God-like master drawing manager to reach into the innards of all involved widgets "from above". To cope with that problem, I have invented the concept of a ViewHook in interplay with a ViewHookable entity.

However, as it stands, this framework still does not completely solve the problem when "hooking" crosses the boundraries of heterogeneous display systems. As is the case, when we go from a child widget structure to drawing on a common canvas...

[Ichthyostega]

This was a extremely time-consuming and challenging task, and required several years of coordination, panning and design work. After integrating the draft for zoom and metric handling, we are now able too...

• attach custom widgets in a systematic way, and in accordance to their nominal temporal extension
• implement editing gestures to work overarching and with several participants
• give the user full control over layout and styling through a CSS stylesheet
• build a »Display-evaluation-pass« to coordinate the layout.

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin