Snapping of rotation center

Bug #607107 reported by LucaDC on 2010-07-19
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Diederik van Lierop

Bug Description

I realized that snapping of rotation center seems broken. I could not say since when.
I can't snap and sometimes it snaps while dragging but when I release the mouse it moves to a different point.
Windows XP SP3, last build before extension dbus has been added.

You mean while dragging the rotation center itself, to move the rotation center to a new position relative to the object? So if I understand you correctly then you're not moving the object using the selector tool.

I will look into this.

Changed in inkscape:
assignee: nobody → Diederik van Lierop (mail-diedenrezi)
LucaDC (dicappello) wrote :

Yes, it's when you want to rotate the object around a different center so you grab the '+' to move it.
Thanks.

su_v (suv-lp) on 2010-07-19
tags: added: snapping

It looks like the snapping is OK, but that the position of the rotation center is not correctly updated while dragging. After releasing it though it ends up in the place where snapping occured AFAICT.

su_v (suv-lp) wrote :

Sometimes I see the rotation center snapping to the bounding box corner instead of a targeted close grid or guides intersection I intended to snap to (and as was confirmed by the snapping indicator). This is puzzling because it happens without bounding box snapping active (i.e. default snapping setting: snap nodes to grid and guides). Zooming in very close helps, but sometimes I miss to check and the result of the rotation is slightly displaced because rotation happens around the bbox corner instead of the targeted grid intersection. IIRC I also saw it happen when snapping to nodes (but this I haven't reproduced with current builds).

AFAICT this is not related to the new rotational snapping code.

> After releasing it though it ends up in the place where
> snapping occured AFAICT.

Not in my experience - the rotation center is not where the snap indicator told it would be (grid or guides intersection).

See attached SVG as an example (using 0.48+devel r9630) - but apparently I fail to consistently reproduce it (it tends to happen when the precise snapping to grid matters but not when trying to demonstrate ;-) ).

On 07/20/2010 05:19 PM, ~suv wrote:
> Sometimes I see the rotation center snapping to the bounding box corner
> instead of a targeted close grid or guides intersection I intended to
> snap to (and as was confirmed by the snapping indicator). This is
> puzzling because it happens without bounding box snapping active (i.e.
> default snapping setting: snap nodes to grid and guides)

I just found some very old code in the selector tool that snapped the
rotation center to the bounding box, with a fixed snapping range of 5
screen pixels and discarding all snapping preferences. That code has now
been removed as of rev. #9634

On top of that I improved the logic behind the snap buttons a bit, i.e.
what snaps to what for each of the buttons. You might notice that too.

The rotation center is still shown in its unsnapped position while
dragging though.

su_v (suv-lp) wrote :

> On top of that I improved the logic behind the snap buttons a bit, i.e.
> what snaps to what for each of the buttons. You might notice that too.

Something is not working as expected now: I have trouble snapping guides to node targets (paths, cusp and smooth nodes etc) - it seems to randomly work for some paths but then again will fail completely. Works fine with 0.47 and 0.48.0 r9619.

su_v (suv-lp) wrote :

I also had a crash when dragging a new guide onto the canvas, though I am not exactly sure what triggered the crash: just before creating the new guide I had unioned a path with itself (to get nodes at intersections of a self-intersecting 'doodle').

Console message:
**
ERROR:sp-item.cpp:977:void sp_item_snappoints(const SPItem*, std::vector<Inkscape::SnapCandidatePoint, std::allocator<Inkscape::SnapCandidatePoint> >&, const Inkscape::SnapPreferences*): assertion failed: (SP_IS_ITEM(item))

Inkscape shouldn't crash any longer in your situation (as of rev. #9638). Instead it will print a warning on the command line and simply refuse snapping. I still am clueless about what's going on here; can you reproduce this?

Guides now snap correctly again to nodes and paths, please try rev. #9638

But what about the initial bug, i.e. snapping the rotation center?

su_v (suv-lp) wrote :

The initial bug as reported by LucaDC I have never seen (besides the non-snapping in the node tool when using transformation handles), but the one about snapping the bounding box corner instead of the intended snap target seems fixed afaict.

I did reproduce it a second time (under similar circumstances but the trigger is still vague to me) with identical crash report/backtrace and console message - I'll try again if I can figure out 'steps to reproduce' before updating to r9638.

