I would find it helpful if you could describe which behaviour (or lack of a certain behaviour) in Kicad you find problematic, from the perspective of a user who considers Kicad a black box. Beyond the "undesirable" operations which mess with the connections (Move and its relatives), what is causing you problems? And why would it require different internal data structures to fix these problems, rather than just making these problematic operations unavailable to you?
Do this simple test: Put an inverter (1/6 of a 7404) down on your schematic. Add a wire from above and to the left
to the inverter's input. Now add another wire from the output of the inverter to above and to the right of the symbol.
Now open the symbol editor and swap the two pins (input and output) on the symbol you just used. When you exit
the symbol editor and return to the schematic, it will look just as it did before you edited the symbol, and your schematic
is now wrong,
because the wires did not maintain connectivity to the pins to which you connected them and your
inverter is now backwards in the circuit, because the input and output definitions are attached to the pins, not the triangle
or circle or where they are on the symbol.
What happens when you wire to a pin in KiCAD is that you are telling it that you want the wire to end at the same
coordinate in space as the pin occupies. But - and this is the key - schematic capture does
not make the wire
and the pin part of the same electrical node; that is, they are not in the same net. Yet they have the
appearance of
being connected. This is what I call a faux connection. Others here argue that this is not the case, but they're hair-
splitting and triangulating their answers and playing with language. Regardless of their protests or what we call these
things, the schematic capture front end you're interacting with is not aware that the connections you (thought you)
were making have any meaning. If they did, when you swapped the two symbol pins as I described above, the wires
would have rubberbanded, with the one on the left following the input pin over to the right side, and the one on the
right that you connected to the output now stretched to the left side. This is the simplest case I can offer to illustrate
what is wrong.
Certainly, after you're done drawing your schematic, at some point the software will generate the netlist to be passed
to packaging and ultimately to layout. But because schematic capture isn't creating that netlist in real time as you
draw, it's unable to stop you from making mistakes that you would not be able to make if the netlist were real.
Here's something else to try. Put down a symbol that has a bunch of pins. Now start a line outside of the symbol
and stretch it across (or along the side of) the symbol so that it passes over a few pins before you end the wire on
the other side of the part.
Do not click on the pins as you pass over them. When you're done, you will have
a wire that
appears to connect to the pins it crosses - again, faux connections, because they look like they're
connected - but by not clicking on them to inform schematic capture that you want those pins to be part of this net,
they won't
really, intentionally be connected to them. Or, to my point, when you postprocess the drawing KiCAD
will happily join them all together in your layout, when a
responsible schematic editor would instead recognize
that since you didn't click on them, you probably don't want them to be connected, so it doesn't connect them and
instead flags them as warnings. (
KiCAD - The Irresponsible Schematic Editor! I should see if I can trademark that.)
My argument is for schematic capture that is absolutely unambiguous and does not permit faux connections without
flagging them as errors. This is the simplest thing in the world to do: Connecting a wire to a pin requires the explicit
act of clicking on that pin during the course of drawing the wire, and that act creates an entry in the netlist (or whatever
the
hell else anyone wants to call it) that says "these two entities are now part of the same electrical node (or net)
and they are not to be separated or merged with another entity (wire, pin, or net) without explicit direction from the
user." There are no accidental connections such as those that occur when elements of the schematic are moved and
things happen to cross other things - those crossings are warning flagged rather than ignored with the possible outcome
that they get merged later by a postprocessing netlisting that doesn't know any better. Similarly, if you want to disconnect
something previously connected, it requires a specific "disconnect" operation - you have to delete the line segment that
you previously connected to the pin (or to another segment) or highlight (select) the pin and tell it to disconnect. In
other words, the schematic capture front end is as aware as it can possibly be what your connectivity intentions are,
because you told it at every step what you wanted those connections to be - and anything that doesn't
look like it is in
keeping with what you want is error-flagged. No faux connections.
And this is why real schematic capture doesn't need both a move and a drag: Because it knows which wires are really
electrically connected to which pins, it doesn't permit faux connections, which look like they're connections but don't act
like they are. So you move the symbol and the wires rubberband with it because moving a symbol does not in any way
imply disconnection, and it knows which wires stick to which pins because you told it so. I'm about to speculate, of
course, because I wasn't there and I haven't examined the commit logs, but drag has the strong appearance of a hack
that was added because move didn't bring the "connected" wires along because they aren't really connected because
there's no netlist to respect. So instead of correcting the underlying deficiency...
The way KiCAD does it is an abrogation of the "A" in CAD and in EDA. According to what we've been told, "we aren't
going to do that because that's not our paradigm", which fails to explain what their "paradigm"
is. This is where we run
into dogma: They refuse to do it without explaining why their approach is
in any way as good as or better than a model
that does real-time error-checking for you and thus reduces both the time you have to spend doing it yourself or fixing the
mistakes later that should have been caught/prevented in schematic capture.
Does that help?