Backspace and delete buttons don't work properly for deleting tracks

Bug #1688074 reported by Art on 2017-05-03
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
KiCad
Medium
Tomasz Wlostowski

Bug Description

Not so long ago a very useful feature was implemented which enables deleting tracks while in the track drawing mode. While in track drawing mode you push delete to delete a track segment and backspace to delete the whole track up to the nearest pad or via (there was a separate bug report here https://bugs.launchpad.net/kicad/+bug/1490958) Unfortunately it is still not working properly. If the track is within another footprint extents or next to another footprint, pressing DEL or Backspace deletes the track segment or the whole track (which is correct behavior) but at the same time it deletes the footprint as well (which is not suppose to happen) If you hit undo you can reverse deleting the footprint while the track remains deleted. So you can eventually get the the desired result, it just takes several steps.

Application: kicad
Version: (2017-04-26 revision ade263f30)-makepkg, release build
Libraries: wxWidgets 3.0.2
           libcurl/7.52.1 OpenSSL/1.0.2k zlib/1.2.11 libssh2/1.8.0 nghttp2/1.19.0 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.60.0
Curl: 7.52.1
KiCad - Compiler: GCC 6.3.0 with C++ ABI 1010
        Settings: USE_WX_GRAPHICS_CONTEXT=OFF
                  USE_WX_OVERLAY=OFF
                  KICAD_SCRIPTING=ON
                  KICAD_SCRIPTING_MODULES=ON
                  KICAD_SCRIPTING_WXPYTHON=ON
                  KICAD_SCRIPTING_ACTION_MENU=ON
                  BUILD_GITHUB_PLUGIN=ON
                  KICAD_USE_OCE=ON

tags: added: pns
Eldar Khayrullin (eldar) wrote :

Application: kicad
Version: 5.0.0-rc2-dev-unknown-30a78f0~62~ubuntu17.10.1, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) librtmp/2.3
Platform: Linux 4.13.0-36-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    Curl: 7.55.1
    Compiler: GCC 7.2.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

tags: added: gal pcbnew
Changed in kicad:
status: New → Confirmed
Jeff Young (jeyjey) on 2018-04-09
Changed in kicad:
importance: Undecided → Low
Wayne Stambaugh (stambaughw) wrote :

@Seth, did by chance your commit d0ffff3b88 fix this bug or is this something different?

Seth Hillbrand (sethh) wrote :

Hmm... What was the expected behavior here?

Currently, d0ffff3b88 just prevents delete from happening while actively routing. I tested and it looks like we can use both delete and alt-delete from within the routing tool as long as you are not actively routing.

I have a patch to allow deleting tracks while routing but it deactivates the full route. I feel like this is not really beneficial as the user would lose their track unexpectedly.

I've looked at ways to allow deletion while keeping the current track but I don't understand the tool framework sufficiently to implement this at the moment. Currently if you allow the delete event to proceed, the PointEditor gets activated, an activation event that stops the routing. I assume that the tool manager is just iterating through tools that tie with interactiveSelection event.

Just skipping the activation events is not a good idea either because then we end up with a partially routed track even when a hotkey has triggered another action (e.g. placing a component).

There's probably a clever solution to this but it escapes me for now.

Wayne Stambaugh (stambaughw) wrote :

I don't know that the expected behavior was ever defined only that it worked a certain way and now it acts a different way. Maybe that is the fundamental problem here, we didn't define the behavior so everyone has their own expectations and we have no good response. Before we make any more changes to the route, we should define this behavior first. That's something to discuss during v6 development.

Jeff Young (jeyjey) wrote :

Bumping the priority and setting to 6.0.

Changed in kicad:
milestone: none → 6.0.0-rc1
importance: Low → Medium
Changed in kicad:
status: Confirmed → Triaged
assignee: nobody → Tomasz Wlostowski (twlostow)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers