Kicad - GUI is Horrific!

[Monkeh]

What if you want some, but not all, of the resulting potential connections to be connected?

Then you don't use the handy 'connect everything' modifier and proceed to handle it manually instead. You choose to invoke it when you know it's the outcome you want.

[propellerhead]

Then you don't use the handy 'connect everything' modifier and proceed to handle it manually instead. You choose to invoke it when you know it's the outcome you want.

Again, I don't see it as an evil way to go about it, just another command option that adds
to a list of command options (if that's your chosen design philosophy) that grows with no
end in sight.  My view is that if you design without allowing those kind of switches (or make
the explicit decision that they should be used only when absolutely necessary, such as
making rotating/flipping/mirroring options within "move", you can keep the sum total of
commands and commands options much smaller - the RISC vs. CISC decision I spoke
of above.

[Monkeh]

My view is that if you design without allowing those kind of switches (or make
the explicit decision that they should be used only when absolutely necessary, such as
making rotating/flipping/mirroring options within "move", you can keep the sum total of
commands and commands options much smaller - the RISC vs. CISC decision I spoke
of above.

And my counterview is that giving no such options to shortcut common actions merely gets in the way of efficient workflows. Further, when workflows are already established which rely on such behaviour, entirely removing that behaviour only alienates existing users to the detriment of the project.

[propellerhead]

And my counterview is that giving no such options to shortcut common actions merely gets in the way of efficient workflows. Further, when workflows are already established which rely on such behaviour, entirely removing that behaviour only alienates existing users to the detriment of the project.

Sure, one can't ignore the "inertia" argument.

[nctnico]

You are overthinking it. Moving a symbol is not editing, so it is not allowed to make/break connections. IOW: the user doesn't select the mode, it is inferred from the type of operation the user is performing.

Huh?  This sounds like either a zen koan or I'm just being pranked.  "When is an edit not an
edit?  When you're moving a symbol."

Moving a symbol on a schematic is, intrinsically, editing the schematic.

No. Moving a symbol is formatting the schematic. Editing is altering the function of the circuit.

[propellerhead]

No. Moving a symbol is formatting the schematic. Editing is altering the function of the circuit.

I reject that as a silly distinction, and would love to hear who made it up.

The dictionary definition of "edit" is "to revise or correct" for any reason,
whether functional or cosmetic.  My schematic editor is my schematic
editor; when I use it I'm editing my schematic, it draws no distinction
between edits made for appearance and those made for functionality.

[ebastler]

Well, in printed media the distinction between "editor" and "layouter" roles is (or has been) somewhat common. One dealing with changes to content and wording, the other only with format and appearance.

[propellerhead]

Yes, I'm aware of that, but this is the first time I've ever seen the notion
misapplied to schematic editing and it draws an unhelpful distinction.  I'd
still like to know who decided to try to use it here, as this is the first time
I've heard such a thing in 35+ years of using EDA.

[nctnico]

No. Moving a symbol is formatting the schematic. Editing is altering the function of the circuit.

I reject that as a silly distinction, and would love to hear who made it up.

In that case you are limited by your own thinking and perhaps get hung up by semantics...  Maybe think about it a bit more and you'll start to see my distinction is very valid. Especially if you want to translate your requirements into creating software algorithms. Ebastler is right on the money with the printed media example.

[propellerhead]

Sorry, I understand the argument, but it's a hair-splitting distinction probably
arrived at by someone with severe OCD.  If I substantially rearrange an entire
drawing to group together related functional blocks for possible reduction into
PLDs, it's a mere matter of "formating".  If I happen to notice a missing ground
connection while I'm at it and correct the error, suddenly I'm "editing" instead.

No, I'm not going to buy into that one.

[nctnico]

Sorry, I understand the argument, but it's a hair-splitting distinction probably
arrived at by someone with severe OCD.  If I substantially rearrange an entire
drawing to group together related functional blocks for possible reduction into
PLDs, it's a mere matter of "formating".  If I happen to notice a missing ground
connection while I'm at it and correct the error, suddenly I'm "editing" instead.

Unfortunately, under the hood the CAD package will have to make that distinction in order for the functionality you proposed to work. But as a user you don't have to understand that. I'm outlining this as a possible implementation for a Kicad developer who might be reading along.

[james_s]

And my counterview is that giving no such options to shortcut common actions merely gets in the way of efficient workflows. Further, when workflows are already established which rely on such behaviour, entirely removing that behaviour only alienates existing users to the detriment of the project.

Sure, one can't ignore the "inertia" argument.

"Better the devil I know"

I don't find the KiCAD GUI to be particularly bad compared to other CAD packages, even those that are far more expensive. They're all pretty bad, but making them better is hard, and when you improve it for one person you risk making it worse for someone else.

[propellerhead]

Unfortunately, under the hood the CAD package will have to make that distinction in order for the functionality you proposed to work. But as a user you don't have to understand that. I'm outlining this as a possible implementation for a Kicad developer who might be reading along.

Oh - okay.  I can totally get that it might be a useful internal distinction, but as a user distinction it's pretty ridiculous.

[propellerhead]

I agree that kicad should have an inherent awareness of the netlist. but not for any of the reasons mentioned so far. My one real feature wish for kicad is to enable back propagation of changes to the netlist from PCB to schematic. i.e. back annotation or pin/gate swapping as some would say. I know not everyone thinks this is needed but its a feature I use all the time in Proteus with processor pins. When designing the symbol, I define groups of pins as swap-able. Then when laying out the PCB I can drag net lines from pin to pin to make the layout easier (it swaps the nets on the to and from pins). These changes back propagate to the schematic, but not by moving any wires. That would lead to the kind of schematic mess already described. Instead it swaps the pins on the schematic symbol. That way a neat schematic layout is maintained.

However I don't see how such a feature could work without the schematic having an intrinsic knowledge of the netlist. That would seem to be a necessary first step.

(I was just skimming back through these exchanges and noticed that nobody had acknowleged this post.)

You're 100% on the mark.  Meaningful backannotation from layout is another very important function
provided by having a meaningfully netlist-aware schematic.  Mentor doesn't put the gate-swap and
pin-swap data in the symbol itself; it's defined in what's called the "map" file, which is a text file that
contains the correlation between the symbol(s) and the package (layout geometry).  But I'm sure it
works the same way; in layout, if the swap rules in the map file permit it, you can swap pins or gates
to aid the layout, and when you exit layout you backannotate to the schematic.  When you open the
schematic, those backannotations (pin numbers, component designations) are highlighted in red so
you can check them over and make sure they look right before hitting the "merge annotations" button.

[craftyjon]

For the benefit of readers here who do not feel up to reading through the long thread on the KiCad forums that repeated this discussion:

Unbelievable as it may seem to at least one frustrated poster here, us KiCad developers *do* see this behavior as a feature, not a bug.

While we will continue to add features and refine KiCad's editing tools to make it faster and more capable (for example, by adding pin/gate swapping) in the future, we will not be changing to a model that requires explicit "connect" and "disconnect" actions to modify the netlist.  (Note that unlike the assumptions made by some in this thread, this does not mean that the schematic editor is unaware of the netlist -- it juts means that the netlist is not a separate "entity" that can be interacted with through explicit connect/disconnect actions).

I suggest that users who cannot approach KiCad's paradigm here with an open mind should probably just move on and use other CAD tools.  None of us will be offended!  There are a number of reasons why KiCad can't and won't be the perfect tool for everyone.  If there is enough demand for an open-source CAD tool that works more like Mentor Graphics, perhaps someone will create one.

[propellerhead]

Never say never.

[nctnico]

While we will continue to add features and refine KiCad's editing tools to make it faster and more capable (for example, by adding pin/gate swapping) in the future, we will not be changing to a model that requires explicit "connect" and "disconnect" actions to modify the netlist.  (Note that unlike the assumptions made by some in this thread, this does not mean that the schematic editor is unaware of the netlist -- it juts means that the netlist is not a separate "entity" that can be interacted with through explicit connect/disconnect actions).

This only shows that the Kicad developers don't understand the core of the problem -yet-. As I wrote before, it likely doesn't take much work to the underlying structures to add a realtime 'ERC' which safeguards the integrity of the schematic while formatting the schematic.

[james_s]

If there's one thing I wish they'd fix, it's the inability (as far as I've found) to create traces with square instead of round ends. I find this incredibly annoying when trying to connect a wide trace to a small pad, the rounded end of the trace overlaps the edge of the pad. It would be nice to be able to select different styles of transition when a trace changes width too.

[tooki]

If there's one thing I wish they'd fix, it's the inability (as far as I've found) to create traces with square instead of round ends. I find this incredibly annoying when trying to connect a wide trace to a small pad, the rounded end of the trace overlaps the edge of the pad. It would be nice to be able to select different styles of transition when a trace changes width too.

100% agreed.

This is also something that bugs me in Altium, which behaves identically to KiCad in this regard. On a recent project, a test board for testing our vector network analyzer, I had a number of (deliberate) transitions between different controlled-impedance trace geometries, and for some of them, I ended up drawing custom net tie components to create nice smooth transitions since you can’t configure trace geometry transitions parametrically.

[hpw]

This only shows that the Kicad developers don't understand the core of the problem -yet-. As I wrote before, it likely doesn't take much work to the underlying structures to add a realtime 'ERC' which safeguards the integrity of the schematic while formatting the schematic.

Did you post above request to the improvement list yet?

Hp

[2N3055]

For the benefit of readers here who do not feel up to reading through the long thread on the KiCad forums that repeated this discussion:

Unbelievable as it may seem to at least one frustrated poster here, us KiCad developers *do* see this behavior as a feature, not a bug.

While we will continue to add features and refine KiCad's editing tools to make it faster and more capable (for example, by adding pin/gate swapping) in the future, we will not be changing to a model that requires explicit "connect" and "disconnect" actions to modify the netlist.  (Note that unlike the assumptions made by some in this thread, this does not mean that the schematic editor is unaware of the netlist -- it juts means that the netlist is not a separate "entity" that can be interacted with through explicit connect/disconnect actions).

I suggest that users who cannot approach KiCad's paradigm here with an open mind should probably just move on and use other CAD tools.  None of us will be offended!  There are a number of reasons why KiCad can't and won't be the perfect tool for everyone.  If there is enough demand for an open-source CAD tool that works more like Mentor Graphics, perhaps someone will create one.

This is not summary but a single sided dismissal...

People point out things where Kicad is suboptimal, some with bad, some with good intentions. People also ask for stupid things.. People will be people, doing both smart and stupid.
It is up to the listener to sort it out. Value of many other people opinions is that it gives us opportunities to learn new things, that are beyond our current scope of vision.

As for netlist / schematic thing that person mentioned, discussion directly went to negative .
It is unnecessary. And immediately shifted discussion to semantics...

Schematic diagram tools are BOTH a vehicle to create information for PCB layout program about component interconnections (netlist) AND also to create human readable interconnect diagrams. And BOM and all other information needed for production process.
There is also very important issue (that programmers should be well aware of) of schematic/PCB maintenance/iterative development.
Many electronic devices are developed in incremental steps, where schematic is ripped partially and redrawn and things are added and subtracted. During process, you redraw and refine symbols and whole schematic. You move blocks around and rearrange them for better clarity..

Kicad does well with it's "drag" and "move" functions. Both are deliberate choice of user. "Drag" will drag the bungee cord wires and user will have to edit wire layout to make it nice and tidy again. But endpoints will stay connected to where I connected them. I don't have to verify all 100 pins CONNECTIONS from the scratch...
If I want to detach component and severe connections i do "move".. It works perfectly.

But If I do horizontal swap of component (mirror) , Kicad will happily DISCONNECT whatever I connected and than silently CONNECT any  pins to any wires that happen to align... Silently is key word here...
And I am deliberately not mentioning netlists here. Netlist IS internal thing. I'm talking that my schematic got scrambled without warning. Things are wrongly connected.

Eagle won't do that for instance... Altium OTOH will happily both keep old and add new connections on intersections, but online ERC will show a warning there are problems ....

What is best way to deal with it? That is going to be hard answer. Every man and his dog will have different solution..

But I would like at least some warning that something was disconnected and then reconnected in stupid manner. Maybe when you do that, wires get pulled back from previous connection point and marked with X as a unconnected endpoint. I personally think bungee cords are good solution. You rotate/ mirror and then it is a quick cleanup sorting wires to tidy them up.

Is this a deal breaker? No, it does not make Kicad unusable. Would Kicad be better by dealing with this  better? Sure, I think it would be great improvement...

[ebastler]

But If I do horizontal swap of component (mirror) , Kicad will happily DISCONNECT whatever I connected and than silently CONNECT any  pins to any wires that happen to align... Silently is key word here...

I agree with your post -- just one small addition: Kicad does also give you a choice to keep the connections intact when rotating or mirroring a component. Start draGging the component, and rotate or flip it while in draG mode. (Via the context menu or the X/Y/R shortcuts.)

Again, one can argue whether it is a good choice to make that a somewhat hidden option, while the default flip & rotate operations break or even change the connections.

[woody]

If there's one thing I wish they'd fix, it's the inability (as far as I've found) to create traces with square instead of round ends. I find this incredibly annoying when trying to connect a wide trace to a small pad, the rounded end of the trace overlaps the edge of the pad. It would be nice to be able to select different styles of transition when a trace changes width too.

Certainly. I go around that by creating small filled zones to connect a larger trace to a small pad but it would be very nice if that could get automated. BTW I often wonder why some pads/pins are SO darned small, while being specced to carry large currents.

[nctnico]

This only shows that the Kicad developers don't understand the core of the problem -yet-. As I wrote before, it likely doesn't take much work to the underlying structures to add a realtime 'ERC' which safeguards the integrity of the schematic while formatting the schematic.

Did you post above request to the improvement list yet?

No. But if you would be so kind to do that and point to this thread. Maybe it helps to create some understanding for how and why this realtime ERC feature is handy instead of outright dismissal. What 2N3055 wrote is precisely on point IMHO.

[craftyjon]

Yes, it's a dismissal -- of one specific idea/request, that KiCad should require explicit user action to "connect" or "disconnect" things in the netlist rather than retaining the ability to make connections by moving/placing objects.

There are many other ideas in this thread that are not really related to this specific idea (for example, realtime ERC) that I'm not dismissing.

This discussion (and previous ones) goes nowhere if people continue to assume that the KiCad developers just don't understand something -- the way KiCad works here is an intentional choice and we really do understand the alternatives that some other software tools use.  If you accept that, we welcome suggestions and feature requests that would improve KiCad within this paradigm.