EESCHEMA : ANOTHER DRAG ISSUES - not critical

Bug #1482111 reported by jbdw
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
KiCad
Fix Released
Wishlist
Unassigned

Bug Description

Platform : W10
BZR : 6032 build 9200 ( downloaded )
---

Found some issues regarding dragging :
- junction not autogenerated
- junction not autodeleted
- wires not auto merged
- connected component is dragged but the other wire ( s) is not dragged.

Explained in the attached pictures .

thanks n rgds / jbd

Tags: eeschema drag
Revision history for this message
jbdw (jbdwiyono) wrote :
Revision history for this message
jbdw (jbdwiyono) wrote :

Similar issue : junction is not autogenerated.

Revision history for this message
jbdw (jbdwiyono) wrote :

The next issue, junction is not autodeleted.

Revision history for this message
Benjamin Kohl (ben-819) wrote :

I would not call it an issue, maybe a missing feature.
I don't know if there was an version of kicad which had the functions you are describing.

Revision history for this message
Chris Pavlina (pavlina-chris) wrote :

Indeed, it's always been like this, unfortunately.

Changed in kicad:
importance: Undecided → Wishlist
Revision history for this message
jbdw (jbdwiyono) wrote :

@Benjamin Kohl :
It was there as well in the stable version BZR4022.

Benjamin Kohl (ben-819)
Changed in kicad:
importance: Wishlist → Low
Revision history for this message
Benjamin Kohl (ben-819) wrote :

I checked BZR4022 from 2013: It works like the current revision: It adds a junction only if a new wire starts or ends at another wire.
It does not add a junction when moving an existing wire close to another wire.
Junctions are not deleted by the program. The user must delete them manually.
Status "wishlist" was correct, sorry.

Application: KiCad
Version: (2013-07-07 BZR 4022)-stable
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Boost version: 1.53.0
Options: USE_PCBNEW_NANOMETRES=ON
         KICAD_GOST=OFF
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF

Changed in kicad:
importance: Low → Wishlist
Revision history for this message
nuess0r (nussgipfel) wrote :
Download full text (3.8 KiB)

Thank you jbdw for your detailed bug report.

I have the strong opinion that this behavior is a serious bug. To
say, that this is the behavior of KiCad for long time is no excuse and
I will explain why.

In short:

Draging something must not change the netlist.

Long explanation:

I work as a professional electronics engineer and did many PCB designs
from low to high complexity and I worked with 7 different PCB design
tools plus several simulation tools in the meantime. Unfortunately the
schematic editors are often a cause of design errors or just a PITA to
use on a daily basis. eeschem is already on the better side but still
has some quirks like this bug here.

I would like to argument, why this bug is serious:

1. CAD means computer aided design. Aides means for a very large part
to avoid errors, human errors or stuff that simply doesn't work.

Thats why we have ERC, DRC, rastnets, the new library system that
avoids reoccurring pinning errors, in/out/power pin functions of
symbols etc.

With the current behavior the risk of producing errors is very high.

2. It's an argument from the realm of clean code but fits well in this
discussion: A function should not have unintended side effects.

This means also that it should only do one thing and nothing else
beside that. Thats why I wrote the statement above that dragging
something must not change the netlist.

Thats what a user expects from this function. If he would like to
change the netlist he would use move or delete.

The situation in the picture KICAD - BUG REPORT - EESCHEMA -
SOME DRAG ISSUES 2.jpg is a tricky one.

The netlist is not changed but looking only shortly to this schematic
it looks like there is a connection. I see here two possibilities:
- Ask the user what he wants. Gives some problems several such
  situations occur at the same time.
- Shorten the net so that no conflict exists an the designer can see
  that there is no connection.

3. This argument comes more from my experience and also reading
discussions about programming language design.

A schematic is the most important documentation for a electronic
design. And like source code schematics are more often read than drawn.
So a schematic should be drawn in a way where it is easy to read and
understand.

As most of you know, when you beginn with a design and start to draw a
schematic it is unknown how stuff should be arranged to have a clean
and easy to understand schematic. So after a while you start to
rearrange stuff, replace wires with netlabels or the opposite, move
parts to another schematic sheet, changing names of nets and so on. In
software development you would call that refactoring.

As explained above a CAD tool should give you aides for that.

The current dragging behavior does the complete opposite. Because it
COULD introduce errors SOMEWHERE in your schematic when you rearrange a
group of symbols and there corresponding nets you simply do not
rearrange stuff and you live on with a unreadable but working schematic.

It gets even worse with Open Hardware where one of our goals is that
people reuse our designs and parts of our schematics. Then I create
some kind of collage of different schematics and have t...

Read more...

Revision history for this message
KiCad Janitor (kicad-janitor) wrote :

Fixed in revision 069448f20ee7954953a95c9e8758e9bc3a42a9c1
https://git.launchpad.net/kicad/patch/?id=069448f20ee7954953a95c9e8758e9bc3a42a9c1

Changed in kicad:
status: New → Fix Committed
Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.