Bounding box snapping regressions in 0.47+devel

Bug #562205 reported by su_v on 2010-04-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Diederik van Lierop

Bug Description

Inkscape 0.47+devel r9319 on OS X 10.5.8:
- default preferences (preferences.xml removed)
changed settings:
- node snapping and node snapping targets are off
- bbox snapping is enabled with varying targets
- rescaling stroke-width proportionally is off
test objects:
- 2 rectangles (unfilled, stroke-width 10px)

Issue I:
  'Squeeze or stretch selection' fails to snap bbox corners to valid targets
fails for:
  ° snap bbox corners to bbox edges
  ° snap bbox corners to grid
  ° snap bbox corners to guides
  (message 'corner to constraint' and the node snap indicator is shown despite node snapping is off)

Issue II:
  'Scale selection' fails to snap dragged bbox corner (except when dragging lower left bbox corner)
fails for:
  ° snap bbox corners to grid
  ° snap bbox corners to guides
  (snapping works as expected with 'Move selection')

  IMHO this is a regression because it is no longer possible to easily rescale an object with the intention to align all bbox corners/edges to grid/guides:
In Inkscape 0.47+devel one has to use two or more steps: first move the object to snap the upper right corner to grid/guides, then rescale the lower left bbox corner to snap to grid/guide too.
This can be done by scaling opposing bbox corners in 0.47 without the need to move the object.

Since 'Stretch selection' also fails for bbox to edge/grid/guide targets, bbox snapping in current devel builds is quite limited.

Issue III:
  'Scale selection' fails to snap dragged bbox corner to other bbox targets:
- fails when dragging upper left or lower right bbox corner (i.e. works when dragging lower left or upper right bbox corner)
- snap to edges only snaps to the lower egde of the bbox snap target, the other three edges are ignored
fails for:
  ° snap bbox corners to bbox edges
  ° snap bbox corners to bbox corner
  ° snap bbox corners to bbox midpoints
  (snapping works as expected with 'Move selection')

Issue IV (minor):
  Sometimes selected bbox targets appear actively used as node snap targets even though bbox snap is turned off and the bbox snap targets are greyed out (I haven't yet figured out how to reproduce it consistently, sorry).

Changing snapping preferences to only snap the node closest to the pointer doesn't improve bbox snapping in above listed issues.

su_v (suv-lp) wrote :

@Diederik - any chance you find the time to look into this issue?

I still have to test with older revisions to see if I can narrow down when these changes in bbox snapping first appeared.

Changed in inkscape:
assignee: nobody → Diederik van Lierop (mail-diedenrezi)
su_v (suv-lp) wrote :

     'Scale selection': upper left/lower right bbox corner fails to snap to bbox corner/midpoints

r9011/9015/9029 (-> changes in r9011 and 9014?)
     scaling by dragging bbox corners start to fail to snap to various bbox targets:
      'Scale selection': all dragged bbox corners fail to snap to vertical bbox edges
      'Scale selection': dragged bbox corners (except lower right) fail to snap to grid/guide intersection
      'Scale selection': lower left/upper right bbox corner fail to snap to bbox edges
      'Scale selection': all dragged bbox corners fail to snap to all bbox edges

r9092 (-> changes in r9082?)
     'Stretch selection': horizontal edges fail to snap to upper edge of target bbox

     'Stretch selection': all edges fail to snap to grid/guides/bbox edges/bbox corners/bbox midpoints (and display the node snap-indicator with the 'Corner to constraint' message although the intention is to stretch the bbox corner)

I didn't test later revisions besides current r9319 (and r9322).

Maybe these changes have been intentional, but IMHO bounding box snapping is less usable now than in 0.47. Or did I miss some hidden new features for snapping ;) ?

Confirmed; this wasn't intentional. I hadn't noticed this yet, but I know what caused this.

I will fix this, thanks for reporting!

Changed in inkscape:
status: New → Confirmed

Fixed as of rev. #9351. Please test!

Changed in inkscape:
status: Confirmed → Fix Released
su_v (suv-lp) wrote :