su_v (suv-lp) wrote :

clarification:
> I did reproduce it a second time (…)

This relates of course to the crash described in comment #7, not to the other issue about unexpected snapping of the rotation center to the bbox corner.

su_v (suv-lp) wrote :

Steps to reproduce crash (tested with r9636, default preferences, on OS X 10.5.8):

1) open attached drawing
2) select path -> break apart
3) select the small path in the middle and snap its bounding box to one of the other bboxes
4) select all (using the button on select toolbar)
5) union
6) drag vertical guide onto the canvas -> crash

su_v (suv-lp) wrote :

Crash not reproduced with a clean rebuild (r9640),
no snapping-related console messages when following the steps listed in comment #11.

su_v (suv-lp) wrote :

> Guides now snap correctly again to nodes and paths, please try rev. #9638

confirmed with r9640 - thx :)

LucaDC (dicappello) wrote :

In rev9640 I have no snap at all for rotation center: I pushed all snapping buttons with no result.
At least now there are no "buggy" behavior like different snapping trigger distances or center moving to strange positions when releasing. Just no snap.

su_v (suv-lp) wrote :

> In rev9640 I have no snap at all for rotation center

not confirmed with r9640 on OS X 10.5.8 (rotation center snaps to all snap targets as set on the snapping toolbar, tested with default preferences as well as my usual ones) - could this possibly be a win32-only issue?

LucaDC (dicappello) wrote :

Ok, I checked better: snapping occours but the visualization is not updated (i.e. the rotation center is always stuck to the pointer). But sometimes it doesn't snap to the correct place and while moving it I always see the tooltip: "Handle to object rotation center".
It seeems it's snapping to itself...

su_v (suv-lp) wrote :

> It seeems it's snapping to itself...
Now I remember that I had noticed this too: using the rotation center as snap target for snapping the rotation center makes snapping seem unpredictable - as a consequence I only activate it if I really need to use it as target when dragging objects but have it turned off normally. Sorry, I completely forgot about that.

Ah, that makes sense to me. I'll get this self-snapping fixed.

su_v (suv-lp) on 2010-07-22
Changed in inkscape:
status: New → Confirmed

The self-snapping has been fixed, and the rotation center is now drawn at its snapped position. See rev. # 9641

I'm not able to reproduce ~suv's crash though...

su_v (suv-lp) wrote :

> I'm not able to reproduce ~suv's crash though...

I haven't been able to either, after updating from r9636 to r9640. The only other change I made at the time was changing the compiler from GCC 4.0.1 to GCC 4.2.1 and completely rebuild r9640 ('make clean; make').

> The self-snapping has been fixed

Looks fine. What I failed to snap to when dragging the rotation center was the rotation center of another object which had been moved outside the object's bbox (?). OTOH dragging one of the objects allows to snap the two rotation centers, which are both outside the bbox of its object.
Snap settings: snap nodes and handles to rotation center, grid and guides; grid turned off.

> The rotation center is now drawn at its snapped position.

Confirmed with r9641.

On 07/24/2010 05:07 PM, ~suv wrote:
> > The self-snapping has been fixed
>
> Looks fine. What I failed to snap to when dragging the rotation center was the rotation center of another object which had been moved outside the object's bbox (?). OTOH dragging one of the objects allows to snap the two rotation centers, which are both outside the bbox of its object.
> Snap settings: snap nodes and handles to rotation center, grid and guides; grid turned off.
>

Yes, that's a good point and an even better observation! When Inkscape
looks for snap targets, it uses the bounding box of each of the items in
a document, plus some margin (equal to the snap distance). If the snap
source is not within range of the bbox+margin, then that item will be
ignored. The bounding box does not include the rotation center however.
I could fix that quite easily for the snapper, but am not sure about
possible side effects yet.

It's strange though that snapping worked correctly when dragging the
objects instead of the center.

su_v (suv-lp) wrote :

> It's strange though that snapping worked correctly
> when dragging the objects instead of the center.

You are correct - I was sloppy in verifying the snapped points/targets. AFAICT when trying to reproduce it, I misread the snapping to be rotation center to rotation center when it actually snapped a corner node of a dragged rectangle to the rotation center (outside the bbox) of another rectangle.
Snap settings: Snap nodes and handles to rotation center, grid, guides; grid turned off.
Snap preferences: unchanged default

