Kicad - GUI is Horrific!

[nctnico]

No electrical engineer thinks in terms of "connectivity by moving things around".

But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.

IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:

- Dragging a component can result in creating new connections that may not be wanted. Especially true when dragging a larger piece of circuitry. Personally I have always found this a tricky & cumbersome operation in Orcad as you need to keep a really close eye on what is going on exactly.

- Changing a symbol where pins end up on other locations could go unnoticed as well. Especially when working on a design in a team.

All in all this thread suddenly has made me feel I have been kind of making do with Orcad (for several decades already!) which simply leaves a lot of schematic integrity checking tasks to the user. To be honest I never really gave this much thought until now.

I'm fully aware of those issues, and understood that.

That doesn't change the fact that in graphical schematic capture software, the graphical representation is how we convey our intent to the software.

The point is that some actions are not intentional and with some additional features, the software can be made smart enough to detect that and warn the user. This is exactly the reason why people use PCB design software with DRC to design PCBs instead of MS paint (to exaggerate a little bit).

[tooki]

No electrical engineer thinks in terms of "connectivity by moving things around".

But there has to be some way to tell the EDA software your intent. In a program with a GUI, moving things around and connecting them is a very established model for entering and editing your intent.

IMHO several peope brought up some good examples where moving/dragging things or changing symbols causes problems that may go unnoticed:

- Dragging a component can result in creating new connections that may not be wanted. Especially true when dragging a larger piece of circuitry. Personally I have always found this a tricky & cumbersome operation in Orcad as you need to keep a really close eye on what is going on exactly.

- Changing a symbol where pins end up on other locations could go unnoticed as well. Especially when working on a design in a team.

All in all this thread suddenly has made me feel I have been kind of making do with Orcad (for several decades already!) which simply leaves a lot of schematic integrity checking tasks to the user. To be honest I never really gave this much thought until now.

I'm fully aware of those issues, and understood that.

That doesn't change the fact that in graphical schematic capture software, the graphical representation is how we convey our intent to the software.

The point is that some actions are not intentional and with some additional features, the software can be made smart enough to detect that and warn the user. This is exactly the reason why people use PCB design software with DRC to design PCBs instead of MS paint (to exaggerate a little bit).

I obviously understand this. I understood it before your first reply. And before the second. At the latest, after reading my last reply to propellerhead above, it should be very clear that I understand the problem deeply.

But that wasn't the claim I was disputing. It was this:

No electrical engineer thinks in terms of "connectivity by moving things around".

I said that "moving things around" is how GUIs work, and it is.

I never said that a poor implementation can't cause mistakes, so I'm not sure where you got that idea, and then decided that you needed to repeatedly give a condescending, dumbed-down explanation of something I clearly already understood before you ever replied to me.

[nctnico]

Then why bother debating something we already agree on?  You keep on insisting something isn't what it is and then you suddenly agree. And it turns out your beef is not even with what I wrote.

[tooki]

I said EE, not graphical designers. When you are designing new "electronic contraption" you are compiling a set of components  (passive, active and parasitic) and their interconnections. Schematic is human friendly, graphical netlist+BOM. Nothing more. Everything else on schematic is organizational data, revisions, manufacturing data etc....
You don't draw a line between two little circles, you are connecting two connector endpoints with a wire. By drawing a line between two little circles. According to a predefined graphical language that was standardized by convention for that purpose.
Clean and clear "look" is certainly a large part of well done schematic layout. But, funny enough, it is not mandatory, and during years I've seen both exceptional and horrible ones. That both created exceptional PCB layout.

I understand this. But it kinda is part of the job to produce schematics that are easy to read for whoever else needs to work on it down the line (which includes yourself in the future!).

The fact that a poor schematic (of a good circuit) can produce a good PCB doesn't mean that it's not part of the job.


