Should wires snap to labels when moving symbols?

When moving a symbol on a schematic with the G key, the wires will snap directly from their far endpoints to the pin that they’re attached to in its new location, ignoring any labels.

Of course, this disconnects the labels, and usually requires deleting and redrawing the trace before you can reconnect them.

Could a label’s connection point not be treated as any other pin on a normal symbol?

If the traces snapped from this point, instead of the far end of the trace, this would keep the net name from being lost, and could also allow dragging the label (also using g?) to the new location, without it being disconnected, or accidentally connected where another net gets dropped across it.

Placing a junction on the attachment point of the label seems close to the functionality you want.
Then you can make ugly slanted traces by dragging the component or the label without losing attachment.

You are still left with ugly slanted traces.
Why not simply use block move and keep all traces horizontal?

You do not have to delete and redraw. You can easily straighten existing slanted traces by grabbing their end
points.
You can also do this with whole blocks of traces.
At least in the KiCad version I am using:

I’m discussing ways to improve the default behaviour, not find workarounds. Is there some advantage to having traces disconnect that would make my idea a bad thing?

Because block moves are not what I’m trying to accomplish. If I’m trying to make space between existing parts, a block move won’t accomplish that either without disconnecting traces. If you’re going to rely on that all the time, why even bother with a G key?

It seems you’re suggesting that if the G key behaves badly, I’m wrong to suggest ways to improve it, and should instead work around it by using block moves all the time? Yes, it will work, and no, my suggestion won’t fix it in most cases, but if it’s not even moving in the correct direction, it’s never going to be useful.

If we fix its behaviour in the right ways, it will allow other fixes that aren’t currently possible (because they would create even more problems) For example, If the nets would stay attached, perhaps it wouldn’t be too difficult to create an add-node similar to how you can edit zones in the PCB editor. Then that would allow you to square your traces to be orthogonal without disconnecting them.

Or maybe someone else will have some better ideas. That’s why I posted to discuss it.

I just want to remind that the schematic editor source code will be rewritten or at least drastically changed for the future 6.0 version and much of the functionality will probably be re-evaluated. This snap-to-grid vs. snap-to-object problem is well known and I suppose it will be taken care of, although I can’t be sure. It’s almost pointless to think about small enhancements to the schematic editor at this point - unless they are easy to implement and the developers will change their release plans so that instead of 6.0 being next they release 5.1 with smaller enhancements.

I don’t say this kind of brainstorming is needless or useless, on the contrary, but I would wait until the new schematic editor engine is in place and we can see where it’s heading to.

There is an unofficial roadmap which has the following items

Schematic

  • Refactor code to common SCHEMATIC shared object
  • ERC Improvements
  • Implement GAL canvas and drawing code
  • Port all editing tools to GAL framework
  • Net Highlighting - done in 5.0
  • Component Library Editor Improvements
  • Allow Use of System Fonts
  • Bus connections enhancements - in progress

While it’s clear there is intended to be a rewrite, it’s not clear whether the intention is to port the tools to the OpenGL canvas and have them work the same way, or port them and implement a new style of UI. With pcbnew, the new tools have a slightly different model, with an entirely new push and shove router. It seemed to come out of some CERN skunkworks, I don’t recall the exact UI being discussed publicly.

It’s 2018, and all the drawing tools I use have rubber banding, and are also capable of re-routing wires accordingly. There are also some that do “push and shove”, admittedly the resulting wires end up in a big mess. Everycircuit is like this, a web applet I occasionally use.

I guess the problem with graphical UI is that it’s hard to write in words what is expected, due to different subjective interpretation. In particular, terms like “easy to use” or “intuitive” are quite useless. It really needs a storyboard or animation to show what is expected. A “rapid prototype” would be ideal.

So I think it’s worth a bit of brainstorming, but the bottleneck is likely not ideas but implementation. There are at least two other new OSS projects, LIbrePCB and Horizon, might be possible to pick some code out of there.

I find the simplicity of the schematic editing in KiCad very charming.
The "g"rab key works well for (mostly horizontal) movements even if there are a lot of wires connected such as memory chips.
"G"rab also works well for simple things such as resistors / capacitors. The only improvement I can see here is to insert an extra line segment now and then to keep things orthogonal.
But if you try to use "G"rab to diagonally move a component you go over it’s limits.
If "G"rab in KiCad leaves some slanted wires they are so easy to clean up that it is hardly worth any development effort. Making more room on a crowded complicated schematic is going to require a bit of hand work. There is no “easy fix” to this.

A long time ago I worked (very shortly) with a schematic design program that had “intelligent” routing of wires in the schematic. If you dared to move any component there with more then 10 wires It would re-route upto 3 or 4 wire segments of all those wires and if there was not much empty space around the components it would make such a big mess of things that trowing all the wires away and restart again was easier.
Once your schematic got more complex, the only sensible way to move anything was to first delete all wires to external components, then do a block move, and then repair the connections you deleted.