Fixed as of rev. #9648. Now we snap to rotation centers even if they are outside the bounding box.

su_v (suv-lp) wrote :

> Now we snap to rotation centers even if they
> are outside the bounding box.
Fix confirmed with r9649.

A possibly related question: could you test the following steps with the attached drawing (or just tell me to stop for now ;-) )?
1) select the rectangle twice to get the rotation handles
2) grab the upper right handle and rotate/drag ~70° CW into the adjacent quadrant of the guides (without triggering a snapping of the object corners to the guide(s))
3) even before releasing the mouse (intention is to not snap to any of the guides for the rotation) the dragged rectangle snaps back to the original location

This seems triggered by keeping the rotation center as snap target and no longer occurs if it is turned off as snap target.

On 07/26/2010 12:22 AM, ~suv wrote:
> > Now we snap to rotation centers even if they
> > are outside the bounding box.
> Fix confirmed with r9649.
>
> A possibly related question: could you test the following steps with the attached drawing (or just tell me to stop for now ;-) )?
> 1) select the rectangle twice to get the rotation handles
> 2) grab the upper right handle and rotate/drag ~70° CW into the adjacent quadrant of the guides (without triggering a snapping of the object corners to the guide(s))
> 3) even before releasing the mouse (intention is to not snap to any of the guides for the rotation) the dragged rectangle snaps back to the original location
>

Hi ~suv,

Just keep those reports coming, don't worry!

I cannot reproduce this though. Does it show a snap indicator when it
snaps back?

Diederik

su_v (suv-lp) wrote :

> Does it show a snap indicator when it snaps back?

Object rotation center to guide

On 07/26/2010 09:33 AM, ~suv wrote:
> > Does it show a snap indicator when it snaps back?
>
> Object rotation center to guide
>

12 hrs later I can suddenly reproduce this behavior, for some reason. So
this means I can get this fixed :-)

Please test rev. #9652

su_v (suv-lp) wrote :

> Please test rev. #9652

Fix confirmed :)

LucaDC (dicappello) wrote :

Everything seems working fine for me too. Thanks.
Now whe only have to find a way to temporarily disable snapping while rotating :)

Changed in inkscape:
status: Confirmed → Fix Released
status: Fix Released → Fix Committed
su_v (suv-lp) on 2010-10-02
Changed in inkscape:
milestone: none → 0.49
LucaDC (dicappello) wrote :

In rev.9813 the rotation center is snapping to itself again when snapping from and to an item's rotation center is enabled.

Hi Luca,

Can you send me a sample file an describe in detail how to reproduce this? I've been trying for about 10 minutes myself but must be doing something differently.

LucaDC (dicappello) wrote :

Diederik,
you are right! I missed something that I realized after your question: it happens when rotating two or more selected objects.
My steps:
 - new fresh drawing;
 - snapping options activated: global, global nodes or handles, from and to rotation center;
 - draw two rectangles;
 - select both and activate rotation with a second click;
 - move the rotation center: here I get self-snapping.

Confirmed, I will fix this

Should have been fixed as of rev. #9817

jazzynico (jazzynico) wrote :

In the Keys and mouse reference, I read (Selector tool, rotation center):
"Dragging the center snaps it to the centerlines and bounding box edges of the selection."

Revision 9890 doesn't act like that unless you activate the appropriate snapping options in the snapping bar (except for the centerlines snapping which doesn't work anymore). Could you please confirm this is the new correct behavior?
Thanks!

Yes, that's the correct new behavior. The center now snaps just like everything else. A similar change has been made for the gradient handles.

jazzynico (jazzynico) wrote :

Ok, I'll change the reference accordingly.

It was possible to temporarily disable snapping with Shift. Could you please reactivate this shortcut so that it is consistent with the other snapping objects (Shift already works as expected with shapes, paths and gradient handles)?
Thanks!

Shortcut reactivated as of rev. #9903!

jazzynico (jazzynico) wrote :

> Shortcut reactivated as of rev. #9903!

Thanks you!

Changed in inkscape:
importance: Undecided → Medium
Bryce Harrington (bryce) on 2015-02-23
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers