(5.0.0-rc2-dev) Pcbnew: When ripping up tracks, the delete tool sometimes is de-selected

[Reece Pollack]

When ripping up (deleting) a parts of routed track, sometimes the delete tool remains selected and sometimes it doesn't.

There doesn't seem to be any pattern I can discern. Sometimes I have to click on the trashcan icon to reselect the delete tool and sometimes it remains selected. No special setup is needed to observe this.

Also... when deleting a track by clicking very close to the pad of a device, every so often the device will get deleted too with the same click. "Undelete" will restore the device. At first I thought I might have accidentally double-clicked, but I no longer believe this is likely.

While I'm complaining... why does KiCad use the same tool to rip up tracks as deleting components? This is dangerous and should be changed to provide separate rip-up and delete tools.

Built from source on a private branch descended from this commit:
    07dc12f Fix incorrect UI management of Zoom to Selection, created by fix 2a419156

Application: kicad
Version: (5.0.0-rc2-dev-440-gd458cd5-dirty), debug build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.13.0-38-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

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=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

[Maciej Suminski (orsonmmz)]

To add more information: as far as I can see, the delete tool is deselected once a disambiguation menu pop ups.

I cannot reproduce the problem with excessive footprint removal. It would be very helpful if you could provide us a test case to investigate (a board file where you can reliably trigger the bug).

I would like to be sure I understand your request regarding separate delete and rip-up tools: should they only differ by the type of removed objects (one removes tracks, the other everything beside tracks)? If so, it will be adressed in a more generic manner with selection filter planned for v6.

[Reece Pollack (reece-pollack)]

It definitely is deselected after a disambiguation popup is closed. This was what I originally wrote in the bug report. However, while testing before submitting the bug I saw it happen when there wasn't a disambiguation popup so I rewrote the bug. I'll try to reproduce the situation.

I'll try to reproduce the footprint deletion situation, but it may be the weekend before I have time. As I recall, I was trying to rip up a short section of track that originated on a DFN pin, and both the track and the DFN itself went away. I hit CTRL/Z once and the DFN came back but not the track.

Looking through the hotkeys list I found that the BKSP key was listed as ripping up a track without deleting a footprint, while the DEL key would do both. I don't believe combining the two is ever a good idea, as there's a huge difference between "I don't like where that track is laid but want to retain the connection" and "I want to remove that part from the board".

[Reece Pollack (reece-pollack)]

I haven't had any more unexpected component deletions, but I have noticed that if I rip up a track in close proximity with a component, often the component or track is highlighted as if it's been clicked on. That could explain how hitting Delete or Backspace a second time by accident could cause the component to be deleted.

When I select a track to be ripped up and delete it, I do NOT expect random nearby components to be selected in its place. I expect nothing will be selected.

[Jeff Young (jeyjey)]

It doesn't look like this is going to get addressed for 5.1, and it was completely re-written for 6.0 so I'm going to mark it fixed in 6.0.