fix only in parts confirmed (Inkscape 0.47+devel r9351):
- fixed: snap stretching bbox to grid line, guide line and some page borders

details (comparing r9351 to 0.47):

Issue I:
  'Squeeze or stretch selection' fails to snap bbox to valid targets

- fixed: snap stretching bbox to grid line, guide line and some page borders
- fails: snap stretching bbox to upper page border
- fails: snap stretching bbox to upper bbox edges as target

Issue II:
  'Scale selection' fails to snap dragged bbox corner to grid, guide and page

- not fixed (setting 'Weight factor' to 1 may help for some cases)
  it is still almost impossible to actually snap the dragged bbox corner (but that's want the user wants to do when enabling bbox snapping and dragging a corner - as opposed to stretching the bbox in one direction). Only the lower left corner can be snapped as expected, the other corners fail to snap to grid intersection, guide intersection & page borders and to upper page corners.

Issue III:
  'Scale selection' fails to snap dragged bbox corner to other bbox targets

- fails: snap scaling bbox corner to bbox edges for non- or partially overlapping objects
  (snap scaling bbox corner to lower bbox edge works if both vertical bbox edges of the selected object are within the vertical bbox edges of the snap target)

Issue V: (previously not specially mentioned)
   snap bbox to page:
- fails: snap stretching bbox to upper page border
- fails: snap scaling upper bbox corners to upper page corners

files demonstrating differences in bbox snapping between 0.47 and
current 0.47+devel (r9359)
(tested with default new preferences, stroke scaling off)

Issue I has now been fixed in rev. #9364

su_v (suv-lp) wrote :

fix confirmed for Issue I:
  'Squeeze or stretch selection' fails to snap bbox to upper page border and to upper bbox edges

with 0.47+devel r9364 on OS X 10.5.8 - thx :)

Setting status back to 'In Progess' in the hope you'll find time to address the other issues as well.

Changed in inkscape:
status: Fix Released → In Progress

I'm on it! I plan to have this fixed by the end of the week.

su_v (suv-lp) wrote :

I'm sorry to report a small regression in r9351:

Ctrl-dragging a node with the node tool up or down snaps the node back to the original or to a new horizontally constrained position unless vertical drag distance is greater than ~32px.

Not reproduced with r9350, reproduced with r9351 on OS X 10.5.8 (default preferences)

jimmac (jimmac) wrote :

I can confirm the jumpy snapping behavior.

I might just have fixed "issue II"..... I'm not going to claim that it truly has been fixed, because I've been mistaken before ;-)

Please test rev. #9402 or newer.

su_v (suv-lp) wrote :

fix confirmed with Inkscape 0.47+devel r9402 on OS X 10.5.8

Issue I-V as described in comment #6 no longer reproduced - it seems that you not only fixed "issue II" but all of them! ;) At the moment I'm only aware of the minor regression as described in comment #11. Otherwise everything seems to work as expected - thank you for continuously putting so much effort into improving snapping, it is very appreciated!

As you know by now I'll continue testing and reporting back any regressions I happen to notice ;)

I hadn't looked at the other issues yet, but if these were fixed too then apparently this is my lucky day ;-)
The jumpy snapping behavior has now been fixed too (as of rev. #94050). As far as snapping is concerned I believe we're now back in good shape for the upcoming v0.48 release.

Thanks for testing, reporting, and confirming ~suv and jimmac, this is equally important and equally appreciated! This wouldn't have been noticed and fixed if you two had remained silent.

Changed in inkscape:
status: In Progress → Fix Released
su_v (suv-lp) wrote :

Fix confirmed with 0.47+devel r9405: ctrl-dragging a node vertically now works as expected. :)

su_v (suv-lp) wrote :

@Diederik - possibly minor regression or new (intended) behavior of constrained dragging?
(noticed in r9819, not yet tested which revision actually caused it, but definitely not present in 0.48):

