Opened at 2022-10-17T01:02:31Z
#1251 new todo
specify Clip media type for the UI
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0integration |
| Component: | lumieraGui | Keywords: | design data interfaces diff gui session format |
| Sub Tickets: | #1150, #1219, #1237 | Parent Tickets: | #1226, #1227 |
Description
As a Lumiera developer,
I want a specification of clip media type as part of the population diff,
so that I can pick a suitable content renderer strategy on widget creation
Background
The display of Clips in the Timeline-UI is based on ElementBoxWidget, which in fact is more like a general framework for a standardised yet highly configurable UI element. More specifically, there is a hook to install a Content Renderer — and the design in its current (2022) shape calls for configuring a suitable strategy for content representation right at construction time of the widget; at least a rough classification of the media type should be given, so the widget can pick the appropriate CSS styles right away. However, this design requirement is somewhat in contradiction to the general usage pattern for the diff content population — which rather works by installing a generic node first and then populating that with further properties in a secondary mutation step. And following the latter scheme here will lead to a lot of re-configuration and even re-installing of UI widgets when receiving and processing those diff messages.
Design Task
So the task is to find the right balance between a compromise of the genericity of the diff format vs. performance savings for the very relevant case when the Timeline UI is populated with a huge amount of content clips. Obviously, a sub-task is even to define the scope and format of actual type information shared between session and GUI for this purpose.
Acceptance Criteria
- Clip information can be sent to the UI such that the
ClipPresenteris able to install a Content Renderer Strategy - a standard scheme for the population diff has been established, fostering efficient object creation in the UI
- a defensive fall-back has been provided for the case if type information is omitted or provided or changed later by further diff messages
Change history (1)
comment:1 by , at 2025-12-25T00:00:00Z
| blockedby: | 1150, 1219, 1237 |
|---|---|
| blocking: | 1227, 1226 |
| Parent Tickets: | → 1226, 1227 |
| Sub Tickets: | → 1150, 1219, 1237 |
