Object snapping discussion

[mbfraga]

Hey guys!

Prelude (tl;dr)

I didn't know how to fit this into the guidelines about issues. I love the idea of what Akira is trying to be, but have reservations about contributing due to some topics I want to avoid (vala, etc). Please close this issue if this is found to be inappropriate or unhelpful.

I figured it may be interesting to contribute by way of making reference implementations for features that will be useful to the project. My idea is to eventually apply these references to make something more interesting--but yeah. You guys have a million things to think about, and maybe I could help out making these references to relieve some of that preliminary ideation and prototyping. And in general the they could serve as platforms for discussion.

I don't discard the possibility of doing actual Akira implementations, but I'm not there yet anyway.

Snapping

With that in mind, I was thinking about snapping. I went to bed a few nights ago playing around in my mind with some possible implementations. Without looking to see if there is something out there that may help (classic), last night I wrote a quick prototype for the first part of the problem.

Please excuse the code, I wrote in a few hours...also, I use Qt primitives (QRect) but changing it to generic ones would be trivial.

Screenshot of current state:

The main idea is:

1. On drag start, register all bounding boxes to a structure that will calculate the snapping
2. On drag move
   • Filter out irrelevant bounding boxes (too far to snap)
   • Generate vertical and horizontal snapping points for all bounding boxes (accumulate and keep uniques)
   • Use vertical and horizontal snapping points (3 in each direction) of the selected block to find closest match to the bounding box snapping points. (not in current prototype)
   • Use some heurestic (distance and possibly some score value) to choose the best coupling to snap to, in the vertical and horizontal directions (not in current prototype)
   • If the distance between the best snap coupling is within a certain amount, SNAP! (not in current prototype)

Considerations

1. In the code, the rectangles I deal with would be bounding boxes--so it is generic in that sense.

2. I've been trying to think if I will need to keep information about the bounding boxes I snap to.

   • My initial thought is not really, but it may be good to add some metadata to snapping points so that when the snap lines are drawn, more information can be drawn on top.
   • My main reason to avoid connectivity is code isolation and speed--but I think both can still be achieved regardless, with more work

3. Not sure how hard the snapping heuristics are going to be. It should take me one more small session of work to get them into the current prototype, and that should give me an idea.

4. Originally I was thinking of several ways of partitioning space to make this faster...but it's so fast, even at ridiculous number of bounding boxes, that I'm not sure it's worth the trouble--unless a lot of extra context is added.

5. Transformations and multi-selections should be really easy to add to this. It just requires smarter generation of snapping points, otherwise the code is fairly agnostic to it.

Code

Here is a link to the implementation written in c++17 and qt.
https://gitlab.com/mbfraga/grid_snapping

Epilogue

If you got here, thanks for reading! Let me hear any thoughts or ideas. I'm really having fun playing around with this--even if it turns out to be pointless (someone already wrote it) or completely suboptimal.

Now back to my lunch break!

[Alecaddd]

Thank you so much for this!
This is immensely helpful and not pointless at all. Being at an early stage of development allows us to experiment and prototype freely with ideas on how to best implement features, and proximity snapping is one of the most important one, so the work you're doing is vital and absolutely appreciated.

Don't worry too much about the coding language, converting C++/Qt to Vala is not too hard, so having a working reference is incredibly helpful.

I think your approach so far is correct, and it emulates what other professional apps do (Figma, Sketch, Adobe XD).
You can also check PenPot, which was recently released, for how they visually handle snapping guides, which is very similar to Figma.

Some info to your points:

On drag start, register all bounding boxes to a structure that will calculate the snapping.

We don't need to do that in Akira because the GooCanvasItem automatically keeps track of its bounding boxes and updates it at every movement: https://valadoc.org/goocanvas-2.0/Goo.CanvasBounds.html

Transformations and multi-selections should be really easy to add to this. It just requires smarter generation of snapping points, otherwise the code is fairly agnostic to it.

Also for these cases, GooCanvas is super helpful.
A transformed item always retains its natural bounding boxes. If you compile and run Akira from master, you can select an item, rotate it, and then hold Alt to make its bounding box appear. That's a simple initial implementation I did to visualize the bounding box of every item.

Multi-selection is also not a problem because we already have a SelectBoundManager item which generates a simple Rectangle encapsulating all the items. So the snapping, in case multiple items are selected, will be in relations to the Selection Rectangle bounds, and not the Items' bounds.

This is very exciting!

[mbfraga]

Yep, that was my thought with regards to using C++ (Qt is mostly to visualize, doesn't serve an actual purpose to the snapping code) and porting to vala.

The idea of registering the bounding boxes is about passing them to the structure that will calculate the snapping, not about computing them. So that logic can be kept modular and isolated. I think it's better than passing pointers, and pretty cheap to do so. But it can be adjusted either way. It's a detail.

The only thing with transformation is that on figma, it seems that objects will use their transformed snapping points, and combine all the selected objects snapping points to find the best match. When I work more on this, I can maybe make this more clear. But again, both are doable.

[mbfraga]

Ok, finished implementing snapping in my prototype. I'm actually fairly happy with it. It's made out of for loops, which is obvious room for improvement--but still so performant that I don't think it matters too much.

At 100,000 bounding boxes with 5 snapping points, it takes 1-3 ms. For a 2-night session build it's pretty ok.

Also, did 4px snapping sensitivity, and I feel really good about it. I do think it's possible that some scoring based on mouse proximity could be interesting, and other layers of snapping (spacing) could be added...but I don't feel like it really makes that big of a difference.

I'll try to see if I can get Akira building properly to see if I can add these features.

[Alecaddd]

I think the 4px snapping sensitive is good for the default 100% canvas zoom.
I think then we would need to account for different zoom state, as maybe a user might need a narrower snapping sensitive when zoomed in, or a wider sensitive when zoomed out.
Just a thought tho.

[albfan]

@mbfraga That looks great. If you open a PR we can guide you through details of zoom events and disabling movements based on proximity