For 90° track connection using hotkey D I get following:
For connection with very short 45° segment (I am typically working with 0.1mm grid) I need carefully point on it to then D-rag it.
I am also not looking for an Altium clone. Altium had a huge learning curve and there are still lots of things I don’t like about it. The difference with Altium is that there’s virtually zero chance your requests or ideas will make it into a release. I had some ideas to optimize workflow / speed as well.
I like open-source in general, I contributed (ideas and code) to several projects.
Will post some ideas / questions here and if I feel comfortable, I will create a Gitlab issue.
The D hotkey helps at least! Instead of click-select > click-drag, D-drag is feeling quicker and smoother.
I only trying to get my head around where to click, it seems to change with the zoom level (I did put a bottom layer track behind to see where it overlaps)
It’s more obvious in track sketch mode:
If you hit an area with no overlapping track, it doesn’t disambiguate. Aim for the triangle-ish areas in the green circles. Obviously, as the chamfer gets longer, this gets proportionally much easier.
It’s theoretically possible to have a special case of the selection logic in this case to prefer the tiny chamfer track more strongly. But that requires very careful implementation so as not to feel janky and inconsistent and also so as not to introduce excessive complexity or fragility into an already fiddly area of code.
If you hit an area with no overlapping track, it doesn’t disambiguate. Aim for the triangle-ish areas in the green circles. Obviously, as the chamfer gets longer, this gets proportionally much easier.
There are blind spots, try it when zooming out a bit. Also D-dragging goes directly into chamfer mode inconsistently (sometimes the selection popup appears) when in the overlapping areas (or even outside on the horizontal or vertical line).
Just don’t hesitate to create issue. You can start title with ‘Feature request’ to clearly inform that this is not bug report.
I think even more important is the comparison of chances to fix bug which disturbs you at work.
Reading the forum I know (and it is also my experience) that reported bug often happens be fixed in few hours.
Once it even happened to me to ask here to get others opinion if it is a bug or not and then when confirmed I reported a bug to be informed at once that it is already fixed (one of developers just noticed this discussion before I reported this bug).
One think I reported (as request) in KiCad V5 times is to make cursor snapping dependent on zoom level as I frequently want to stop wide track with cursor inside pad, but not at its center (so that it does not stick out on the other side). You can temporarily switch snapping off, but with big zoom in, I simply don’t see cursor being snapped by 1/4 of screen as rationale. If snapping were limited to some number of screen pixels you will not have a problem with it by just working for a moment with bigger zoom.
Try for example to drag segment you are experimenting with for less than 1/2 of its width, what is frequent need if you just want to distribute tracks a little.
I’m not sure how it is now (last time using KiCad (V8) in December), but suppose it is still like that.
Yes and the fact that the community is very active made me decide to dare the step to switch over too.
For now it feels all okay for me, I did set snap to vias pads and tracks to always so when dragging, I am able to align to other tracks or pads. That works perfect but I sometimes I need to turn it off (still gotta figure out a hotkey for that).
With the ‘blind spots’ I meant KiCad fails to D-drag select the track even when the mousepointer is clearly pointing to the track.
I made a video so you can hear the D clicks:
Try Shift, Ctrl and Shift+Ctrl while moving mouse.
This are not hotkeys but rather mouse modifiers.
One should switch off grid snapping, other should switch off snapping to other objects, both probably switch off both.
I think it have to be documented somewhere, but I don’t know where.
I suspect its snapping to the grid and the grid point it selects is outside the area you need to be in to select the correct segment.
I have opened PCB Editor documentation and Ctrl+F and write ‘Shift’ in selection box and got 105 hits. The 17-th hit is about modifying snapping.
I’m planning to read the entire documentation again (I read it for KiCad V4 before downloading it)
This may be fixed in 9.0.4, the same basic thing as Footprint grabbed by the wrong pin during a move. (#10471) · Issues · KiCad / KiCad Source Code / kicad · GitLab, where a relatively coarse grid inhibits snapping to any point where some grid point is nearer the mouse than the mouse is to the object.
I don’t think snap modifiers should be needed then, but they can be handy to know about in general.
Snap modifiers subject here is not about dragging segment but about ending track in pad, but not in its center, I think.
I think I will be using KiCad next week, but there is 99% I will just still use V8.
To be able to use V9 I have to:
Decisions I made with V4 were good for V5…V8 but not for V9 
Oh I see, then yes, Shift helps a bit (but annoyingly not that much if the pad isn’t on the grid).
Actually I think there is still something weird going on, and it’s not the grid thing. I can also get D to fail to pick up the track in some places even on master, and with a tiny grid. I raised an issue for it:
I’m on 9.0.4 and the dead spots seems to be just on the half-grid lines (like those lines provide a dead spot when doing D-drag).
It was indeed a bug, but turned out not to be related to the grid (makes a change). Fix will be in 9.0.5 and the next testing and nightly builds if you want a sneak peek. In the mean time, stay a few pixels away from the H/V track ends and it won’t happen.
