If you could, that’d be terrific. As I just mentioned in the previous reply, my big old
dinosaur runs on RGB video, so recording the output would be nontrivial and I’m left
with having to stand a camera up in front of the monitor. Plus, it’d give me a chance to
see if and what they changed since V8.
That’s a charming analogy. I’m not sure it’s completely appropriate for this case, but it’s
charming nonetheless.
Both ideas (“movement breaks connectivity” and “movement maintains connectivity”) can be present in the same tool, and already are to some extent in KiCad – in addition to the hierarchical pin example @paulvdh gave earlier, eeschema supports both “moving” a component (which breaks connectivity) and “dragging” a component (which maintains connectivity, at the expense of odd wire angles). The same is true in pcbnew.
I really like @craftyjon’s idea to allow dragging symbol pins around in the schematic editor. I find myself using project-specific symbols for most nontrivial components. Ideally, it would be easy to sync these rearrangements back to the project library symbol - though this raises questions whenever the symbol is used more than once within the project: should the matching pin on all copies of the symbol be dragged simultaneously?
I can also imagine a “Maintain connectivity when editing symbol” checkbox in a schematic component’s edit menu which would let you decide whether you want wires to follow your pins around or not. When this checkbox is checked, the effect of editing a symbol and moving pins around would be the same as if you had dragged them all around with craftyjon’s proposed idea. (Someone clever would have to figure out how to handle deleted pins, renamed pins, renumbered pins, etc., as well as whether this could apply to swapping to a different symbol.) This idea sounds more complicated to implement, with more corner cases to deal with, compared to dragging individual pins.
No (not in KiCad at least). Edits only apply to the symbol under your mouse cursor.
Yeah, I guess that’d be consistent with the current behavior of editing the library symbol, where you need to “Update symbol from library” on the other components.
Good!
It really is just an aesthetic thing then. Just for that symbol on that Schematic.
If a/some permanent changes wanted, then dive into the symbol editor.
Hah Hah… when? 
Please do this. A demo is worth 1000’s of words …
Mentor is a highly loved tool by those who knew it well. I used it for a few years early in my career and know engineers who today still think it was the best system ever. There are probably some things we can learn from it, so again some video demos of the most valuable features could be useful to influence KiCad’s future development.
However, I also respect the reality that there are tradeoffs – if we make one thing easier to do, other things will be harder. Simplicity and constraints are good things. We also need to optimize for where we spend the most time.
Great discussion! Stay open-minded. Don’t be easily offended, and we’ll probably all learn something.
Kicad 7 will soon be released with over 500 functions that can be assigned to hotkeys. Maybe one day those functions may be able to be assigned to a set of mouse gestures as well as hotkeys???
v8 already planned to include a rework of mouse handling to allow that Draft: 8.0 hotkey / action changes (!1421) · Merge requests · KiCad / KiCad Source Code / kicad · GitLab
No, that’s for assigning mouse buttons, not gestures. If someone wants to make a separate gesture system that would be theoretically possible but nobody has signed up to do so.
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.