Kicad - GUI is Horrific!

[propellerhead]

One of us must be missing something. What exactly do you mean with the schematic capture not joining pins and wires and adding that information to the netlist? KiCAD quite obviously "knows" in the schematic editor, that wires are nets and what they connect to, and it becomes abundantly obvious as soon as you hit the ERC button.

Schematic capture evidently knows nothing and enforces nothing.  Tell me:  If you lay down
a symbol, then "connect" (air bunnies because it isn't an actual connection, it just plays one
on your screen) wires to it, what happens if you then pick up that symbol - just the symbol -
and move it somewhere else on the drawing?  Do the connections follow along, rubberbanding
the wires to the pins?

Regarding the GUI, beauty is in the eye of the beholder. I can find no (major) fault with KiCads way of interacting with me, but that may just be my personal bias (or lack thereof). As far as "steal is better than invent", I'm sure glad the developers didn't copy from "Eagle".

Of course, a "good" GUI is a matter of personal preference, and often not what's actually
superior in any sense, rather what you've gotten used to.  Turns out, though, that people
are capable of becoming quite accustomed to a lot of really terrible stuff - don't make me
make a list to prove it.  But (in my admittedly very limited experience) KiCAD's simply
hasn't been thought out at all.  I had a hard time detecting any consistency in the schematic
capture, and when I opened a pulldown menu and was presented a ~30 item list, all I
could think was "This is cancerous - it looks like it just keeps growing and growing and it
isn't occurring to anyone that it's ridiculous and needs to be - at least - pared down, and
probably rethought.

I'm going to tip my hand here.  I'm running Mentor Graphics V8, which, it seems, will have
to be pried from my cold, dead hands.  Mentor comes with a lot of complexity and a huge
learning curve.  But there is real innovation, real genius in their UI.  They based it around
something called "strokes", which is a set of mouse gestures - you hold down the middle
button and draw a little pattern on the screen, and it activates a function.  For example,
if you want to move something, you open the "select filter" with a left-then-down stroke,
the filter box pops up, and choose what it is you want to act on - a symbol, vertex, text,
whatever.  A left-to-right "swipe" stroke dismisses the select filter.  Select the symbol
(or whatever) by clicking on it.  The "move" stroke is up-then-down-to-the-right, which
picks up whatever you're moving - and all the connections to the symbol rubberband
with it.  The "C" stroke copies whatever you've selected.  The "U" stroke unselects
whatever you selected.  And if you can't remember a stroke?  Do a "?" stroke and the
strokes help box pops up.  Diagonal strokes zoom you in or out.  Do you get a sense of
what I mean?  In this example I didn't have to grind through 30-entry drop-down lists or
touch the keyboard, and it's fast as hell.  Sure, there are a few operations that involve
the keyboard, such as if you want to flip or rotate as part of a move, but they are few
and not used often.

And if you can actually visualize it, play these operations for your mind's eye, you'll
immediately grasp that at no time do your eyes deviate from the area of focus - the
part of the schematic or layout that you're actually working on - so your brain doesn't
have to do a context switch finding the needed function in a huge menu or the key
you need on the keyboard before returning to the work and trying to recover your
context.  Not only fast as hell, but less mentally exhausting.  This is what's meant
by "a good UI".

I'm telling you, the hardest part of my day is stepping away from that big old HP-UX
machine and going back to my desk to do "normal" windoze or penguix stuff, and trying
to swipe a spreadsheet to close it because it's just become that instinctive.  And spare
me "oh, they just stole that from Apple", because this version of Mentor predates IOS
by a decade and it was probably part of earlier versions too, and we all know that Jobs
was the biggest idea thief in the history of computing.

Why would anyone put out greasy kid stuff if they can steal from the best?  Even if
Mentor patented this UI, the patents have expired, so what are the KiCAD developers
waiting for?  Oh - I know... they're waiting for someone to sit them down in front of a
real EDA system so they can grow up and stop impressing themselves with how
they compare to Eagle.

[fourfathom]

Tell me:  If you lay down
a symbol, then "connect" (air bunnies because it isn't an actual connection, it just plays one
on your screen) wires to it, what happens if you then pick up that symbol - just the symbol -
and move it somewhere else on the drawing?  Do the connections follow along, rubberbanding
the wires to the pins?

Yes, with KiCad the connections rubberband, maintaining 90-degree angles if you like.    Air bunnies not involved.  When have you last tried it?

[propellerhead]

Yes, with KiCad the connections rubberband, maintaining 90-degree angles if you like.    Air bunnies not involved.  When have you last tried it?

What was the most recent major release?  7?  It was either that or a late 6.

Oh, it's coming back to me... Aren't there different ways to move things that behave
completely differently - a "move" vs. a "drag" or similar?  I think I was (stupidly, it
would appear) using move and you're describing a drag.  How obvious.  Does the
phrase "feeping creaturism" mean anything to you?  This is what happens when you
have a perfectly democratic, egalitarian project:  Nobody takes responsibility for QC
and saying "wait, that's an obscure, idiotic, and confusing sort-of-duplication of
functions, so one of them has to go."

But let's assume the wires come along, whichever it is.  Edit the wired-up symbol and
swap two pins.  When you return to the schematic, do the wires stay where they were,
now connected to the wrong pins, or do they rubberband/reroute to the correct pins'
new locations?

[ebastler]

Schematic capture evidently knows nothing and enforces nothing.  Tell me:  If you lay down
a symbol, then "connect" (air bunnies because it isn't an actual connection, it just plays one
on your screen) wires to it, what happens if you then pick up that symbol - just the symbol -
and move it somewhere else on the drawing?  Do the connections follow along, rubberbanding
the wires to the pins?

The command you want is G(rab), not M(ove). Voilà, rubberbanding. Voicing strong opinions does not work so well if not backed by solid knowledge...

In any case you are jumping to conclusions. Yes, in some situations KiCad does not automatically re-route the connections (namely if you change a footprint and move its pins around while it is already in your schematic). But how does that lead you to the conclusion that it does not "know" about the connections? KiCad knows about them; it lets you break them; it then knows they have been broken (and will tell you so if you do an ERC).

You may wish for a feature that lets you move footprint pins mid-flight, I can see how that might be useful at times. (I can also see how it might create a mess at times.) But jumping from there to a "KiCad's architecture is fundamentally flawed" is fundamentally flawed...

[propellerhead]

The command you want is G(rab), not M(ove). Voilà, rubberbanding.

Oh, of course.  My apologies - I couldn't remember whether it was M(ove), D(rag), G(rab),
B(eg), C(oax), C(ajole), P(lead), or W(ish).  Thank you for the meaningful clarification.

Voicing strong opinions does not work so well if not backed by solid knowledge...

I'm really not the guy you want to attempt that tack with.  If something isn't worth knowing,
it isn't worth knowing well.  It's not necessary for me to read the entire bible and be able to quote
chapter and verse to qualify my views as an atheist.  So please stick to the subject matter at hand
and avoid trying to launch a bigger discussion.

In any case you are jumping to conclusions. Yes, in some situations KiCad does not automatically re-route the connections (namely if you change a footprint and move its pins around while it is already in your schematic). But how does that lead you to the conclusion that it does not "know" about the connections? KiCad knows about them; it lets you break them; it then knows they have been broken (and will tell you so if you do an ERC).

You just answered your own question.  You make connections, then modify the symbol, and when
you return to the schematic it has not only failed to rubberband the connections, but it hasn't
flagged the connections as errors!  What about that isn't clear?  If the schematic netlist meant
anything, KiCAD, would do something to show that there's been a change that has now
violated the netlist!  But it doesn't do a damn thing, just lets it slide.  I'd love to hear which other
EDA packages you have extensive experience with that makes this behaviour look in any way
acceptable.  But it "will tell you so if you do an ERC"?  WTF?  If it knows, why the hell
shouldn't it just tell me, without my having to ask?  The reality is that there is no netlist
within schematic capture!  That was painfully confirmed in the course of the long argument in
the KiCAD forum that I referred to earlier, so please don't try to pretend there is.

You may wish for a feature that lets you move footprint pins mid-flight, I can see how that might be useful at times. (I can also see how it might create a mess at times.)

I don't have to wish for a damn thing. I already have a system that doesn't allow me to make
those kind of mistakes without making it very clear where they are - WITHOUT my asking.

And I honestly don't know what the hell "mid-flight" means.  Sounds to me like you're
just making stuff up.

But jumping from there to a "KiCad's architecture is fundamentally flawed" is fundamentally flawed...

I'm sorry, I thought you were about to tell me about your extensive experience in the field.
You've worked with how many "Free as long as your board isn't more than 9 square inches
or a hundred traces" packages in addition to KiCAD?

[JohanH]

