ESC doesn't cancel move when using the Node Tool

Bug #788560 reported by Ricardo Graça
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Krzysztof Kosinski
inkscape (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: inkscape

ESC key doesn't cancel the move action when moving a node using the Node Tool. Tested in the Inkscape version from the Ubuntu 11.04 repositories, which is version 0.48.

Steps to reproduce:
1. Create a new bezier curve
2. Using the node tool click and drag one of the vertices
3. While still dragging the node press ESC hoping that the node returns to its initial position

Expected result:
The node returns to the initial position, canceling the move action

Actual result:
The move action isn't canceled and the node doesn't return to its initial position

Related branches

Revision history for this message
Ricardo Graça (devius) wrote :

The tested Inkscape version is actually 0.48.1 r9760

Revision history for this message
Alex Valavanis (valavanisalex) wrote :

I can confirm this behaviour in inkscape_0.48.1-2ubuntu2 in Ubuntu Natty

@upstream - Is this behaviour intended?

Changed in inkscape (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
su_v (suv-lp) wrote :

> Is this behaviour intended?

I can confirm that in Inkscape 0.46 and 0.47 (old node tool), <esc> cancels a node drag and restores the prior location of the dragged node(s).
In Inkscape 0.48.0, 0.48.1 and current trunk (new node tool), <esc> doesn't cancel dragging a selection.

@Krzysztof - can you comment on this? Was it changed by design?

tags: added: node-editing
su_v (suv-lp)
Changed in inkscape:
importance: Undecided → Low
status: New → Confirmed
tags: added: regression
ScislaC (scislac)
Changed in inkscape:
milestone: none → 0.48.3
assignee: nobody → Krzysztof Kosinski (tweenk)
Revision history for this message
John Smith (john-smithi) wrote :

Patch for pressing Esc with one or more nodes or a node handle dragged resets to previous position.

> Was it changed by design?
This appears to be a todo in the code ... // TODO add ESC keybinding as drag cancel

Tested on Ubuntu 11.10 and WIndows 7.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "788560.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

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

Patch tested and fix confirmed (same behavior as in the old node tool of 0.47):
- OS X Lion (64bit), GTK+/X11 2.24.8
- Mac OS X Leopard (32bit), GTK+/Quartz 2.24.8

When running Inkscape under X11 (XQuartz 2.6.3 (xorg-server 1.10.3)) , pressing escape still seems to somehow keep the mouse focus partially grabbed (I don't know how to properly describe it in technical terms): when using a trackpad (built-in) instead of an external mouse, an additional tap (~LMB click) is required after pressing <esc> before a new selection of nodes can be made, or the same selection dragged again. If the mouse pointer is moved outside of the Inkscape window before that additional tab occured, X11 gets confused and other X11-based application windows (xterm, another inkscape window) get randomly displaced as if they had been grabbed and are now dragged in the window manager context (until a tab on the trackpad occurs).

Inkscape 0.47 exposes the same behavior when cancelling a node drag.

When running Inkscape built with the Quartz backend of GTK+, an additional (second) tab on the trackpad is required to activate any other (native) application window after cancelling a node drag (normally, a single tab or click is sufficient) - no other side effects observed though.

tags: added: patch-forwarded-upstream
removed: patch
Changed in inkscape (Ubuntu):
status: Incomplete → Triaged
su_v (suv-lp)
tags: added: backport-proposed
John Smith (john-smithi)
Changed in inkscape:
assignee: Krzysztof Kosinski (tweenk) → John Smith (john-smithi)
Revision history for this message
John Smith (john-smithi) wrote :

@suv, this looks like one of the last issues tagged as 0.48.3.
Do you think this is good enough to commit ?

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

> Do you think this is good enough to commit ?

Based on my tests, yes - AFAICT it restores the old and expected behavior of the node tool in prior releases.

Local tests have been done using Inkscape with keyboard and external mouse/internal trackpad (laptop) - maybe feedback by advanced tablet users testing this re-implemented feature would be useful? I don't know whether some might have mapped <esc> to a button(+modifier) of the tablet/pen (if that's possible at all)?

jazzynico (jazzynico)
Changed in inkscape:
status: Confirmed → In Progress
Revision history for this message
Krzysztof Kosinski (tweenk) wrote :

The patch looks unnecessarily intrusive. It is possible to fix this without requiring every type of control point to implement custom cancellation handling by simulating a drag event to the origin before ungrabbing. I am working on an improved fix.

Revision history for this message
Krzysztof Kosinski (tweenk) wrote :

The improved fix has been committed as r10925 to trunk, please test.

Revision history for this message
Krzysztof Kosinski (tweenk) wrote :

Fixes for edge cases (cancelling a drag of a line segment and drag of a handle that is within dragtolerance of its node) added in 10926, both revisions backported and committed to stable branch as 9859.

Changed in inkscape:
assignee: John Smith (john-smithi) → Krzysztof Kosinski (tweenk)
status: In Progress → Fix Committed
Revision history for this message
John Smith (john-smithi) wrote :

Yes, works well on Ubuntu 11.10.
Thanks for the quick fix.

tags: removed: backport-proposed
Ted Gould (ted)
Changed in inkscape:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package inkscape - 0.48.3-0ubuntu1

---------------
inkscape (0.48.3-0ubuntu1) precise; urgency=low

  * New upstream release (LP: #933188). Fixes several Ubuntu bugs:
    - inkscape fails to build with glib 2.31 (LP: #898538)
    - ctrl c ctrl v of text in edit mode crashes inkscape (LP: #496793)
    - Completely replace lcms1 by lcms2 in Ubuntu (LP: #885324)
    - parameters ending with '\' causes python to bomb (LP: #168417)
    - Extensions with <check> tags fail to load (LP: #668895)
    - ESC doesn't cancel move when using the Node Tool (LP: #788560)
    - unable to edit attributes in Inkscape XML Editor (LP: #884368)
    - Some layers should be visible by default in Layers dialog (LP: #902054)
    - Path Effect List is hidden (LP: #909958)
    - Input Devices > Hardware > Tree of devices is hidden (LP: #910467)
    - Glyphs Font styles are hidden (LP: #911079)
    - Error messages from Extensions hidden (LP: #911079)
    - Messages dialog doesn't work (LP: #911123)
  * Drop 02-add-shebangs-and-fix-permissions.dpatch: Applied upstream.
  * Drop build-dependency on specific libwpd/libwpg version.
 -- Alex Valavanis <email address hidden> Thu, 16 Feb 2012 14:33:40 +0000

Changed in inkscape (Ubuntu):
status: Triaged → 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.