Different behaviour: Select Component, then Move / or only Move

[Thomas Pointhuber]

# Current behaviour

It was noted to me the difference of behaviour depending on when you select a component and then press M, and press M in default state over a component:

## Select behaviour:

1. Select Component
2. Press M
3. Move Component
4. click with mouse to fix position, component still selected
5. move over other component, press M, old component is moved 🔥

## Without select behaviour

1. Move over component
2. press M
3. Move Component
4. click with mouse to fix position, component is no longer selected
5. move over other component, press M, new component is selected to move

# Expected behaviour

Unify behaviour. My current ideas:

* keep selection active after tool use, but use unselected behaviour when mouse is outside of the bounding-box of current footprint and there is a valid footprint underneath.
* always remove selection after move/rotate (could be annoying in dense boards)

# Version Information

Application: kicad
Version: (6.0.0-rc1-dev-1610-g90178eb68), debug build
Libraries:
    wxWidgets 3.1.1
    libcurl/7.63.0 OpenSSL/1.1.1a zlib/1.2.11 libidn2/2.1.0 libpsl/0.20.2 (+libidn2/2.1.0) libssh2/1.8.0 nghttp2/1.35.1
Platform: Linux 4.20.3-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.1.1 (wchar_t,wx containers) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.63.0
    Compiler: Clang 7.0.1 with C++ ABI 1002

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    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

[Wayne Stambaugh (stambaughw)]

@Thomas, proceed carefully before changing this. You may want to get input from other users not just developers. There seems to be a large contingent of KiCad users who prefer this tool-centric mode view of the the world. I personally don't like the current behavior either but there may be some resistance to your proposal.

[Thomas Pointhuber (pointhi)]

The issue was noted to me, and I know that non of the proposals are ideal.

Another Issue I often face is selection of a footprint in a dense layout, and a pad is selected instead. One idea to fix this would be that the footprint has to be selected and then a second selection needs to be done for the pad (because pads are edited quite rarely). But I somehow assume that this behaviour could be affect usecases heavily I do not know at the moment.

[Wayne Stambaugh (stambaughw)]

One of my pet peeves is the router. If I want to quickly move a footprint or delete some traces that were routed prior to the current routing tool instance, the route tool is exited and the select tool is enable. It would be nice if once I was done moving or deleting, the route tool would be re-enabled. As it stands now, I have to enable the routing tool again to get back to routing. In any event, we should define the behavior we want before we code anything to prevent any push back on the changes.

[Jeff Young (jeyjey)]

I think the original issue (which bugs me too) is exacerbated by going back and forth between eeschema and pcbnew. I wonder if we'll stop tripping over it once eeschema also has a selection-based model?

[Michael Kavanagh (michaelkavanagh)]

I've marked this as the duplicate (despite being older) as the duplicate is already milestoned.