Opened at 2009-10-15T19:56:46Z
Last modified at 2023-09-14T23:47:17Z
#332 new todo
Properties of Placement
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | urgent | Milestone: | 0integration |
| Component: | lumieraSteam | Keywords: | FocusTopic session design spec data |
| Sub Tickets: | #100, #119, #328, #335, #540, #554, #656, #720 | Parent Tickets: | #20, #86, #143, #232, #393, #425, #556 |
Description (last modified by )
As Lumiera Architect,
I need a clear definition for the possible properties to be expressed as Placement,
to serve as foundation for the arrangement of Session content and for the resolving mechanism used in the Builder.
Requirement analysis, specification and design work
Placements were introduced as uniform binding to assemble the contents of the Session into a structured model. This way, the Placement of an object would be a way to define multiple relationships, by adding some constraining terms into the placement definition. Notably a Placement would allow to bring some media object at a specific position within the timeline. What is lacking though is a complete and workable concept to define what can be added to a Placement, and what would be the generic scheme to interpret and resolve those constraining terms and properties.
What is the role of Placement properties...?
- for the Builder
- for the navigation within the high-level-model
- for the handling of multichannel
- for the GUI presentation
How can several constraining terms work together? Are there several independent dimensions of specification? Is there a way how the general framework of resolving placement properties can be extended later to add specific and more elaborate constraint systems?
Moreover, Placements were established to form a system of nested scopes within the timeline, which is rendered as a »Fork« in the GUI. The intention behind this approach was to allow adding specifications and constraints to a complete scope, with the ability to specialise and shadow these definitions in a more local scope. This implies that Placements must be processed and resolved hierarchically — and the task is to transform this into an algorithm that can be implemented.
Change history (8)
comment:1 by , at 2009-10-31T23:13:38Z
| blockedby: | 100, 328 → 100, 328, 335 |
|---|---|
| blocking: | 20,232,143 → 20, 143, 232, 393 |
comment:2 by , at 2009-11-21T06:45:39Z
| blockedby: | 100, 328, 335 → 100, 119, 121, 328, 335, 422, 427 |
|---|---|
| blocking: | 20, 143, 232, 393 → 20, 143, 232, 393, 425 |
comment:3 by , at 2010-03-03T04:42:53Z
| blockedby: | 100, 119, 121, 328, 335, 422, 427 → 100, 119, 121, 328, 335, 422, 427, 511, 519, 554 |
|---|
comment:4 by , at 2010-03-03T04:56:24Z
| blocking: | 20, 143, 232, 393, 425 → 20, 143, 232, 393, 425, 556 |
|---|
comment:5 by , at 2010-11-19T18:02:35Z
| blockedby: | 100, 119, 121, 328, 335, 422, 427, 511, 519, 554 → 100, 119, 121, 328, 335, 422, 427, 511, 519, 554, 656, 720 |
|---|
comment:7 by , at 2023-09-13T01:44:26Z
| blockedby: | 100, 119, 121, 328, 335, 422, 427, 511, 519, 554, 656, 720 → 100, 119, 328, 335, 540, 554, 656, 720 |
|---|---|
| blocking: | 20, 143, 232, 393, 425, 556 → 20, 86, 143, 232, 393, 425, 556 |
| Description: | modified (diff) |
| Keywords: | FocusTopic spec added |
| Priority: | grave → urgent |
| Summary: | properties of Placement → Properties of Placement |
| Type: | planned → todo |
While compiling a list of »Focus Topics« to define the further direction of Lumiera development (after the crucial integration slices currently worked on are completed) it became evident that the precise meaning of »placement«, together and in connection to a definition of Event and Modification are the most important decision points to shape the next steps of the project.
comment:8 by , at 2025-12-25T00:00:00Z
| blockedby: | 100, 119, 328, 335, 540, 554, 656, 720 |
|---|---|
| blocking: | 20, 86, 143, 232, 393, 425, 556 |
| Parent Tickets: | → 20, 86, 143, 232, 393, 425, 556 |
| Sub Tickets: | → 100, 119, 328, 335, 540, 554, 656, 720 |
Migration MasterTickets ⟼ Subtickets-plugin

yes, this is indeed a pivotal task.
But we're not in the position to address it right now -- this needs to be considered in the context of the Builder