Similar to comment #11 while Ctrl-dragging a node vertically or horizontally - this time when snapping to grid is active - the dragged node intermittently jumps back to the original position. If the mouse is hovering precisely over the snapping target (grid intersection), the position sticks, but user experience might be that constrained dragging with grid snapping is either disabled or only works randomly.

Tested with Inkscape 0.48+devel r9819, default settings, on OS X 10.5.8

Confirmed, thanks for reporting... once again ;-)

I've modified the calculation of the snap metric , which is being used for determining which snap target should be preferred. The behavior for constrained snapping should have been improved now, surely for the use-case you described (thanks for the attachment). Please keep one eye open though for possible regressions in other use cases, because it's next to impossible for me to oversee this completely.

The new code is in rev. #9837; if no regressions are found then I will backport it to v0.48

su_v (suv-lp) wrote :

> The behavior for constrained snapping should have been improved now

@Diederik -- another question, slightly off-topic for this report maybe (but related constrained snapping and to the recent topic in inkscape-devel -- [fixed] regression for paraxial mode):

When testing the restored paraxial mode in trunk, I noticed a basic difference in snapping behavior compared to previous Inkscape 0.47:

When drawing paraxial lines in Inkscape 0.47 it is possible to 'snap' to a point outside the orthogonal restriction/constraint and have the tool either use the x- or y-coordinate of the snapped point -- allowing to align rectangle shapes and corners of orthogonal path with other objects/nodes or snap targets on grid and guides outside the projected path of the current segment.

In Inkscape 0.48 and current trunk, only the actual position of the next node is snapping i.e. if the constrained orthogonal path direction doesn't happen to cross a snap target, no snapping / aligning of the next corner is possible. IMHO this reduces the usability of the paraxial mode (only closing a path by clicking on the start node works as expected and uses the x- or y-component when inserting the last corner before closing).

Is it possible to restore the old behavior (take x- or -y-coordinate from snapped point under the cursor, not from the node position along the constrined path segment) without breaking other use cases of constrained snapping?

Test case:
1) draw a diagonal line, deselect it
2) set 'Snap nodes and handles' and 'Snap to cusp nodes'
3) draw a path in paraxial mode that complements the diagonal with an orthogonal corner (path with 2 segments):
   - first click snaps to start node,
   - click twice snapping to the end node of the diagonal path.
4) <enter> or right-click to finish the second path

-> works in 0.47 (yes, the first node in the bézier tool doesn't yet snap in 0.47, but that's fixed in 0.48 ;) ),
-> in 0.48+devel r9850 the end node of the diagonal is not used/seen as snap target at all

Tested with 0.47, 0.48 and 0.48+devel r9850 on OS X 10.5.8; default preferences and default A4 template without grid enabled.

Hi ~suv,

There's an option in the snapping preferences which might/should just
do that. It's the bottom one in the "snapping" tab, if I'm correct. I
cannot test this myself today. If it doesn't work then just let me know.


su_v (suv-lp) wrote :

I had tested that setting before but redid the tests: default (i.e. new) preferences, with both states of
'Preferences > Snapping: [ ] Snap the mouse pointer when dragging a constrained knot''
(default setting: not activated)

Afaict, when drawing in paraxial mode, activating the mentioned option in the snapping preferences pane has
- no effect in Inkscape 0.47
- no effect in Inkscape 0.48.0 for above example (snap to cusp nodes) [1]
- no effect in current trunk r9850

[1] but in 0.48.0 -- if e.g. 'Snap to path' is used -- the setting breaks the paraxial mode and connects the snapped target directly, or breaks the constrained (h/v) mode when ctrl-dragging a node in the node tool.

The option to snap the mouse pointer instead of projecting it first onto the constraint, was only implemented for a very specific use case. I have reworked the constrained snapper (rev. #9866) and now implemented it properly I believe. This should fulfill your request, not only for the paraxial mode but for _any_ constrained snap of a single node or a single handle.

I've done the best I can to test this, but this touches upon so many use cases that I'm bound to overlook one or more. It noticed already that this doesn't work yet when dragging a gradient with ctrl (to snap to angle increments)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers