Kicad - GUI is Horrific!

[propellerhead]

Well. KiCAD recently gained the ability to rubberband wires on dragging symbols, but it's a far cry from what you describe. It will create a tangled mess of lines when you "overdo" it. Hence I tend to not "wire up" my schematics, but I use net labels mostly to connect, well, nets by their name instead of using an actually visible wire. Rearranging my schematic is then just moving the symbols with their connected net labels. Some say it creates schematics that are easier to read. But this may just be an excuse

I can assure you that I'm not among that "Some".  That has its place, but I keep seeing it done where its use isn't
really justified and could be avoided by just thinking the drawing's layout through a little further.  I really won't do it
unless I'm carrying signals to another sheet.  And I've seen it done to such a ridiculous extreme that what should have
been a coherent schematic really had no lines at all; it was a thick binder of 11x17 sheets, each of which had maybe
a dozen gates on it, with the net names on every input and output.  It was perfectly accurate, perfectly unreadable
and perfectly uninformative.

Regarding the stroke UI, I can totally see the advantage of gestures instead of chasing a menu, and I can picture how it would work far better with a tablet and stylus instead of a mouse. Indeed it might be really fast, when it's ingrained in your brain after a couple years. But is there really a clear advantage over well chosen keyboard shortcuts to common functions? Apart from the obvious advantage of freeing up one hand for holding a coffee mug.

I've never had any issues with doing it via mouse, and I was never a tablet user, so that case doesn't mean much
to me.  Maybe it would work, maybe even be good, but I'm not sure where the three mouse buttons' functions would
come from.  The keyboard shortcut thing is a little different problem.  I've been a fast touch typist longer than I've
been laying out boards, and I don't much like having one hand on the keyboard and the other not.  What I'm often
using my non-mouse hand for is keeping track of something on a schematic or prototype or something to the side
as I work.  This is really YMMV territory.

The existence of a superior UI doesn't make all other UIs horrible, tough.

No, but it should make all others envious and the horrible ones obvious, right?

And, for a project that effectively has two full-time paid developers and a 5 figure budget, I think they're doing
great. I'd guess even the first prototype for Mentor Graphics stroke UI was more expensive than KiCads entire yearly
budget.

You know, it'd probably be a lot cheaper and faster (read: a good volunteer chunk) than you think.  The strokes are
all defined in a 3x3 grid, so as soon as the middle button is depressed you follow the pointer in the matrix and go:
Let's see... 3-2-1-4-7-8-9 is a "C" (It's probably simpler than that, like skipping the 1 and 7 corners - I'd have to check,
but you get the idea).  "Move" is 7-4-1-5-9.  There are only a couple of dozen of them, so it's not really complicated.

Funny story, though... I just learned a couple of months ago that one of Mentor's founders is the first cousin
(as in: mom's brother's son) of one of the guys who brought me into the business in the 70s and is still a dear friend.
Crazy.  So if we really wanted to know what it cost them to implement it, I could probably ask.

[thinkfat]

Well. KiCAD recently gained the ability to rubberband wires on dragging symbols, but it's a far cry from what you describe. It will create a tangled mess of lines when you "overdo" it. Hence I tend to not "wire up" my schematics, but I use net labels mostly to connect, well, nets by their name instead of using an actually visible wire. Rearranging my schematic is then just moving the symbols with their connected net labels. Some say it creates schematics that are easier to read. But this may just be an excuse

I can assure you that I'm not among that "Some".  That has its place, but I keep seeing it done where its use isn't
really justified and could be avoided by just thinking the drawing's layout through a little further.  I really won't do it
unless I'm carrying signals to another sheet.  And I've seen it done to such a ridiculous extreme that what should have
been a coherent schematic really had no lines at all; it was a thick binder of 11x17 sheets, each of which had maybe
a dozen gates on it, with the net names on every input and output.  It was perfectly accurate, perfectly unreadable
and perfectly uninformative.

Oh yeah, totally with you there. I've seen that a lot especially in KiCad "tutorial" videos on YT. It's totally atrocious. The way I tend to do it is wire up only functional groups and then use net labels to connect them to the rest of the circuit. For example, a switching regulator is one functional group and is drawn with wires, but it is not connected to the rest with wires. So I don't draw a supply "bus" and then connect all the other groups to it. A reset circuit may be one functional group, a reverse voltage / overvoltage crowbar may be another one. But I rarely put those small groups on separate sheets, because it's too disruptive during schematic review.

[baldurn]

I am causal KiCAD user. I get that there is some non optimal issues when updating a symbol already used in your schematic. What I do not get is the extreme violent reaction to such a simple thing? Obviously we are many that manage to use the tool anyway.

When evaluating if I need to ditch KiCAD for a commercial alternative, it is really not the small things like that. It is the big things like Altium being totally unaffordable and the company appears to behave badly too.

Is KiCAD a good enough tool not is KiCAD perfect. We know it has flaws. The issue being discussed here I would put under "quirks" and not something that will stop my use of the tool. I hope it gets fixed. Until then I will just remember that I need to fix my schematic after updating a symbol - not that big a deal?

[5U4GB]

Where it comes to the GUI: in my experience every piece of software that does a somewhat complex task, has a horrible GUI that simply needs time to learn.

All GUIs suck, but some do suck a lot more than others.

Years ago a friend of mine worked at an IT vendor that sold, among other things, Photoshop.  Occasionally someone would come in and ask "why should I pay $$$ for Photoshop when GIMP is free?".  His response was always the same "go and play with GIMP for a bit, then come back here when you're ready to buy Photoshop".

I at least partly suspect that GIMP was secretly created by Adobe's marketing department.

[Doctorandus_P]

I am causal KiCAD user....

Is KiCAD a good enough tool not is KiCAD perfect.

KiCad is certainly "good enough" for "casual users", and quite complicated PCB's can be made with it. For some Ideas have a look at https://www.kicad.org/made-with-kicad/ I switched to KiCad myself some 7+ years ago, when I switched from windoze to Linux. Back then I evaluated some 5+ different PCB design programs and KiCad was the clear winner. But I do confess I have a warm place in my heart for Open Source programs. Back then KiCad had some quite serious flaws, for example the library management was so buggy that it did not work at all and you had to manual copy & paste in between text files, but those days are long gone. KiCad has become quite mature in the last few years, and development is also accelerating. This also has a downside, as quite a lot of bugs are introduced, but in general they get fixed fixed quickly. I have seen quite a lot of small bugs that had less than an hour between reporting them on gitlab, and the issue getting closed with a "fix committed". Each month between 200 and 300 issues are both reported on gitlab and closed too, so the total of open issues stays roughly the same. There are also some things that take years to fix, and there are also still some quirks that have not been fixed even after years, but as KiCad development progresses the remaining quirks get less important and fewer. I think I've gotten used to most of them and avoid them subconsciously.

As an Open Source program, KiCad's development is also a bit chaotic. KiCad's developers are free to work on any feature they have a particular interest in, but there are a lot of people working on KiCad. Some like to fix GUI things, others like to implement some new feature, and yet others (or the same) fix bugs. And this does explain why some quirks and missing features take a long time to get fixed or get implemented. As an Open Source program, KiCad has no artificial limitations. No limits on pin count or board size, It does not get slowed down "extra" to encourage people upgrading to a "more expensive" version. You just get an unlimited free trial period, and you can donate whatever you see fit and when it suits you. (Maybe after having finished some pcb project for a paying customer?) Or of course "give back" by working on the source code, documentation, libraries, answering forum questions, website, etc.

And there is also the personality of individuals. I liked KiCad from the first day I used it, and I never quite understood why others did not like the GUI of KiCad. My best guess is that different people learn in different ways and have different preferred workflows. And my kind of workflow fit's quite nicely with KiCad.

[propellerhead]

I don't want to come off sounding as though I have fundamental problems with the open source development
model, but with the passage of time it's become quite clear that it has not fulfilled one of its basic promises,
which is the assurance of high quality thanks to a large number skilled participants constantly vetting and
improving the code.  Nice theory, seldom practiced, because projects that allow any idiot (or not) to commit,
combined with everyone just working in their little pet corner results in a world of chaos.  The most successful
projects I've seen operate under the "benevolent dictatorship" model, run by proven, hardcore pros who set
the rules, control the commits, and aren't there to hand out participation trophies.  In these cases, a higher
proportion of brilliant work accrues because QC standards are maintained and well-intentioned-but-less-than-
competent volunteers' feelings are not given standing.

In this case, the discussion I've been pursuing is subtly OT in that realtime netlist observance is very closely
coupled to, but not actually a feature of, the GUI.  It's core functionality that, if not taken seriously (as I've
argued), compromises and diminishes schematic capture ease of use and reliability and pushes the burden
of both avoiding and detecting errors back to the user.  This is a foundational failure.  If one chooses not to
recognize that the "A" in "CAD" stands for "Assist(ance)", or in "EDA" for "Automation", and in a knee-jerk,
cult-victim defense of the software because it's open-source rather than on the actual merits of the
case, attempts to argue that this very basic function should be exempted because... because... because...
"that's just how we've always done it here", then better to exit the conversation rather than fight for inferior
tools that make you do more work finding the errors it never should have allowed in the first place.

Is it "good enough"?  Obviously, for many people, yes.  But then again, if you're chained to a car axle in a
dump, eating weeds, garbage, and the odd rat and drinking your urine might be "good enough" to keep
you alive.  So can be eating a few of your friends if your plane crashes in the Andes.  The question you
should ask is whether this version of "good enough" is a good enough standard to hold this or any other
project to.

Look, I don't get into these bunfights because I have some weird personality defect that craves conflict,
a perverse need to lord superior knowledge over others, etc.  This entire conversation comes from a
sincere desire to see KiCAD improve to the point at which I think it's "good enough".  I love Mentor, and
there isn't anything I can't do with it.  But I would like to be able to work on a system that weighs
less than 50 kilos - without having to suffer windoze!  At present, though, that's just not possible because
whomever made the early decisions around schematic capture and the netlist appears to have lacked
some really necessary experience in the field of EDA and made very poor choices.  The emperor has no
clothes; you can now choose what you see.

[edit]

Actually, there is another motivation to want to be able to use KiCAD (if not actually to switch completely),
and that's modernization and collaboration, mainly the latter.  I'm perfectly aware that one of the downsides
to running Mentor is that it's expensive big-project software that most individuals, hobbyists, indie designers,
contractors, etc., will never have access to - or need.  A lot of my friends are those people, need good, cheap
tools, and I'd like to be able to share work on projects, for which this stands to be ideal... if only it can get
"good enough".

[propellerhead]

I am causal KiCAD user. I get that there is some non optimal issues when updating a symbol already used in your schematic. What I do not get is the extreme violent reaction to such a simple thing? Obviously we are many that manage to use the tool anyway.
...
Is KiCAD a good enough tool not is KiCAD perfect. We know it has flaws. The issue being discussed here I would put under "quirks" and not something that will stop my use of the tool. I hope it gets fixed. Until then I will just remember that I need to fix my schematic after updating a symbol - not that big a deal?

Wow - you've really missed the point here, haven't you?  The problem with symbol editing is not what
this conversation is about.  It's where it started - the rock that, when flipped over, exposed a cavern of rot.
It's not the disease, just a symptom.

You need to go back, read, and absorb, the thread from its restart a few days ago.  This is about KiCAD
schematic capture's absolute ignorance of the netlist, and resulting failure to maintain and enforce it.

And do yourself a favour and stop listening to children who think a strongly-worded argument somehow constitutes
"violence".  An "extreme violent reaction" to the problems I perceive with KiCAD would be to find one of the developers
and stick a knife in his neck.  Do you understand the difference?  One is a conversation, the other is physical assault.
We're having a little chat over coffee, not rocketing someone's fucking apartment in Kiev.  Can I offer you some more
contrasting examples to clarify for you the proper use of the language, or are you now ready to get a grip?

[thinkfat]

I don't want to come off sounding as though I have fundamental problems with the open source development
model, but with the passage of time it's become quite clear that it has not fulfilled one of its basic promises,
which is the assurance of high quality thanks to a large number skilled participants constantly vetting and
improving the code.

I don't see this "promise" broken. The definition of quality is a difficult thing, and everybody who has a different opinion on that should read Robert M. Pirsigs' "Zen and the Art of Motorcycle Maintenance". Subjectively, you're hunting for a certain functionality and declare "rot" because your expectation is not fulfilled. When actually, KiCad is in fact constantly improving, becoming more and more useful with every release.

Is it "good enough"?  Obviously, for many people, yes.  But then again, if you're chained to a car axle in a
dump, eating weeds, garbage, and the odd rat and drinking your urine might be "good enough" to keep
you alive.

[...]

Look, I don't get into these bunfights because I have some weird personality defect that craves conflict,
a perverse need to lord superior knowledge over others, etc.  This entire conversation comes from a
sincere desire to see KiCAD improve to the point at which I think it's "good enough".  I love Mentor, and
there isn't anything I can't do with it.  But I would like to be able to work on a system that weighs
less than 50 kilos - without having to suffer windoze!  At present, though, that's just not possible because
whomever made the early decisions around schematic capture and the netlist appears to have lacked
some really necessary experience in the field of EDA and made very poor choices.  The emperor has no
clothes; you can now choose what you see.

Your personality might not crave conflict, but there's a definite trait of "you need to do this and that and how I say or everything you achieve is just lipstick on a pig", which is not going well with people doing the actual work :-)

[PlainName]

... realtime netlist observance is very closely coupled to, but not actually a feature of, the GUI.  It's core functionality that, if not taken seriously (as I've argued), compromises and diminishes schematic capture ease of use and reliability and pushes the burden of both avoiding and detecting errors back to the user.

The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.

[nctnico]

... realtime netlist observance is very closely coupled to, but not actually a feature of, the GUI.  It's core functionality that, if not taken seriously (as I've argued), compromises and diminishes schematic capture ease of use and reliability and pushes the burden of both avoiding and detecting errors back to the user.

The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.

The behaviour in Orcad capture (and I suspect Altium as well) is that every connection receives a unique netlist name which get updated when several connections are joined together in a schematic. During post-processing the nets get optimised & cleaned up depending on whether sheets are re-used or not (like the linking process when compiling a C program). This behaviour makes it possible to browse nets in a design and navigate to them from an overview of all the nets in a schematic (for example). This is useful to work efficiently on bigger designs but from the remarks of some it seems Kicad isn't doing this (yet).

When evaluating if I need to ditch KiCAD for a commercial alternative, it is really not the small things like that. It is the big things like Altium being totally unaffordable and the company appears to behave badly too.

Last time I checked Orcad is pretty affordable and you can choose the modules you need so you don't pay for what you don't need (although I highly recommend getting the CIS option for database driven component management).

[baldurn]

Wow - you've really missed the point here, haven't you? 

Sorry but this is a violent reaction - attacking anyone who disagree with you. Admittedly you did not quite manage to kill me yet with just words 

The problem with symbol editing is not what
this conversation is about.  It's where it started - the rock that, when flipped over, exposed a cavern of rot.
It's not the disease, just a symptom.

I have a degree in computer science. If I had to only use software, which according to my education can be declared "sound", I might not be able to use a computer at all.

The thing is you have a perceived idea of what the underlying data structures should be. Without actually checking how said data structures actually are implemented and why. From what I can tell, you are just doing a guessing game here. I suspect the issue is a lot more complicated.

Checking the text content of a random schematic file, I notice that everything has a UUID assigned. Yes it appears the wire end points are identified by the coordinates instead of the UUID. But switching that around would be a trivial change of the file format. Generating the netlist from this file is actually trivial.

But this is completely irrelevant for me as a user of the program. If I wanted to contribute to the program I might care but not as a user. You are naive if you believe the internal data structures of your favorite closed source program is perfect according to some standard for perfectness. You might even be shocked to discover your favorite closed source program doing the exact same thing internally - how would you know?

[SiliconWizard]

In the end it all comes down to habits, but KiCad's GUI has become reasonable.
If you want to try something with a *really* horrible GUI, try FreeCAD.

[propellerhead]

The thing is you have a perceived idea of what the underlying data structures should be. Without actually checking how said data structures actually are implemented and why. From what I can tell, you are just doing a guessing game here. I suspect the issue is a lot more complicated.

Checking the text content of a random schematic file, I notice that everything has a UUID assigned. Yes it appears the wire end points are identified by the coordinates instead of the UUID. But switching that around would be a trivial change of the file format. Generating the netlist from this file is actually trivial.

But this is completely irrelevant for me as a user of the program. If I wanted to contribute to the program I might care but not as a user. You are naive if you believe the internal data structures of your favorite closed source program is perfect according to some standard for perfectness. You might even be shocked to discover your favorite closed source program doing the exact same thing internally - how would you know?

In order:  Wrong, wrong, and wrong.  And they are so because you still evidently haven't actually read and
understood the thread, choosing instead the "skim and guess" approach.  I couldn't give a rat's ass what
the "underlying data structures" are.  Generating a netlist from a data file is completely contrary to what's
required, and your last comment doesn't even address a question.

I've described a functional, behavioural model, nothing more, and how it's implemented couldn't be of
less concern.  You just seem not to understand my explanation at all, nor the comments of those who do,
whether they agree with me or not.  Sleep it off and try again tomorrow.

[propellerhead]

The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.

No, you're getting lost in the explanation.  The entire netlisting part that I've described isn't, and shouldn't be,
the user's business.  It's something schematic capture does without your participation - it's just part of the
process.  You go about your business and the schematic UI creates, maintains, and enforces - in real time - the
netlist which, yes, will be needed later, but in the here and now keeps you from inserting errors into your own
work.

What rational person argues against that premise?

[nctnico]

The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.

No, you're getting lost in the explanation.  The entire netlisting part that I've described isn't, and shouldn't be,
the user's business.  It's something schematic capture does without your participation - it's just part of the
process.  You go about your business and the schematic UI creates, maintains, and enforces - in real time - the
netlist which, yes, will be needed later, but in the here and now keeps you from inserting errors into your own
work.

I'm guessing you are referring to realtime ERC. For this to work you'd need to have symbols with input, output, bidirectional and power pins properly specified. In reality this gets in the way quickly. What if you want to filter the power supply using an RC filter or ferrite bead? All of the sudden you are connecting a generic net to a power pin.

Same for input / output / bidirectional pins. What about programmable logic or a microcontroller that can feely defined inputs / outputs? You'd need to create a symbol for your specific project that caters to the actual use. And you'd need to be able to setup exceptions as well (like when connecting 2 power nets together to form a single supply). For a really huge project (thousands of parts / tens of thousands of nets) where an error can be costly, this may make sense but you'd typically use a higher end package (beyond Altium, like Orcad) to work on such a project anyway.

[propellerhead]

I don't see this "promise" broken. The definition of quality is a difficult thing, and everybody who has a different opinion on that should read Robert M. Pirsigs' "Zen and the Art of Motorcycle Maintenance". Subjectively, you're hunting for a certain functionality and declare "rot" because your expectation is not fulfilled.

Oh, I wish you hadn't gone there.  I read that pop junk as a teenager shortly after it came out, rejected it as
the edge-of-new-age woo-woo that it is, and opted for a life of engineering instead that wasn't informed by
Jonathan Livingston Seagull or Carlos Castaneda or whatever other silliness occupied the bestseller charts at
the time.  I talk about stuff like that over Sunday coffee with old university pals who took the arts+philosophy
route, and as I did at the time and have in the decades since, continue to gently mock them for ever having
taken it seriously, and over time most of them have gradually swung over to my side and acknowledged that
it really was a complete waste of time.

But that stuff was harmless, and the world's become in many ways too serious to tolerate that kind of mushy
thinking - that's essentially why the US political scene is the giant smoking trash fire that it is.  As a society
they allowed themselves to be steered, by sinister forces, into believing that objective truth does not exist
and that "alternative facts" is a valid notion.  Take that step, and the next thing you know half of your electorate
believes in goddamn Qanon.

So, contrary to your claim, I'm out on the ramparts fighting for objective truth, which includes "This is superior
to that, and if you think otherwise and lack evidence, experience, and a sound and compelling argument, it is
not a mere 'matter of opinion'.  You are a cult victim."

Ultimately the choice is yours.  As we say, "Your gun, your foot."

[propellerhead]

I'm guessing you are referring to realtime ERC.

Nope.  My recommendation would be to go back and actually read what I wrote rather than guessing.

[nctnico]

I'm guessing you are referring to realtime ERC.

Nope.  My recommendation would be to go back and actually read what I wrote rather than guessing.

No. Please rephrase your wall of texts / rants into 2 or 3 (at most) short sentences for everyone to understand the exact problem definition you are trying to convey.

[propellerhead]

Please rephrase your wall of texts / rants into 2 or 3 (at most) short sentences for everyone to understand the exact problem definition you are trying to convey.

