You haven’t succeeded in coherently articulating what you actually want, never mind a cogent interaction model for it.
To the contrary, I've repeatedly offered a clear and concise model for exactly what schematic
capture should be doing.
You have repeatedly offered explanations, but they have not been clear and concise. That you
think it was clear and concise doesn't mean it actually was. As others have pointed out, you have made contradictory explanations that have prevented people from having a clear idea of what you want. And your very rigid, yet unconventional, use of terminology has also made it harder to understand what you mean.
If you haven't read it, it's not because I haven't (coherently) articulated it.
I
have read it, which is why I know it's not been coherent.
1. When you connect something, it's connected. Not only is it visually connected, but the connection is
entered (by the schematic capture) into the netlist it maintains.
Which it does.
2. When you disconnect something, it's disconnected, and that disconnection is similarly reflected in the
netlist - again, transparently to the user.
Which it does.
3. The software may not make or break connections as the result of moves, symbol edits, etc. Only the user
can change connections.
So which manipulations
do allow connections to be made or broken? It's a graphical editor, so the schematic diagram
is how the user makes and breaks connections (that is, that is the mechanism for conveying user intent to the software).
If, as a result of moves, edits, etc., entities in the schematic intersect such that they
create the appearance of connections (that haven't been explicitly created by the user), they are flagged
as warnings to the user.
The connections created during those operations
are real connections.
Saying "the
appearance of connections that haven't been explicitly created by the user" implies that those connections
aren't being made, but that it nonetheless appears that they are. But that's not the case, they
are being made.
You can see #1-3 in action: in KiCad, click a wire in the schematic and the status bar tells you the net name (under "connection name").
Under no circumstances should the software permit faux connections, that is, elements of the drawing
that appear to visually represent connections yet aren't properly represented in the netlist. This is what #3
is meant to prevent. It's also apparently the only kind of "connection" presently supported by KiCAD.
"Faux" means fake, non-real. But they
are real connections, and they
are represented in the netlist.
So what you really mean, if I understand you correctly, is that you don't want
unwanted connections to be created. Is this correct?
The challenge, from an interaction design standpoint, is knowing what is and isn't wanted. Sometimes it will be completely unambiguous, but other times, it will be fuzzier, and you have to design the software to handle every one of those cases in some way or another. And you want the decision logic to seem obvious to the user (or to be precise, you want it to feel transparent, like it just magically "knows" what you meant). This is really,
really hard to get right: witness how people swear at MS Word for it doing "unwanted" things (because the intent inference logic didn't do what they wanted). And those moments
are frustrating. What people don't realize is how often it gets it
right, because those moments
are transparent. Only when you go back to an early version that didn't have that particular logic do you realize how much it's been doing for you.
I understand well the problems of 1) unwanted connections being created during certain drag operations, rotates/flips, etc, and 2) of existing connections getting made/broken when editing a symbol after it's been placed and connected. (Altium, my primary EDA program, has both of these issues, so I am completely familiar with them, and the frustration they can cause.)
So how do we:
a) prevent that from happening,
b) differentiate between wanted and unwanted connection changes,
c) provide real-time feedback during the edit, so the user knows exactly what the result will be,
d) provide the user a real-time mechanism for influencing the end result, and
e) provide recovery in case the result isn't what the user wanted?
Let's look at problem 1 only.
For the purposes of this discussion, please accept
as a given that the internal representation (which we can call the netlist) at any given moment is
always coherent with the schematic as displayed. Let's also work from the assumption that schematic wires can cross, but that wires that cross without a dot are not connected to each other, so wires only connect to each other when a dot is shown.
One solution, which we know the KiCad team expressly does not want, is to have explicit connect/disconnect commands or modes. But my hunch is that you probably don't
actually want that, either.
Another approach would be to only allow some operations to create connections, like adding wires. Some example questions:
Does only the
end of a wire create a connection?
What about if some point along the wire lands on a pin? Does it depend on whether the wire is already connected to something else?
Does dropping a component onto a wire (such that a pin is on the wire) create a connection or not? What if it's just one pin? What if it's multiple? Does it depend on pin functions (input, output, power source, etc)?
For the sake of the next step, let's assume we've made decisions on all those things, and we have a coherent, happy mechanism for creating new connections and breaking existing ones. Now we move onto making
changes to a schematic.
What happens when we drag a component, and it is now in a position that could add connections? Do you make the connections, or do you require the user to make them separately?
Does it depend on whether that component has any other connections yet? (That is, do you treat a "virgin" component differently from one that's already got a few connections? What are the criteria?) Does it depend on what kind of component it is? (For example, do we treat connectors differently, since there, the likelihood that the symbol layout actually corresponds to the physical layout is much higher?)
Do we handle it differently when flipping or rotating?
Bear in mind that I'm not asking you to answer these questions -- they're simply to give you an inkling of just how much thought has to go into program logic, of all the decisions the user interface designer has to make regarding how a program works. (I have worked in UX, so I am used to thinking about these types of questions.)
So let's look at another aspect.
What I think we all agree on is that what we
don't want is for attached wires to drag along with the component and add additional connections of their own. I know I have been in the situation where, for example, I would have loved to be able to select one or more components and drag them to a totally different area of the schematic, and know that every single connection is exactly as I created it -- none added, none removed.
One idea would be to use the netlist
as it existed when the drag operation began to perform real-time comparison with the "future netlist" that would result if you were to release the mouse now, and give feedback/warnings. But if you're doing that, you could just as well use that logic to avoid netlist changes to begin with, by using autorouter-like wire layout logic to move wires around more intelligently by avoiding short circuits between nets, by scooting (or meandering) other wires and parts out of the way. (If memory serves me correctly, I actually saw a video from a KiCad developer back in the version 4 or 5 days, showing an experimental schematic editor change that kinda worked this way. I was unable to find that post now.)
Other than being more computationally expensive than "dumber" logic, I don't see any real problems with this. (I don't know how much it would slow it down. But given how fast the push-and-shove logic is in PCB editors, I can't imagine it being problematic on modern hardware.) With flips and rotates, it could result in some visually really messy schematics, but as long as it scoots wires out of the way so that no unconnected wires land on pins, that remains a cosmetic problem only, since wires can be crossing each other without connecting.
For the situation I described a paragraph ago, that would work great.
How about if you
want to make or break connections while dragging? Well, breaking is easy (at least to break all of them at once) since that's the "move" command. But suppose you have a typical dual-row header for an IDC connector, for ribbon cable where you want every other wire in the ribbon to be a ground. Well, that's connecting ground to every even pin, or every odd pin, i.e. all the pins on one side or the other of the symbol. You've wired up your signals, now you need to add the ground. Do you force the user to manually wire each one? Do you allow the user to draw a long-enough wire, then drag the connector symbol so that all of the pins on one side land on that wire? Does that connect them, or does the wire scoot out of the way to prevent adding new connections? Do we only scoot the wire away for pins that already have something on them? Do we treat GND differently from other already-connected pins? Do we treat connectors differently from other components? Do we have different modes that behave differently? Are those modes separate functions, or are they modes of one function (like how Altium's PCB editor lets you enable or disable the component reconnector while dragging a component)?
Could that possibly be clearer or more coherent?
Yes. Your terminology in particular is really problematic.
(a) I fully understand the desire for a set of commands which manipulate the schematic while keeping all connections intact. KiCad has those: You can drag a part or a wire, including rotating and mirroring the part, and keep all connections in place.
Almost, except for the part about "keeping all connections intact". My overarching point is that they
aren't actually "connections" - they just look like connections. If they were real connections you
would not, for example, require a "drag" (which maintains the faux connections) vs. a "move",
which just lets things reveal their true nature and fall apart.
You are operating from a dichotomy that does not exist. There aren't "real" and "faux" connections. Every connection you see
is a real connection, they're the only thing that exists.
(As an aside, bear in mind that the "move" command is essentially just shorthand for "cut and paste": it's
removing the symbol (and nothing else) from one spot and pasting it back in somewhere else, as opposed to relocating it
in situ. I think "move" vs. "drag" is
awful UI terminology, but many EDA programs use it.* )
What I think you seem to want (or seem to think exists already) is some kind of authoritative "shadow netlist" that remembers your
original intent, and then works to preserve that intent against future graphical modification. KiCad (like many other EDA programs) does not work this way: there is ONE netlist, which is always equivalent to the schematic as displayed. Your approach would require the program to know the
intended connections, but then also track which of those have and have not been made in the schematic. That would require it to somehow be able to display those intended-but-unmade connections, and give you some way to edit them, since your intent can change, too.
I don't know for certain whether the dual-netlist approach is or isn't good. But what I am sure of is that "real" vs. "faux" is certainly not a sensible way to describe it, because both the "intent" netlist and the "actual connections" netlist would be equally real. Neither one has a "true[r] nature" than the other, they'd just be different aspects of the design.
A usability concern I'd have is whether it would add unnecessary complexity to the PCB layout process: we already have the "intent vs. actual connection" dichotomy in layout programs, in that the schematic captures the intent, and the PCB layout captures the embodiment of that intent. Real-time and batch DRC work to enforce that intent. You'd be adding a second layer of intent, resulting in "intended intent", "actual intent", and then embodiment.
Rather than this, I think that adding limited "smarts" to the schematic and symbol editors, giving them the ability to retain or transfer aspects of your original intent through certain types of edits, is probably smarter.
* I did the German-to-English translation of a substantial desktop application, which meant writing literally thousands of on-screen text strings, including hundreds of names for menus, commands, buttons, etc, as well as of error and status messages and the like. It takes real work to come up with concise, memorable, self-explanatory and
distinct names for commands. "Move" vs. "drag" totally fail the "distinct" and "self-explanatory" tests, because it is in no way obvious what the difference between them is. Never mind that "drag" shouldn't even
be a command, since "drag" means "move the mouse with the button held down".)
Home
Help
Search
Login
Register
