Hey, another person in the space industry using Tinderbox! That’s out of this world.
Admitting that I haven’t read every post above in detail, I’ll quickly add my 2 cents.
Warning! High School math ahead!
When modeling two sets of objects which share an intersecting subset I’ve also reached for adornments with the
$Query attribute set and been disappointed that the adornments don’t figure out that a note matching both should be in the overlap of the two adornments. I understand why they don’t yet — this isn’t a trivial problem to solve — but composing adornments did seem like a natural solution at the time.
If I were to implement something like this my approach would be:
- Find all of the adornments whose
$Queryset contains the note in question.
- Extract the
y_bottom_lcoordinates for each adornment’s bounding box. (I’m going to assume that notes have a single point coordinate which determines their location, but the below should generalize to rectangular shapes pretty easily.)
- Construct a system of linear constraints (pseudocode):
for x_tr, y_tr, x_bl, y_bl in adornment_bbs: constrain(x_note <= x_tr) constrain(x_note <= y_tr) constrain(x_bl <= x_note) constrain(y_bl <= x_note)
- Solve the system of linear constraints, yielding a bound on the values of x and y which the note can take. Assign the note a set of coordinates freely within the box. If there are other notes in the intersection and you want to avoid covering them entirely, add additional constraints to the system above.
This is a very fast problem to solve using Gaussian elimination. If you want, you can also go the more complex route and add a linear objective function which determines the “best” point to put the note at and solve it with the Simplex algorithm, although I would imagine the constraint systems that Tinderbox would be solving are small and could also be easily optimized with a simple search over the solutions to the linear equations.
Whew! That wasn’t too hard. Looking forward to a constraint-based Tinderbox layout engine, @eastgate!