Why is KiCad PCB layout still clunky

[steaky1212]

Not to put KiCad down, but why is is that the PCB aspect still so clunky, especially with regards to moving components around.
- The default (and unchangeable) behaviour is moving components, instead of dragging them.
- Rotation components breaks the connection to the trace.
- I can't drag and rotate at the same time.
- If I drag a component, the traces default to collision mode.

And it doesn't look like any of these are being raised as issues on github. So weird

[ataradov]

It is a matter of preference. I personally like the way KiCad implements PCB editing.

So, if anything the argument would be to add options for other types of behavior. But if they are not being added or even discussed a lot, people must feel that the default behavior is fine.

[janoc]

And what would you expect to happen?

Given that KiCAD has online DRC, would you prefer:

- DRC constraints get violated, tracks touch/cross/short after you have rotated the part

- Tracks get automatically rerouted, possibly messing up a large part of the layout

There are no sensible options here unless you expect the software to read your mind.


Moving is the default only if you use the mouse. Use a hotkey if you want to initiate a drag. Much faster anyway.

And it doesn't look like any of these are being raised as issues on github. So weird

Maybe because those are not really a problem for anyone?  You can change the behavior of the push-and-shove router (whether the tracks should collide or to reroute automatically) and dragging/moving is easily done by hotkeys.

[ebastler]

Dragging parts (and dragging connected traces along with them) already is a supported operation. But frankly, it feels more limited than it needs to be. Drag mode gives up far too easily -- highlighting a trace overlap and throwing up its arms in despair. In many cases, a bit of local push & shove-routing would go a long way when dragging a part by a short distance, e.g. to make room for another component next to it.

No mind reading required, and it could make life much easier than the status quo, where I have to resort to moving the part, manually ripping up and re-routing many short traces. Always in danger of leaving some redundant trace segments behind, or having made some undesired connections during the component move.

So yes, I would wish for smarter component dragging, and I think it should be achievable.

[nctnico]

Dragging parts (and dragging connected traces along with them) already is a supported operation. But frankly, it feels more limited than it needs to be. Drag mode gives up far too easily -- highlighting a trace overlap and throwing up its arms in despair. In many cases, a bit of local push & shove-routing would go a long way when dragging a part by a short distance, e.g. to make room for another component next to it.

No mind reading required, and it could make life much easier than the status quo, where I have to resort to moving the part, manually ripping up and re-routing many short traces. Always in danger of leaving some redundant trace segments behind, or having made some undesired connections during the component move.

So yes, I would wish for smarter component dragging, and I think it should be achievable.

Just out of interest: Is there no way to just have the traces overlap (causing a DRC) and clean-up later by moving the traces around? I did watch a short video but that didn't answer this question.

[bson]

Is like other dragging?  If so you can override the DRC conflict with the CMD key on Mac and maybe CTRL on Linux and Windows?

I use this all the time when dragging traces and vias, to clean up messes.

[johnboxall]

And it doesn't look like any of these are being raised as issues on github. So weird

You can pay these guys to modify KiCAD for you:
https://www.kipro-pcb.com/

[ebastler]

Just out of interest: Is there no way to just have the traces overlap (causing a DRC) and clean-up later by moving the traces around? I did watch a short video but that didn't answer this question.

The only way I found to allow DRC violations during component dragging requires that one switches the autorouter to "highlight collisions" mode, i.e. not push & shove. Only then the autorouter options dialog enables a checkbox to "allow DRC violoations". But one loses push & shove for routing or dragging traces. (Dragging parts always operates in "highlight collisions" mode, but without a dedicated control checkbox to my knowledge.)

I should say that I am still on Kicad 7; maybe that UI glitch has been fixed? Component dragging itself does not seem to have changed, beyond allowing multiple parts to be selected and dragged with the same limited trace dragging.

[ebastler]

You can pay these guys to modify KiCAD for you:
https://www.kipro-pcb.com/

