Hi, I hope you don't mind if I increase the traffic on inkscape-devel even more ;-) At some point an idea popped up to only snap to nodes at discontinuities in paths, and not to nodes at smooth transitions from one Bézier segment to another. This is more intuitive (less "Hey, what it is Inkscape snapping to now?") and might increase performance. Problem is that in the object-snapper I only have access to SPCurve, which is a wrapper for "old-style" NArtBpath. It's easy to find out whether a point is inbetween two Bézier segments, but how do I find out if a transition is smooth? I guess that should be done by comparing the control points, or is there an easier way? With the transition to lib2geom, will the NArtBpath be deprecated in favor of the Path class? (that would make this rather exercise useless in the long run). Any pointers would be appreciated here, Diederik ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Something even more annoying: node doesn't snap to path intersection.

There's no visualization of snapping (pervert request -- I know it wouldn't be easy to implement) :)

And don't know about that how hard would be to implement this one... There was some mentioning of current svn version slowness when dragging shapes over the canvas (with complex drawing) because it wants to snap to everything. Would it be even possible to determine how fast user wants to move something?

On Wednesday 22 August 2007 14:33:22 Johan Engelen wrote: > In notepath.cpp from line 4051 onwards, the node type is determined. >

> I think 2geom will replace all path representations in the end, but I don't know.

> Right now, guide-grid intersections do not snap. Another thing is angled snap lines. Angled guides are often requested, and the axonometric grid can also use those snaplines. >

On 8/22/07, Diederik en Rezi <mail@...1689...> wrote: > >> In notepath.cpp from line 4051 onwards, the node type is determined. > >> > As far as I can tell this class is not being used in the object-snapper, > so I guess we'll have to do without this. It's very easy just to borrow the math from there. Basically a node is smooth when its handles and itself all lie on one line.

Someone here suggested a great idea: in seltrans, snap only if the current move/scale etc. is "small enough" and skip snapping otherwise. The "small enough" can be defined as a fraction of the current snapping distance. This way fast moves will be more responsive and only small slow movements will snap.

GDK input events come with timestamps attached, so this should be relatively easy to do (aside from the necessary care to sample only event times that occur far enough apart to avoid underflow/overflow).

> As far as I can tell this class is not being used in the object-snapper, > so I guess we'll have to do without this. It's very easy just to borrow the math from there. Basically a node is smooth when its handles and itself all lie on one line.

-----Original Message----- From: Diederik van Lierop [mailto:mail@...1689...] Sent: zaterdag 25 oktober 2008 15:22 To: inkscape-devel Subject: [Inkscape-devel] Snapping should only occur at the end of a movement Hi, Way back in time, someone suggested that snapping should only occur at the end of a movement or only at low mouse-speeds, as this would make Inkscape more responsive. I finally got to implementing this and apparently it works nicely, but I think it could use some testing on other systems, for example by users with a tablet. Let me first shortly explain what I implemented: Inkscape now has a hard-coded speed limit above which no snapping will occur. The speed is calculated after each GDK_MOTION_NOTIFY event (in sp_canvas_motion). When trying to stop my mouse movements as fast as possible I measured speeds up to 1 pixel per millisecond at the last event in line. The speed limit should be above this value, otherwise snapping might not occur when breaking hard. When moving slowly though, almost all motion events will cause snapping when we use such a high speed limit, which wouldn't help in making Inkscape more responsive. I solved this by using both a watchdog timer and a relatively low speed-limit of 0.1 px/msec. The watchdog ensures that Inkscape will always snap at the end of a movement, even when we break abruptly. It will bark when no event comes in below the speed limit, within 100 msec after the last event. In such a case the last event will be repeated with snapping enabled. There might be some issues though: 1) Is it good practice to resend an event? Or might this have side effects of which I'm not aware? 2) Someone mentioned in another thread that tablets will show jitter or noise. If the noise-level of the measured speed is above our speed limit, then Inkscape will not snap predictably. Could someone with a tablet (or a more expensive mouse) please uncomment line 1615 in sp-canvas.cpp and report to me what speed is measured? 3) When moving at speeds around the speed limit, Inkscape might snap for one motion event but not for the next, which will make the object that's being dragged jump from the snapped position to the mouse position and back again. That could be annoying, but I don't see an easy way around this. Any comment is appreciated! Diederik -------------------------------------------------------------- ----------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1. In Corel Draw each type of snap is either on or off for the whole document (like inkscape), but it is possible to override this by holding down a keypress as the point is selected. So 'N' removes all snapping except Node snapping (E for endpoing, I for intersection etc.) and the cursor jumps to the _nearest_ node snap with a much larger snap radius. If the N is released it goes back to normal with all active snaps working and a smaller snap radius. This allows a rapid way to force the snap for a single point only.

2. Alternatively, how about using a key like 'TAB' to cycle between all the possible snaps within some radius of the cursor. The shape of the snap indicator, together with the tooltip text below could show which is being applied as the cursor jumps to the snap.

Hope this may have helped! Kindest Regards, Alex On Sun, 26 Oct 2008, J.B.C.Engelen@...1578... wrote: > Hi Diederik, > > Seems to work great!! Very nice work. > > A long standing wish of me...: > The snapping points should depend a bit on where the user clicks. If I > want some point to snap to some gridpoint, I tend to click close to that > point and drag it close to where I want it to snap. Does that make > sense? > I do not have a clear idea how to go about this; perhaps some "rating" > of possible snaps with better rating for snaps occuring short distances > away from the mouse cursor... > > Cheers, > Johan

How about holding down CTRL and then using TAB to cycle. As soon as CTRL is pressed the current cursor position would be 'locked' and it would cycle each time tab is pressed irregardless of how the mouse moves until CTRL is next released. This still only requires a single hand and so would still be reasonably elegant.