"Wall of Rants" - I like it, except for the Phil Spector comparison it suggests/invites;
he was always a psychopath who made near-totally-shit music.

You will find what you seek in reply #173, a page back.  If you can't be bothered to
make a nominal effort to get up to speed, I'm really not going to repeat myself again.

[PlainName]

The impression I am getting is that you suggest the GUI should be reflecting the netlist. That is, you make the netlist and the schematic is a visual indication of that. But I can't see how that works well - you have to create the netlist in the first place, and the schematic is how you do that, so it's a kind of chicken and egg thing. I am failing to see why dicking around with a diagrammer and then metaphorically clicking a button to say, "There, that's how I want to connect stuff", is terrible. Surely that's where you start.

No, you're getting lost in the explanation.  The entire netlisting part that I've described isn't, and shouldn't be,
the user's business.  It's something schematic capture does without your participation - it's just part of the
process.  You go about your business and the schematic UI creates, maintains, and enforces - in real time - the
netlist which, yes, will be needed later, but in the here and now keeps you from inserting errors into your own
work.

If you don't understand what it is trying to do then you'll be either fighting it all the time or trying different things out because that worked, once, last week.

In response to the realtime ERC thing that nctnico brings up, you referred to:

Once you've generated that net, you can't mess it up by accident.  If you, say, move a resistor pin onto an existing
net, it gets an error flag until you either explicitly connect or separate them.

But my post above, which you quote, is asking how essentially how it decides you've 'metaphorically clicked a button' and the design is as you want it, or you're still working on it. It's quite common to be modifying the design as you go along (that's why we do it all in CAD rather than scribbling it on a fag packet before drawing it up so it's Right First Time). Often I will insert a resistor or remove it or have hanging nets because, well, it's being designed innit. I don't mind a little red icon pointing out some unfinished business (but tend to ignore them anyway because, well, it's being designed and I know it's not finished). But if I had to manually ack every such case I'd be rooting away in settings to find the relevant tickbox to untick.

So it's not clear to me at all what benefit (other than the one nctnico spelled out about overview maps) being hassled to ack something every time I make a change brings.

And, while we're here, I really hate the Kicad GUI. In fact, that's the major reason I am not making things with it. But I hate gesture-based interfaces just as much because you can end up commanding something unintentionally. And even intentionally, you can command the wrong thing. Just to keep this on topic

[propellerhead]

If you don't understand what it is trying to do then you'll be either fighting it all the time or trying different things out because that worked, once, last week.

I can't even begin to imagine where you got that from.  You connect things and they're connected.
You don't and they aren't.  If they aren't but look like they are (such as might happen with a move or a
symbol edit) they get flagged so you can correct them and make sure they aren't errors in the making.
I absolutely cannot comprehend how you get a recipe for confusion and conflict out of a few simple rules
like that.

But my post above, which you quote, is asking how essentially how it decides you've 'metaphorically
clicked a button'

Work with me here and avoid speaking in metaphors.  What does that mean?  You're clicking a button or you aren't.

and the design is as you want it, or you're still working on it. It's quite common to be modifying the design as you go along (that's why we do it all in CAD rather than scribbling it on a fag packet before drawing it up so it's Right First Time). Often I will insert a resistor or remove it or have hanging nets because, well, it's being designed innit. I don't mind a little red icon pointing out some unfinished business (but tend to ignore them anyway because, well, it's being designed and I know it's not finished). But if I had to manually ack every such case I'd be rooting away in settings to find the relevant tickbox to untick.

So it's not clear to me at all what benefit (other than the one nctnico spelled out about overview maps) being hassled to ack something every time I make a change brings.

I certainly didn't mean to imply that the UI was going to freeze up on you and refuse to let you do anything
else until you clear the error/warning - you're entitled to leave as many of those warning dots in place as you
wish while going about other business.  I mean, nobody expects the Spanish Inquisition here.  Clean 'em up
now, or clean 'em up later.  You do you.

And, while we're here, I really hate the Kicad GUI. In fact, that's the major reason I am not making things with it. But I hate gesture-based interfaces just as much because you can end up commanding something unintentionally. And even intentionally, you can command the wrong thing. Just to keep this on topic

