| Age | Commit message (Collapse) | Author | 
|---|
|  | Just committing as we might mess with the format a bit
and will treat these new entries as pre-existing. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | This will definitely not have any consequences. | 
|  |  | 
|  | This code is meant to replace a rectangle that is the result of
an intersection with a spanning-infinitely-left region, i.e.
the opportunity area for placing a tooltip to the left of its
hoverable, with a narrow channel so that its `x` is the
appropriate left alignment for the tooltip.
That behavior is working correctly (hopefully), but the fallback
is that it *shouldn't* be modifying a rectangle which intersected
with a spanning-infinitely-right region. We were mistakenly
dropping anything to do with the intersection and returning
the region rectangle instead, which broke vertical alignment
any time a tooltip is aligned to the right of the hoverable. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | Generators don't necessarily make the moset sense for splitting
an operation into just two steps, instead of one that might
recurse in a more complex fashion. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | Includes baseline rectangle computation and actually applying an
arbitrary position to a tooltip. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | Instead of the flipwise direction. |