Yes, that's a comment which is often made in response to Kicad criticism or improvement suggestions. Either "join the team and do it yourself if it's important to you", or "feel free to pay for it", often with a derogatory tone.

I don't think this is helpful, because it discourages user feedback on perceived weaknesses or desired enhancements. Look, users should not feel entitled to certain improvements and be indignant that the developers have not implemented them yet. But likewise, Kicad developers should not feel indignant when "ungrateful" users are not happy with each and every aspect of Kicad, but point out which aspects they would most like to see improved.

[Doctorandus_P]

A lot of the limitations of KiCad are already well known, and regurgitating them (although well meant) is also not helpful. Ideas are cheap, and there is no lack of them. The main bottleneck is simply available time for the people working on KiCad. KiCad has made a lot of progress over the last 5 or so years. Interest in KiCad started rising noticeably when eagle got bought by autodesk.  Each month some 200 to 300 issues get fixed on gitlab, but just as many new issues get opened each month too, and this has kept the total number of open issues around 1500 for several years now. (There has been a peak of 2000 open issues) Just look at KiCad's https://www.kicad.org/blog/categories/Release-Notes/ to get an idea of KiCad's development pace.

If you want to give user feedback, you can search for topics / issues that interest you and give them a thumbs up on gitlab. You can add comments / ideas with details in gitlab too. Just posting a message on a website that is not affiliated with the KiCad project itself will not get much attention from a KiCad developer.

Priority development from https://www.kipro-pcb.com/ is not a realistic option for hobbyists because of it's cost, but it can be for companies who are thinking about adopting KiCad instead of some commercial EDA suite, but are missing some important (to them) feature. Priority development is done by hired employees, and salaries of software engineers are not cheap. But especially if a company has multiple seats to (potentially) convert to KiCad, then there can be a considerable budget, especially if a payback time of a few years is taken into account. And you know that your money is going into real development, and not into a bonus for the CEO, dividend or evaporates in some other way.

[steaky1212]

I'm not sure they'd especially want a C programmer anywhere near the codebase! But I may clone it and see what damage I can do.

Regarding what my expectation would be, I can't imagine (although call that a lack of imagination) that it would be difficult to change the default behaviour (under a config option) so that dragging is the default instead of moving. Even the vernacular around mouse usage would align (click and drag). Obviously dragging was only introduced recently, so maybe the drag-and-rotate will follow? In terms of what I want to happen if I rotate something, keep the connection to the net (or at least put this under an option to not frustrate existing users). Whether this goes to collision/shove/walk around, maybe on shove unless it shoves a huge amount and then revert to collision.

I guess it is just pointing out how expectations are based on previous software usage. For example, my expectation was that doubleclicking on the end of a trace would allow me to continue it, whereas it actually opens the properties. Yet when I rightclick on the trace, the properties are halfway down, so clearly not that important as the default behaviour. My thought is that if I am doubleclicking at the end of a trace, then I am wanting to continue routing that trace (same if I double click on a pad). Unsure if this is mindreading or context driven UI?

Like all open-source projects, it just suffers from a lack of polish. Having push/shove routing is more than I have with the current EDA software, but breaking connections to nets (when rotating) just seems a recipe for disaster.

[JohnG]

KiCad is being adopted by my company, and I don't think we will acquire any more Altium licenses, though we will keep the ones we have. For what it's worth, sure it could use some improvement. But, the devs do pay appear to pay attention if you vote or add something on Gitlab. That doesn't mean you will get it, but you have a say at least, and you can add your support to those you think should be highest priority. I would suggest looking at the roadmap first to get familiar with things.

I'm not knocking the requests. However, this sounds to me like "my last CAD software did it this way, therefore they should change to what I am used to." It would be nice, sure, but it is simply not a realistic expectation. I've worked with at least 7 PCB programs (Eagle*, Cadence (before ORCAD), ORCAD* (before Cadence), AutoCAD (years before Eagle), Altium*, KiCad), either directly*, or sitting next to a layout engineer for days. They all do the same thing and they all have greatly different interfaces. It sucks to switch, but you might as well bite the bullet. The only software you have a chance of changing is KiCad, and it's already got a lot of users used to its interface. For commercial software, experience has been that $100k is not even enough to get them to fix bugs quickly, unless one of their million dollar customers cares about it.

