Kicad - GUI is Horrific!

[tooki]

Yes, and probably another reason why they are so irritating!

Agreed.

At least there aren’t many of them!

[propellerhead]

Worth 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?

[propellerhead]

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?

Because when you're in layout you're working from the netlist that was generated from your schematic,
and when you're in schematic there isn't one - it's only extracted after you've done drawing.  That's my
entire argument in a nutshell.

[propellerhead]

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.

[nctnico]

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.

You have two modes: 1) making connections and 2) placing components / moving components around to make the diagram fit / look better.

[PlainName]

Worth 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?

It's annoying, yes. Can't remember if it's an option but if so then it's enabled because turning it off also kills something else that is actually useful. Just simpler to remember not to make a turn straight out of a pin but leave at least one grid space first.

[propellerhead]

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?

(Stressing that I'm not attempting to launch an argument for this...)  The system I'm used to
keeps it simpler - if you want to move something, you do a move.  What gets moved is what's
been selected, and what gets selected is determined by the select filter.  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.  If KiCAD's model is essentially that working with symbols is one
mode, and working with wires is another, does that mean there's no way to do what I just
described?

[PlainName]

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.

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.

[propellerhead]

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.

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.

That's a good question - I don't know whether Mentor's schematic capture supports locking/fixing symbols
in place.  I can't think of a reason for it not to, it's just that I don't think I've ever had a reason to want to do
it.  I should go look.

Of course, layout is a different story - if there's something that's fixed yet within the select filter, it'll light
up when you select it, but just not move along with whatever else you may be moving.

[edit]

I just took a look, and that's "Protect", a function I've never felt a reason to use in schematic capture.
When you protect an object, it's greyed-out and can't be selected.  I suppose they put it there for a
reason, but I've done some pretty complicated schematics and have never used it.

[nctnico]

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.

[propellerhead]

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.

Huh?  This sounds like either a zen koan or I'm just being pranked.  "When is an edit not an
edit?  When you're moving a symbol."

Moving a symbol on a schematic is, intrinsically, editing the schematic.  How on earth can
anyone stand behind "I moved a symbol, and the schematic no longer looks as it did before
I moved the symbol, yet I did not edit the schematic."

Um... I dunno - maybe the invisible hand of the market moved it when I wasn't looking?

As for the mode:  Okay, I had a sense of that while I was editing the schematic - that there
was some kind of mode switch happening, but it wasn't clear to me when or why, made
worse by there being no obvious indication.  Is there a solid argument for behaviour like
this?  Because it was just confusing and maybe isn't necessary at all.

[Monkeh]

Moving a symbol is not (should not be..) editing the netlist. Does that clarify matters?

[propellerhead]

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.  But moving anything sure as hell is editing the schematic,
or we're becoming untethered from any reasonable agreement on what "edit" means.

[ebastler]

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?

[Monkeh]

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.

And that's exactly what he's trying to express. A slight error in terminology has slipped past you, and now you're stuck in violent agreement.

[Monkeh]

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.

[ebastler]

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.)

[Monkeh]

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).

[ebastler]

I believe that was my second point regarding library updates (changes to symbols).

Yes indeed -- sorry, I shouldn't post while distracted...

[propellerhead]

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.

Violently agreed!

Now I just have to convince everyone to take this idea a step further, and start paring away all
the unnecessary/undesirable variations e.g. moving a symbol shouldn't just keep the connections
intact by default - it shouldn't have any other behaviour/mode/option available.  If there exist subtle
differences between Move, Grab, and Drag (and I poked fun at this the other day), then it's time to
decide how necessary those differences are and ditch two out of the three.

If that sounds radical, think of it as a CISC vs. RISC argument:  The idea behind RISC is that if you
have a very small and consistent instruction set, you can architect for better overall performance
even if more instructions need to be executed in order to provide the same operation.  In this case,
I would invoke Mentor's select (choose: pins) and disconnect (enclose all the pins in the box)
functions, and everything would be disconnected.  Then I can move the symbol out without disturbing
any of the wires.  Without the explicit disconnect operation, all the wires rubberband to the symbol.

Go with Einstein on this one:  Everything should be made as simple as possible, but no simpler.

[baldurn]

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.

But aside from that special case, I agree that move should neither break existing nor make new connections. Which may mean it should reject a move if you place something in a position where it could make new connections. Some people might find that annoying. For example you could delete a transistor leaving the wires hanging, then drop in a new transistor - should it then refuse that because that would make new connections?

[Monkeh]

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.

[propellerhead]

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.

Yes, BUT...  I just think it unnecessarily complicates things if what you're doing is invoking
conditionals and decision trees in what should be simple, atomic commands.  What are your
assumptions surrounding that modifiable move?  Are we talking about the present context in
which there's no such thing as a connection anyway, or my suggested context in which a wire
in contact with a pin is either a connection or a warning?  Because they don't suggest the same
use case.  In Mentor I don't have any such option.  I can move a symbol (or select a fresh one)
and drop it into existing wire ends.  A move does not imply connection, nor is connection offered
as an option.  It's simple - a move is a move, and that's all.  So when I complete the move any
wire end in contact with a pin is going to be a warning.  If I want to connect them, I do exactly
the opposite of the example I just gave a few minutes ago:  I select the wire ends and pins and
issue a "connect" command, which connects the wires and removes the warnings.

I'm not saying it's the only way to do things.  I'm saying that it's extremely simple, consistent,
and clear, and doesn't force you to invoke some probably-obscure-to-a-new-user option switch.

[Monkeh]

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.

[propellerhead]

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.

Sure, that's not something worth a fight, but it's worth considering potential use cases.  What
if you want some, but not all, of the resulting potential connections to be connected?  In my
case I connect the ones I want connected and otherwise clean up the others.  In yours you have
the choice of either that or disconnecting the undesired connections made.  If I had to pick a
side, I might say that auto-connecting a bunch of wires/pins that I don't want to connect is a
worse result, because you're intentionally adding mistakes you're then going to have to remove,
and I think that holds potential for an outcome worse than a move-without-connect operation
that still leaves work to be done, but not errors to be undone.  It's a fine point, but that's probably
the side of it I'd land on.