Thanks Diederik,
Although it seems the snappers return the necessary displacement, and not the point to which they snapped. I propose to make the snappers return something like a SnapInfo struct:
struct SnapInfo { bool snapped; //did we snap? Geom::Point snaplocation; // to which point did we snap SnapType type; // some info about the sort of snap (tangential, node-on-node, whatever, this is future work of course) ... }
This assumes one always snaps to a *point* which is not always the case maybe. I'll wait a bit for you to work on it, I think you know more about it. I really just gave it a quick glance.
I do have a bugreport though: guides don't snap! the guideSnap function never gets past the check if it should snap at all, so it always returns Inkscape::SnappedPoint(p, NR_HUGE, 0, false). Can you look into this Diederik? Once guide snapping works, you'll see the snapindicator on-canvas :)
Cheers, Johan
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Diederik van Lierop Sent: zondag 2 maart 2008 17:20 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: temporary on-canvas indicators
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. Sinces[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
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel