Wow, there seems to be a lot of energy expended here! I did my last hand-taped board in February of 1987, the month we got our first group of Apollo DomainOS workstations with Mentor Graphics BoardStation 500. The DA (Design Architect) UI evolved over the next 10 years that we used Mentor. At one stage our operation had 4 full time PCB designers and a full time librarian and 6 seats of DA in constant use. We released about 55 board designs per year. By the late 90’s though PC’s were no longer toys and it was obvious the EDA market’s hardware platform of choice would begin shifting to PC’s with the release of Windows NT. Never mind that we had been using Linux and X-windows on PC’s for years by then to run DA at our desks. In the early 2000’s I began using Zuken CADSTAR and the first thing I did with its schemo entry tool was program all the function keys and strokes to work exactly the same way Mentor DA worked, so you lot out there who are truly pining away for the Mentor experience I invite you to try the new e-Cadstar tools. Expensive, but not nearly as much as Mentor Boardstation 500 which was almost $100,000 a seat back in the day. One thing that seems lost in the discussion here is the tremendous value proposition that KiCad brings to the table. Only companies that can justify the return on investment can afford “big iron” EDA tools but then why not, if you are doing that kind of work on a daily basis? Why should I be forced to spin up something like CADSTAR (disclaimer- I have a license…) when KiCad, in spite of its quirks and limitations, will do perfectly well to create my PCB? Admittedly I will reach for a fancy tool when controlled impedance, length matching, and multiple layers are involved, especially for a 64bit processor that’s parts down along with DDR3 memory. But for a lot of the work out there KiCad is perfectly fine. One thing I would like to see in KiCad is pad stacks (you Mentor types know what I mean). We accomplish something similar in CADSTAR with “assignments”. These are things useful for tuning artwork for various manufacturers’ processes if you are sending your board to high volume production. EDA software is constantly evolving. I find new KiCad tricks every time I do a new board with it. I have no idea how well it works on Windows or Mac since I don’t use those platforms but on Linux it just works. And it frees me from having to use that detestable Altium tool. One feature I don’t miss from the Mentor days however is the ‘package’ utility. I always said that utility separated the men from the boys when it came to preparing schemos for place & route.
Cliff:
I think you can safely be forgiven for missing, in this War and Peace-sized thread, that
@janvi offered to record something, as I’m still running on a big fat old HP PA-RISC
RGB tube and have no way of capturing a video stream other than by standing a
camera in front of it, while he’s running a newer version on a windoze box. Regardless,
I’ll probably try it out and see whether I can grab a few minutes of acceptable quality.
Not that I’m looking to start a fresh bunfight, but my jaw drops at the very thought that
there are 500 functions, let alone assigning them to hotkeys. Without actually seeing
that list, my first reaction is to wonder whether it’s a command set out of control and in
need of reconsideration.
Ohhhhh… I never got to use DomainOS myself, but worked closely with a bunch of
guys who ran a big network before it got eaten by HP. I tell you, if you want to hear
poetry, ask an old DomainOS user what it was like. With tears in their eyes they’ll
tell you what truly seamless integration of computers on a network is like.
Ah, now that’s helpful! Cadstar’s been around since the dawn of PC EDA, and I didn’t
realize that it was even still around rather than merged-up like most of the packages
from back in the day. So they implemented strokes too? That’d make it a lot easier to
make the case for it here, that’s for sure. Does it appear in their freebie version?
It may not be explicitly discussed, but I don’t think there’s anyone here who doesn’t
agree that KiCAD, as an open-source suite, brings huge inherent advantages to the
table. And though it may not at time seem like it, getting into dustups (like this one, in
spots) is precisely one of those advantages, because nobody would engage in them if
not to try to help improve the tools.
You mean they don’t? I’m not far enough along yet to have found out, so I’ll see when
I get there.
Agreed, Mentor has its share of unwelcome complexity, and that qualifies. (Side note:
Another separate-men-from-boys task was writing sendmail rulesets, and I once saw a
guy write one that played Towers of Hanoi…)
But back to the OT: As someone of obviously broad experience in the field, what’s your
take on KiCAD’s notion of connections vs. other tools you’ve used? Am I overreacting?
Ohhhhh… I never got to use DomainOS myself, but worked closely with a bunch of
guys who ran a big network before it got eaten by HP. I tell you, if you want to hear
poetry, ask an old DomainOS user what it was like. With tears in their eyes they’ll
tell you what truly seamless integration of computers on a network is like.
DomainOS was truly a thing of beauty. Its seamless networking allowed one to create remote processes on other workstations (‘creeping on’ someone else’s box was a favourite pastime as I recall, especially because you could play sounds remotely, melt their screen, and do other silly things as well as real work). The fine grained file permissions feature was especially brilliant, our sysadmin really howled about losing that when we were forced to switch to HP-UX. But with DomainOS basically all the workstations on a network functioned as one big computer. The physical network was a 12Mbit token ring. While that seems slow nowadays the fact that it was token ring, and bi-directional at that, meant that the network could run perfectly fine fully saturated, it seemed faster than 100base-T ethernet which was just rolling out around that time.
Ah, now that’s helpful! Cadstar’s been around since the dawn of PC EDA, and I didn’t
realize that it was even still around rather than merged-up like most of the packages
from back in the day. So they implemented strokes too? That’d make it a lot easier to
make the case for it here, that’s for sure. Does it appear in their freebie version?
I’d have to go back and look. I believe Zuken (still based in Japan) is the only EDA company that hasn’t been bought out by someone else. I remember when DA implemented strokes way back when we thought yeah that’s cool until I went to actually use strokes. There were maybe one or two moves I actually used, I found that mouse + hotkeys (the AutoCAD way…) was faster for me. Too often I’d go to make a stroke and move the mouse a little bit the wrong way and get the wrong command. I quickly abandoned strokes. Also it’s impossible to use strokes mid-command when drawing with the mouse. Since I was also fighting carpal tunnel issues at the time doing as little as possible with the mouse was helpful.
But back to the OT: As someone of obviously broad experience in the field, what’s your
take on KiCAD’s notion of connections vs. other tools you’ve used? Am I overreacting?
It seems to me that when a wire is connected to a pin in the schemo that’s an entry into the netlist. The only way to change the netlist should be for the designer to disconnect the wire from the pin in the schematic, or swapping pin connections in the layout according to swap rules assigned to the component. Moving a symbol or component should result in “rubber bands”- the wires staying connected to the pins. Maybe for simple stuff made with KiCad it’s not a big deal but for large designs with multiple sheets and tons of components disconnecting wires when moving components is error prone. Components have to be shuffled during the course of editing. Wires should stay connected.
Having said that, there’s a lot to be said for keeping things simple. I don’t think anyone is going to try to design a PC motherboard with KiCad. The design rule checker tool seems to work, so use it. Adding complexity will slow KiCad operation. I can’t stand using Altium because it is such a dog. PADS is the same way, ugh. Not so with CADSTAR. Lightning fast, no waiting. It’s not perfect by any means. But if you long for the Mentor DA days CADSTAR is about the closest thing to that experience. AND, just like Mentor, the learning curve is very steep. It’s not a tool for the occasional user. KiCad is definitely newbie friendly, especially when it comes to generating manufacturing output. Note however that the PCB manufacturing world is moving to ODB++ for manufacturing data. Adding that to KiCad might be complicated by licensing issues however, dunno…
Well you would be wrong. I used Mentor in the 1980s, and absolutely hated it. We all have different viewpoints on this.
Also, your comment regarding being passive-aggressive and condescending is pretty passive-aggressive and condescending. Surely it is obvious to you that KiCad does not do what you want, so suggestions to choose something else would appear to be intended in a helpful way.
As indicated, I started using it in the late 90s, so I have no idea whether the Mentor
you used bears any resemblance to the V8 that I ran (and run) or that within @fomJeffs
experience (which is clearly broader than both of ours) so I’d tend listen to him. Also,
for this to be a helpful contribution, you’d really have to be specific about what you
“absolutely hated”. This conversation started with the concept of “connections” and
has strayed into matters of UI, specifically strokes.
As for that other stuff, we’re way past all that by this point in the conversation, so please
try to keep up.
I can’t remember what the version of Mentor was back in 1987 when I started with it, something like 5 or 6 maybe? We were on 7 for a long time as the writing was on the wall that Mentor was going to have to be ported to C and X-windows at some point due to the demise of Opollo Computer. The DomainOS graphical workstation environment was a completely different animal than the X-windows system on HP-UX and so Mentor for V8 came up with a window manager to work inside of X called the Falcon Framework, an attempt to maintain as much of the “work alike” as possible that DomainOS provided. It nearly killed the company as it was a mammoth software effort, we were beginning to think they would never get it working. They finally did, we moved to HP-UX, and just kept on going. That was a long time ago, most likely before many users on this list were even born let alone thunk of. Designers of modern software should study their history lest they repeat the mistakes of the past or expend tremendous amounts of effort re-inventing the wheel. There are features in Mentor and early efforts like Cadnetix (which I used briefly before we decided on Mentor as the way forward) which should be in any modern EDA tool much the same way as features in AutoCAD 2.6.2 from 40 years ago are still included in SolidWorks, AutoCAD and other mainstream mechanical packages. This thread began 97 posts ago with a question about how components and nets should behave on a schematic page and that led to an unexpectedly large number of posts. If there are (former) OrCad users out there you probably have a pretty long list of how NOT to do schemo capture and layout. Back to the original topic of this thread, all serious (commercial) EDA tools keep wires attached to pins when moving symbols and components. Does the fact that KiCad not “rubber band” nets and traces doom it to the dust bin? I think not. Just think of it as a feature and not a bug, and use the design rule checker religiously. That’s the way I use it. Mentor had a very steep learning curve back in the day. I went to school for a week on AMPLE, the stuff they used to customize the user interface. Wasn’t nearly enough time to figure it out. It was an amazing tool, but a beast to learn. It’s easy to see why people could “hate” it, especially if you’ve ever had to deal with the packaging tool. There were an awful lot of ‘thunks’ in that software suite…
Not quite the original question/observance.
M for Move and G for draG… pick your poison, solves that comment.
The original topic was “Wires don’t stick to the original pin when that pin is moved in the symbol editor”
This suggestion, and possible future addition:
Would solve this issue.
98 posts now?
Post 99,
I’ve made a feature request on Gitlab:
https://gitlab.com/kicad/code/kicad/-/issues/13417
Anyone liking the idea, please give the thumbs up 
@fomJeffs has a solid handle on this issue. It would be an oversimplification to go back
and focus on my original question, because I didn’t understand at the time that I was
asking about a symptom rather than (what I see as) the underlying problem itself.
When I found that moving pins around in a symbol edit didn’t maintain connectivity, I
didn’t get that the lack of connectivity is a fundamental (I say “problem”) (you say
“feature”) of KiCAD.
So it makes little sense to address my original symbol-editing gripe if it doesn’t alter the
very notion of connections in schematic capture.
Not that it matters much, but I would really prefer that once I have made a connection, the schematic editor would respect that connection.
But I can see that people in the forum here are very sensitive to critizism of KiCad, or even saying that it doesn’t have a feature it should have…
Anyone is welcome to criticize KiCad, but in this case it has been made clear that this is a difference in opinion, not a bug, and the KiCad project will not be changing this behavior.
Yes, it became overly clear in the discussion that there were strongly differing opinions, to the degree that it resembled some of the more heated religious discussions that can happen.
When a discussion goes into that mode, it is a good indicator that nothing reasonable is going to be learned from it, even if the potential could have been there initially.
“It’s difficult to make predictions, especially about the future.” - variously attributed
I think this complaint - initially mine, but shared by others - is the beginning, not the
end, of this conversation. As KiCAD grows in popularity, I suggest that you’re going
to hear increasing calls from more sophisticated designers for a tool that doesn’t
regard connections as mere spatial coincidences to which one can attribute meaning
when it’s convenient to do so. Sooner or later, the idea of connections will be taken
seriously and reworked, and it’s reasonable to think that it’s better to do it sooner
rather than later.
As I’ve said earlier, it’s a matter of your opinion that you think that sophisticated designers require that programs work the way you are personally used to. What makes you think that you are the first “sophisticated” designer to use KiCad, and that therefore any difference you find from the programs you used before comes down to KiCad not being as “sophisticated” as you are?
This isn’t about me, so that approach isn’t going to work.
Listen to the other designers here who agree, based on their experience with mature,
sophisticated, and (incidentally) expensive tools, that EDA should take connections
seriously and completely.
So don’t waste your time trying to distract people by attempting to discredit me.
Instead address the substance of the argument, which is “connections that connect
rather than pretend to connect”.
I’ve already addressed the subject above; it’s been rather beat to death. At this point you are simply choosing to ignore the points I and others have made about KiCad’s design in this regard.
I agree with Via that not handling connections as connections but as graphics is somewhat problematic and I would prefer having some way, whether it be only perceived or actually reflecting the architectural implementation, of preventing accidental de- and re-connecting implicitly something while modifying a design. But I also agree strongly with Jon that the tone in this discussion haven’t been constructive, whether Via feels that way or not. I honestly have felt some arrogance here.
I certainly have my disagreements with many design decisions in KiCad implementation or behavior and have certainly annoyed the developers more than once. Yet this isn’t a good way forward. I’ll close this thread for now. The facts and opinions have already been expressed anyway. The subject matter itself is open for discussion in the future, of course.