Nightly PCBNEW : Del key not delete multiselect

[Michele Giorato]

In PCBnew I noticed that if I make the multi selection of routed tracks and then press the "del" key, nothing happens.
In particular, only the track segments can be deleted with the "del" key.
If I make the multi-selection, press the right mouse button, the menu appears, and selecting "delete" deletes all the selected tracks.
I have already tried to reset all the hotkeys to default but nothing changes. If I am not mistaken in the previous versions the "del" key erases everything ....

Application: Pcbnew
Version: 6.0.0-unknown-r16086-daad58e5, debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.64.0 OpenSSL/1.1.1c zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.8.7/openssl/zlib nghttp2/1.38.0
Platform: Linux 5.1.8-300.fc30.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.64.0
    Compiler: GCC 9.1.1 with C++ ABI 1013

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Jeff Young (jeyjey)]

@Seth, this is because of the new "ClearIfOutside" logic. Since we have the Delete Tool for doing hover-style deleting, maybe we don't need the ClearIfOutside for delete?

[Jeff Young (jeyjey)]

@Michele, delete will still work if you mouse pointer is within the bounding box of the selected tracks.

[Seth Hillbrand (sethh)]

Hmm...

Maybe I need to add an "action accomplished with selection" flag. That way if you select something the first action doesn't care about the BBox.

So, options I see here:

1) Old behavior
2) Current BBox behavior (have to be inside the selection bounding box for the action to work
3) Deselect on action complete (similar to AutoCAD)
4) Selection permits single action anywhere but then the second action requires the mouse in the BBox
5) Add some wiggle-room to the current BBox by using an expand by some number of pixels to allow for mouse slop after selecting.
6) Reduce the number of items that allow the new behavior.

This seems like too many options, so I'd be happy if folks would be willing to rule a few out as not workable for them.

[Jeff Young (jeyjey)]

An idea I was toying with was two different selection tools: one that acts like (1), and another that supports roll-over behaviour and changes the selection as you roll over objects. But then you kind of have to switch selection tools to do a drag-selection, so I'm not sure it's a good idea.

I think the bounding-box idea makes some sense when the action is mouse-driven. It probably doesn't when it's not.

I wonder how well (3) would work if only applied to hover selections? That is, if the user made the selection (either via drag or via clicking), then it stays around. But if we made the selection (because the user executed a command which needed one), then we drop it after the command.

[Seth Hillbrand (sethh)]

Doesn't (3) apply to hover selections now? Or did I misunderstand that?

[Michele Giorato (mr-miky64)]

Now that you have explained it I understand the logic but at this point when the cursor goes out of the boundig box (perhaps with an additional margin) I would expect to deselect everything that was selected. It would be better if the bounding box remains perhaps with an "ant" type border to highlight the area in which the hotkeys are accepted.

[Jeff Young (jeyjey)]

> Doesn't (3) apply to hover selections now?

I does now but I was under the (possibly mistaken) impression that it didn't used to in Pcbnew.

So do we really want any of (2) - (6)? Remember that we'll soon have an inspector palette, which won't play terribly well with continually dropping the selection.

[Seth Hillbrand (sethh)]

The point about object inspector is a good one.

How about the following proposal (from Michele's suggestion):

After a group of objects are selected, we draw the bounding box that we are using. If the mouse cursor is inside the box, it is green-ish, if it is outside the box, it is orange-ish. This can be both a visual indicator of whether the action will affect the selection as well as the selection limits.

[Michele Giorato (mr-miky64)]

or change shape to the mouse pointer in "Access denied" type outside the bounding box, or green inside, red outside ...

[Jeff Young (jeyjey)]

But the whole idea is to get hover actions to be hover again, and boxing the cursor would lead me to believe that hover actions weren't going to work either.

[Seth Hillbrand (sethh)]

Maybe... But the action still happens, it just happens to the object you are hovering over instead of the selection.

What if, in addition to the colored selection box, we add a light item outlining when using the select tool? Then, when you have a group selected and the mouse is inside the selection bounding box, the selection is what is highlighted but if you are outside the bounding box, the bounding box color changes and you have the single item that will get the action outlined?

This would let us get rid of the automatic disambiguation menu because the user could see which item is receiving the action before they activate it. The disambiguation menu still exists when using the "Alt" modifier.

The more I think about it, the more I think this solves a number of UI issues (double-click being prominent). If there are not strong objections, I'm going to code this up to give it a try.

[Wayne Stambaugh (stambaughw)]

It seems like we are making this more complicated than it needs to be. When objects are selected whether it be individually selected and/or box selected, the next action should be applied to all selected objects regardless if the mouse is inside the bbox or not. I've always been fond of the AutoCad deselect on action paradigm (#3 above) although I'm not opposed to something better if we can figure out what that might be.

[Michael Kavanagh (michaelkavanagh)]

This is a result of the change from [1] right? IMHO this was a mistake and should be reverted. Why fly in the face of convention? What other piece of software behaves this way? It just adds confusing edge cases like this one.

[1] https://bugs.launchpad.net/kicad/+bug/1827242

[Seth Hillbrand (sethh)]

@Michael- Agreed. Playing with it more doesn't feel right. I'll adjust this tonight after work.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 2dd82cbca7f1f0e2316a6360f3d28c3f901df3a5
https://git.launchpad.net/kicad/patch/?id=2dd82cbca7f1f0e2316a6360f3d28c3f901df3a5