As for "not graphic designers" -- well, the only places where you see schematic diagrams drawn by graphic designers are in magazines and datasheets. Everywhere else (at least that I've seen), even in places with technical documentation teams, schematics come from the engineers.

You move things around to organize layout and functional groups. That is important, but connections between components are THE SCHEMATIC.

Well, the connections between components are the circuit. The schematic is simply a diagram of the circuit. That is to say, the connections/circuit are the actual concept, the design itself, while the schematic is a visual representation of that concept. The fact that the same circuit can be represented in any number of schematic layouts, or even completely different schematic types (e.g. the ones used in industrial automation).

Other stuff is only how it looks and consequently how nice is to read.

The latter of which is kinda important.

And many of these things newest versions of Kicad do very well. What is left open to "unpredictable results" is component mirroring and changes to component symbol after the fact. If you mirror pins left and right on symmetric layout component will scramble where inputs and outputs connect... Without warning... That is potential source of error... That would not exist if Kicad was remembering connection to pin which had coordinate , instead remembering connection to arbitrary coordinate in coordinate space that happen to coincide with coordinate of pin of a (whatever) component that happen to be on that position...

I know that, but I never said otherwise. I was disputing your blanket claims about how all engineers think.

[tooki]

Then why bother debating something we already agree on?  You keep on insisting something isn't what it is and then you suddenly agree. And it turns out your beef is not even with what I wrote.

My "beef" was with something someone else wrote, which is why I responded to them. I didn't write to you. You later chose to respond to me over your interpretation of something I hadn't actually said. I didn't "suddenly agree", you only think that because you thought I said things which I had, in fact, never said.

Bear in mind that I'm not assuming ill intent on your part. I simply think you may have gotten a bit confused about who originally said what, causing you to ascribe to me things actually said by someone else.

[2N3055]

I said EE, not graphical designers. When you are designing new "electronic contraption" you are compiling a set of components  (passive, active and parasitic) and their interconnections. Schematic is human friendly, graphical netlist+BOM. Nothing more. Everything else on schematic is organizational data, revisions, manufacturing data etc....
You don't draw a line between two little circles, you are connecting two connector endpoints with a wire. By drawing a line between two little circles. According to a predefined graphical language that was standardized by convention for that purpose.
Clean and clear "look" is certainly a large part of well done schematic layout. But, funny enough, it is not mandatory, and during years I've seen both exceptional and horrible ones. That both created exceptional PCB layout.

I understand this. But it kinda is part of the job to produce schematics that are easy to read for whoever else needs to work on it down the line (which includes yourself in the future!).

The fact that a poor schematic (of a good circuit) can produce a good PCB doesn't mean that it's not part of the job.


As for "not graphic designers" -- well, the only places where you see schematic diagrams drawn by graphic designers are in magazines and datasheets. Everywhere else (at least that I've seen), even in places with technical documentation teams, schematics come from the engineers.

You move things around to organize layout and functional groups. That is important, but connections between components are THE SCHEMATIC.

Well, the connections between components are the circuit. The schematic is simply a diagram of the circuit. That is to say, the connections/circuit are the actual concept, the design itself, while the schematic is a visual representation of that concept. The fact that the same circuit can be represented in any number of schematic layouts, or even completely different schematic types (e.g. the ones used in industrial automation).

Other stuff is only how it looks and consequently how nice is to read.

The latter of which is kinda important.

And many of these things newest versions of Kicad do very well. What is left open to "unpredictable results" is component mirroring and changes to component symbol after the fact. If you mirror pins left and right on symmetric layout component will scramble where inputs and outputs connect... Without warning... That is potential source of error... That would not exist if Kicad was remembering connection to pin which had coordinate , instead remembering connection to arbitrary coordinate in coordinate space that happen to coincide with coordinate of pin of a (whatever) component that happen to be on that position...

I know that, but I never said otherwise. I was disputing your blanket claims about how all engineers think.

Now you are semantically arguing fine points of English language. I'm not saying youre not technically correct, but I'm sorry my English is not that good.
To most of the people I know, saying schematic means schematic diagram, and that is a document that explain circuitry in device.. It has same functional meaning. You will hear people saying schematic and think circuitry in a device (as in:" we changed the schematic" meaning they changed the circuit ) and when meaning they changed the documentation they will explicitly say "schematic diagram"..

I will have to insist here.  ALL EE think in terms of circuits. When you are designing a circuit you are designing the circuit, not it's schematic representation and don't use idiosyncrasies that particular tools bring in design process.
 
While designing the process is not creating schematic file but the actual working circuit. Schematic is just a jolted down notes about it...

So when designing ALL EE think in terms of circuit (in physical sense) and all the idiosyncrasies of tool they use to document it is what they have to suffer on the way. So when drawing circuit the have to "translate" to CAD idiosyncrasies to write it down. Less translation needed, more intuitive and productive tool is.

What did ALL EE think about when designing circuits for years before CAD tools, with pencil and paper?.. You would jolt all kinds of crap on paper in whatever format it was simplest and most logical for you.. Schematic was mostly done later by draftsman based on engineers notes and sketches. Or in a small company or working alone, EE would do combination of notes, sketches and iteratively would eventually make a full schematic in presentable format...

Today all is the same logically. Only pencil and paper are replaced with computer and CAD. It is much easier to draw and edit, tidier, easier to do revisions...
But this is the circuit (schematic) you are designing:

and schematic diagram is only this:


Don't get confused by the fact that in CAD it seems that you are "designing" the second one because it all happens at once..

[propellerhead]

I'm not going to reply in my usual point-by-point manner to your extremely long, rambling, and probably stoned posting.

Instead, I'm going to present a single key example illustrating how little attention you've paid to what I've been saying:

One solution, which we know the KiCad team expressly does not want, is to have explicit connect/disconnect commands or modes. But my hunch is that you probably don't actually want that, either.

When what I wrote in my immediately-previous post was:

You have to be able to disconnect with the same ease and consistency of use as you had when you connected. 
Nothing hidden, nothing asymmetric.  A "connect" function and a "disconnect" function, both doing exactly that, and
retaining the awareness of what each means, which is actual connectivity vs. faux connectivity.

Seems I was pretty clear about the need for both connect and disconnect commands.  So instead of "hunching",
I recommend "reading".  Your entire reply is filled with similarly spurious writing based on a profound failure to
understand what I said.

To be absolutely clear about my terminology, many respondents who are very familiar with KiCAD have confirmed that
schematic capture has no internal representation of the netlist.  None.  Just a bag of coordinates that indicate where
things are, but not any relationships between them, such as "connection".  I have thus employed my own term "faux
connections" for those that appear be connections on the drawing, but really aren't because schematic capture does
not understand that concept - in other words, everything on a KiCAD schematic that you call a connection is in fact a
faux connection.  That's why, when you move a symbol, the wires do not remain connected and rubberband.  In order
to make that happen, KiCAD has a parlour trick called "drag" which - perversely - brings along all the wires that aren't
connected to it.

Where others here (and elsewhere) understand very clearly what I'm talking about, you've employed lengthy sophistry
of very poor quality to convince yourself otherwise.

[tooki]

Now you are semantically arguing fine points of English language. I'm not saying youre not technically correct, but I'm sorry my English is not that good.

Your English is very good!

To most of the people I know, saying schematic means schematic diagram, and that is a document that explain circuitry in device.. It has same functional meaning. You will hear people saying schematic and think circuitry in a device (as in:" we changed the schematic" meaning they changed the circuit ) and when meaning they changed the documentation they will explicitly say "schematic diagram"..

Oh, for sure, you hear them used somewhat interchangeably in everyday speech, but they are still distinct things, and since that distinction is at the core of this entire discussion I think it's important to keep it in mind!

I will have to insist here.  ALL EE think in terms of circuits. When you are designing a circuit you are designing the circuit, not it's schematic representation and don't use idiosyncrasies that particular tools bring in design process.
 
While designing the process is not creating schematic file but the actual working circuit. Schematic is just a jolted down notes about it...

So when designing ALL EE think in terms of circuit (in physical sense) and all the idiosyncrasies of tool they use to document it is what they have to suffer on the way. So when drawing circuit the have to "translate" to CAD idiosyncrasies to write it down. Less translation needed, more intuitive and productive tool is.

What did ALL EE think about when designing circuits for years before CAD tools, with pencil and paper?.. You would jolt all kinds of crap on paper in whatever format it was simplest and most logical for you.. Schematic was mostly done later by draftsman based on engineers notes and sketches. Or in a small company or working alone, EE would do combination of notes, sketches and iteratively would eventually make a full schematic in presentable format...

Today all is the same logically. Only pencil and paper are replaced with computer and CAD. It is much easier to draw and edit, tidier, easier to do revisions...
But this is the circuit (schematic) you are designing:

and schematic diagram is only this:


Don't get confused by the fact that in CAD it seems that you are "designing" the second one because it all happens at once..

I totally get that, that we are often doing both circuit design and schematic layout simultaneously. But not always, and this is why I think your blanket statement is wrong (that is, it is not ALWAYS true, even if it is true most of the time): sometimes, you're modifying schematics in ways that aren't really circuit design as such, but certainly aren't mere graphic design, either. For example, changing a pinout on a connector. It's absolutely part of the system engineering, but it's not reeeeeeallly conceptual circuit design as such. Imagine if the change is to a connector with more pins, and you need to insert a new signal somewhere in the middle, so you need to shift the existing ones over by a pin. That really is something where your thought process will be entirely on how to do it in your program, not on circuit design.

Same if you need to parallel something (perhaps a daisy chain connector, or an extra capacitor) or insert a jumper (to make a single-sided PCB, not a configuration jumper) or net tie.

Furthermore, I still don't entirely agree that the mechanical (the tool) and the conceptual are as thoroughly distinct as you think. Maybe they are for some people. But consider this: when you write text onto paper/screen, is the "sentence design" stage separate? Do you think a sentence in your mind and then write it down in a second step? Or do they happen simultaneously? Or are they one and the same thing? I think they actually become the same thing, at least for many people. I think that is probably why I find using dictation software so uncomfortable: I am not at all accustomed to having to compose a sentence in my mind, then speak it out. When I type, I am constantly pausing and revising as I type. There is no intermediate step. (I know for a fact that this is not how everyone writes. Some people do, in fact, compose entire sentences and then type them in.)

I don't know about you, but I can't really visualize a circuit in my mind; the written note is an integral part of how I think about it. Not everything is written down, but without the visual part, my brain struggles to know where to begin. Maybe that'll come with more experience. But I simply don't think you can discount or compartmentalize the visual aspect in the wholesale, absolutist way you do.

Finally, consider how fluidly we humans integrate tools into ourselves -- a good tool becomes invisible, like it's an extension of your body or mind. When you drive your car, you don't have to think "rotate steering wheel to turn right", you simply think "go right" and your body knows what to do. So I don't think it is a stretch to consider drawing a schematic to be distinct from circuit design: at least for me, operating the tool (be it Altium or a pencil and paper) are tightly integrated into the conceptual part. (I usually start with pencil and paper because it feels more transparent.)


So ultimately, I think the main problem I have with your position is simply that it doesn't offer any room for anyone to think or work differently from you. The way you describe it doesn't describe me, so it can't be a Boolean "true" blanket statement.


P.S. "Jolt" = shake. "Jot down" = write.

[ebastler]

(a) I fully understand the desire for a set of commands which manipulate the schematic while keeping all connections intact. KiCad has those: You can drag a part or a wire, including rotating and mirroring the part, and keep all connections in place.

Almost, except for the part about "keeping all connections intact".  My overarching point is that they
aren't actually "connections" - they just look like connections.  If they were real connections you
would not, for example, require a "drag" (which maintains the faux connections) vs. a "move",
which just lets things reveal their true nature and fall apart.

Thanks for replying! But I still don't get it. It seems to me that you are concerned with the internal data representation, not the user-facing functionality:

From a user's perspective, if I draw a wire which ends at a components pin or at another wire, I make a connection. Kicad knows about that connection, or automatically figures it out any time it needs to know about it. E.g. it lets me drag parts or wires around, including rotation and mirroring, without changing the connections.

(Kicad also lets me do other operations, like "moving" parts or flavors of rotation and mirroring which can make or break connections. You may consider that undesirable; but this is what I discuss in point (b) below. So regarding point (a), what is missing in Kicad, from a user's perspective?)

(b) I kind of understand the preference that commands which break connections should not be available at all, or should be well-hidden in a way where you do not use them unintentionally. Kicad does not do that by default, it makes the connection-breaking Move, Rotate etc. commands easily available. But that is a very superficial change which you can make on the user level: Just assign exotic hotkeys (or none at all) to these commands you don't want. And I see the developers' point that other users will have different workflows and styles and want to use these commands regularly.

No, you're imagining something complicated and useless.  You have to be able to disconnect with
the same ease and consistency of use as you had when you connected.  Nothing hidden, nothing
asymmetric.  A "connect" function and a "disconnect" function, both doing exactly that, and retaining
the awareness of what each means, which is actual connectivity vs. faux connectivity.

I was discussing the Move etc. operations which disconnect (or connect) something as a side effect -- assuming that these were at the core of your dissatisfaction with Kicad. In addition to these operations you can of course explicity disconnect a signal, by simply deleting a wire segment which connects it (to another wire or component pin). Totally symmetrical to the connection step (by drawing the wire). Not hidden in any way. Obvious and intuitive to me, since if there is a gap on screen, it is no longer connected.

Again, what is missing from a user's perspective? And what do you mean by "faux connectivity"? Maybe there is something "extra" in Kicad which some users may prefer not to use or even to disable, namely the Move etc. operations with side effects. But I can't see anything missing, and I can't see any fundamental architectural flaw.

(c) What I do not understand is your insistence that a "proper internal netlist" representation is the only path to happiness. That seems dogmatic. From a user perspective, why should I care how Kicad works internally -- as long as it offers (a), and for those so inclined enables (b)?

Internally to the software, I couldn't give a single shit in a million years how it's done - or what it's called. 
So there's no dogma to be found here, nor for that matter catmas or mousemas.  The schematic capture needs
to maintain some kind of internal database in order to keep track of valid connections, otherwise it has no
way of distinguishing the valid connections (the ones you made) from the faux connections and other errors it
needs to bring to your attention.

I don't follow the logic highlighted in bold typeface. It's certain operations (Move etc.) which can cause confusion, because they make or break connections -- which the user may want at the time, but which may also be an unwanted or unexpected side effect to them. Don't use those operations and you should be fine; and the existing data representation in Kicad should do what you need.

[2N3055]

Thank you for kind words and for teaching me...
My English is quite OK on some levels, but not being native speaker, it is hard to explain some things...
I think we pretty much agree in general and we started to go into much detail that I don't think is helpful to main topic...
I'm aware of research that languages shape how we think, and different tools change how we solve problems.
I'm not disputing that. I'm talking on more fundamental level.. And fact that tool should be shaped to us not us to tools...
Fact that human is extremely adaptable doesn't change the fact that if something is done right it doesn't need to...
Anyways, good talk.

[hpw]

Here some simple testings about the pitta.

Even LTSpice is in this regard miles better while strict .... while KiCad deals with no NETLIST 

1) Normal 2 resistors connected (BasePicture)

2) Shifted main and lines follow = OK (BasePictureShifted)

3) Mirror Horizontal.... whats on the connected lines ?? (BasePictureHorizontalMirrored)