John

[Doctorandus_P]

I'm not sure they'd especially want a C programmer anywhere near the codebase! But I may clone it and see what damage I can do.

The most damage you can do is probably:
* Get hopelessly lost in a big codebase (although I had some short peeks in KiCad's code and it appears to be quite neatly organized).
* Waste your own time if you can't manage to figure things out
* Waste a tiny bit of time from a KiCad developer when he is reviewing your pull request.

But there is no way that contributions from an unknown developer are going to be accepted without a review. You can always start by cloning the code and having a look at it. When you're serious to start with developing, then also do the social thing and join the developers mailing list via: https://dev-docs.kicad.org/en/getting-started/index.html

Having push/shove routing is more than I have with the current EDA software, but breaking connections to nets (when rotating) just seems a recipe for disaster.

Moving and rotating blocks completely disregards DRC, and thus easily creates short circuits, but DRC catches these and shows you where they are. (along with a whole lot of other errors). Running an error free DRC should be on your checklist as one of the last things to do before creating Gerber (Or IPC-2581(stupid name)) files to send to a PCB fab.

[EugenioN]

And what would you expect to happen?

- Tracks get automatically rerouted, possibly messing up a large part of the layout

This! When the auto rerouting (also auto-pushing away traces nearby) can do its magic with given rules, grabbing can continue. When auto rerouting can't be done, then grabbing stops.
This would work beautifully with small positioning. Pads behaves like that, don't know if this is by default or the pcb guy made this a "corporate standard setting".

I actually remember that some early version of Kicad used to allow simple component grabbing with tracks "prolongation" with complete disrespect of design rules: quick and dirty, but super useful when you have no time to polish things up.

[SiliconWizard]

Well, currently the "push and shove" feature in KiCad is still not all that good. It's relatively basic and often either can't push tracks (depending on context) or makes a complete mess (occasionally). It's one of its weak points IMO.

Related point, online DRC is so-so. Pushing tracks will (not always, but) often result in DRC violations.

[Doctorandus_P]

Push 'n Shove does have its limitations but I do see it as one of the more powerful features of KiCad. It is constantly being tweaked and works "a bit" differently in each KiCad version.

It rarely created DRC errors, and when it did, bugs were fixed very quickly after reporting them. On the bad side, recently I started experimenting with custom rules to change clearance in different areas of the PCB, and the interactive router got very confused by it. It constantly created DRC violations, and it hardly could shove any other track at all. I reported it and they are now working on it.

[delfinom]

However, this sounds to me like "my last CAD software did it this way, therefore they should change to what I am used to."

Yep, a large amount of feedback is , "why isn't KiCad an Altium clone". Heck, there was one guy that went "Why isn't KiCad a clone of PADS that I have on my old windows PC circa 1998? It is the superior CAD tool and you are dogshit."


In general, making drag the default instead of move would probably never be accepted. If anything, maybe a option in Preferences.

Though I feel this has come up before hmmph.

[nctnico]

In general, making drag the default instead of move would probably never be accepted. If anything, maybe a option in Preferences.

That would get my vote for sure  Maybe have seperate commands for moving and dragging. Personally I really like to drag components a little bit with the traces attached. Shoving the traces a bit after to tidy up after, is easier compared to re-connecting the tracks.

[bson]

I did like the P&S better in v7, it would push over an entire bus, now with v8 I have to push them one trace at a time.  Of course, with v7 it would also something cause serious messes or go off and think for a few seconds.  But that's what the undo is for.    Perhaps it was problematic with footprint dragging.  Maybe it could be more aggressive when dragging a trace than a footprint?

I now find myself wanting to be able to drag a group or selection of footprints and traces.

[Doctorandus_P]

The P&S Interactive Router can still shove multiple tracks at the same time in KiCad V8 but there is some interference with DRC rules, and as I mentioned earlier, it's being worked on to fix it.

[ebastler]

In general, making drag the default instead of move would probably never be accepted. If anything, maybe a option in Preferences.

That would get my vote for sure  Maybe have seperate commands for moving and dragging. Personally I really like to drag components a little bit with the traces attached. Shoving the traces a bit after to tidy up after, is easier compared to re-connecting the tracks.

What am I missing here? I don't think anyone suggested to "make drag the default". And there already are separate commands for moving or dragging a component. The suggestion was just to make dragging work better, namely to enable push & shove routing for the wires connected to the component.

Which I think would be quite desirable to have. Since one sees the effect of push & shove in real time, one can alway abandon an operation if it causes undesired side effects and messes up the routing in adjacent areas.

[Doctorandus_P]

The "default" is box select.

In the PCB editor when you depress the left mouse button and move the mouse,  (when there is no current selection) then you start creating a selection box. It does not matter if you start on a pad, footprint or track segment. You always start a selection box.

When there already is a selection, the behavior depends on what the selection is.

• Pad -> The footprint is moved.
• Footprint -> The footprint is moved.
• Selection -> The whole selection is moved.
• Single track segment -> The track segment is dragged.
• Multiple track segments -> The track segments are moved (It is a selection).
• Text -> The text is moved.
• Graphics -> Graphics is moved. (Also for zones, rule area's)
• Square box of graphics -> Graphics is modified, just one coordinate is moved.

So clicking on something that is already selected almost always is a move. Only for a single track segment, and for the modify points of graphic objects it is different.

I think I can appreciated it if the default for footprints and selections, is to drag them, but it does not matter much to me. I am used to using Hotkeys to unambiguously tell KiCad what I want it to do.

My bigger problem is with the >[Ctrl] modifier key. It does two things. First it takes your item (or selection) off grid, but it also overrules DRC during a drag. (DRC is already ignored during a move). When dragging a footprint while rubber banding the tracks, the final position often creates a few DRC violations. I usually want to accept these violations (I did not start the drag for nothing, fixing the DRC by dragging another item would be my next move). But this needs [Ctrl] This both takes the footprint off-grid, and it needs an extra hand movement from the b key to the [Ctrl] key.

[nctnico]

In general, making drag the default instead of move would probably never be accepted. If anything, maybe a option in Preferences.

That would get my vote for sure  Maybe have seperate commands for moving and dragging. Personally I really like to drag components a little bit with the traces attached. Shoving the traces a bit after to tidy up after, is easier compared to re-connecting the tracks.

What am I missing here? I don't think anyone suggested to "make drag the default". And there already are separate commands for moving or dragging a component. The suggestion was just to make dragging work better, namely to enable push & shove routing for the wires connected to the component.

Which I think would be quite desirable to have. Since one sees the effect of push & shove in real time, one can alway abandon an operation if it causes undesired side effects and messes up the routing in adjacent areas.

Alternatively, in some cases it is better push & shove just stops beyond a certain point and just have whatever shorts are created by dragging a component. The user can cleanup later. This is especially true in case a board is already densily routed.

[bson]

Another option is a hybrid approach: drag traces as far as possible, and when it stops being possible start deleting them!  Remove the end of them up to some reasonable distance, to create space.  This is what we end up doing manually anyway.  Or maybe, avoid DRC conflicts by removing conflicting trace segments.

[nctnico]

Another option is a hybrid approach: drag traces as far as possible, and when it stops being possible start deleting them!  Remove the end of them up to some reasonable distance, to create space.  This is what we end up doing manually anyway.  Or maybe, avoid DRC conflicts by removing conflicting trace segments.

I'm suite sure such a feature is likely to delete the traces I want to keep