Connecting pads by ones origin inside the second one don't work.

[Piotr Gałka]

From https://bugs.launchpad.net/kicad/+bug/1843993 message #3 I understood that smd offsets were introduced to allow connecting two pads by positioning origin of one of them inside the second one.
That doesn't work in 5.1.4 stable.
The KEY10.kicad_mod (attached) is designed that way. Top pad1 I left without offset, but all others smd pads use offsets to have their origin in top pad1, or pad already connected that way with top pad1.
When I put that footprint at PCB (project attached) I see pads not being connected and connection lines pointing the pad graphic centers and not their origins.
Compare KEY_1.png and KEY_2.png. When I connect track to right pad 1 origin two connection lines disappear. At first I supposed that at that moment they were found to be connected (thanks to my offsets) but now I think that both of them are found to be connected to track so they are connected also.

I supposed connection lines would point to pad origins. And I think it should work that way (if not then what for are the offsets in smd pads). But what if someone use both X and Y offset and position origin out of pad. First thought is to not allow it in footprint editor. But in my footprint would't it be logical to position all pad 2 origins in center of through-hole pad 2 making them being connected and at once making the connection line to point where the connection is expected to be done.

Application: KiCad
Version: (5.1.4)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

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

[Seth Hillbrand (sethh)]

Hi Piotr- Please direct support requests for how best to work with pads to the forum (https://forum.kicad.info)

As we mentioned in the linked bug report, the correct way to do this is with complex pads. If you'd like to work around that with groups of regular pads, the forum may be able help.

[Piotr Gałka (piotrgalka)]

Was there.
https://forum.kicad.info/t/how-practically-to-connect-connected-pads-in-footprint/18910
but that doesn't mean that I moved from there to here.

I've never written here to ask for help and don't expect such type of answers. I write here only if:
- I think (it happened that wrongly) I found a bug or
- I think some feature would be needed or
- I think something should be changed.

In mentioned bug I read (#3):
--------------
"Your example footprint would be solved by using a complex pad"
Or just by a better design:
using rectangular pads with a suitable offset to keep each pad origin inside an other pad.
this is the reason on offsets in smd pads.
--------------
No one written there that it is not true so I understood you (all) assume rectangular pads work as Jean-Pierre has written, and as they work differently then I think you should know that - report it.
This not match those bug title so I written as a new one.

[Seth Hillbrand (sethh)]

My apologies Piotr. I see that you are correct. The footprint should have fewer ratsnest lines which indicates that we are not taking the offset into account. I'll get that fixed shortly.

[jean-pierre charras (jp-charras)]

In fact, this is a regression: Kicad 4.0.7 see pads connected.

[KiCad Janitor (kicad-janitor)]

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