In addition to holding down keys like N, E (as mentioned before) to provide a temporary over-ride to the global snap, I think an indicator of which snaps are globally active in the status bar may be useful.

I've prepared a PDF mock up (using corel screenshots) of how this may work. I'm not sure how whether the mailing list handles attachments, so I will e-mail it directly to you. I wondered if it might be possible to place it online as a suggestion?

> gives indeed excellent control for translations, but what about scaling > and stretching? You're not using the handles for this, so how is > Inkscape to know which transformation to use? BTW, perpendicular and > tangent snapping will be difficult with our current mechanisms, but the > other modes are either already there or easily implemented. I'm not sure I understand the distinction; if the cursor is above the snap point it will translate the object. If it is above a handle (which is why these have to be outside the perimeter of the object) it will either scale or stretch.

As Krzysztof was describing, in Corel only the point directly below the cursor is active for snapping, and this applies equally to all transformations (including scaling and stretching). In other words only the node or handle you are moving is considered for snapping to other objects; no other points on that object do. If you want a different handle to snap you simply stretch it from that handle.

-----Original Message----- From: A.J. Carter [mailto:ajc200@...1930...] Sent: 2008 okt 27 14:35 To: Diederik van Lierop Cc: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] Snapping should only occur at the end of a movement Dear Diederik, In the case you mentioned of rotating a rectangle: you can rotate the shape by 15 degrees, and then as a seperate action translate it _from_ the new corner to a given gridpoint. You can't rotate the shape such that the rotated corner snaps to a gridpoint in a single motion though no. Only the point directly below the cursor snaps as it moves, irregardless of the type of transform. All snapping points rotate with the object and are still accessible in the new oreintation no matter what transformation you perform on it, so I would say it's not really just boundary box snapping only no. The bounding box is actually a subtlety in Corel Designer since it doesn't have to be the smallest rectangle which contains each object as in most programs. You can actually tell it to use different shapes for the 'object coordinates' - e.g. the bounding shape can actually be set to be the smallest ellipse (or polygon, square etc.) which contains a given object or group, and you then position this ellipse relative to the page, and set the width or height of the ellipse to resize the object. It's not something I've used myself but corel have a free designer X4 trial if you wanted a play! I was thinking last night - if you wanted a fully general way to use snapping with _any_ transformation I guess it depends on what you are doing. Rotations require a 'centre', scalings require a 'point' (not necessarily on the bounding box of the shape !) and stretches require a 'line' (most non CAD systems assume this to be the opposite side of the selection, but it can be any distance away as long as you drag perpendicular to it). One way to do this would be to have a point or line associated with each shape (which can be moved using regular snapping like any other shape) to define the origin of the transformation. The problem is then that a different tool would need to be selected for each type of transform (in corel it automatically switches to rotation mode if an object is clicked twice, then a circle appears in the centre defining the point of rotation and this can be dragged as with any other point, before using the handle to do the actual rotating). Hope this has made sense !! Kindest Regards, Alex > Wait a minute. Maybe I'm misunderstanding you here, but what about a > rectangle that has been rotated let's say 15 degrees. Is it possible at > all to snap its rotated corners in Coreldraw to a grid for example? > These corners are not at a handle. So basically it's just boundingbox > snapping that Coreldraw does then, plus some special points like > intersections and quadrant points and such.

This brings me to some other point though: Hasn't any one ever thought of using the tab key to cycle through the items which are to be selected? Now we can use left-click and alt-left-click to select an item on the canvas, but this is still tricky when there are many overlapping items. Modern 3D CAD programs show a list of all available items near the mouse pointer when left-clicking, through which the user can cycle with the tab key, including highlighting on canvas! Now wouldn't that be cool too?

That's indeed an elegant way to create some more flexibility. If however this is only to select what we snap _to_, then we could still use something that gives us more control of what we snap _from_. For the latter we could still use Johan's proposal.

Vladimir Savic wrote: > Something even more annoying: node doesn't snap to path intersection. Well, that would be possible, but unfortunately far from easy to implement though.

> There's no visualization of snapping (pervert request -- I know it > wouldn't be easy to implement) :) Bulia and I had a discussion about this some time ago. We could have a an icon in the statusbar that lights up when you're snapped and grays out when not. From what I've heard this is the way Xara does it. We could also have a dot blinking for a second, on the canvas, at the position where the snapping occurred... That would really be cool, but maybe this is also a bit too much eye-candy. It certainly wouldn't improve the responsiveness I guess.

> And don't know about that how hard would be to implement this one... > There was some mentioning of current svn version slowness when dragging > shapes over the canvas (with complex drawing) because it wants to snap to > everything. Would it be even possible to determine how fast user wants to > move something? That would be a possible work around, but I'd rather fight the cause itself instead of just the symptoms. I think there's still room for improvement in the object-snapper. On top of that, the new lib2geom is expected to improve the snapping responsiveness significantly. Don't know when that is due though...

Diederik

Vladimir Savic wrote: > There's no visualization of snapping (pervert request -- I know it > wouldn't be > easy to implement) :) > Bulia and I had a discussion about this some time ago. We could have a an icon in the statusbar that lights up when you're snapped and grays out when not. From what I've heard this is the way Xara does it. We could also have a dot blinking for a second, on the canvas, at the position where the snapping occurred...

Good point, but I still think an on canvas "post"-snap indicator could be useful. I seem to run in to the non-obvious corner cases pretty regularly. Is my node snapping to the path or a node on the path? Is the upper left corner of the bounding box snapping to something on the edge of my drawing or is the invisible center of rotation snapping to something else? etc. Sometimes I have no clue what is being snapped to.

I suspect bugs in in these cases but I haven't been sure how to debug them, if anyone has any hints I would be glad to followup.