Yes, and probably another reason why they are so irritating!
QuoteWorth adding that the system I'm talking about doesn't flag every crossing, of course. That'd
be a makework PITA. It just flags the ones that are more likely to be mistaken for valid connections,
such as a line crossing a pin, vertex landing on a pin, vertex (or end) touching a line, etc.
Altium does that: drag or otherwise cross a pin with a net and they auto-connect, often leading to adjacent-pin shorts when trying to work close to a part. And Altium is a grown-up product. I've also used several products which make a great point of being able to plonk down something in the middle of a net (or, sometimes, net collection) and have them auto-connect.
I don't think Altium and Orcad being 'grown up products' means that their implementation is somehow right or wrong. IMHO the idea that you have to make a connection between parts specifically instead of having the CAD package making assumptions (like Altium and Orcad do) has a lot of merit. I can certainly see the added value of having the CAD package ensuring the integrity of the connections during editing so the chances of errors due to moving / shuffling parts around and/or changing symbols are much smaller.
I don't think this is particulary hard to implement; keep a netlist with connections between devices / pin numbers and only allow changes to this netlist in 'connection mode'. Any other edit that invalidates the netlist, results in errors.
Thinking about it: a PCB package will yell at you when you try to make the wrong connection. But why does the schematic package allow you to do this without warning?
Yes, but what if the change to the schematic is unintentional (when using an editing mode that isn't intended to create/change connections)?
Yes, but what if the change to the schematic is unintentional (when using an editing mode that isn't intended to create/change connections)?Can you explain that, please? I don't understand what an editor that doesn't edit might be.
QuoteWorth adding that the system I'm talking about doesn't flag every crossing, of course. That'd
be a makework PITA. It just flags the ones that are more likely to be mistaken for valid connections,
such as a line crossing a pin, vertex landing on a pin, vertex (or end) touching a line, etc.
Altium does that: drag or otherwise cross a pin with a net and they auto-connect, often leading to adjacent-pin shorts when trying to work close to a part. And Altium is a grown-up product. I've also used several products which make a great point of being able to plonk down something in the middle of a net (or, sometimes, net collection) and have them auto-connect.
That's insane. Is it optional, that is, behaviour you can disable?
You have two modes: 1) making connections and 2) placing components / moving components around to make the diagram fit / look better.
So if I want to move not only a symbol (or symbols), but some other stuff along with it like text, a block of wires,
etc., I enable symbols, text, and wires in the select filter, then enclose the block I want to move, select and move it.
QuoteSo if I want to move not only a symbol (or symbols), but some other stuff along with it like text, a block of wires,
etc., I enable symbols, text, and wires in the select filter, then enclose the block I want to move, select and move it.
What happens if something in the selection filter isn't moveable (or open to whatever command you're pushing)? Proteus used to be like this, in that you could select multiple components but only move the last one. Then they had a 'move' mode where you could multi-select and all would be moved, but it failed on some non-component things that got excluded. I think this is an example of changing the existing code to implement a new style, and often it's non-optimal. Don't know what the solution is, other than change the underlying design.
You have two modes: 1) making connections and 2) placing components / moving components around to make the diagram fit / look better.
Maybe that was one of the things I was finding confusing - some combination of not knowing
that they were different modes and not knowing where to look to see which one I was in. I'm
not a fan of modes like this in UIs if there's any other way; why not just have one mode - edit -
and make everything else a command/operation?
You are overthinking it. Moving a symbol is not editing, so it is not allowed to make/break connections. IOW: the user doesn't select the mode, it is inferred from the type of operation the user is performing.
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
Not even a little bit. Of course it shouldn't alter the netlist, any more than should moving
anything else. The netlist should only be affected by explicit "connect" and "disconnect"
operations/commands.
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
This seems quite close to what propellerhead suggested from the start? One might expect the default "move" operation to keep netlist connections intact. Which in KiCad it does not; you need to G(rab) or (dra)G to do this.
Kicad behaves the way it does for historical reasons, I assume: M(ove) came first. Then dragging was added, but it could only produce awkward angled wires, so one definitely wanted to keep the M(ove) mode for moving parts and connections around manually. Kicad 7 now has added a dragging mode which retains tidy, orthogonal traces. Maybe it's time to make that the default "Move" behaviour?
As far as I can tell this is essentially the entire issue, wapped up in major communication failure.
As far as I can tell this is essentially the entire issue, wapped up in major communication failure.
Yes, that's what I also understand now, with one addition: If one edits a symbol while it is already connected in a schematic, Kicad does not offer any way to automatically keep the connections. (For moving the symbol around, it does offer dragging as an alternative, so it's only a debate what the default command should be called or how it should behave.)
I believe that was my second point regarding library updates (changes to symbols).
Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?
This seems quite close to what propellerhead suggested from the start? One might expect the default "move" operation to keep netlist connections intact. Which in KiCad it does not; you need to G(rab) or (dra)G to do this.
Kicad behaves the way it does for historical reasons, I assume: M(ove) came first. Then dragging was added, but it could only produce awkward angled wires, so one definitely wanted to keep the M(ove) mode for moving parts and connections around manually. Kicad 7 now has added a dragging mode which retains tidy, orthogonal traces. Maybe it's time to make that the default "Move" behaviour?
Moving a symbol while severing it from connections should indeed be something you need to ask for explicitly. Additionally, library updates which physically move a pin on the symbol should not sever connections made to that pin.
As far as I can tell this is essentially the entire issue, wapped up in major communication failure.
We should not overlook the case of drawing the wires first and then dropping in a component. This usually only happens with really simple components such as resistors and caps. Nevertheless it is a move or place command that does two things: moves something and makes new connections. And is used all the time by everyone.
We should not overlook the case of drawing the wires first and then dropping in a component. This usually only happens with really simple components such as resistors and caps. Nevertheless it is a move or place command that does two things: moves something and makes new connections. And is used all the time by everyone.
Indeed, and there's discussion to be had as to whether that should occur. I admit, I have a tendency to drop things like dividers and decoupling onto nets in that manner, but I can very easily adapt to either positioning components prior to drawing the net, or giving an explicit command to connect at that point (non-connections of course should be clearly marked in realtime - a simple red x suffices).
Both this case and the case of moving a component while detaching it from nets could be comfortably handled by the use of a modifier key to cause the connect/disconnect behaviour when desired. If one doesn't like such behaviour.. don't press the key.
And I would happily skip those steps in favour of holding Alt as I finish the move command. Same result, less work. Just a macro to save effort.