Opened at 2009-05-07T02:02:29Z
Last modified at 2025-04-15T12:32:18Z
#100 new todo
Placement and LocatingPin refactoring
| Reported by: | Ichthyostega | Owned by: | Ichthyostega |
|---|---|---|---|
| Priority: | lesser | Milestone: | 0integration |
| Component: | lumieraSteam | Keywords: | |
| Sub Tickets: | #115, #331, #438, #439 | Parent Tickets: | #109, #123, #332, #422, #426, #427, #511 |
Description (last modified by )
This is a long-standing issue with the first draft implementation from (11/07).
To implement the full placement concept, we need a real solving mechanism, and this doesn't fit well into the current class design.
My intended solution is to keep the class LocatingSolution, while at the same time changing this class into specially constrained LocatingPin. This would streamline the (currently missing) implementation of the solving process, because there could be always a catch-all default solution, and the actual solution would be derived from there by constraining. As a plus, the computed solution could be handed over immediately to the ExplicitPlacement as rendered LocatingPin.
Change history (14)
comment:1 by , at 2009-05-24T17:07:23Z
| blocking: | → 109 |
|---|
comment:2 by , at 2009-05-29T04:38:04Z
| blockedby: | → 115 |
|---|
comment:3 by , at 2009-10-15T19:40:26Z
| blockedby: | 115 → 115, 331 |
|---|
comment:4 by , at 2009-10-15T19:56:46Z
| blocking: | 109 → 109, 332 |
|---|
comment:5 by , at 2009-10-16T20:34:53Z
| blocking: | 109, 332 → 109, 123, 332 |
|---|
comment:6 by , at 2009-11-21T00:41:58Z
| blocking: | 109, 123, 332 → 109, 123, 332, 422 |
|---|
comment:7 by , at 2009-11-21T06:43:42Z
| blocking: | 109, 123, 332, 422 → 109, 123, 332, 422, 426 |
|---|
comment:8 by , at 2009-11-21T06:45:39Z
| blocking: | 109, 123, 332, 422, 426 → 109, 123, 332, 422, 426, 427 |
|---|
comment:9 by , at 2009-11-27T15:30:22Z
| blockedby: | 115, 331 → 115, 331, 438 |
|---|
comment:10 by , at 2009-11-27T16:33:40Z
| blockedby: | 115, 331, 438 → 115, 331, 438, 439 |
|---|
comment:11 by , at 2010-01-07T22:15:42Z
| blocking: | 109, 123, 332, 422, 426, 427 → 109, 123, 332, 422, 426, 427, 511 |
|---|
comment:12 by , at 2010-01-07T22:19:36Z
| Description: | modified (diff) |
|---|
looks more and more like this ticket denotes the next big step to target....
comment:13 by , at 2025-04-15T12:32:18Z
Haha ...many years later I consider this as a marker for building a suitable interface to base the resolution mechanism on. The first implementation was a placeholder, and was kept in the code base ever since. The use of Placement as a common »glue« in the model is still considered a tenet of the Lumiera architecture. And for that very reason, the centrepiece (which is the Builder) was delayed as long as possible, to avoid premature decisions without having clarified all requirements.
comment:14 by , at 2025-12-25T00:00:00Z
| blockedby: | 115, 331, 438, 439 |
|---|---|
| blocking: | 109, 123, 332, 422, 426, 427, 511 |
| Parent Tickets: | → 109, 123, 332, 422, 426, 427, 511 |
| Sub Tickets: | → 115, 331, 438, 439 |
Migration MasterTickets ⟼ Subtickets-plugin
(In #123) probably should also build upon the revamp of the Placement internals