Agreed.  The irony here is that my personal opinion being that everything that isn't strokes pretty much
sucks goat ass isn't actually affecting my choice not to use KiCAD (yet) - that choice is entirely due to
the netlist-ignorance problem.  In my limited experience I found it confusing and inconsistent, in part
because when I thought I was making connections they didn't behave as though they were... which
turned out to be correct.  And in general terms, drop-down menus taller than my screen is high, commands
that seem to half-overlap other commands, and hot-key lists longer than I think it reasonable to memorize
say to me "it looks like people just keep adding shit" rather than "this is governed by a thought-out UI
philosophy".  But honestly, I could live with a lot of that if only I could trust what I see on the screen.

Wrt strokes, I'd be interested in hearing more about your experience and why you don't like them.  Sure,
I muff strokes when I get going too fast and the gestures get a little too sloppy, but you can always escape
a function before it does anything you don't want, and if you don't, there's an undo queue - you just back
up as many steps as necessary with the Undo stroke.  Hardly happens, though, I more often just find myself
selecting the wrong things because the select filter maintains state and want to move a symbol or text when
I last moved traces and vias and left it set for those.

[fourfathom]

"Wall of Rants" - I like it, except for the Phil Spector comparison it suggests/invites;
he was always a psychopath who made near-totally-shit music.

Is this an example of the "objective reality" we should all be striving for?

[fourfathom]

[...] that choice is entirely due to
the netlist-ignorance problem.  In my limited experience I found it confusing and inconsistent, in part
because when I thought I was making connections they didn't behave as though they were... which
turned out to be correct.

In the 50 or so designs I've done with KiCad (some simple, some not) I have have not seen this "netlist ignorance problem".  I create the schematic, then do the layout.  The layout rats next shows the netlist connections, and there's never been any confusion there.  I run the layout DRC tool and it tells me if the layout matches the schematic.  I don't change the layout connections and then back-annotate the schematic (which might be a useful thing for me to try), I always work from the schematic.  So where do you see the netlist ignorance problem?

[PlainName]

If you don't understand what it is trying to do then you'll be either fighting it all the time or trying different things out because that worked, once, last week.

I can't even begin to imagine where you got that from.  You connect things and they're connected.
You don't and they aren't.  If they aren't but look like they are (such as might happen with a move or a
symbol edit) they get flagged so you can correct them and make sure they aren't errors in the making.
I absolutely cannot comprehend how you get a recipe for confusion and conflict out of a few simple rules
like that.

How do you square that with:

The irony here is that my personal opinion being that everything that isn't strokes pretty much
sucks goat ass isn't actually affecting my choice not to use KiCAD (yet) - that choice is entirely due to
the netlist-ignorance problem.  In my limited experience I found it confusing and inconsistent, in part
because when I thought I was making connections they didn't behave as though they were... which
turned out to be correct.

You're saying earlier that you shouldn't be trying to understand under the bonnet, so whether the netlist is there or not shouldn't be an issue for you in the schematic editor. So long as wrong things get flagged, you should be happy.

Wrt strokes, I'd be interested in hearing more about your experience and why you don't like them.  Sure,
I muff strokes when I get going too fast and the gestures get a little too sloppy, but you can always escape
a function before it does anything you don't want, and if you don't, there's an undo queue - you just back
up as many steps as necessary with the Undo stroke.

I want stuff to do what I think I'm telling it to, not back up a few steps every so often. A keyboard is good because there is no mistake of the intent - you press the B key and the system knows you meant 'B'. It's not going to turn into a T, because.

Strokes are sloppy, imprecise and multi-action. A trivial example: swiping up and down on a phone is about as simple and natural as you can get, but now and then I find the phone interpreting the swipe as a press-drag, and what was underneath is now over here rather than there. Doing that stuff with a mouse is worse, because a mouse isn't any good at drawing lines (which is what you do with a gesture. The only way to make it reasonable is to have a big gesture, but then you're just waving the mouse pointer all over the screen. Right-click context is just so much more civilised and less tiring, plus you don't have to navigate your pointer back to where you were at the start.

Apart from that, it's probably OK.

[propellerhead]

I won't own a tracking device (what you call a "cell phone") for many reasons, only one of which is the awful UI.

If you haven't used Mentor, you're only speculating on how it implements and reacts to strokes, which, as I indicated
above, are very limited in number and well-defined.  It works well.