This is (was) a real problem:
https://forum.kicad.info/t/type-2-errors-in-shcematic/10238/13
Wires would not connect to components, probably because he changed the grid and coordinates would not align anymore. Solving this, either by either “snap to pin” or other methods is far more important than making it a little bit easier to make more room on a complicated and crowded schematic.

EEschem can benefit from some cleanup here and there, but it has been fairly wel developed and is very usable. The schematic entry part (not the schematic design) is a small part of the design of a pcb and there are a lot much more important issues than this. I would very much like to see ngSpice integraton in the official release to call one.

I have used over 10 different pcb packages in the last 30 years and KiCad is the best of them yet.
It surely has it’s flaws, but adding a lot of complexity in an attempt to mitigate a minor inconvenience is a step in the wrong direction. It is not an improvement.
One of the reasons I like KiCad so much is the absensce of big flaws. Any inconveniences it has, has usually simple workarounds. A long time ago I bought “EdWin”. After using it for a few weeks I discovered that if you delete a trace in the schematic, then sometimes it did not delete that trace in the netlist, with no workaround to edit the netlist. That was EUR 300 right into the garbage bin.
Part of the reason workarounds are so easy in KiCad is it’s simplicity.
Please keep it simple.

1 Like

Can you show me some screenshots of that?

Because the combination of "G"rab and block moves makes it very easy to make more room on a complicated schematic with lots of connectons. Use blocks to move diagonally, use grab to lengthen / shorten a lot of wires with 1 mouse move.
I really do not see the problem here.
I suspect that you just can’t seem to work out the trick to do this fast & simple.
If you start a thread with some screenshots of this “make more room” problem, then I will make some screenshots of how I would do it.
Words are not a good medium to convey graphical issues.

I am not sure if you want to consider this a “workaround” or “improvement in user behaviour”.
If you have a complex schematic and want to make more room, you can start by placing "j"unctions on the wires around the area you want to move. Then you can move the block, and afterwards straighten up the wires by "g"rabbing the junctions.

Improvement for KiCad:
Once a wire has become slanted (after a "g"rab action), it becomes hard to manipulate because, because the end points are ofthen the only parts which align on the grid.

A simple and usefull improvement would be that if a "j"unction is placed on such a wire that it snaps to the wire and the wire is cut into 2 wire segments. This makes it easier to repair these slanted wires and turn a single slanted wire into 2 orthogonal wires.

Simple test case:
1). Draw resistors with a wire between them:
2018-04-06T16-50-24_resistor
2). "g"rab a resistor and move so that the wire is exactly diagonal:
2018-04-06T16-52-59_diagonal
3). Place 2 junctions on the wire:
2018-04-06T16-54-03_junctons
4). "g"rab the junctions and drag to make them orthogonal again:
2018-04-06T16-55-27_Orthogonal

Being able to do this with wires on any angle would make it easier to clean up after a component with a lot of connections is moved.
Being able to do this without first placing junctions would make it still easier to do this.

With Kicad 4.0.7 when you put the mouse cursor on a junction and press [Del] you usually get a popup menu.
In the example above:

  • Clarify:
  • Horizontal wire.
  • Vertical wire.
  • Junction.

The Wires always (if not slanted) have other coordinates to selct them, but the junction has just one grid coordinate. Simply giving junctions (and other small objects) preference when deleting (moving, etc) makes schematic editing faster and more fun.

5 is still a release candidate. I think there’s still time for some minor tweaks to get in there before 6.
Even if it’s totally rewritten from scratch, I assume that they’ll be trying to maintain a lot of the same behaviours as is in 5 at the time they get there while fixing some places where they might have painted themselves into corners in the past. :wink:
I think there’s some value to users letting the devs know our perspectives on things regardless. It’s easy to get too close to your project and internalize workarounds and behaviours, at which point you can miss a lot of simple things that could be big improvements in usability.
Whether anyone will be focused on those kind of small fixes/tweaks is a different question, but I’d rather not assume there isn’t.

bobc:
Yes, I would assume (and hope) that they don’t plan on scrapping the UI entirely for a completely different model. Generally those kinds of things result in trading one set of problems for another.

I think “intuitive” is not entirely useless, though you’re probably right that a lot of people read it the same as “easy to use”, so maybe it doesn’t get the point across.

The main issue is “internal consistency”. A UI should work in ways that you would expect, based on the way other things in the UI work.
In this specific case (wires snapping to labels) they don’t.

All three of the left resistors were “g” moved down .1". The first is what happens if there’s a label on the line.
The 3rd is what happens if there’s any part on the line.
The middle one is what I think should happen. given how things behave elsewhere.

A harder example to screenshot is is you G a horizontal trace with a label on it, in which case the label does stick.

