Unfortunately, we need to consider each axis separately. So for each axis, we're comparing the relationship between four numbers: the min and max of a, and the min and max of b.
Some of the moves are obvious: when layers are aligned on an axis and the other axis is disjoint, then they can have a straight line. But things get trickier with overlaps and contains.
Each rectangle has four connection points at the midpoint of each edge, plus eight points padded out around it. My hunch is that if I got the angle between the two rectangles, then I could compare these points to get the right connection shape.
I'm also doubling my work here by including right-to-left and bottom-to-top arrows. I can skip these by just running everything in two directions, once I've decided which rectangle is topmost/leftmost.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Today I found a ten year old micro-app by @evanwallace with a great arrow-drawing algorithm. I worked through the code and adapted it for perfect-arrows. Really beautiful arrows! Playground here: 2vu07.csb.app
And here's the original source: madebyevan.com/fsm/ . In this app, you can adjust the arc of an arrow by clicking and dragging. I like that! But the goal with perfect is to calculate that automatically, too. Points can also be padded out here.
These arrows are using arc segments rather than quadratic curves, which is how I've been doing things so far. I really this might just be the better way. Intersection points are much easier with circles, though I imagine the algorithm will hold up with other shapes too.
Pinch zooming to the pointer on an infinite canvas. We're having to offset the camera as we change the zoom, and that offset amount was... not intuitive.
With this kind of thing, it's useful to think in terms of separate "screen space" and "document space" coordinates. These are usually very different: a pointer at x=100 y=100 on the screen could be anywhere in the document, depending on how the document is scrolled or zoomed.
The goal here is to *preserve* that document coordinate as the user zooms in or out. So as we zoom, we need to scoot the document over so that the user's pointer is still pointing at the same place in the document.
It's Friday! Let's get wild 🙆♂️ and learn about finding intersections between line segments and boxes with rounded corners.
This is a lot like finding the points where a line segment intersects a rectangle—it's just that the rectangle has rounded corners, or a "corner radius".
Let's start with a regular rectangle. To find its intersections, we test each of its sides—or "segments"—separately. There are lots of ways to do that. Here's one: gist.github.com/steveruizok/9f…
New approach on my arrows problem. More math, less logic. These are the kinds of arrows I wanted from the start!
So here's how it works. Start by drawing an edge between the two centers. We need this line to have a minimum width—this minimum is: double the length of the shortest side among the two rectangles. We also want a second edge, rotated 90 degrees.
If the distance between centers is below the minimum, add the amount of that overlap to the cross edge. Basically, we want the cross edge to grow as the two rectangles get too close. Here's a better look at it.