Does the
phrase "feeping creaturism" mean anything to you?  This is what happens when you
have a perfectly democratic, egalitarian project:  Nobody takes responsibility for QC
and saying "wait, that's an obscure, idiotic, and confusing sort-of-duplication of
functions, so one of them has to go."

Someone always has to come from nowhere, jumping into some open source project, with their strong voiced opionion of how wrong it does things.

Just another day on the Internet.

 

[propellerhead]

Dude, if you actually have an opinion on the subject at hand, and not just the tired old
"oh, another boring critic" rap, then by all means offer it.  But you said nothing at all.

[JohanH]

Kicad has actually pretty good documentation, so instead of whining, read up a little and then if some feature still bothers you, change to another product or actually get involved and do a feature request. Or instead of that attitude, actually ask nicely, and someone could bother to answer. Sorry, if I'm being an ass today.

[Monkeh]

And here we see the sort of person who doesn't think a bolt can be turned without a Snap-On wrench.

You already have a tool which works exactly the way you want, and you cannot conceive of a tool not working in that manner. That's great, stick with it.

[propellerhead]

Kicad has actually pretty good documentation, so instead of whining, read up a little and then if some feature still bothers you, change to another product or actually get involved and do a feature request. Or instead of that attitude, actually ask nicely, and someone could bother to answer. Sorry, if I'm being an ass today.

• The quality of the documentation is immaterial if the product being documented is defective.
• I made clear above that this has nothing to do with "whining".  I'm providing a public service,
  which I hope will help other serious EDA users avoid wasting their time learning what I just have.
• I suggest you get up to speed with the conversation before diving in with strong opinions.  I've
  already indicated that this is the point at which I abandoned the KiCAD experiment and returned to
  grown-up tools.
• You apparently don't get that this is a structural problem, and not a "feature" to be "requested"
• If you aren't an ass today (or any other day), you'll find you don't have to apologize for it.

[propellerhead]

And here we see the sort of person who doesn't think a bolt can be turned without a Snap-On wrench.