4) Shifting the mirrored as  (BasePictureHorizontalMirroredShifted)

Or I am doing something false ??

Cheers

Hp
 

[tooki]

I'm not going to reply in my usual point-by-point manner to your extremely long, rambling

I think the words you're looking for are "thorough" and "detailed".

and probably stoned posting.

That's presumptuous. I actually don't do weed (or any other drugs), though I don't care if others do.

Instead, I'm going to present a single key example illustrating how little attention you've paid to what I've been saying:

One solution, which we know the KiCad team expressly does not want, is to have explicit connect/disconnect commands or modes. But my hunch is that you probably don't actually want that, either.

When what I wrote in my immediately-previous post was:

You have to be able to disconnect with the same ease and consistency of use as you had when you connected. 
Nothing hidden, nothing asymmetric.  A "connect" function and a "disconnect" function, both doing exactly that, and
retaining the awareness of what each means, which is actual connectivity vs. faux connectivity.

Seems I was pretty clear about the need for both connect and disconnect commands.  So instead of "hunching", I
recommend "reading".  Your entire reply is based on, and filled with, similarly spurious writing.

Oh, I read everything you wrote. That didn't escape me.

My point is that what you think you want and what you actually want need not be the same thing! (And this is in NO WAY a criticism, it's actually a really normal human thing!!!)

Ever heard of the XY problem? It's the extremely closely related issue of people seeking help with their solution to a problem (whether it is the correct approach or not), rather than asking for help with the problem.

I believe you're so fixated on your solution being the only possible solution that you're not actually listening to any discussion about the problem. (Note how you phrase it as a "need" for those commands, as if that's the only possible solution. It's not.)

Your entire reply is based on, and filled with, similarly spurious writing.

It would make sense if you actually climbed off your high horse and read it (like really read it to understand it, not just read it to retort).

Well, at least others who read it can appreciate my example of the thought process behind interaction design.

To be absolutely clear about my terminology, many respondents who are very familiar with KiCAD have confirmed that
schematic capture has no internal representation of the netlist. None.

So the KiCad representative in this thread is wrong?

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.

(To be aware of the netlist, it must also have some internal representation of it.)

Just a bag of coordinates that indicate where things are, but not any relationships between them, such as "connection".  I have thus employed my own term "faux
connections" for those that appear be connections on the drawing, but really aren't because schematic capture does not understand that concept - in other words, everything on a KiCAD schematic that you call a connection is in fact a faux connection.  That's why, when you move a symbol, the wires do not remain connected and rubberband.  In order to make that happen, KiCAD has a parlour trick called "drag" which - perversely - brings along all the wires that aren't connected to it.

If they're connected on the schematic, then they're connected in the netlist. That's as real as it gets.

"Parlour trick"... there's more of your condescending, dismissive language, and to boot, it's in a sentence that is absolutely incorrect.

Where others here (and elsewhere) understand very clearly what I'm talking about, you've employed lengthy sophistry
of very poor quality to convince yourself otherwise.

Umm, multiple different people have told you that you are unclear. The fact that multiple different people have used phrases to the effect of "I think you mean...", "I guess you mean...", etc. indicate that you are pervasively bad at articulating your thoughts. The fact that you think you're being clear does not mean you are actually being clear in your communication. It's not helped by your grotesque attitude. You think you're some goddamned prodigy who does no wrong, but you're actually just a conceited, rigid bully who doesn't even feign an attempt to really listen to what others have to say, even those who are trying to understand and help you. And then you lash out at anyone and everyone who doesn't lick your boots.

[propellerhead]

My point is that what you think you want and what you actually want need not be the same thing! (And this is in NO WAY a criticism, it's actually a really normal human thing!!!)

Honestly, if you stuck to the subject matter rather than playing amateur psychologist, we
might even get along.  In discussing these matters of schematic capture behaviour and UI,
we all draw from our own experiences and examples.  You'll read people talking about Eagle,
Altium, OrCAD, Proteus, and a lot of other suites past and present.  In my case it's Mentor,
which is the system I've been using since around 2000.

I have sound reasons for wanting to be able to use KiCAD (or another open-source suite, should
one emerge) if not in place of, then in addition to, Mentor.  No need to get into those reasons
here, I just tell you that in order to indicate that my desire for KiCAD to improve is genuine
and not a Quixotic crusade.  So when I describe the desired behaviour, though I'm describing
the steps one goes through in Mentor, I am not insisting that it's a standard that KiCAD
should conform to, but a clear example of the essential functionality - maintenance of the
netlist - that I and many others regard as a requirement for a credible schematic capture
package.  The fine details of the UI and the underlying implementation aren't particularly
important, as long as the overall concept is the same.  That's all.  Now, I'm just not going to
get into these long, drag-out, tedious, point-by-point arguments with you, because I've made
myself clearly understood to most of the other participants here.  So instead of wasting your
time on me, go find one of the others who agrees with me and pick a fight with him.

[propellerhead]

Thanks for replying! But I still don't get it. It seems to me that you are concerned with the internal data representation, not the user-facing functionality

No, absolutely not.  I'm unconcerned about how the required relationships are represented internally,
as long as they are represented internally in a manner that carries the required meaning.  But this is
intimately coupled to the UI as well - they have to work in concert.

If you'll permit my not answering your other questions for a moment, I'd like to try another tack (and yes,
I actually am a sailor!) to try to make this easier to understand.  I'm finding this difficult because the
necessary concepts should be really easy to grasp, but obviously there's something missing.  First,
allow me to ask whether you have experience with any other schematic capture packages, or whether
KiCAD is the extent of it.  Your answer may give me some context for moving ahead with an explanation
you might find easier to grasp.

[ebastler]

First, allow me to ask whether you have experience with any other schematic capture packages, or whether
KiCAD is the extent of it.  Your answer may give me some context for moving ahead with an explanation
you might find easier to grasp.

I have used Orcad and Eagle at some length.

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?

[tooki]

My point is that what you think you want and what you actually want need not be the same thing! (And this is in NO WAY a criticism, it's actually a really normal human thing!!!)

Honestly, if you stuck to the subject matter rather than playing amateur psychologist,

Not amateur: I used to work in usability professionally, and that included user observation, requirements engineering, interaction design, etc. At the absolute core of usability is human behavior. And one of the many, many human quirks is that what people think they want is often not really the scratch for their itch. If you give them what they say they want without digging deeper, you can end up investing in a solution that doesn’t actually solve their problem. That’s frustrating for everyone.

I just tell you that in order to indicate that my desire for KiCAD to improve is genuine and not a Quixotic crusade.

I absolutely believe that. Despite the obnoxious way you go about communicating it, it is very evident that you do care and that it’s coming from a place of positive intent, of a sincere desire to improve the software.

So when I describe the desired behaviour, though I'm describing
the steps one goes through in Mentor, I am not insisting that it's a standard that KiCAD
should conform to, but a clear example of the essential functionality - maintenance of the
netlist - that I and many others regard as a requirement for a credible schematic capture
package.  The fine details of the UI and the underlying implementation aren't particularly
important, as long as the overall concept is the same.  That's all.

Well, therein lies the rub: As you absolutely correctly mentioned to ebastler in the next post, the internal representation is closely coupled to the UI, and they have to work in concert.

As a former usability professional, I firmly believe that the internal model needs to reflect the needs of the UI, not the other way around. (The very best UIs are built atop foundations that were built for them. In particular, GUIs that are retrofitted onto existing, originally text-based systems really struggle with usability, because the software architecture just isn’t laid out properly for the type of interactivity in a GUI.) The worst thing — and we’ve all seen software like this — is where the internal model “leaks out” in the user interface, requiring the user to make strange accommodations for the software’s internal data structures and architecture. That’s the tail wagging the dog. (As a total aside, the “tail wagging the dog” mentality is one of the reasons I left IT entirely: dumb IT managers whose self-serving IT departments force IT decisions on users, undermining rather than serving users’ needs.)

And that’s why I think it’s so important to work out a lot of the details in a UI before working on the underlying software architecture, whether it’s a blank slate, or a reworking of an existing one. And as such, rather than cloning what another program does — whose design includes features and limitations from its entire evolution — it can be really smart to let go of existing expectations of how it needs to work, and instead take a totally fresh look at the problem and brainstorm solutions. Sometimes, the brainstorming ends up producing the same solution as before, which can be a sign that it already was the optimal solution. But sometimes you end up with a totally novel solution that is way, way better — one you never would have come up with by just borrowing prior art.

But to do this, you have to let go of the conceit that you already know the One True Solution. Your wording throughout your participation in this thread has continuously used wording that just oozes overconfidence and/or disdain: “essential” functionality (apparently not, since many EDA programs don’t do it), “parlour trick”, “reveal their true nature and fall apart”, etc.

It could be that there’s a better design that works better than either the current KiCad model or the Mentor model. But you can only figure that out if you give others and yourself the space to explore the interface design. And to do that, you have to dial your ego back a bit and be open to digging deeper into the problem. When people challenge you for more information or clarification, it’s not because they’re attacking you, it’s because they want to get to the root of the problem. You’ve been quite resistant to that, however.

[propellerhead]

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?

[propellerhead]

But to do this, you have to let go of the conceit that you already know the One True Solution. Your wording throughout your participation in this thread has continuously used wording that just oozes overconfidence and/or disdain: “essential” functionality (apparently not, since many EDA programs don’t do it), “parlour trick”, “reveal their true nature and fall apart”, etc.

It could be that there’s a better design that works better than either the current KiCad model or the Mentor model. But you can only figure that out if you give others and yourself the space to explore the interface design. And to do that, you have to dial your ego back a bit and be open to digging deeper into the problem. When people challenge you for more information or clarification, it’s not because they’re attacking you, it’s because they want to get to the root of the problem. You’ve been quite resistant to that, however.

Okay, replying to this posting will be a lot more tolerable than those prior in which you quoted six-deep.  Do you really expect
people to parse all that noise?  And I really, once again, could do without the extraneous personality (defect) analysis.  You may
have heard the phrase "Sure, he's an asshole.  But he's our asshole."  That's my friends describing me, and in case you're
finding it hard to parse, it means that as much of a pain in the ass as I am, I'm right more often than not and overall worth
putting up with.  Now, can we set all that peripheral shit aside and focus?

I've made repeatedly clear that the interaction model I'm citing is simply the example I'm most familiar with that offers an
effective contrast to KiCAD's failure to do its job.  I didn't write it, and I'm not here to champion Mentor as the One True Path
or anything else.  But it does illustrate what's required of the job. If you don't agree, why aren't you suggesting a similarly
functional alternative rather than arguing here to little or no positive outcome with those who essentially agree with me?  Do
what you're telling me I should be doing rather than just pointing out what an asshole I am for failing to do it.

[tooki]

Okay, replying to this posting will be a lot more tolerable than those prior in which you quoted six-deep.

How magnanimous of you… 🙄

Do you really expect people to parse all that noise?

1. It’s not noise, it’s detailed analysis. Detail takes time and space.
2. Yes, someone who actually cares about the outcome would read it.

Some of your replies, like the one above to ebastler, are just as long and detailed (and rightly so). The only reason you’re attacking me for the length of my posts is because they don’t say anything you want to hear.

And I really, once again, could do without the extraneous personality (defect) analysis.

It’ll stop when you decide to focus only on the content and stop with the jabs and insults and condescension to me and everyone else. But I doubt you will, since you’ve been exuding that arrogance from every pore literally from the very post you ever made on these forums.

You mayhave heard the phrase "Sure, he's an asshole.  But he's our asshole."  That's my friends describing me, and in case you're finding it hard to parse, it means that as much of a pain in the ass as I am, I'm right more often than not and overall worth putting up with.

English is my native language, I have no trouble parsing your sentences when they are cogent, like in this reply.

Anyhow, your friends must be infinitely more patient and forgiving than I am (and than you are!!), or are gluttons for punishment, or you bring something enormously valuable to the table. But based on your interactions here, I am disinclined to believe that you are right as often as you think you are. Actually being right a high percentage of the time requires being open to new information, and that is most decidedly not something you are.

I've made repeatedly clear that the interaction model I'm citing is simply the example I'm most familiar with that offers an
effective contrast to KiCAD's failure to do its job.  I didn't write it, and I'm not here to champion Mentor as the One True Path
or anything else.  But it does illustrate what's required of the job. If you don't agree, why aren't you suggesting a similarly functional alternative rather than arguing here to little or no positive outcome with those who essentially agree with me?  Do what you're telling me I should be doing rather than just pointing out what an asshole I am for failing to do it.

I did. It’s in that “lengthy sophistry of very poor quality” that you dismissed without actually reading it, or if you did read it, that you casually dismissed because it wasn’t the same solution you envision. I don’t know which, since you declined to comment on it other than the snide

I'm not going to reply in my usual point-by-point manner to your extremely long, rambling, and probably stoned posting.

[propellerhead]

(A whole bunch more stuff that's all about propellerhead rather than the actual subject matter.)

So, because I'm here to discuss KiCAD's schematic capture, and not me, I'm really done with you now.

[tooki]

(A whole bunch more stuff that's all about propellerhead rather than the actual subject matter.)

So, because I'm here to discuss KiCAD's schematic capture, and not me, I'm really done with you now.

’twas your decision to attack me instead of replying to the on-topic discussion I posted earlier. You could have chosen to engage with the content and maybe say “oh, sorry for being unclear, I simply meant this…” You chose to ignore the content and attack me instead, so that’s on you, dude.

[hpw]

Here some simple testings about the pitta.

Even LTSpice is in this regard miles better while strict .... while KiCad deals with no NETLIST 

1) Normal 2 resistors connected (BasePicture)

2) Shifted main and lines follow = OK (BasePictureShifted)

3) Mirror Horizontal.... whats on the connected lines ?? (BasePictureHorizontalMirrored)

4) Shifting the mirrored as  (BasePictureHorizontalMirroredShifted)

The behavior or automatic snapping is on Schema & PCB, while the underlying logic do not deal with the NETLIST at all.
In other words, the object connections would produce the NETLIST as on Export procedure.

The only solution so far in case of rotating / mirroring circuits is, at first, to disconnect/delete ALL related connections to the involved circuit.

Currently there is no simple solution on rotating / mirroring nor any blocking(s) on that action, if a circuit has any connection(s).

Hopefully, there are no any other issue(s) as on rotating / mirroring. Or please provide information(s).

Hp


 

[PlainName]

The only solution so far in case of rotating / mirroring circuits is, at first, to disconnect/delete ALL related connections to the involved circuit.

I don't often remake symbols mid-design in the schematic^[1], but where I do that kind of change on the PCB I do tend to disconnect any tracks before the operation. I far prefer a blank space into which I will re-route the tracking than the mess of rubber-banded connections that's just a, well, mess. I think for the schematic, in the example where a pin is moved, I'd just naturally check afterwards that things are as they are meant to be.

---
1. Thinking back, mid-design symbol changes seem to fall into two camps: small ones (like in the discussion) which I make before connecting stuff because they're tend to be obvious, and big ones where the symbol will be split into two or more smaller parts (or vice verse). In the latter it's just simpler to vape the connections and do them all again.

[ebastler]

The only solution so far in case of rotating / mirroring circuits is, at first, to disconnect/delete ALL related connections to the involved circuit.

Currently there is no simple solution on rotating / mirroring nor any blocking(s) on that action, if a circuit has any connection(s).

You do not really state what you want to achieve. But assuming that you want to mirror or rotate a component which already has connections:

Select the component, enter drag mode (G), then mirror (X/Y) or rotate (R) to taste. Kicad does not seem to support the new "orthogonal" dragging of connections for mirror and rotate operations (why not?!), but it does leave all connections intact, using diagonal lines to show them.

To my knowledge, editing a symbol mid-flight is the only operation where Kicad does not offer any option to do this without changing the schematic connections as a side effect. Since symbol editing is done by a different application, it happens "under the radar" from Eeschema's perspective, and Eeschema cannot keep track of the connections. Hence in this specific case propellerhead's statement seems to be correct that Eeschema would need a different data structure to stay on top of things.

[hpw]

The only solution so far in case of rotating / mirroring circuits is, at first, to disconnect/delete ALL related connections to the involved circuit.

Currently there is no simple solution on rotating / mirroring nor any blocking(s) on that action, if a circuit has any connection(s).

You do not really state what you want to achieve. But assuming that you want to mirror or rotate a component which already has connections:

Select the component, enter drag mode (G), then mirror (X/Y) or rotate (R) to taste. Kicad does not seem to support the new "orthogonal" dragging of connections for mirror and rotate operations (why not?!), but it does leave all connections intact, using diagonal lines to show them.

To my knowledge, editing a symbol mid-flight is the only operation where Kicad does not offer any option to do this without changing the schematic connections as a side effect. Since symbol editing is done by a different application, it happens "under the radar" from Eeschema's perspective, and Eeschema cannot keep track of the connections. Hence in this specific case propellerhead's statement seems to be correct that Eeschema would need a different data structure to stay on top of things.

Did the simple test again...

Actions: G hit, mirror, than shifting .. see attached

it gets as this as already posted while after the mirror action the snapping gets into account what results in a mess!!

Hp