I think that this would be a relatively simple way of getting a consistent (intuitive) behaviour with no negative effects I can see.
Maybe someone can point one out that I’m missing?

IMO, longer term we should have some kind of 90 degree dog legging where instead of diagonal lines, you would get steps like near pin 5 on my example, but obviously this would require a lot more effort (dealing with intersecting corners, overlaps, etc).
But looking forward to the eventuality of that happening, I think we would still want that corner to happen such that it doglegs at “bar”, instead of at a random location which may or may not leave “foo” behind.

paulvdh: You’re entirely missing the point. I understand how to do all these things with blocks, g moves, etc. It’s exactly what I’ve been doing, while seeing a lot of places where things could be improved.
It shouldn’t require “tricks” to do things efficiently.

That would be a time saver, but it’s a little ugly.

An improvement on the idea would be if those junctions weren’t junctions, but simply nodes (without the dot which implies an intersection), and they be placed .050" horizontal from the pins on each component. Then they could still shoot a similar diagonal, but you would have a pair of points for your “step 4” without the dots. In implementation this would likely be better, since it could be implemented without a special case for diagonal vs horizontal. Horizontal “g” moves could still generate the nodes exactly the same way, and they would automatically vanish just like any other time you straighten out a trace.

I do fear that we’re drifting off of the topic again, though, which is specifically the behaviour regarding labels.
I don’t think that treating them like other symbols/pins messes with any of the other functionality discussed, and it should actually make some other improvements easier.

Any thoughts on that?

Drew up a quick example of my improvement of paulvdh’s idea, as it would look with my suggested label behaviour implemented first.
withnodes

I agree that breaking the wire in 2 wire segments (at the label attachment point) is an improvement.
It seems that the whole slanted wires and drag functionality was left at a “half developed” state at some point, while the main focus of the developer working on it was with another (hopefully more important) issue.
It is nearly impossible to attach labels, junctions or other stuff to the slanted lines because they do not align to the grid and this is another indication that this part simply was not worked out completely. You can not even "g"rab or [Del]ete it, except where it aligns perfectly with the grid.

My "J"unction dots example was more to indicate that it can now not be done without adding the junction dots manually. The "j"unction dots should not be inserted if there is just a bend in the wire. (My error here).
What do you think would be better? Adding the slanted wires, or putting the center part vertical (if it fits) like in this screenshot:
2018-04-07T02-51-12_Vertical
The wires above were hand drawn, not the result of a "g"rab.

Another indication that this slanted wire stuff was never properly finished is the over simplified way it works now. The algorithm is: “draw a straight line between start and end”. That is really all it is now. and it only works well if the wire was horizontal (or vertical) before and after the "g"rab. In the screenshot below I moved the left IC up a bit. The “logical” and “intuitive” way would be to make the vertical wires a bit shorter. Instead KiCad simply redraws the ripped up wire to the old point.
2018-04-07T02-52-32_Slanted

Adding some wire segments seems like a usefull improvement but it still is minor in the overal picture.
I think what happened is that the developers (mostly) stopped development on EEschem a few years ago, because it was in a “usable” state and started improving PCBnew instead. That is where a lot of development happened.

One of the simple things that Bugged me is that you can delete almost anything with [Del] in a schematic, but if you select a block, you can not delete it with [Del], but you have to use the [RMB] menu.

I think that these and a lot of other “small” things are known to the developers and they will be fixed when they have time for them. (V6 overhaul?). Priority now is of course getting V5 stable for Release.

Yeah, obviously the ideal would be to break it into vertical and horizontal segments, and move them in the way you’re describing but that would require writing the logic to space them appropriately so they don’t end up in a mess, and to collision detect, when you’re dragging one in such a way that it would hit another. Diptrace tries to do it this way but you’ll often get all of the corners in the same place and end up with something that looks like a grid or a vertical bus, until you straighten them out. They clearly haven’t done a 100% job on it either.

I guess it is still 1 less click per segment you fix, since you’re generally just horizontally dragging the vertical segment, instead of each of its corners, but the readability is pretty bad.

The diagonals (with .050" stub horizontals) would require a lot less code, and would be easier to read while you’re straightening them up. It’s not an ideal answer, but it would be a big improvement without massive rewrites.

Automatic adding of stubs in the same direction as the pin during a diagonal grab does seem an easy addition to speed up cleanup after such a move.

Adding those stubs could also speedup editing of this:

I also have some related ideas of how the drawing of wires can be improved to a more intuitive way.
A very simple example is that "m"ove for a wire segment is not implemented. (But "g"rab is).
Another simple example would be if [Del] on the coordinate of a Junction simply deletes the junction.
Other Ideas would take more effort to explain, and I don’t know if anyone is interested in listening.
Maybe redo this conversation after V5.0 is out.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.