That's a fun comparison, as I'm a mechanic in addition to an EE (and over the last 45 years
the only needlenose pliers and flush cutters I've used are Snap-On), and I jam econo - I use
the best tools I can afford - why would anyone do otherwise?

But your comment is really just an ad hominem attack that fails to address the issue
being discussed.

[ebastler]

Dear propellerhead, you got Mentor Graphics, you got an attitude problem -- is there anything else you need? Not from me, I reckon. Bye.

[propellerhead]

Dear propellerhead, you got Mentor Graphics, you got an attitude problem -- is there anything else you need? Not from me, I reckon. Bye.

Oh, no!  Please don't leave before answering the questions I asked you in my previous reply!

The ones about why anyone should settle for behaviour designed to help you make errors and then
fail to take any proactive steps to let you know you made them?

[Monkeh]

But your comment is really just an ad hominem attack

Oh - I know... they're waiting for someone to sit them down in front of a
real EDA system so they can grow up and stop impressing themselves with how
they compare to Eagle.

 

Your uh, 'good' gesture driven UI, by the way, would be entirely unusable to me.

[propellerhead]

Your uh, 'good' gesture driven UI, by the way, would be entirely unusable to me.

I'm genuinely interested in learning why.  Is it a physical limitation, or something else?

[JohanH]

I'm providing a public service,

Well, you are not doing it in the right way nor in the right place.

• If you aren't an ass today (or any other day), you'll find you don't have to apologize for it.

I wish I was such a saint, but apparently there are somebody out there with the ability, saving our face. Thanks!

[Monkeh]

Your uh, 'good' gesture driven UI, by the way, would be entirely unusable to me.

I'm genuinely interested in learning why.  Is it a physical limitation, or something else?

Spatial dysgraphia. Or at least symptoms generally in line with such. I can type at speed, I can spell perfectly well, my fine motor control ranges from microsoldering to long range shooting, but ask me to draw you the letter 'a' and you'll get something you'd expect from a three year old. Gestures are torture.

[propellerhead]

Spatial dysgraphia. Or at least symptoms generally in line with such. I can type at speed, I can spell perfectly well, my fine motor control ranges from microsoldering to long range shooting, but ask me to draw you the letter 'a' and you'll get something you'd expect from a three year old. Gestures are torture.

That's really interesting.  I don't envy you at all, but it's certainly interesting.  So are you
able to successfully navigate EDA like this because you're picking items from a list, have
orthogonal routing enabled on a coarse snap grid, etc., - operations that don't require
accurate and unconstrained motions in space?  Do you substitute a lot of keyboard
operations for stuff usually done by mouse?  If so, maybe the issue would be the tolerable
level of complexity of the gestures - or is it so severe that controlling the orientation of a
straight line is really hard?

Aside:  The whole strokes conversation is really where I got interested in KiCAD - whether
it might be something they'd be interested in implementing as an option.  But I didn't
pursue it because of the bigger problems that most seem to think unimportant (but not
all, I hasten to add - there were a few folks in the previous conversation whose experience
was more extensive than mine and recognized the gravity of this flaw).

[jaromir]

Just for reference, this topic has been discussed here, too https://forum.kicad.info/t/symbol-editing-and-the-netlist/39271 in similar style and with similar intent.

[Monkeh]

Spatial dysgraphia. Or at least symptoms generally in line with such. I can type at speed, I can spell perfectly well, my fine motor control ranges from microsoldering to long range shooting, but ask me to draw you the letter 'a' and you'll get something you'd expect from a three year old. Gestures are torture.

That's really interesting.  I don't envy you at all, but it's certainly interesting.  So are you
able to successfully navigate EDA like this because you're picking items from a list, have
orthogonal routing enabled on a coarse snap grid, etc., - operations that don't require
accurate and unconstrained motions in space?  Do you substitute a lot of keyboard
operations for stuff usually done by mouse?  If so, maybe the issue would be the tolerable
level of complexity of the gestures - or is it so severe that getting the orientation of a
straight line is really hard?

Dysgraphia is not as simple as not being able to move a mouse or a pen accurately, I can draw a straight line, place my cursor at any point I wish with fair precision, but the drawing of a shape is a very different process. I want to say it's like talking vs singing, but being that I don't sing that might be an awful comparison.

I do indeed use keyboard shortcuts where most people trawl through menus because they don't remember the shortcuts. That's just familiarity, and unrelated to difficulties with drawing.

[propellerhead]

Just for reference, this topic has been discussed here, too https://forum.kicad.info/t/symbol-editing-and-the-netlist/39271 in similar style and with similar intent.

If you think this is your "big reveal", note that I referred to it in my initial post here.

[SiliconWizard]

The reality is that there is no netlist
within schematic capture!  That was painfully confirmed in the course of the long argument in
the KiCAD forum that I referred to earlier, so please don't try to pretend there is.

That's one point I agree with. The schematic editor has no notion of netlists and is a purely graphical tool. It generates the netlist as a post-processing step, only relying on proximity of objects.
I also think that is a flawed approach. But to be fair, a number of other schematic editors in other EDA do the exact same thing. Granted, not all.
Even Eagle definitely stores the netlist along with the schematic itself - that can be seen in the XML schematic files.

The schematic editor has seen less overhaul than the layout editor in general in KiCad. Handling true connections between objects would certainly be a nice plus.
I don't know how hard that would be to implement in the existing editor.

[PlainName]

I don't know how hard that would be to implement in the existing editor.

Bear in mind I haven't the faintest idea

Looking at the referred-to thread in the Kicad forum the example shown is where a pin is moved from the bottom of a device to the top, and the wire that was (supposedly) connected to it is left hanging. But, it shows that the wire has the correct net name, and the device has the pin named as such. Surely it wouldn't be that difficult to think, "Hmmm, this wire is on the net for that pin, when not just plonk it on top?"

Of course, there would be unintended consequences - do you really want wires auto-joining whenever you plonk something down? Perhaps there could be some distance-related magnet on a pin (which might solve the queries we see of wires not joining to pins because both aren't on the same dot of a stupidly small grid).

However, if the wire has the right net and the pin isn't connected to that net, wouldn't that cause an ERC error? If so, surely that's the problem solved.

[propellerhead]

Looking at the referred-to thread in the Kicad forum the example shown is where a pin is moved from the bottom of a device to the top, and the wire that was (supposedly) connected to it is left hanging. But, it shows that the wire has the correct net name, and the device has the pin named as such. Surely it wouldn't be that difficult to think, "Hmmm, this wire is on the net for that pin, when not just plonk it on top?"

Of course, there would be unintended consequences - do you really want wires auto-joining whenever you plonk something down? Perhaps there could be some distance-related magnet on a pin (which might solve the queries we see of wires not joining to pins because both aren't on the same dot of a stupidly small grid).

However, if the wire has the right net and the pin isn't connected to that net, wouldn't that cause an ERC error? If so, surely that's the problem solved.

Sure, if your design philosophy is "Always keep the user guessing - or doing the work that the CAD system oughta!"

What we're seeing is the consequence of really not giving a damn about where the lines go or how they got there,
because it'll all get fixed in the mix, later in some ERC/DRC operation.  Frankly, that approach is just sloppy as shit,
and reminds me of a brief stint 30-some years ago when the geniuses running a startup I did some subsequent
design rescue work for decided that since they already knew AutoCad and were using it for something else, it'd be
fine for EDA too.  So they bought some expensive third-party modules that were supposed to give them the desired
functionality and the result was... my getting called in to do a design rescue.  They too took the view that "it's all
just lines, right?" and that real-time netlist creation, checking, and enforcement weren't necessary.  Expensive
lesson.

Again, it's easiest for me to cite Mentor's DA (Design Architect) approach, because it's simple, strict, and bulletproof.

To begin routing, select the "route wire" function.

Start a wire by clicking on a pin, then draw it out as desired - click to get a vertex, etc., depending on which routing
modes you've chosen.  When you reach a pin you want to connect to, click on it and carry on to connect to the next,
or double-click to end it.  You can draw lines in space, but they're not going to be assigned net names because
they're not connected to components pins or defined as supply nets, etc., and will generate warnings.

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.  The same thing happens if you move
traces around and one overlaps another, a vertex coincides with a line or a pin, etc.  In other word, if it looks
connected, but you didn't explicitly connect it, you get an error in real time.  Obviously, two wires (or buses) simply
crossing are not considered errors.

Same thing if you edit a symbol.  Return from the edit and your connections haven't been messed with just on
account of some minor visual tweak, and if any wires have been rubberbanded into questionable locations (like
running over other pins), the error flags will point them out so you can clean them up.

And none of this involves the user running checks, it just happens as you work.  Do I look like someone who looks
at a bunch of wires going to a bunch of pins on a drawing and thinks "Fabulous!  I can't wait to transcribe or print
out the names of all those nets so I can manually correlate them and figure out which ones are out of place!"? 

Ahem... don't make me say it, but that's what computers are for.

And to answer your question:  "if the wire has the right net and the pin isn't connected to that net, wouldn't that
cause an ERC error?", the answer is "no".  The reason is that when you connected them, they were part of the same
net.  But when you disconnected them, one got assigned a different net name (or the pin had its net name reset -
I'd have to check), because they're no longer part of the same net.  If you want them connected (again), it's up to
you to do so - you can't expect the editor to grasp your design intention.  Or if they weren't connected in the
first place, the editor is not going to go "well, that looks close enough, so let's just assume they should be
connected."

It's blindingly simple, really.  Nothing is connected until you connect it.  If you disconnect it, it's disconnected.
We do not make assumptions, guess, or surmise.  If something looks connected and you didn't do it, it doesn't
count and must be reported as an error - in real time.  This is how you maximize design entry correctness and
minimize user effort, period.  You strictly enforce a couple of simple rules.  Anyone arguing the contrary is just
presenting a nonsensical case for reducing reliability and increasing effort - an argument against one's own best
interests, like the people who vote... no, I'm not going do that...

[thinkfat]

One of us must be missing something. What exactly do you mean with the schematic capture not joining pins and wires and adding that information to the netlist? KiCAD quite obviously "knows" in the schematic editor, that wires are nets and what they connect to, and it becomes abundantly obvious as soon as you hit the ERC button.

Schematic capture evidently knows nothing and enforces nothing.  Tell me:  If you lay down
a symbol, then "connect" (air bunnies because it isn't an actual connection, it just plays one
on your screen) wires to it, what happens if you then pick up that symbol - just the symbol -
and move it somewhere else on the drawing?  Do the connections follow along, rubberbanding
the wires to the pins?

[...]

[skipped description of stroke based UI]

And if you can actually visualize it, play these operations for your mind's eye, you'll
immediately grasp that at no time do your eyes deviate from the area of focus - the
part of the schematic or layout that you're actually working on - so your brain doesn't
have to do a context switch finding the needed function in a huge menu or the key
you need on the keyboard before returning to the work and trying to recover your
context.  Not only fast as hell, but less mentally exhausting.  This is what's meant
by "a good UI".

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

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.

The existence of a superior UI doesn't make all other UIs horrible, tough. 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.