J.B.C.Engelen@...1578... wrote:
Perhaps you can point me to the file(s) where the snapping point is finally determined? I've forgotten the precise details.
Unfortunately it's not at a single location in our snapper code. For example, have a look at seltrans.cpp, around line 920:
// Snap along a suitable constraint vector from the origin. std::pair<NR::scale, bool> bb = m.constrainedSnapScale(Snapper::SNAPPOINT_BBOX, _bbox_points, it, s,
_origin_for_bboxpoints);
std::pair<NR::scale, bool> sn = m.constrainedSnapScale(Snapper::SNAPPOINT_NODE, _snap_points, it, s,
_origin_for_specpoints);
if (bb.second || sn.second) { // If we snapped to something /* Choose the smaller difference in scale. Since s[X] == s[Y] we can ** just compare difference in s[X]. */ double const bd = bb.second ? fabs(bb.first[NR::X] - s[NR::X]) : NR_HUGE; double const sd = sn.second ? fabs(sn.first[NR::X] - s[NR::X]) : NR_HUGE; s = (bd < sd) ? bb.first : sn.first; }
Here we call the snapmanager twice, and only after that it is decided which of the two results leads to the closest snap. So it's in seltrans were the flashing should be invoked. On two places in scaleRequest(), two in stretchRequest(), one in skewRequest(), etc. The code calculating which snap is the closest is different for each case, which makes merging of this code not very straightforward.
Besides, we might not always want something to flash, e.g. when dragging a single node in the node tool. It would be quite obvious in such a case what's snapping. When scaling a complex object though the flashing is really valuable.
Regards,
Diederik