Snapping of rotation center

Bug #607107 reported by LucaDC
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
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.

Tags: snapping
Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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)
Revision history for this message
LucaDC (lucadc) 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)
tags: added: snapping
Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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.

Revision history for this message
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 ;-) ).

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote : Re: [Bug 607107] Re: Snapping of rotation center

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.

Revision history for this message
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.

Revision history for this message
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))

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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?

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
su_v (suv-lp) wrote :

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

confirmed with r9640 - thx :)

Revision history for this message
LucaDC (lucadc) 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.

Revision history for this message
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?

Revision history for this message
LucaDC (lucadc) 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...

Revision history for this message
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.

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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

su_v (suv-lp)
Changed in inkscape:
status: New → Confirmed
Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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...

Revision history for this message
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.

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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.

Revision history for this message
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

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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

Revision history for this message
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.

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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

Revision history for this message
su_v (suv-lp) wrote :

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

Object rotation center to guide

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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

Revision history for this message
su_v (suv-lp) wrote :

> Please test rev. #9652

Fix confirmed :)

Revision history for this message
LucaDC (lucadc) 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)
Changed in inkscape:
milestone: none → 0.49
Revision history for this message
LucaDC (lucadc) wrote :

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

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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.

Revision history for this message
LucaDC (lucadc) 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.

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

Confirmed, I will fix this

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

Should have been fixed as of rev. #9817

Revision history for this message
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!

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

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.

Revision history for this message
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!

Revision history for this message
Diederik van Lierop (mail-diedenrezi) wrote :

Shortcut reactivated as of rev. #9903!

Revision history for this message
jazzynico (jazzynico) wrote :

> Shortcut reactivated as of rev. #9903!

Thanks you!

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.